6 ms·

Sorry for posting under top comment, but I think it is very important. Official response hides fact OpenVPN CA keys also leaked, so attacker could impersonate

Sorry for posting under top comment, but I think it is very important. Official response hides fact OpenVPN CA keys also leaked, so attacker could impersonate any other NordVPN server: https://gist.githubusercontent.com/Snawoot/85f77356e229d77aa36f16059a629eea/raw/e4e4af26e4c411d32bbc6bd3ba26301c2ae074bd/nordvpn.txt 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.

panarky 7y ago
Also allowing historical sessions to be decrypted.
- rasengan 7y ago
  Also looks like NordVPN has been misleading customers about the number of servers they have (or didn't make clear they were VM/containers).
  - dx034 7y ago
    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.
- kzrdude 7y ago
  Who has logs of full historical sessions, and the tools to decrypt them? NSA?
  - Forbo 7y ago
    Yeah, as far as I understand that's pretty much the purpose of the Utah datacenter.
deleted 7y ago
[deleted]
chelmzy 7y ago
What is the source of the gist you linked?
- Snawoot 7y ago
  It is copy of snippet linked from 8ch.net: https://web.archive.org/web/20180504001844/https://8ch.net/b/res/7948898.html#7950919 https://web.archive.org/web/20180504001844/https://8ch.net/b...
  - blaser-waffle 7y ago
    Hasn't that site been down for weeks now?
    - Snawoot 7y ago
      It's a snapshot of thread dated by May 3, 2018. Info leaked long time ago, but became sensation just recently.
xvector 7y ago
> 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.
- Snawoot 7y ago
  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. [1] - https://wiki.strongswan.org/projects/strongswan/wiki/EAPRadius#EAP-Radius https://wiki.strongswan.org/projects/strongswan/wiki/EAPRadi... [2] - https://tools.ietf.org/html/rfc5216#section-2.3 https://tools.ietf.org/html/rfc5216#section-2.3
iscoelho 7y ago
Read up on "Perfect forward secrecy": https://en.wikipedia.org/wiki/Forward_secrecy https://en.wikipedia.org/wiki/Forward_secrecy 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!
- Snawoot 7y ago
  > 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. > Read up on "Perfect forward secrecy": https://en.wikipedia.org/wiki/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.
  - iscoelho 7y ago
    > 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/ 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-forward-secrecy/ 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 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.

panarky 7y ago

Also allowing historical sessions to be decrypted.

rasengan 7y ago
Also looks like NordVPN has been misleading customers about the number of servers they have (or didn't make clear they were VM/containers).
- dx034 7y ago
  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.
kzrdude 7y ago
Who has logs of full historical sessions, and the tools to decrypt them? NSA?
- Forbo 7y ago
  Yeah, as far as I understand that's pretty much the purpose of the Utah datacenter.

deleted 7y ago

[deleted]

chelmzy 7y ago

What is the source of the gist you linked?

Snawoot 7y ago
It is copy of snippet linked from 8ch.net: https://web.archive.org/web/20180504001844/https://8ch.net/b/res/7948898.html#7950919 https://web.archive.org/web/20180504001844/https://8ch.net/b...
- blaser-waffle 7y ago
  Hasn't that site been down for weeks now?
  - Snawoot 7y ago
    It's a snapshot of thread dated by May 3, 2018. Info leaked long time ago, but became sensation just recently.

xvector 7y ago

> 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.

Snawoot 7y ago
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. [1] - https://wiki.strongswan.org/projects/strongswan/wiki/EAPRadius#EAP-Radius https://wiki.strongswan.org/projects/strongswan/wiki/EAPRadi... [2] - https://tools.ietf.org/html/rfc5216#section-2.3 https://tools.ietf.org/html/rfc5216#section-2.3

iscoelho 7y ago

Read up on "Perfect forward secrecy": https://en.wikipedia.org/wiki/Forward_secrecy https://en.wikipedia.org/wiki/Forward_secrecy 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!

Snawoot 7y ago
> 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. > Read up on "Perfect forward secrecy": https://en.wikipedia.org/wiki/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.
- iscoelho 7y ago
  > 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/ 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-forward-secrecy/ 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 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.