The 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.
> 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.
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?
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.
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.
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)
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.
https://github.com/runZeroInc/sshamble