Monday, July 13, 2009

One Year After Terry Childs' Arrest, IPSec VPN Security

He's still in jail, actually, going through a number of hearings. There have been a good number of analyses about the topic, particularly on Paul Venezia's blog and some of the links from it, so I won't reanalyze it here. But I am reminded of a huge security mistake that the prosecution had made, yet I feel very few people realized the implications.
Just prior to Childs' arrest, I had been working on implementing an IPSec VPN that would work with the built-in firmware VPN client on Sun Rays. This meant all the settings had to be compatible with Cisco EasyVPN (doing so was harder than it sounds). Since IPSec is so complicated, I'd been doing a lot of research on the topic at the time. When news broke that the prosecution had entered a list of VPN passwords Childs had kept into public evidence, I had an understanding of what exactly those passwords were for. Those passwords were what are known as "pre-shared keys." If you want to set up a Cisco IPSec VPN, both sides of the connection need to have a shared secret string. These were the passwords that the prosecution had supposed were other users' personal passwords that Childs was keeping so he could impersonate them. But as a systems administrator, I knew that knowing these passwords were essential to properly configuring Cisco IPSec VPN devices. In addition, these keys encrypt the user-specific password that gets passed over the network. You see, for Cisco IPSec VPN clients, you need two passwords: the pre-shared key, which only the administrator and VPN program are supposed to know (but is easily decrypted for human consumption), and the user's personal password. The former is used to encrypt the latter. After both passwords are accepted, additional encryption is negotiated.
What this means is anyone with the shared secret key is able to obtain the user-specific password if they have a network dump of the VPN traffic while logging on to the server. Where I implemented the VPN, I was able to mitigate this risk by assigning each user a unique key, but in most legacy Cisco deployments, everyone has the same key. That these keys were posted online meant that during the time between the document becoming public record and when the city of San Francisco IT realized that the VPN server was insecure, hackers may have been able to extract users' passwords. Based on news sources, though, it seems San Francisco was lucky enough to have avoided that consequence.

No comments:

Post a Comment