⌨ Labor omnia vincit ☮

How to detect SSH or SCP is using?

Posted in Network, security by anaumov on 27.09.2018

That was interesting to spend some time and to try to detect what kind of service is use SSH. As you know, OpenSSH provides ssh(1) and scp(1) programs. Both use the same protocol and the same port number. In fact, both programs has been developed exactly with purpose to be secure enough to protect its users to network packet analysis. But there is nothing more interesting that to try to figure out how exactly all these things works together and try to find a way to detect what service is used on the server.

My first idea was to get this information from OpenSSH server itself, because I was pretty sure that packet analysis will not help me. There is an option in the config file calling LogLevel. The default value (tested on openSUSE) is set to INFO. Let’s change it to DEBUG3 and restart OpenSSH server. After that try to copy something to the server and check the syslog:

As you can see, server provide this information very easily. The problem is – I need to be root and I need to reconfigure and restart OpenSSH server… that is not intelligent and that’s why it’s a bit boring. How we can get the same information without root-right on the server? There is the second way to get it. You will not need root-right, you will not need to be on the server at all.

Welcome to the network packets analysis 🙂

Yeah, I was wrong to thinking that sniffer will not help. But please don’t misunderstand me, SSH connections is pretty secure! There is no way no recognize or find some differences in secure shell or secure copy connections. What kind of authentication is used – password or publickey authentication – is also terra incognita. Packets generated by OpenSSH looks same in all cases. At least by authentication phase… 🙂

As you know, SSH is a cryptographic network protocol and it operates on the Application layer. It’s great and amazing, but it does nothing with bottom layers. And this is exactly where our story begins.
As I said, authentication phase is secure, but after the new connection is established (open_session phase is done) the picture changes drastically and I would even say – dramatically. The culprit here becomes a DSCP/ToS or Differentiated services.

Differentiated services, as the name says, differentiates the ToS-bit depend on used service. In case of SSH, for secure shell ToS-bit will be sets to 0x10 and for secure copy it has value 0x08. Yes, it seems that the IP header (where ToS-bit is) “includes information” about upper layers content… Unbelievable. I know, it sounds like a craziness. I’m still think that I get something wrong, but let’s repeat it together.

The tcpdump’s expression for filtering content of IP header looks like this:

sudo tcpdump -n -i any -v 'ip[1] & 0xfc == 0x10' and port 22

This filter will parse IP packets, where ToS sets to 0x10 (for normal secure shell).
Change it to 0x08 to get a filter for SCP-connections.

You don’t need to be root on the machine where OpenSSH server is running, you don’t need to login on this machine at all. As we all know, to sniff the traffic (encrypted or not) can be easily happen by using the MITM-attack.

You can add port 22 at the end of tcpdum command to get “SSH packets”, but don’t trust it too much, because… to reconfigure OpenSSH server to use other port, say 2222, is not a big deal. Unfortunately, it seems like tcpdump doesn’t support filters for application protocols like SSH and we can just sets the port number (in the hope of the using of standard port). But there could be used a small trick – at the beginning of the connection establishing (exactly after TCP three-way-handshake), OpenSSH client and server exchange its application version and version of used SSH protocol. It’s not encrypted. This wireshark screenshot shows that system has no idea to what service/protocol belongs this data and it says just “Data”, but you can see in TCP header that port of server is 2222:
Should I say, that theoretically every server (implemented by bad guys) can send the similar “fake SSH-data” to deceive or just to confuse you? 🙂 So, be careful with filter for something like *OpenSSH_; check it carefully.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: