>NordVPN said it found out about the breach a “few months ago,” but the spokesperson said the breach was not disclosed until today because the company wanted to be “100% sure that each component within our infrastructure is secure.”
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.
I don't think they ever wrote anywhere that they have 6,000+ physical servers. Calling a VM (like an EC2 instance) a server is not unusual. For the customers it was important that the resources, bandwidth and different IPs were available. For that it doesn't matter if it's a physical server.
> 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.
When StrongSwan EAP-RADIUS plugin is in use, authentication delegated to RADIUS server. Actual EAP handshake occurs between VPN client and RADIUS server. [1]
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.
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!
> Impersonation is an issue, but the article stated the CA keys have already been rotated and are out of date.
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.
> 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.
> 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.
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.
"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 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.
I've lost track of discussion and maybe some misunderstanding takes place, but I'll attempt to synchronize.
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).
i find it surprising that none of the threads in this topic mention the very serious threat this breach might have for users in countries like china. the fact that nordvpn neglected to tell its users for months after the breach quite possibly endangered people's lives. unforgivable.
From the article:
"“One of the data centers in Finland we are renting our
servers from was accessed with no authorization,” said
NordVPN spokesperson Laura Tyrell."
I believe that would be the section they're referencing.
“We failed by contracting an unreliable server provider...”
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.
Within 72 hours According to GDPR I thought?
“ The GDPR introduces a duty on all organisations to report certain types of personal data breach to the relevant supervisory authority. You must do this within 72 hours of becoming aware of the breach, where feasible.”
https://ico.org.uk/for-organisations/guide-to-data-protectio...
The tinfoil hat would argue maybe this was a leak that happened, but it was shared by design. It’s an HK company with questionable relationships and owners.
> I wonder when that sort of thing will become a criminal offence.
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.
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.