Why Your SSH Infrastructure Is Leaking Data Before You Even Authenticate

TLDR: SSH is the second most common remote administration protocol on the internet, yet it remains a goldmine for pre-authentication information leakage and post-authentication exploitation. Recent research highlights how misconfigured services, hardcoded credentials, and flawed implementations in everything from IoT devices to enterprise software like MOVEit allow attackers to bypass security controls. By using tools like SSHamble, security researchers can automate the discovery of these flaws, turning what was once manual, tedious reconnaissance into a streamlined process for identifying vulnerable infrastructure.

Security professionals often treat SSH as a solved problem. We assume that because the transport layer is encrypted, the service is inherently secure. This is a dangerous oversight. SSH is not just a secure tunnel; it is a complex protocol with a massive attack surface that exists entirely before a single credential is verified. Whether you are auditing a hardened server or a cheap network appliance, the protocol handshake itself often reveals enough information to compromise the system.

The Pre-Authentication Information Goldmine

Many administrators fail to realize how much data leaks during the initial SSH handshake. Before you even reach the authentication phase, the server broadcasts its version, supported key exchange methods, and often a pre-authentication banner. In the world of embedded systems and OT devices, these banners are frequently verbose, providing clear indicators of the underlying hardware and software versions.

Attackers use this to fingerprint targets with surgical precision. If you are running an outdated version of OpenSSH or a custom implementation on an ICS device, that handshake is a neon sign pointing to your specific vulnerabilities. The goal for any serious researcher is to move beyond simple banner grabbing and start probing the state machine of the SSH implementation itself.

Exploiting the State Machine

The most interesting research in the last year has focused on manipulating the SSH state machine to trigger unexpected behavior. Take the Erlang OTP SSH remote code execution vulnerability. By sending specific commands before the authentication process is complete, an attacker can force the service to execute arbitrary code. This is not a theoretical edge case; it is a direct path to system compromise that bypasses traditional authentication entirely.

When testing these implementations, you need to look for how the service handles out-of-order packets or malformed requests. Many vendors, particularly those building custom SSH daemons for network appliances, fail to implement strict state checks. This leads to scenarios where an attacker can initiate a session, send a payload, and have it processed by the service before the authentication logic is even invoked.

Automating Discovery with SSHamble

Manual testing of these vulnerabilities is slow and error-prone. This is why we built SSHamble. It is designed to automate the discovery of SSH-specific security flaws by scanning for pre-authentication state transitions and post-authentication misconfigurations. Instead of manually crafting packets to test for Terrapin or other sequence number manipulation attacks, you can use the tool to quickly identify if a target is susceptible.

The power of this approach lies in its ability to handle multiplexed channels. Once you have successfully authenticated, SSH allows for a variety of operations, including command execution, file transfers, and TCP forwarding. If a vendor has implemented a "restricted" shell that is actually just a wrapper around a standard SSH session, you can often use these features to break out of the intended environment.

# Example of scanning a target for common SSH vulnerabilities
sshamble scan -o results.json 192.168.0.0/24

During an engagement, you should focus on these post-authentication channels. If you gain access to a shell, do not stop there. Check if you can use the session to perform TCP forwarding to internal services that are not exposed to the public internet. This is a classic A07:2021-Identification and Authentication Failures scenario where the initial access is just the beginning of the lateral movement phase.

The Reality of Patching

Despite the severity of these vulnerabilities, the reality of patching is grim. We have seen time and again that even when vendors are provided with detailed reports, including the serial numbers of affected devices, the adoption of patches is abysmal. Many of these systems are "set and forget" appliances that will never see a firmware update.

For defenders, the best approach is to minimize the exposure of SSH services. If a device does not need to be accessible from the internet, it should be behind a VPN or a jump host. For those that must be exposed, implement rate limiting and, where possible, disable password-based authentication in favor of public key authentication. The OpenSSH project has introduced built-in rate limiting in recent versions, but as our research shows, the vast majority of the internet is still running older, vulnerable versions.

What to Do Next

Stop assuming your SSH configuration is secure just because you use strong keys. Start auditing your infrastructure for pre-authentication leaks and ensure that your SSH daemons are not just patched, but configured to reject unnecessary authentication methods. If you are a researcher, use tools like SSHamble or integrate these checks into your Nuclei workflows to identify these patterns at scale. The next time you encounter a network appliance, do not just look for the web interface; look at what the SSH service is willing to tell you before you even try to log in.