SSL VPNs might not be as secure as you think

By Tim Greene, IDG News Service
August 07, 2008

SSL VPNs can be compromised in a way that enables them to take over remote users' machines and potentially cause mischief inside the networks they attach to, according to research presented at the Black Hat conference.

The problem can exist with Web clients that install themselves on remote machines at the start of SSL VPN sessions, said Michael Zusman, a senior consultant for the Intrepidus Group. (Dan Kaminsky also spoke at Black Hat about how SSL certificates used to confirm the validity of Web sites could be circumvented with a DNS attack.)

Zusman said his research does not apply to SSL VPN clients that are installed permanently on machines as part of computers' standard software loads.

Elements of the so-called Web clients Zusman referred to can expose them to attacks, however. These clients are downloaded to remote machines by SSL VPN gateways and include Active X components. Some vendors include a feature that enables the client to launch full application clients on the remote machine.

So, if remote users want to access a corporate accounting application, for example, they click on that application as listed on the VPN portal. The VPN client then launches the client for the accounting application so users don't have to do it manually, making the process cleaner.

The danger lies in these clients' reliance on an Active X component that acts as an application launcher, which means it also could launch malicious code, Zusman said. So, the convenience of having the SSL VPN client launch other client applications opens up a potential attack vector, he said. "I think that's a pretty bad tradeoff," he said.

Zusman actually carried out this Active X repurposing with SonicWall SSL VPN gear, he said. SonicWall fixed the problem when he told the company about it. This may be possible with other SSL VPN gear as well, he said, but he has not tried.

Zusman also demonstrated a trick he devised to acquire a valid SSL certificate from a trusted third-party-certificate authority. He wouldn't name the authority, but he tricked the certificate out of it by saying he wanted the certificate for an internal network only.

He then used the certificate to validate SSL sessions to a proxy server for a legitimate Web site. Users could be directed to the proxy via e-mail phishing. "The victim machine is being routed to an attacker-controlled address," Zusman said. Because the certificate is valid, the tricked users don't receive popup warnings about whether it is valid, he said.

Using this method, Zusman could capture users' passwords, as well as perform drive-by downloads of malware from the proxy site, he said.

While his exploit was not directly related to SSL VPNs, it demonstrated that SSL itself is not perfectly secure, Zusman said. "The way we use SSL today is flawed," he said. "There are ways around it."

Only registered users can write comments.
Please login or register.

---