Black Hat 2024: Secure Shells in Shambles [pdf]
i.blackhat.comThe Secure Shell (SSH) protocol has survived as an internet-facing management protocol for almost 30 years. Over the decades it has transformed from a single patented codebase to a multitude of implementations available on nearly every operating system and network-connected device.
This presentation dives deep into the Secure Shell protocol, its popular implementations, what's changed, what hasn't, and how this leads to unexpected vulnerabilities and novel attacks. An open source tool, dubbed "sshamble", will be demonstrated, which reproduces these attacks and opens the door for further research.
I didn't realise the old ssh.com codebase was patented, apart from crypto patents like RSA (or IDEA?)
See perhaps:
* https://www.ssh.com/legal/patents/
* https://patents.justia.com/assignee/ssh-communications-secur...
Those are all dated after the OpenSSH fork
SSH and other services can be further protected by Single Packet Authentication (SPA), https://github.com/mrash/fwknop
> SPA requires only a single packet which is encrypted, non-replayable, and authenticated via an HMAC in order to communicate desired access to a service that is hidden behind a firewall in a default-drop filtering stance. The main application of SPA is to use a firewall to drop all attempts to connect to services such as SSH in order to make the exploitation of vulnerabilities (both 0-day and unpatched code) more difficult.
Every now and then I use GnuPG encrypted emails (or a web form) to my servers to open the firewall for certain IP addresses. If the server can decrypt such a message it can safely act on it.
The server's default is to only allow certain network ranges to access certain ports, e.g. from my local providers or employers networks.
Presumably you sign the emails rather than encrypt them?
Otherwise anyone who knew the public key of the server (which shouldn't be presumed secret) could send an encrypted instruction, and it would be acted upon, and past encrypted instructions could be replayed.
> Presumably you sign the emails rather than encrypt them?
That's correct, encrypted and signed. Replaying wouldn't be easy because the payload contains a timestamp. The main purpose was to limit the networks which can attempt to connect to ssh and still allow me to have a fallback if I'd happen to be outside of the "usual" network ranges.
Doesn’t wireguard solve the same issue? Crypto key packet authentication?
Same question. Can someone chime in on how deploying this would be different from putting ssh behind wiregaurd? On first glance it looks like if you were ultra paranoid you could put this in front of wiregaurd and not even have to open up a udp port? Would that be an advantage to add a layer to secure wiregaurd against 0day?
> Doesn’t wireguard solve the same issue?
Presumably, but my solution is quite a bit older and just a poor man's hack from about 20 years ago ...
So instead of exposing thoroughly tested OpenSSH to the web, I’m exposing this thing, which can also run shell commands…
Just had a random thought… what about port knocking, but the combination was TOTP’d? Port knocking is visible to third parties… but if the combination was a TOTP nonce, guessing the correct combination would be fairly difficult.
Didn’t have a beef with the general idea or the cryptography (assuming that some form of replay protection was already baked-in) so much as the idea that exposing a novel, less-tested, non-trivial service is a security win. If the implementation (TOTP or not) were dead-simple, I think SPA would be a win, but as soon as we get to dynamic cross-platform firewall-fiddling and custom commands, we are no longer in “dead-simple” territory.
There are many points made in the presentation, including that a significant number of ~~targets~~ hosts are not running OpenSSH. See the list and the claims that some classes of them are important.
The swipe at "running shell commands" isn't very credible, but the second attack surface is legitimate.
4th bullet from the bottom sounds credible to me:
> Supports the execution of shell commands on behalf of valid SPA packets.
Even if it were only a statically configured command (no idea if it is or isn't), as soon as that door is opened, it leads to a morass.
That is interesting! Is this widely used or are there downsides I am not seeing?
> is this widely used
Single Packet Authorization (SPA) is an architectural pattern of modern cloud security ("Software-Defined Perimeter"), with multiple OSS and proprietary implementations, https://cloudsecurityalliance.org/artifacts/software-defined...
UDP-based SPA provides the following security benefits to the SPA-protected server: ● Blackens the server: The server will not respond to any attempted connections from any remote system until they have provided an authentic SPA that is valid for that SDP system. Specifically, the host will not respond to a TCP SYN, thereby avoiding the disclosure of any information to a potential attacker. ● Mitigates Denial of Service attacks on TLS: Internet-facing servers running the HTTPS protocol are highly susceptible to Denial-of-Service (DoS) attacks. SPA mitigates these attacks because it allows the server to reject unauthorized connection attempts before incurring the overhead of establishing a TCP or TLS connection and therefore allowing authorized connections during and in spite of DoS attacks. ● Attack detection: The first packet to an AH from any other host must be a SPA packet. If an AH receives any other packet, it should be viewed as an attack. Therefore, the SPA enables the SDP to determine an attack based on a single malicious packet.Dependencies of reliable Pinholing-by-SMTP are but not limited to:
- reliable SMTP hopping
- a working SMTP account
- pinholer is up and running and robust against DoS/DDoS.
- replayability of PGP (use TOTP in original message as well as wrapper of encrypted SMTP payload)
> Tons of issues in the periphery
I wonder how TinySSH[1] compares
a lot to grasp in this one. anyone know if a video is available ?
Usually will be in the weeks or months after. I don’t know what the reasons are for the variance though.
If you use YouTube, subscribing there should get you notified when defcon starts releasing them all.
What is the fancy htop-like program displayed on page 44?
It reminds me of the DeLorean dashboard in Back To The Future :)
Reading your comment I was putting my money on a customized glances - but after checking the slide... Nope, that's just the default view for btop++ (first screenshot in the link)
Wow, thank you so much for showing me this. I'll check out glances, too.
Any other badass TUI dashboards out there?
I wish there were a way to expose these as webpages.
Glances can be started in server mode/exposed as website
https://glances.readthedocs.io/en/latest/quickstart.html#web...
Wrt other CLI apps: the only way to find out about them is to randomly explore, check out projects. I.e. take anything from here https://github.com/agarrharr/awesome-cli-apps
Most people call that procrastinating though ◉ ‿ ◉
;) thanks for making my day ffsm8, cheers.
It looks like btop. One of my favorites.
Looks like bashtop
Great presentation.
As the founder of teclada.com, I'll also share that one of the biggest risks is not even technical but human:
- not managing your SSH keys properly
- not even knowing where they are
- reuse, copying, etc
- forgotten placement of keys in authorized_keys
- "no way I'm going to even consider changing any of it"
- "our audit logs are .bash_history"