Today, Laura Poitras and Jake Appelbaum spoke at the 31C3 conference and in collaboration with Der Spiegel published an interesting article on VPN exploitation by the NSA.
The “TL;DR” summary of what follows below is: If you configure your IPsec based VPN properly, you are not affected. Always use Perfect Forward Secrecy (“pfs=yes” wich is the default in libreswan IPsec) and avoid PreSharedKeys (authby=secret which is not the default in libreswan IPsec). If you really need to use PSK, use a strong shared secret that cannot be brute forced. The NSA has their own version of IKEcrack running on millions of dollars worth of CPU’s. Also, the NSA sneaks into your router to steal your PSK’s so they can decrypt all your traffic.
Update 1: from media-35513.pdf (“TURMOIL/APEX/APEX High Level Description Document”):
CES generally requires the packets from both sides of an IKE exchange and knowledge of the associated pre-shared key (PSK) in order to have a chance of recovering a key for the corresponding cipher (ESP). A major goal of APEX is to access two sides of key exchanges of traffic of interest”
Update 2: To stop the NSA HappyDance, I just commited code to libreswan IPsec to warn about weak PSKs with a message notifying the sysadmin that as of July 1st, 2015, libreswan will refuse those weak PSKs. To determine the strength of the PSK, I used the Shannon Entropy value. If the PSK has a Shannon Entropy of less than 3.5, a warning will sound and in 6 months it will refuse to use that PSK.
Update 3: Just to make it clear – To break IKE PSKs, you first need to break the initial DiffieHellman exchange, which is usually MODP1024 or MODP1536 in the bad cases (and MODP2048+ in the good cases). The exception to this is IKEv1 Aggressive Mode, where the MAC computed with the PSK as secret key is sent
in the clear. As a result one can mount an offline dictionary attack.
IPsec is not IKE
First, let’s clarify things a little bit. Although everyone is talking about breaking IPsec, what they really mean is breaking the Internet Key Exchange (IKE) that is used to negotiate and create symmetric keys that are used with IPsec for encryption and decryption. IPsec itself can use various ciphers and algorithms. It can use a separate encryption (AES, CAMELLIA, SERPENT, TWOFISH, 3DES, etc) + integrity (SHA2, SHA1, AES_XCBC, MD5, etc) mode or it can use an AEAD cipher that combines these two into one (AES GCM, AES CCM, CAMELLIA GCM, etc)
But Jake said to stop using IPsec
None of what was said by Jake or published by Der Spiegel shows any attack on these ciphers or algorithms. Even the MD5 use within IPsec (HMAC-MD5) is not as weak as people usually believe it to be by confusing it with non-hmac use of MD5. The comments Jake made and the material in the published slides show attacks against weak IKE configurations, router compromises, and possibly against some IPsec hardware accelerators. Below are my comments on those slides that are interesting in the context of IKE and IPsec.
The focus of the VPN decryption team lies with IPsec and SSH. I think that fits the deployment. These two protocols are the most widely used encryption protocols to transfer bulk data. While the hacker community might focus on OpenVPN, that’s not where the real deployment is. The mention of PPTP is curious. From what I see, PPTP is basically dead as a VPN technology, although it is still widely used in Russia as an encapsulation technique for ISPs to connect endusers. It’s probably just listed there for intercept because it is so trivial to do, you might as well gather it.
This slide is harder to make sense of. I think that here the NSA is talking about IKE and IPsec combined, although they call it IPsec. Perhaps once they decrypt traffic, it goes into XKEYSCORE? They don’t seem to use XKEYSCORE as an input to crack the IKE PSKs? I’m amused by the name VULCAN-DEATHGRIP which might indicate that the HiFN (now Exar) Vulcan IPsec accelerator card might have a flaw in it that allows them to decrypt those IPsec VPNs. Also, I hope they properly mask their perl scripts for malicious decrypted traffic :P
This is probably the most interesting slide. It basically states that IPsec VPNs are compromised by router compromises that steal the IKE PSKs. This might be a good time to upgrade your router firmware to the latest version, and change to new strong PSKs (or switch it over to RSA 2048+ instead)
The AppID refers to the XKEYSCORE signature name. I’m glad to see that IKEv2 is finally catching on, even within the NSA :)
This slide is mentioning IPsec scripts, which might refer back to the previously mentioned genericIPSec_wrapper.pl script. This clearly indicates an IKE PSK brute force decrypting engine. If you are using weak PSKs, the NSA is decrypting your IKE traffic which will give them the keys to decrypt your IPsec traffic. Enabling PFS will help you a bit, but ultimtely you should really just switch to using RSA (or ECP) authentication and skip PSK’s alltogether. Note that the FIPS standard already disallows using PSK’s for IKE/IPsec. The NSA knows it is just too dangerous and weak.
Note to the NSA, please see RFC 4301 Section 1.1 which states:
The spelling “IPsec” is preferred and used throughout this and all related IPsec standards. All other capitalizations of IPsec (e.g., IPSEC, IPSec, ipsec) are deprecated.
On slide 31 it states: IPSec: 6640 (protocols) and 6648 (ports)
I don’t know what that refers to. Possible backhaul transport ports or part of an API port ?
On slide 33 it states: Need all the pieces (IKE and ESP for IPSec)
This really shows that the NSA is breaking IPsec by breaking IKE, which mostly seems to come down to weak PSKs and no PFS. And again, in case you still did not get it on slide 39:
“TAO got the configuration files which provided us the PSKs to enable passive exploitation”
So your IPsec VPN is getting owned because your VPN gateway got owned! Run your VPN on a dedicated machine, preferably opensource, and lock remote access via ssh down using strong keys and IP filtering.
And the last interesting nugget is on page 40:
“NSP had an implant which allows passive exploitation with just ESP”.
I read this to mean that the hardware or software of the system running IPsec was compromised, causing it to send valid protocol ESP packets, but creating those in such a way that these could be decrypted without knowing the ESP session keys (from IKE). Possibly by subverting the hardware number generator, or functions related to IV / ICV’s / nonces that would appear to be random but were not. Or less likely if the hardware/software was using padding bytes to reveal decryption keys.
Conclusion
If anything, I would say that IPsec and IKE have withstood the attacks of the NSA. The fact that the NSA needs implants and needs to use brutce force attacks against IKE PSKs shows that despite its kitchen sink nature, IKE and IPsec are doing quite well if you configure it properly and run it on a secure host. But misconfiguration of IKE is something we did a poor job of preventing. We can and should have more automatic IKE/IPsec deployed using strong default configurations.
And you should hear back from The Libreswan Team in the next two months regarding just that. Opportunistic Encryption: Round Two
> I’m not sure what the “AppID” refers to.
From the releases of the XKEYSCORE sample script & web UI from some time ago it seem that they are they identifier used for protocols filtering both in their web query interface and when they write scripts to filter through raw data.
See AppID like the filters on a NextGen FW ;)
Good analysis. That was exactly my understanding of the slides. In fact it makes me feel rather good that there is nothing “more secret” hidden (like they actually demand in the slides). It is a bit shocking to see how easy and long it is possible to hack into bank routers and systems.
Pingback: Latest Snowden Revelations Expose Scope Of NSA Interceptions | TechCrunch
I wish I was so confident about what they mean by “passive”. A PSK from the configuration should only allow them to MitM the IKE, in which case calling it “passive” is disingenuous. Not that the NSA would ever be disingenuous…
Perhaps the name “Vulcan-Deathgrip” means that it’s something that doesn’t exist and claims of its existence are just there to trick the enemy? No? I guess I wouldn’t count on that either.
My interpretation of “passive” is “just by sniffing IKE”. So this would mean sending the IKE traffic via (SCARLETFEVER / LONGHAUL ?) to Ford Meade or ORNL for brute forcing. You are right that I think submitting VPN endpoints might mean they will try an active attack on the endpoint to gain the PSKs from the config file though.
Brute forcing IKE means breaking Diffie-Hellman. I’m sure the infamous “Group 2” with 1024-bit is still very common, but I don’t believe even the NSA has the resources to brute-foce group 2 en masse.
Yoav: While I agree with you, I do wonder about them backhauling all IKE and having an API to signify they can retrieve the key. I doubt that is all based on only router compromises ……
They are most certainly doing some kind of crypto attack on VPN! You can tell because many of the documents state that the “PIQ Blade” must remain within the “CES enclave” (i.e. keep our crypto tech secret!). CES by the way are the NSA crypto attack group. From the PIQ blade the IKE Messages and ESP Key Req/Res go to CES, then to POISON NUT Attack Orchestrator (AO), and from there the “Cryptovariables” go to CORAL REEF and the rest to “HPC Resources” which I assume is High Power Computing (source: media-35526.pdf). See also media-35527.pdf — “the classification should be TS//SI//ORCON//REL since CES deals with exploitation”. “DNC Protocols: IPsec – ISAKMP, IKE, ESP, AH .. PPTP .. HOOKED – HOOKED HAND is a DNC protocol used in a commercial DNC product. .. DNSC”. And “(TS//SI//ORCON//REL) ..(the KEYCARD tasking action is labeled ‘TRANSFORM’ so as not to use the term ‘decrypt’) — they don’t even want their allies to know that they can break the encryption. “..If KEYCARD returns a hit for an IKE packet, then the IKE packet is sent to POISONNUT (DNC Attack Orchestration) Service. A POISONNUT response message will either return the key or indicate that a key could not be recovered.” “..If KEYCARD returns a hit for an ESP packet, a key request is sent to LONGHAUL.” Note the use of the word “recover”. See also media-35529.pdf — “Exploited Protocols: The VPN capability exploits the following key management protocols: ISAKMP ..(RFC2407, RFC2408) .. IKE..(RC2409) — The VPN capability exploits the following security protocol: ESP..(RFC2406)”. It does say that “Spin 9 VPN .. will not process IKEv2 (RFC4306)” however it appears that “Spin 9” is a really outdated version of the program. See also media-35532.pdf — “For the past decade, NSA has led an aggressive, multi-pronged effort to break widely used Internet encryption technologies” .. “Cryptanalytic capabilities are now coming on line” .. “Vast amounts of encrypted Internet data which have up till now been discarded are now exploitable.” .. “(TS S1 COMINT) Capabilities against the encryption used in [VPNs, IPSEC, TLS/SSL, HTTPS, SSH, PPTP..]”. Starting to sound more like a crypto attack?
Here are a few notes . . .
— I believe the 6640, 6648 etc. “Categories” numbers are showing what fields are required when creating an entry in the CADENCE system. CADENCE tracks “sustained exploitation” so once a VPN is exploited and confirmed to be of value, they will capture and decrypt all of its traffic. In order to manage resources they use CADENCE to keep track of each VPN, who requested it be captured/decrypted, endpoint IP(s), the type of encryption and/or ports etc. I believe page 31 is saying that for an IPSec VPN they want to record into CADENCE the protocols and ports, whereas for PPTP and SSL they only want to record the ports. Then the UTT (Unified Targeting Tool) would keep track of who they are actually targeting plus the associated CADENCE entry. So many different targets could all be connected to the same CADENCE entry if they all used the same VPN.
— What they mean by “passive” is that they can decrypt captured traffic using only the PSK! See media-35513.pdf where it says “The capability to decrypt selected IPSEC/ESP streams is built into TURMOIL, as is the capability to route back to CES the IPSEC key exchanges necessary to recover selected keys.” Also, “CES generally requires the packets from both sides of an IKE exchanges and knowledge of the associated pre-shared key (PSK) in order to have a chance of recovering a key for the corresponding cipher (ESP).” You might also be able to make more sense out of the file media-35551.pdf.
— Regarding slide 15, you are correct that traffic is decrypted and then put into the XKEYSCORE database. That is because the analysts use XKEYSCORE to do all of their work (search through large volumes of data).
— NSA parses router configs from full-take network captures using XKEYSCORE. Ever emailed a router config to yourself? Or used Telnet? Your config is now in DISCOROUTE. If they don’t have a config file for the router they want to access, they use QUANTUMINSERT to gain access to the admin’s computer and either find a copy of the config file or install a keylogger and wait for the admin to login to the router. Or they might just steal the admins SSH key and then they can “passively” decrypt their SSH traffic.
You should download all of these Der Spiegel documents from Cryptome, read them, then go back and read the “I Hunt Sys Admins” document on The Intercept. It will all come together. It is probably why the NSA’s own guidelines for securing Cisco routers state to only configure out-of-band management! All of this hacking is only possible because admins use the same machine to access facebook/gmail/linkedin as they use to configure routers. See also the end of the I Hunt Sys Admins document where they hint that a savvy sys admin could watch and compare the hash of their router IOS and detect if it’s been modified.
Hi there,
On hacker10.com i read that there is a document that have a list of 200VPN’s.
http://www.hacker10.com/internet-anonymity/secret-documents-show-the-nsa-is-spying-on-vpn-users/comment-page-1/#comment-33082
This is from that page.
Recently released Snowden’s NSA documents published by the German magazine Spiegel reveal the NSA has a dedicated team to crack VPN traffic and feed it to their data mining software. The documents list over 200 commercial VPN providers, like Astrill, CyberGhostVPN, iPredator and PrivateInternetAccess (PIA), they include companies that no longer exist like Xerobank and also name small VPN providers.
I downloaded al the documents about VPN’s but don’t see any names.
Do i miss something?
These are listed in
In what?
it’s a normal vpn provider list !!!
its not a list from providers that are hacked from the nsa!!!
Its a normal provider list