Official response hides fact OpenVPN CA keys also leaked, so attacker could impersonate any other NordVPN server: https://gist.githubusercontent.com/Snawoot/85f77356e229d77aa...
RADIUS secret key also leaked, so propably it is possible to break into EAP session which infers session secret key for StrongSwan.
Could you elaborate on this? I am familiar with PKI so the first part makes sense, but I am not familiar with the intricacies of VPNs so I am not sure what this means.
Some EAP authentication methods (namely, EAP-MSCHAPv2 and EAP-TLS) export Master Session Key, which is exported to StrongSwan via MS-MPPE-Send-Key/MS-MPPE-Recv-Key EAP attributes. [2] So, MSK derived on RADIUS side and sent to StrongSwan. Eavesdropper with knowledge of RADIUS secret key capable to intercept and decrypt such EAP payload.
[1] - https://wiki.strongswan.org/projects/strongswan/wiki/EAPRadi...
Assuming their IPsec was enabled with it (and OpenVPN should be enabled by default), them leaking their keys does not matter. The sessions can not be decrypted even if the master key is leaked.
TLS also has perfect forward secrecy by default.
Impersonation is an issue, but the article stated the CA keys have already been rotated and are out of date.
EDIT: I meant to reply to the post below me, but this is fine. Sorry about that!
They were not rotated back then in 2018, so we can only guess if MITM had place. Their line of defence appealing to keys which are NOW outdated is just ridiculous.
> Read up on "Perfect forward secrecy": https://en.wikipedia.org/wiki/Forward_secrecy
> The sessions can not be decrypted even if the master key is leaked.
It's not true. PFS provides cryptographic isolation between long-term keys and session key used to encrypt data. Obviously, if MSK compromised it is irrevelant, how it was inferred: with PFS or not.
MITM could have taken place anyway because the attacker was on the machines. They did not need the key.
> It's not true. PFS provides cryptographic isolation between long-term keys and session key used to encrypt data. Obviously, if MSK compromised it is irrevelant, how it was inferred: with PFS or not.
PFS implementations have the session key rotated automatically in software and dependent on the implementation multiple session keys are in use at any given time dependent on flow. The PFS session key would also be different for every VPN server in the NordVPN environment. The only possible way to compromise a session on another VPN node (that was not compromised itself) would have been to intercept it at the time of the session being created and MITM by injecting your own PFS session key.
That is why it is called "Forward secrecy": the session can not be decrypted in the future, only in the present.
Unless your assumption is that this is a state actor with the ability to MITM connections in the first place, or a rogue ISP BGP hijacking that would have been obviously seen on something like BGPStream [https://bgpstream.com/], it is safe to say that no other VPN node's traffic was compromised. Only traffic on this single host in this single location.
More reading: https://www.speaknetworks.com/what-is-ipsec-vpn-pfs-perfect-... (Step 5)
"Instead of making use of the DH Keys Calculated during Phase-1, PFS forces DH-Key calculation during Phase-2 Setup as well as Phase-2 periodic Rekey. The PFS ensures that the same key will not be generated and used again."
OpenVPN (using TLS) also uses PFS by default. There is a reason it is called "Perfect."
EDIT: PFS is commonly also implemented by Diffie-Hellmen (DHE) key exchange: https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange
EDIT 2: I am not defending them as well. I just believe extrapolating the technical details is fear mongering at best. Believe it is best to focus on the facts as it makes for a stronger argument.
There are two distinct severe security issues. First one is leaked CA key, which allows to certify any key as a valid key for NordVPN server certificate key. I think it is not necessary to argue about this: traffic decryption to any Nord OpenVPN server became simple as network MITM. Not likely a state-level BGP hijack, but local attack targeting channel of small group of users. Anyway, we do not have cryptographical guarantees since this point.
Second issue is leaked RADIUS key. Why it is a problem for encryption? Because EAP authentication and key derivation runs between VPN client and RADIUS, and VPN server receives derived keys as attributes of EAP message: https://wiki.strongswan.org/projects/strongswan/wiki/EAPRadi...
> The eap-radius plugin does not implement an EAP method directly, but it redirects the EAP conversation with a client to a RADIUS backend server. On the gateway, the EAP packets get extracted from the IKE messages and encapsulated into the RADIUS protocol, and vice versa. The gateway itself does not need special support for a specific EAP method, as it handles the EAP conversation between the client and the RADIUS backend more or less transparently.
> For EAP methods providing an MSK, the RADIUS server must include the key within the MPPE-Send/Receive Keys; Unfortunately, FreeRADIUS before 2.1.10 did not include these attributes when used with EAP-MSCHAPv2.
So, despite session encryption key is not bound directly to long-term secrets which server possesses, they can be extracted from communication between StrongSwan and RADIUS server.
PFS has nothing to do with all of it. In first case it is possible to issue VALID certificate for eavesdrop VPN server and redirect users traffic to it. In second case MSK probably can be extracted communication between VPN server and RADIUS server (I can't say if it will require MITM of RADIUS session or it is possible to decrypt EAP payload with passive sniffing and posession of RADIUS secret key).
Basically:
1- Nord falsely blames its server provider.
2- Nord hides it from their users.
3- Nord claims all will be well with an “audit” (again, since they were already “audited”)
This is either criminal negligence, “security theater”, or both.
I don't see anything in the article about those claims being false. Where did you get that?
I believe that would be the section they're referencing.
They are casting blame on the provider. Providing remote access tools is not a fault. Failure by NordVPN to disable said access is the issue, yet they passed the blame on.
It's a bad look in any case.
That seems to be ExpressVPN[1], the main competitor of NordVPN.
[1] https://vpnscam.com/expressvpn-really-based-in-hong-kong/
If they have EU customers then article 33 of GDPR should see to that.
"In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay."
Unless the authorities in EU accept the explanation they are in trouble, but I think you shall report even if you think there has been a breach.
Does this always/necessarily lead to customers/the public being informed? But yeah, better than nothing.
So instead of allowing their customers to do their own damage limitation, they left their customers in the dark and continued to expose them to a breach they weren't sure they had fully contained.
I wonder when that sort of thing will become a criminal offence.