Hey there,

I thought I would post some interesting bits and pieces that I took away from BSides CBR 2019 last week.

SSH, so hot right now. Profiling it with HASSH - Ben Reardon and Adel Karimi

This talk was all about fingerprinting SSH clients and servers, beyond the (client|server)-id that they send explicitly.

They were able to discover a very unique fingerprint based solely on the SSH_MSG_KEXINIT messages that the server and client exchange to discover which key exchange, encryption, authentication and compression mechanisms that eachother support.

This exchange happens before encryption starts, so no MITM or (client|server)-side access is required, this can all be collected from the network.

By taking a hash of the KEXINIT string, they are able to tell the difference between (for example) PuTTY, OpenSSH, powershell, and more.

HASSH - GitHub Project

Edit (2019-03-30): A Conference for Defense (ACoD) released their video (below) of this same presentation. Unfortunately Ben and Adel were unable to present at ACoD, so a colleague, John Althouse gave the presentation in their place.

Takeaways for Defenders

This information can be added to Splunk or other security systems to alert when a likely malicious SSH client connects to your server

Or you can alert/raise suspicion when an SSH client identifying itself as OpenSSH/PuTTY has the HASSH fingerprint of a client more often used as a hacking tool, such as Empire/Meterpreter (as though it’s trying to disguise itself).

You could also scan your network to detect which SSH servers are in use, potentially identifying embedded systems that you were not aware about, or that should not be accessible from the main network.

Another possibility is tracking cred stuffing attempts from multiple IP addresses, if they have a unique HASSH.

Takeaways for Attackers

When performing lateral movement with SSH in a mature environment, be aware that your SSH fingerprint may give you away. Potentially take a look at a benign/likely trusted SSH client (OpenSSH/PuTTY?), and copy it’s client-id and KEXINIT string before connecting to hosts in the environment.

Wi-Bear: Intelligent Autonomous Wi-Fi Honeypot Detection - Vivek Ramachandran

This was another talk about fingerprinting, but instead of SSH, it was about fingerprinting 802.11 WiFi beacon frames.

The goal of fingerprinting these beacon frames is to be able to tell the difference between a safe, legit access point, and somebody who has created a rogue access-point with the intention of having you connect, in order to collect your traffic or credentials.

We currently have rogue AP detection, however the majority of it works by two main detection methods:

1. Does the SSID match .*Company.*? (somebody is trying to impersonate our access-point)
2. Does the AP MAC also appear on the LAN side of the wireless controller? (somebody has connected a rogue AP to the network)

[Un]fortunately, these detections only protect you when your device is within range of the legitimate wireless network. Once you head out to the car-park, your device is happy to connect to the rogue network, and nobody will know about it.

Vivek’s detection involves reading the Information Elements (IE) in an AP’s beacon frame, and creating a fingerprint based off of the IE values.

IE values convey information that the client might need or want to know prior to connecting, such as:

• SSID
• Supported Rates
• Country Code (802.11d)
• Power capabilities (802.11h)
• and many more…

He discovered that the majority of attack tools omit many of these IEs so that they only send the necessary IE to get a client to connect.

[Un]fortunately, this means that these tools (Airbase-NG, WiFi Pineapple, etc.) are able to be fingerprinted based on which IEs they include/exclude, and what their values are set to.

Based on his research (which was originally released in 2015 at DEF CON 23), it is quite simple to detect a malicious rogue access point, based on the contents of it’s beacon frames.

His tool, Chellam, talks to native Windows APIs to gather the information it needs to determine whether or not an access point is a malicous rogue, and will alert (or perform a configured action) when one is encountered.

Takeaways for Defenders

As far as I could find, and as far as Vivek is aware, no endpoint security product is performing such detection.

He spent a bit of time putting his tool together, but it’s not really something that organisations would use (it’s in Alpha, and has been for a number of years).

Unless you’re keen to put in some dev time, I think the best we can currently get out of this is performing passive detection on Windows machines, and analysing it with Splunk. It would be really cool if we could implement blocking of APs detected as rogues on the client-side, instead of relying on WIPS APs.

Takeaways for Attackers

When attempting to pull off an evil-ap attack of some kind, try and check out what a legitimate beacon frame looks like from the target’s APs. Try and modify your tooling to mimic (as close as possible) the beacon frames of your target.

Thank you to all of the organisers, volunteers, sponsors and speakers, I had a great couple of days in Canberra.

Thanks for reading!

XORcat