SSH Issues: Does Installing SSH Enable More Exploits Than it Solves?
Date: May 26, 2006
SSH as Salvation?
Some years ago I started doing research on SSH, the wonder tool of the security set. I read one article about a clever SSH setup. The administrator’s DMZ hosts could contact the intranet patching server, something normally verboten. The DMZ servers would route through the administrator’s PC and then access the internal patching server. After considering the author’s SSH design, however, I soon recognized definite security impacts to this approach.
Although several major security compromises are made possible through poor SSH design, does that mean that SSH is a likely target? Consider this: SSH is one of the most attacked services. As the SANS Institute states in its current top 20 vulnerabilities roundup, "Of particular interest this year are attacks against SSH." SSH is rated U1, the top UNIX vulnerability. Why is SSH such a target? In this article, you’ll learn why people are implementing SSH on Windows, mainframe, and UNIX devices. We’ll explore port forwarding, a cool SSH capability. Then we’ll take apart the clever administrator’s SSH design, including attacks against key authentication itself.
In a later article, I want to discuss what you can do if you’re a firewall or a UNIX administrator. You probably recently implemented SSH as a drop-in security precaution against Telnet and FTP exploits—if so, depending on your firewall and SSH design, you likely just enabled many more exploits.
SSH: Many Great Things
SSH is a terrific tool. It encrypts the communications going between a server and a client. More importantly, it authenticates the server so as to lessen chances of man-in-the-middle attacks.
With some work, the clever user can create and configure digital keys to be used by SSH for authentication. These keys can take the place of multiple plain-text scripts with embedded passwords littering your infrastructure. In fact, once I authenticate to machine A, agent forwarding allows me to go to machine B via an effortless authentication exchange, done for me. Machine A will "proxy" the authentication for me. Combining all of these features, I can place my USB drive with my private key into the PC. I unlock the private key via my 40-plus character passphrase, and then ssh to machine A. From there, I can access all other devices that I’ve prepared with my public key, itself shared freely. Now that’s security!
Any Safe Port in an Internet Packet Storm
SSH also offers another type of forwarding: port forwarding. SSH’s inventor, Tatu Ylönen, soon realized that the SSH tunnel might help to improve the security of other applications as well as end the risks of FTP, Telnet, rexec, rcp, rsh, and rlogin. If only there were a way to cram an application’s traffic into the SSH tunnel....
There are two types of port forwarding:
- Local forwarding. Allows the client to set up a
"hijacker" process. This will intercept your PC’s traffic and
shove it into the encrypted tunnel. The standard argument for local forwarding
is the use of POP3 (Post Office Protocol), a service that uses port 110/TCP.
Normally, this service sucks because it passes the ID and password in the clear.
That’s bad. Even worse, people set their POP3 clients to hammer the server
for new mail every five minutes or so. This makes POP3 a hacker favorite because
there are so many chances to grab that password.
But through the magic of local forwarding, I can use the SSH tunnel. POP3 traffic will go from my PC to the POP3 server with encryption. Without drowning a security article in SSH configuration details, here’s an abbreviated version of the process: The client configuration statements have SSH listening on the local host adapter on any port the user chooses. The user statement instructs the listener to grab all port 110 traffic and cram it into the SSH tunnel. On the other end, the SSH server honors the user’s configuration and sends the POP3 traffic to the destination the user dictates, on the POP3 port.
- Remote forwarding. This type of port forwarding has the user’s SSH client acting on the server’s behalf. In this case, those forwarding configuration statements have the client receive traffic on a non-privileged port coming in from the tunnel. It then places the traffic into the correct port, per the SSH client configuration statement, and sends it to the destination the user chooses.
Advantages of Port Forwarding
What is the practical, positive impact of these two capabilities?
Consider the needs of the system administrator (let’s call her Jo) who must patch servers in your company’s DMZ. Maybe you are the mean, rotten, lowlife firewall administrator who refuses to allow Internet-facing machines a direct, ad hoc connection to the intranet’s patching servers? What’s Jo to do? Use SSH port forwarding.
Assume that Jo’s client is Box A, the DMZ server is Box D, and the patching server is Box P. Here’s how our clever server administrator sets up SSH port forwarding:
- Jo creates a remote forwarding statement on Box A that allows traffic coming from port 6789 to be translated to port 22 and then be shuttled to Box P.
- Using SSH, Jo connects to Box D.
- Once at Box D, she creates a local forwarding statement to cram all port 22 traffic to the patching server into port 6789. Therefore, a script pulling files from the intranet patching server will go to port 6789, into the tunnel, and to Box A. At Box A, the remote forwarding statement will take the traffic arriving at 6789 and send it over port 22 to the patching server, Box P.
- Now that the tunnel is built, Jo sets up patching scripts launched on Box A to use SSH to send the processing to Box D for execution. As these scripts execute, commands will access the patching server as if it’s directly connectible. So the DMZ box gets patches and can kick off commands against the patching server itself. The patching server for the entire company. The one safe source for binaries for all servers and client PCs. That one.
At this point, many of you firewall administrators are shaking your heads. How is this possible? Go ahead and review your logs. The tunnel appears to be one outbound connection initiated from an internal "trusted" host to a host with less trust. This seems secure. The encryption certainly keeps hackers, thieves, and firewall and security administrators from determining just what was done and with whose account.
Many Ways to Misuse Your Current SSH Architecture
In this illustration, our server administrator, Jo, connected a DMZ host to an intranet-patching server so as to apply patches to the DMZ host. She was able to get around technical restrictions, but, sadly, architectural separations were lost as well. Let’s review agent forwarding risks.
Depending on the scripts, the administrator may use this capability to negotiate the connection from Box D to Box P. With this design, Box D would pass your login credentials (stored on Box A) to Box P and further automate the convoluted process. How is that done? In most cases, via a UNIX domain socket file.
In UNIX, all things are files. To send network traffic, UNIX writes the traffic to the network device file. In this case, the connection to Box A (and that private key used for authentication) is a socket file. This file will shuttle the authentication traffic between Box A and Box P. So what’s the risk?
Maybe the hacker can’t get a copy of the private key through the socket file, but something better (from his/her view) can be done. If the hacker has root on Box D, he or she can point a private copy of the agent forwarding software to that socket file and thereby point the authentication process to the administrator’s credentials—the ones kept on the "safe" intranet. What are the chances that the administrator has configured access to all the DMZ servers he controls? Altering some environment variables allows the intruder to attempt to access other DMZ hosts with our administrator’s private key. This can mean direct access as root or local administrator. And so this socket file becomes a door to many other systems in the DMZ.
Additionally, by setting the right booby traps, the hacker can alter the administrator’s patch-loading scripts that act against the company’s intranet-patching server. If the server administrator is root on that internal device and the private key identity is recognized as such, how many copies of ’bot software will be installed on your company’s PCs in no time?
This is but one way in which bad SSH design worsens security.
Other Hacks
Do an MSN search on SSH forwarding. You’ll find countless articles detailing how to open an SSH tunnel to your home network and thereby allow for some after-hours work without the hassle of using the official company VPN. Remember the baseline configuration:
- Set a remote forwarding configuration to receive incoming traffic from your home network.
- Execute some clever scripted pings and sleep statements to keep the line alive.
- Set up local forwarding directives on your home system that will use your work PC as a tunnel into your company’s network.
Considering the impacts of a poor home WLAN security design, this setup may have your company infiltrated.
Additionally, you’ll find several great implementations of SSH server technologies that are based on Java and Perl. To you and your firewall, it’s simply a web site receiving encrypted SSL/TLS traffic. To the web site administrator, it’s a private administrative tunnel into the DMZ, available directly from the Internet—and possibly secured with a silly, easy-to-guess password. Point a browser at the target site, authenticate, and get a terminal session.
At this point, we need to stop and consider all those hacker probes of SSH installations. We know that old SSH software often gives root access "by the onesies" via buffer overflows. Additionally, after looking over the many articles describing ways to use SSH to beat firewall restrictions, I believe that there are other reasons hackers probe SSH installations and web sites. Amateur SSH security designs will create unmonitorable paths with full privilege to most devices in your DMZ. Add in those DMZ-to-intranet connections some companies allow, the ones the Evil Developers force on us, and the pathway infiltrates the intranet itself.
Fixing the Problem
This article hopes to set a baseline of understanding on these topics:
- What SSH can do
- How SSH can encrypt other applications normally left unencrypted
- How good security intentions can lead to bad security design
- How unmonitorable an SSH attack can be
- How pervasive SSH technology can be, such that we may find bad SSH security designs hidden among the web server farms
Having covered this much ground, it’s important to consider all the factors and work on a better security plan. Review this material and see how many controls you can come up with that jibe with my suggestions. Consider adding to the comments section so that all of us can partner on an Internet-driven solution.
For the record, I’ve been a server administrator, a web site administrator, a firewall administrator, etc. I’m even a has-been developer now making penance for my earlier foolish escalations. I’m not singling out any particular type of administrators for abuse. We all have a job to do, and when we work together, the job’s done well. As single-minded individuals pressing our own needs in front of others, however, we get into these terrible security designs. So let’s make this the first step to a solution: all the parties coming together to understand the problem better.
From Here
SSH has many other useful features that we don’t have time to explore here. If you’re really interested, consult some of the helpful books on SSH in Safari’s online collection. Now is the time to enjoy the benefits SSH can bring to you.
Want to see more articles about SSH? Comment below in the discussion board.
John Traenkenschuh is a Certified Checkpoint Security Engineer/Security Administrator, CISSP-ISSAP, Microsoft MVP Visual Basic .NET 2004–2006, and a mean, rotten, lowlife firewall administrator.