With all the hype and press surrounding the Dan Kaminsky DNS Cache exploit at the 2008 Black Hat Conference, another presentation with broad Internet security ramifications went almost unnoticed. Mike Zusman, a senior consultant at the Intrepidus Group, demonstrated the ability to exploit a widespread vulnerability in virtual private networks that use secure socket layer encryption (“Leveraging the Edge: Abusing SSL VPNs”) and discussed how he was able to obtain the credentials to operate a Web site that he did not own.

I was fortunate to interview Zusman and get a personal demonstration of the SSL VPN vulnerability as well as get his insight into why there is a little-known weakness in a very common corporate security tool.

While many of us use a VPN or SSL encryption on a regular basis, most of us do not know how it works. VPNs are commonly used to encrypt data from a remote user computer like a notebook to a corporate network across the Internet. What actually happens when we establish a VPN connection from a remote computer to a network is, of course, more complicated.

Typical VPNs require the user to install client software on their computer before they can establish a secure connection with a remote network — hence the name “thick client.” Thick-client VPNs usually provide full access to a corporate network even though the user may only need a limited number of remote resources. Note that thick-client VPNs can be thwarted by firewalls that prevent such connections.

Enter SSL VPNs, the lighter, friendlier cousin of the thick-client VPN. SSL VPNs have several advantages over traditional VPNs. SSL VPNs:

• use the same protocol used by SSL-encrypted Web sites (e.g., online banking Web sites or Paypal). This means that most firewalls at any organization will automatically allow SSL-encrypted traffic to pass through;

• provide the same level of data integrity and data authentication as many traditional thick-client VPNs;

• are typically much easier to install on both the network and on the user’s computer. Many SSL VPNs have a Web-based client install that uses ActiveX or Java within the Web browser; and

• allow for granular or limited access to a remote networks. For example, an SSL VPN will identify a user and limit access to those resource to which the user has the proper permissions.

These benefits have led to a surge in corporate use of SSL VPNs. In January 2006, the Gartner research company predicted that by 2008, SSL VPNs would be the primary remote-access method “for greater than 90 percent of casual employee access, more than three-fourths of contractors and more than two-thirds of business telecommuting employees. In their December 2008, “Magic Quadrant Report for SSL VPNs, Gartner reports that SSL VPNs aren’t the thick-client VPN killers that they originally thought but that SSL VPN use continues to grow at a rapid rate (projected at 14 percent annual growth between 2007 and 2012) and currently account for more than 10.8 million users.

On the good side, SSL VPNs are easy to install and manage. On the bad side, they come with Web application vulnerabilities in the client software that is loaded into a user’s Web browser of choice. All of the major SSL-VPN vendors, like Cisco, F5, NetScreen, SonicWall and Juniper Networks, have experienced a variety of vulnerabilities in their SSL-VPN Web clients in the past couple of years. These vulnerabilities cover a broad range of threats that include:

• Disclosure of information about the inside of the protected corporate network.

• Deletion of files on the user’s laptop.

• The ability for a hacker to remotely shutdown a corporate VPN.

• The ability for an SSL-VPN user to escalate their privileges and access normally restricted computers.

During his presentation, Zusman was actually able to demonstrate directed attacks on a remote user’s computer without their knowledge simply because they had SSL-VPN client software using ActiveX controls installed in their Web browser. What makes the vulnerabilities Zusman demonstrated so dangerous is that the user does not have to be actively using the SSL VPN for the attack to succeed. They only need to browse to a Web site that is configured to attack them. This problem is created because once the SSL-VPN client is installed in the Web browser, any Web site can use the associated ActiveX control to manipulate it. In a normal ActiveX Web browser plug-in, arbitrary access by Web sites is prevented by a Microsoft security model called SiteLock. SiteLock tells the ActiveX plug-in which Web sites are allowed to activate it. Unfortunately, SSL VPNs don’t use SiteLock because they have to be configured to work with a multitude of corporate networks that make it impractical for security vendors to make custom plug-ins for all.


In his demonstration, Zusman used the following combination of actions to exploit a Juniper Networks SSL VPN ActiveX client as follows:

1. A Trojan Web site tricks the SSL-VPN ActiveX plug-in into upgrading itself.

2. The SSL-VPN ActiveX plug-in downloads the Trojan program.

3. The SSL-VPN ActiveX plug-in does not perform an upgrade because the Trojan program isn’t properly signed by Juniper Networks.

4. Since the SSL-VPN ActiveX plug-in puts all downloads in the same, known location on every computer, Zusman’s Trojan Web site next asks the plug-in to run his Trojan program — which it happily does.

5. Zusman has remote access to the user’s computer without their knowledge simply because they visited his evil Web site.

In his second demonstration, Zusman showed a remote access exploit on a SonicWall SSL VPN and an ActiveX client as follows:

a. A Trojan Web site tricks the SSL-VPN ActiveX plug-in into upgrading itself.

b. The SSL -VPN ActiveX plug-in actually downloads a Trojan program.

c. In this case, the SonicWall SSL-VPN ActiveX plug-in does not check the downloaded program to see if it is digitally signed by SonicWall and simply runs the Trojan program.

d. Zusman used this exploit to get a remote command line on the exploited laptop giving him full access to the computer’s hard disk.

Both demonstrations allowed a potential hacker to gain full access to the unsuspecting victim’s computer without their knowledge just because they had the SSL-VPN ActiveX plug-in installed in their Web browser. In effect, a situation is created where computers are compromised simply because they use an SSL VPN to access a remote network. Zusman went on to point out how well this sort of attack worked when used in conjunction with phishing e-mails sent to corporate computer users.

For example, a phisher might send an e-mail to thousands of corporate users telling them about new information on ways to improve their earnings through the company’s 401k plan. The unsuspecting visitor browsing to the Trojan Web site would get some 401k information and provide the hacker with complete access to their computer hard drive. Zusman went on to explain the dangers of a hacker who simply places a Trojan SSL-VPN ActiveX command on compromised business Web site. Thousands of users from hundreds of organizations might be compromised before the innocuous change to the business Web site was discovered.

As a security professional, Zusman offered a number of ideas to help organizations better secure their SSL-VPN infrastructures:

• Use SSL certificates signed by the organization. A Certificate Authority public key would need to be installed onto each SSL-VPN client computer so that the plug-in can verify who it is communicating with. This makes it very hard for a hacker to attack but also complicates the otherwise simple Web-based SSL-VPN client installation.

• Use an SSL-VPN solution that supports client-side “white lists.” White lists are lists of Web sites or VPNs that the SSL-VPN ActiveX plug-in is allowed to communicate with. An SSL-VPN client that uses white lists will pop up a security alert box if it is communicating with an unknown Web site trying to launch programs. Unfortunately, many users simply click “yes” without reading or understanding the security pop-ups, making them less effective.

• Make sure the SSL-VPN users are actually getting updates and patches. SSL VPN vendors frequently release updates and patches to address potential security problems. Organizations need to ensure that their users are actually using the latest and most secure versions of their vendor’s SSL-VPN ActiveX plug-ins.

• Minimize SSL-VPN ActiveX plug-in capabilities. Organizations should make sure that SSL-VPN users are only able to use the features necessary to conduct their business. By disabling unused or unnecessary components of the ActiveX client, you can reduce risk.

• IT staff should lock down the configuration of SSL-VPN appliances. Simple solutions like explicitly listing the remote computers that are allowed to connect to the SSL VPN and removing allow-access-from-all rules can go a long way toward improving security.

• SSL VPNs should be configured so that remote computers connecting to the corporate network can only access corporate network resources they need, not the rest of the Internet. This prevents a remote user from accidentally downloading a Trojan onto the protected corporate network during an SSL-VPN session.


Being an expert in the areas of Web application and VPN security, Zusman also has an interest in the security of Certificate Authorities that sell organizations SSL Certificates used to protect data and secure Web sites. “The big problem is that SSL certificate authentication has been automated. If you went to the bank and there was a person standing outside claiming to be a teller, you wouldn’t use them. But we accept SSL certificates without really knowing who is behind them. CAs have downgraded their security standards for obtaining a certificate out of band to a fully automated, ‘quick’ processing.”

Zusman explained to the audience how he was able to purchase a valid SSL certificate from a major Certificate Authority for Microsoft’s “http://login.live.com.” Live.com is the Microsoft Web site associated with Windows Live accounts used for Hotmail, Messenger and Xbox Live. Given that Zusman is not an employee of Microsoft, he should have never been allowed to purchase an SSL certificate for Microsoft’s sites. The implications of being able to purchase a valid SSL certificate for the Live.com site is that Zusman, with the Microsoft certificate in hand, could set up his own Trojan version of Live.com. And any Web browser visiting his Trojan site would believe it was actually Live.com, when it was not.

Zusman pointed out that he didn’t have to use any kind of exploit or hacker technique to obtain a “valid” Microsoft SSL certificate. He noted that there were two failures in the Certificate Authorities’ process:

1. If the CA verified the certificate application using, for example, an automated, outbound SSL connection to log in to Live.com, it would have been obvious that the domain already had a valid, non-expired SSL certificate. Why would Microsoft need another one? This should have thrown up a red flag.

2. WHOIS information that identified the real owner of the “login.live.com” Web site was simply disregarded.

Zusman informed us that it appeared to be an employee at the CA who failed to properly authenticate his false request, not a computer system. “The scariest part was that people I spoke to on the phone saw nothing wrong with what I was requesting,” said Zusman.


Talk to your IT staff about the security of your SSL VPN and some of the secuirty issues presented here. Like everything else associated with computers, attendant security devices require independent testing and maintenance — don’t let your security solution turn into a security liability.

Brian Dykstra is a senior partner at Jones Dykstra & Associates, a Maryland-based consulting firm that specializes in e-discovery, computer forensics, expert witness testimony and computer intrusion response services.