Those who have worked with me, or at least had a beer with me, know my feelings on web based SSL VPNs. They are very useful, very complicated, and can be very insecure. Useful because they allow a mobile work force to connect to the enterprise from any computer with a web browser; complicated because they need to do so with minimal inconvenience to both users and network managers; and insecure because this convenience is achieved through automation.

The automation starts with the browser based installation of client side components (ActiveX/Java applets). Network teams, management, and help desk personnel alike, love the fact that users can get the required client side software simply by visiting a web site. Once the components are installed, they can even maintain themselves by automatically download and installing updates and patches! Hallelujah!

Unfortunately, this type of behavior can be easily abused as Haroon from Sensepost has revealed. He disclosed a vulnerability in a Juniper SSL VPN ActiveX control that allows an attacker to execute code on a victim machine by getting them to view a malicious web site. The vulnerability is simple to exploit; the malicious web page invokes the ActiveX, calls one of its functions, and the ActiveX sends an HTTP request to the web server asking for commands to execute on the client machine. No stack smashing required!

Funnily enough, I reported an almost identical vulnerability to another large SSL VPN/firewall vendor. This other company makes it even easier. Instead of requesting a string of commands, their ActiveX will request, download, and execute an attacker supplied .EXE file. No signature checking or anything. Altogether, I have knowledge of these types of vulnerabilities in 4 of the leading SSL VPNs. Details will be discussed pending responsible disclosure.

We all know that SSL VPNs have similar features – you can spend days comparing vendor product descriptions. What I find interesting, and have spent much time researching, is that while SSL VPNs from different vendors share the same features, they also share the same vulnerabilities in their application logic. This research has provided most of the material for my upcoming talk at BlackHat 2008, “Leveraging the Edge: Abusing SSL VPNs”.

My talk is in the network track, but a lot of what I’ll be talking about is purely application security. This is funny to me, because during my time at Whale Communications (a Microsoft subsidiary) supporting Whale’s SSL VPN, the device was usually managed by network people who were not versed in application security at all. The “networking” (and security) in SSL VPNs terminates with the SSL connection. Beyond that, abusing gaps in access control, and other areas of application logic, can provide an attacker with all he needs to compromise clients and the networks they connect to.

-Schmoilito