LAS VEGAS -- 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.
- The SSTP client establishes a TCP connection with the SSTP server between a dynamically-allocated TCP port on the client and TCP port 443 on the server.
- The SSTP client sends an SSL Client-Hello message, indicating that the client wants to create an SSL session with the SSTP server.
- The SSTP server sends its computer certificate to the SSTP client.
- The SSTP client validates the computer certificate, determines the encryption method for the SSL session, generates an SSL session key and then encrypts it with the public key of the SSTP server’s certificate.
- The SSTP client sends the encrypted form of the SSL session key to the SSTP server.
- The SSTP server decrypts the encrypted SSL session key with the private key of its computer certificate. All future communication between the SSTP client and the SSTP server is encrypted with the negotiated encryption method and SSL session key.
- The SSTP client sends an HTTP over SSL request message to the SSTP server.
- The SSTP client negotiates an SSTP tunnel with the SSTP server.
- The SSTP client negotiates a PPP connection with the SSTP server. This negotiation includes authenticating the user’s credentials with a PPP authentication method and configuring settings for IPv4 or IPv6 traffic.
- The SSTP client begins sending IPv4 or IPv6 traffic over the PPP link.
Source: Cisco.com, Microsoft.com
2 comments:
good one man , thanks for sharing
the picture was almost compelet description about sstp.
thank you
Post a Comment