SSLVPN Vulnerabilities - Client Certificates offer a superior defense over OTP devices

Blackhat '08 disclosed several SSLVPN and DNS vulnerabilities that caused several people to sit up and take notice. Some of these new exploits performed a brilliant Man-in-the-Middle attack on SSLVPN tunnels. I'll walk you through how using certificates, instead of OTP tokens, for second factor authentication can increase the security of your SSLVPN solution against these new types of attacks. I wrote an article a while ago about using certificates as a second factor for authentication to an SSL or IPSEC VPN. The model is based on a feature that came out in the Cisco ASA 8.x release which allows an SSL VPN to be configured to require a certificate plus AAA authentication. However, in the last 8 months and after attending Black Hat this year I have had a few new thoughts on the matter and discovered a new tool to help make this a workable solution.

First off we need to tackle the basic question; Are certificates a valid second factor?
As discussed in the previous article and thread, PCI section 8.3 indicates that they are; or, the least that we can say is that they are for PCI compliance purposes. This supposition generated a lot of feedback about the ‘something you have and something you know’ model of two-factor authentication. One of the popular sentiments was that if a ‘certified’ system was lost or stolen all that was left to gain access would be pulling the username and password out of the computer, and if the password was saved in the browser, well, the work is done. I did mention that tokens could be lost too, but what is more likely to be noticed a lost laptop, or a lost token? And, since the certificate alone cannot grant access to the SSL VPN, couldn’t we just change the password to lock out the lost system?
That seems to help minimize the damage of a lost computer. Another thing we could do to help tighten up the overall security of our system is create certificates with limited lifetimes. Instead of a certificate being good for a year or more, we could set them up to be good for only 90 days, or even less. Yes, I know that you are laughing at me and think I have gone out of my mind to suggest this, but read to the end, there is a way.
So, I was not necessarily convinced that certificates are a valid factor when I first wrote about this, but I have turned that corner. One thing that helped me step in this direction is the added security value of certificates over password replacements with these new attack vectors that announced recently.

Most two-factor authentication solutions are some form of One-Time-Password (OTP), which is really just a password replacement. So, how much security do passwords really give us? Let’s look at how a Man-in-the-Middle (MITM) Attack against an SSLVPN session works when using an OTP solution and how it works using a Certificate solution. The MITM attack will showcase some of the new DNS attack techniques and show how a lack of oversight by some Certificate Authorities affects your security. At Black Hat ‘08 there was a great demonstration of how valid “internal testing only” FQDN certificates for URLs that you don’t control can be obtained by anyone asking. The one obtained by the researcher at Black Hat was for MSFT’s https://login.live.com site, he didn’t disclose the CA that issued it to him but it was one that was trusted in IE by default. Having these completely valid certificates allows a MITM attack to be staged without generating a browser security warning saying the certificate has issues. (see my previous article on the subject at http://www.networkworld.com/community/node/30822).

First, let’s looks at a MITM SSLVPN attack where two-factor authentication is done using username and an OTP token device. See the diagram for a flow of what is happening, in order. The first thing, not shown in the diagram, the attacker will do is a Google search or perimeter scan to figure out what SSLVPN URL to go after. A good search term to use is something like https://sslvpn. They will then go to all of the trusted CA’s and try to get them to issue them a valid “internal only” certificate with the FQDN of a target sslvpn URL. As soon as they get a success, that company now becomes their target of choice. Remember, the certificate they need can be issued from any trusted CA in the browser and does not need to match the CA that the SSLVPN gateway is using. Now for 10 steps to MITM success:
MITM SSLVPN attack with OTP device



Here are the 10 steps explained:
1. The attacker launches either a client side or a DNS server side DNS poisoning attack that changes the https://sslvpn.xyz.com DNS record to point at the MITM proxy server IP address and not at the real SSLVPN headend device. For additional details on the various new DNS attack techniques see http://www.endeavorsecurity.com/dns.php .
2. At a time of their choosing the Client user will initiate a SSLVPN connection to their office. Because, the SSLVPN login url has been changed to point to the attackers proxy server, that is where their connection request goes to. Their real SSLVPN headend device never sees the request.
3. The proxy gets all excited because it has a new victim and happily completes an SSL handshake with the them. The key is that it uses the ill begotten fully qualified domain name certificate it got from a trusted CA to established the connection. Since the client trusted the CA that issued the cert and the certs FQDN matches that of the real sslvpn headend device, the client is just as excited as the attacker proxy is. Oh goody I am about to connect up to my real sslvpn server.
4. The proxy then asks the real SSLVPN headend to initiate a session.
5. The SSLVPN headend completes a handshake with the attackers proxy.
6. Once the sslvpn handshake is completed it asks the proxy for credentials.
7. The proxy forwards the credential request to the real client using it’s own session.
8. The user enters their username grabs their OTP token, puts in their pin number, and then inputs the generated password into the password field.
9. The proxy copies the provided credentials and then politely informs the client that indeed it provides a correct username and OTP password and establishes a full SSLVPN tunnel between itself and the victim client. The client is thrilled that the proxy trusts its credentials and gleefully participates in full SSLVPN tunnel establishment. Now, behind the scenes it uses the previously copied credientials from the victim to authenticate itself against the real SSLVPN headnend. Now everyone is pleased on that side too and the proxy and sslvpn headend establish their own SSLVPN tunnel.
10. Walla!!! (inside joke, see my previous posts comments), the attacker has succeeded in establishing a Man-in-the-Middle position and sees all victim data in the clear. He also has free reign to copy, modify, or delete any data being sent or received from either side.

So how does using certificates as the second factor prevent this type of attack you ask? In a nutshell, it is because certificate authentication requires mutual authentication/verification. That means that neither party trusts the other one. In the above scenario the client verified the identity of the sslvpn headend through it’s certificate. We spoofed that by getting one from a CA. When using certificates we introduce the requirement that the sslvpn headend must verify the identity of the client as well. This is accomplished by issuing client certificates to all users PC’s. Well, why don’t we just go to a CA and spoof the client cert too you ask? Because it wont work. The change is that the VPN headend will check with validity of the client’s certificate only with the CA that it is configured to trust. That might be an internal CA or an outsourced CA. This is in contrast to the client in the above example that would trust any CA that is had in its keystore already. FYI, Firefox has over 40 trusted CA’s by default!

Ok, you say well what if the attacker was somehow able to get the CA that the SSLVPN headend trusted to issue them a “internal only” certificate.? Well, they’d have another problem. Some SSLVPN devices, like the Cisco ASA, can use embedded information in the client certificate to pre-fill fields like username for example. So when the client logs in the username they type in is disregarded and the ASA instead uses the one that is part of their client certificate. This means that the attacker would have to know in advance what their username was (or any other pre-fill information needed) before they could ask for a “internal only” cert from the trusted CA.

Here is a quick diagram on how the flow looks when using username/password AND certificates for authentication and encryption.
Diagram:MITM SSLVPN Attack Fails when using Username/pwd and Certs



1) Handshake: ClientHello
2) Handshake: ServerHello, Certificate, CertificateRequest, ServerHelloDone
3) Handshake: Certificate, ClientKeyExchange, CertificateVerify; ChangeCipherSpec; Finished (this step fails without the possession of the client side certificate)
4) ChangeCipherSpec; Handshake: Finished

So as you can see putting a certificate on the client side stops the attacker dead. With client-certificates in play, the SSL negotiation is based on the public/private key pair of both the client and the server. This means that the attacker would have to have a valid personal certificate in order to authenticate.
The value of certificates has been recognized for years, and the cryptography has been well reviewed. The biggest problem with securing you network using client-certificates is the administration. A recent addition to the stable of Cisco Certified Technology Development Partners, MultiFactor Corp., has overcome the administrative burden with their SecureAuth for Cisco VPN product.
SecureAuth offers a strongly authorized, user self-service, certificate deployment platform. I have a demonstration system running and it was amazingly simple to install and integrate with my SSL VPN. In fact, I deployed PKI in less than an hour, added no administrative overhead to my SSL VPN, and it is easy enough to use that the average end-user would require little or no training.

Here is how it works: SecureAuth is deployed as an appliance in the DMZ of the ASA and connected to my existing back-end AD with Secure LDAP. The ASA is configured to automatically direct un-certified browsers to the SecureAuth enrollment process. When a user logs in successfully they are immediately directed to enrollment, bypassing the portal. The next step is authorization for enrollment. SecureAuth has a number of registration methods available, among them are sending the registration code via a text message or a phone call (a voice reads out the code to you), and the code is only good for that session. The phone numbers that SecureAuth uses are all in my AD, so I did not have to create a new authentication database, and do not have to maintain any separate user database for it, either. Once registration authorization is complete the client system generates the public/private key pair, sends a signing request and then installs the completed certificate. Here are some screenshots of the SecureAuth process.







Now, when a user returns to the SSL VPN the certificate is presented and validated, and the user is directed to an authentication page for access to the SSL VPN. The second-factor part of access is nearly invisible, but is adding all kinds of security value to the connection; something a password replacement cannot do.
Remember how I mentioned certificates with short lifetimes? Seemed pretty absurd, huh? Dealing with expired certificates and certificate re-enrollment has traditionally been a very cumbersome and painful process. However, with the ASA & SecureAuth solution, when my certificate expires the ASA will simply send me back to certificate enrollment, and I just go through the registration process again. Or, if I go home and want to use a different computer, I just enroll from there. If, you want to restrict what types of devices can login you can either control cert enrollment or use the features in ASA to perform a pre-login host assessment/scan. For example, the assessment results can determine if the host is a company owned asset or a kiosk PC.

Using client certificates for SSL VPN certainly adds security value in ways that password replacements (read OTP tokens) cannot. There are certainly some tradeoffs in the model, but with the recent DNS flaws that have been published, and the volume of attacks that followed, it seems reasonable to consider how to protect the network layer of your SSL VPN connections. Certificates seem the best, maybe the only, way to do that. All you need now is a tool (like SecureAuth) to get them in the hands of your end-users without a huge administrative burden … Oh, and if you really, really want a ton of security, run your tokens on top of the certificates.

Big thanks to Mark Lambiase for his assistance with this blog article. For more information on SecureAuth you can contact him directly at . Or go to www.multifa.com to setup a free trial using your own ASA box.

The Cisco ASA product line can support using both username/password AND certificates for authentication, for more info go to http://www.cisco.com/go/asa
Finally, if anyone knows of another company that is doing something similar to SecureAuth I’d like to hear about it.


So, what are your thoughts? Are certificates really more secure than OTP devices? Based on the above info can you still justify the increased cost of an OTP solution vs. certificates? What advantages do you feel that OTP still offers over certificate based solutions? I’m trying not to pick sides here but it is getting hard and harder for me not to.



The opinions and information presented here are my personal views and not those of my employer.