SSHole Attacks Go Beyond the Login Bypass

A successful login is the start of an intrusion, not the end of the story. New reporting on SSHole, the OpenSSH authentication bypass we covered last week, now describes what attackers did after getting into affected Linux systems: reconnaissance, searches for credentials and attempts to keep access.

That is the useful change since our original report. The patch already exists. The new evidence makes the case for checking exposed machines as well as updating them.

What the observations show

In its November 9 report, BleepingComputer says GreyNoise logged 16 successful exploitation chains from six source IP addresses. Its first recorded successful exploitation was November 7 at 00:46 UTC. These are observations from one sensor network, not a count of every compromised Linux machine.

The reported activity included checking the system and container environment, querying cloud metadata services, trying to read password hashes and root SSH keys, and attempting to change authorized_keys files. Those keys matter because an attacker can try to leave a way back that does not depend on the original password bypass.

One observed intrusion reached root and installed TAC Agent, a Python command-and-control implant. According to the report, that implant could not reach its control server and received no task. Ars Technica's reporting also describes GreyNoise's observations of the backdoor and post-exploitation activity.

There is no need to dress this up as millions of confirmed SSHole compromises. Large totals for general SSH scans or attempted sessions do not establish that those connections exploited this particular bug.

Not every OpenSSH installation is affected

The OpenSSH 10.6p2 release notes describe a workaround for password-authentication bypass on some Linux systems using musl libc with PAM support disabled. The account configuration also matters. This is not a blanket claim that every Linux computer, SSH client or public-key login is vulnerable.

The underlying issue can cause an account whose password field contains an asterisk, normally intended to reject password logins, to accept an oversized password under the affected conditions. Alpine is a relevant example of a musl-based distribution, but the name of the distribution alone is not a complete exposure check.

Patch, then check what happened before the patch

Affected administrators should install their distribution's fixed OpenSSH package and follow its instructions for putting the fixed daemon into service. Upstream's workaround is in version 10.6p2.

If an immediate upgrade is not possible, the musl maintainer's advisory recommends disabling SSH password authentication and restarting sshd, after making sure working public-key access is available. That last check prevents a security fix from becoming a very efficient way to lock yourself out.

For a machine that was exposed, also review unexpected successful password logins, unauthorized SSH keys and unexplained services or files. Applying the fix closes this route in; it does not remove access an intruder may already have established. That is the part of this follow-up worth acting on.

Cover: archival ssh-keygen screenshot, uploaded March 2011 by Der Messer on Wikimedia Commons, CC BY-SA 3.0, unmodified. This illustrates an OpenSSH utility, not SSHole exploitation or a current key-generation recommendation.