Independent Evaluation of VPN Systems

1. Independent Evaluation of VPN Systems Rob “Shoten” Shein Shoten@hushmail.com and Drew “Ender” Miller Res06chh@verizon.net

2. Agenda • Point of this whole concept • Issues, benefits and challenges of VPN use from the organizational perspective • Challenges and methods of VPN development from a code/packet perspective • A look at a “theoretical” (because we’re not allowed to tell you which VPN it is yet) VPN system that is vulnerable

3. Why do it? • Once upon a time, firewalls were seen by clients as the magic bullet • Invulnerable • Perfect • All they needed for security • Now, we know that there are good and bad firewalls, but only because others have shown the flaws in the bad ones

4. Why do it? • VPNs are the new “Emperor’s Haberdasher” • Maybe the Emperor really does have some new clothes • Then again, maybe he’s butt-ass naked • Someone needs to look and see if we can get a glimpse of the “crown jewels” • That someone is us

5. Why Do it? • After all, who else is going to do it? • …the people who make the VPN? • …the client who doesn’t know what a Diffie-Hellman exchange is, or how important really random numbers are in crypto? • People without any vested interest one way or the other make the best watchdogs

6. Basics of VPNs • Encrypt all traffic or just specified kinds of traffic • Between two points or two entire networks • Hardware or software • Various levels of encryption, based upon export restrictions

7. Benefits of VPNs • Secure and rich communications between multiple offices of a company • Cheaper network access for remote users • Full network access for telecommuters without opening the network to the world

8. Challenges • Speed • Uptime • Connection recovery • Scalability of traffic and users • Interoperability issues with global deployments • Crypto export restrictions • User management, support, and client deployment

9. Risks of VPNs • Since VPNs work across public networks, they must be publicly addressable • VPN gateways for entire networks that connect only to other entire trusted networks can be hidden with firewall rules • All other VPN gateways must be visible to anyone, even the script kiddie sitting in the third row right over there

10. Risks of VPNs • Placement on the network is an issue • Put it in front of the firewall and it can be attacked more easily • Put it on the DMZ and you have unencrypted traffic passing across a network that should not be trusted • Put it on the back network and you hazard your back-end systems • Put it on the firewall, and: • Your firewall is now publicly addressable • You may suffer major performance hits on all internet traffic (encrypted or not) due to massive overhead from the VPN

11. How to Bake a VPN • Ingredients: • Crypto • Authentication controls • Rules defining what will and won’t be sent over the connection

12. Ingredient One: Crypto • The challenge: how do you give a secret to someone you trust, using a form of communication you can’t trust? • Public Key algorithms are too slow and processor-intensive for use in VPN connections, so you have to use Symmetric (shared secret) encryption • But how do you get the shared secret from one end to the other across an untrusted network? • Diffie-Hellman is the solution

13. Diffie-Hellman In a Nutshell • RFC 2631 • There are two parties, Dick and Jane, who need to derive a shared secret without passing anything across the network that can enable a third party to derive or learn that shared secret • Dick and Jane both create a key pair, one public and one private

14. Diffie-Hellman In a Nutshell • Dick sends his public key to Jane and Jane sends her public key to Dick • Dick encrypts Jane’s public key with his private key, and Jane encrypts Dick’s public key with her private key • Both encryption actions result in the same thing, ergo Dick and Jane now both have a shared secret

15. Diffie-Hellman In a Nutshell • This algorithm requires random numbers for key pair generation so that nobody can guess at either key pair • This is the potential weakness of a Diffie-Hellman implementation • (Remember this point, it will come up later)

16. Diffie-Hellman: The Math • Shared Secret =(J_KeyPublic ^ D_KeyPrivate) mod p =(D_KeyPublic ^ J_KeyPrivate) mod p • Public Key = g ^ KeyPrivate mod p, where • g = h ^ {(p – 1)/q} mod p, where • 1 < h < (p – 1) such that h{(p – 1)/q} mod p > 1 • g ^ q mod p = 1 unless g=1 • p is a large prime number • h is a random integer and source of entropy

17. Ingredient One: Crypto (Does Your VPN Protect Dick?) • Ok, so now you have the ability to do Symmetric cryptography, so now what? • What algorithm do you want to use? • The current choice is usually Triple-DES, with an effective key size of 56*3=168 bits • Some systems (like ISS RealSecure IDS systems and the Palm VII) use Elliptical Curve crypto • Strong crypto requires key escrow, or cannot be exported at all

18. Ingredient One: Crypto (Does Your VPN Protect Dick?) • We will be assuming use of Triple-DES for the purposes of this presentation • We will also assume that Triple-DES is properly implemented

19. Ingredient Two: Authentication (Does Your VPN Know Dick?) • How do you know that the person trying to connect should be granted access? • Do you check who they are before or after you establish encryption with them? • If before, how do you protect against sniffing attacks? • If after, how the hell do you open a session in the first place without letting anyone in?

20. Ingredient Two: Authentication (Does Your VPN Know Dick?) • Solutions: • Variants of CHAP • Kerberos • Signing using PKI • Keep a copy of a public key for each user at the gateway, and the client maintains the corresponding private key • A challenge is sent to the client at logon time, which the client signs with the user’s private key. The gateway can then verify that the client is in possession of the correct private key, and therefore must be a valid user.

21. Ingredient Three: Rulebase (Does Your VPN Allow Dick?) • What does and doesn’t get encrypted? • If this is wrong: • Privileged traffic will potentially be sent in the clear • The VPN will interfere with non-privileged communications by attempting to establish VPN sessions to sites/hosts that do not have the capability to participate in a session • The rulebase often defines what strength of encryption to use; this is for interoperability with foreign implementations

22. What Was the Point of All That? • Now, we know where to hit the VPN • Ingredient One: • Attack key exchange for session establishment • Look for weak entropy (seeding from the system clock, anyone?)

23. What Was the Point of All That? • Ingredient Two: • Get a VPN client and attempt authentication • See if you can get any kind of session at all

24. What Was the Point of All That? • Ingredient Three • See if the rulebase can be subverted, to force encryption to a weaker level • Remember, VPNs are publicly addressable…try overflows

25. Case Study: A VPN That Doesn’t Protect Dick • Imagine (heh) a theoretical (heh heh) software-based VPN • We will walk through a validation and verification of this VPN system that did not require having access to source code or information more detailed than that available on the install CD

26. Case Study: A VPN That Doesn’t Protect Dick • Ok, it’s not theoretical at all…but we can’t tell you which one it is yet, because it has been implemented somewhat widely and there are still a lot of unpatched systems • We cannot disclose who makes it, what it’s called, nor who is using it • Don’t ask, please • No, we are NOT feds, so don’t try to spot us

27. First Step: RTFM • We examined all publicly available documentation, including PDF files located on the install disk. The goal was to find hints as to what might not be so secure • We hit something straight off: the reason this product is exportable with strong crypto

28. First Problem • The product has a mechanism for re-creation of session keys after the fact. This is to enable decryption of captured sessions by law enforcement and other governmental <cough> authorities • The product has an exemption because of this, rendering it exportable with Triple-DES but no key escrow

29. First Problem • All session keys are based upon one shared secret between client and gateway; compromise this, and you can generate session keys at will • The real problem is that from a business standpoint, it actually makes sense to do this • Otherwise, the product would be harder to sell, thanks to export controls

30. Second Step: Installation • We set up a small lab, with a single gateway and a set of clients • We then proceeded to perform network connections and sniff the traffic, looking for data formats that can be identified and decoded • Possible attacks against data: • Tests for sufficient entropy in encrypted data • Identification of vulnerable data before the session is fully established • Identification of standard data format so that buffer overflow attacks can be tried

31. Anatomy of the Session • Entirely TCP-based; no UDP or ICMP • Based on HTTP • Data between gateway and client is sent as specialized GET methods, with “Pragma: no-cache” to prevent caching by cache proxies • A great deal of care was taken to ensure that this will work in proxy-based networks

32. Session Establishment Sequence • Time request from client to gateway (for synchronization purposes) • Time response from gateway to client • Then, “Packet X” from client to gateway

33. Packet Capture: Packet X • This is the critical packet. It contains a set of information that is used to generate the session key. • Passes from client to gateway in TCP • This packet contains the user name, the client software version, plus two fields of additional data that originally were a mystery

34. Packet X Dissection • Packet X Dump • Packet X Decode Only • Packet X, With Fields Separated

35. Packet X Anatomy • Expected HTTP GET action, plus two fields • All fields are delimited • Two fields are not binary • The namespace of the two fields is all upper and lowercase letters, plus numbers, plus the “+” and “/” symbols • The fields stay pretty constant in size, padded with the “=“ character • Can anyone guess what this is? • Hint: there are 64 characters in the namespace

36. Packet X Anatomy • The two fields are Base-64 encoded • One is part of a public key • The other is the random number used to generate the session key

37. Problem Two • That’s right…the source of entropy passes across the wire in the clear from the client to the gateway • That’s also right…the client (probably a Win98 box) is the source of the random number • Not a very good source of entropy, not that you need to worry when you can sniff the number outright

38. Next Step: Attack Packet X • Now we know how this system works to some degree at the packet level • Let’s try buffer overflows and invalid data in various data fields

39. Problem Three • Guess what? • No, really…guess! • Wow, good guess!

40. Problem Three: The Gory Details • Packet X passes from client to gateway • Packet X contains the name of the user • Therefore, Packet X must come from an untrusted source • A properly malformed Packet X can be used to root the gateway • A differently malformed Packet X can also be used to DoS the gateway with a single packet

41. First, the DoS Packet • This packet contains a large number of 0xFF bytes, all of which are out of scope for anything that should belong in the data section of Packet X • Remember, Packet X is an HTTP action, and consequently cannot contain binary data without violating the HTTP standard • But, if you fed it this packet, it would be just fine…until you disconnected • Then, BOOM! 100% processor utilization until you reboot ALL YOUR BASE

42. Then, the Buffer Overflow Packet • We’re going to show you this one • Here it is • You see, it’s not expecting a user name larger than 31 bytes • This kills the VPN service itself, in one packet • It also overflows the VPN service • No, we are not going to give you the offsets, exploit code, or nuclear weapons ARE BELONG TO US

43. Deep Gratitude

44. Questions?