Recently I’ve seen quite a large trend in customers that use alternative SSH ports. I like the idea behind this but as with most things, I don’t consider it a cure all.

Essentially, for those not in the know, when you have a public facing SSH Daemon on the standard port 22, you can just expect brute force attempts. It’s a fact of life. As is people using common usernames and common passwords. We have one issue, simply because we have the other.

Now, I’m fine with moving SSH to a different port, this avoids just about all types of standard SSH brute force scanning (with the exception of someone trolling the ports on your server and doing individual banner checks). My gripe is that people use non-priveleged ports for their SSH daemons. This, my friends, is an issue.

Linux has what’s known as “privileged ports”. These are ports from 0-1024 and what distinguishes these ports from the other 64512 ports you can bind to is that the linux kernel simply won’t let you open a socket on one of them unless you’re root. That’s it, nothing else. Any user can bind a socket on a port between 1025->64512 without an issue, but in that 0-1024 range, the kernel says NO.

Why? Well, security. With 1024 ports only bindable by the user root, we create a bit of a ‘haven’ for public facing services.

I’m a huge fan of analogies, so here’s one to try to illustrate the importance of privileged ports and more or less what they signify.

Let’s say your server is a Concert and the vendors, ports. At the concert, everyone wants to get their schwag, the T-shirts, the CDs, the posters, all the good stuff. Now the *quality* merchandise is inside the gates. The band can say “This stuff is quality and we stand behind it.” These shirts aren’t going to fall apart in three washes, posters aren’t going to be misprints, and the CDs not labeled with a sharpie. The vendors you buy this stuff from are your privilged ports. You know it’s authentic, good stuff.

Now, you go out to your car and pass the hippies selling hand made t-shirts out of a bag, posters printed at kinkos, and burned rips of the bands CD. It’s just not as good as the stuff the band stands behind, but anyone can open up shop out there in the parking lot. These, are your unprivileged ports.

So with basic services being under port 1024, you can gaurantee the authenticity of these services. That’s essentially it.

When server admins start binding SSH to port 9999, this raises an interesting security risk. Any standard user on the machine in question is capable of starting an app and binding to that port. The tricky part here, is getting the existing SSHd to drop it’s tie to the port so the users modified SSHd can attach to it. There are various methods of doing this, however I think the easiest way would be to symply synflood the port until the server operator triggers a restart. Given that your average hosting machine has a control panel that *will* still respond even if there’s a synflood on the SSHd port, it’s a easy enough to click a few buttons to restart SSH in order to see if that fixes the issue. Quite a few administrators have auto-restarts tied into their monitoring as well, so the server operator may not even know there was an issue with the daemon.

When that restart occurs, the trojaned SSHd is ready for it and grabs ahold of the port. Now, the fun starts. Basically we just have to answer with a standard banner and then force a downgrade of the SSH protocol to v1. After that, all of the authentication can be decrypted quite easily.

Now typically, Man in the Middle attacks through SSH are based around a separate node on the network ARP flooding with false information hoping to redirect an SSH session *through* the server with some form of hacked SSHd. They’ll then typically act in a passthrough state after downgrading the SSH connection to v1 in order to appear fairly seamless to the end user. In the above example, a hosting machine, a standard user account and a non-priv’d SSHd, you’re not going to be able to do successful passthrough as the trojaned daemon is going to be running as a non-priv’d user. You might be able to trick a remote user by throwing them into a sandbox, but that probably wont’ last too long. However they *will* have your password which can be retransmitted pretty quickly.

I’ll see if I can get a test environment setup for to be able to replicate this sort of behavior, but in the meantime there’s no shortage of information on implementing a MiTM attack via SSH on google. :) Stay tuned for part 2 where we’ll implement this in a test lab.

In closing, you should know what a privileged port is and you should now know to QUIT RUNNING SSHD ON NON PRIVILEGED PORTS. :)