Black Hat 2024: Secure Shells in Shambles [pdf]

https://i.blackhat.com/BH-US-24/Presentations/REVISED02-US24_Moore_Secure_Shells_in_Shambles_Wednesday.pdf

by hdmoore • 2 years ago

101 30 2 years ago

i.blackhat.com

hdmoore• 2 years ago

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.

https://github.com/runZeroInc/sshamble

mkj2• 2 years ago

I didn't realise the old ssh.com codebase was patented, apart from crypto patents like RSA (or IDEA?)

throw0101d• 2 years ago

See perhaps:

* https://www.ssh.com/legal/patents/

* https://patents.justia.com/assignee/ssh-communications-secur...

transpute2• 2 years ago

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.

jcynix3• 2 years ago

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.

anotherhue• 2 years ago

Doesn’t wireguard solve the same issue? Crypto key packet authentication?

g_p• 2 years ago

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.

ykonstant• 2 years ago

That is interesting! Is this widely used or are there downsides I am not seeing?

egberts1• 2 years ago

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)

transpute2• 2 years ago

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.

hello_computer3• 2 years ago

So instead of exposing thoroughly tested OpenSSH to the web, I’m exposing this thing, which can also run shell commands…

fn-mote• 2 years ago

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.

exabrial• 2 years ago

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.

tzury• 2 years ago

a lot to grasp in this one. anyone know if a video is available ?

baby_souffle• 2 years ago

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.

mrbluecoat• 2 years ago

Tons of issues in the periphery

I wonder how TinySSH[1] compares

[1] https://github.com/janmojzis/tinyssh

metadat3• 2 years ago

What is the fancy htop-like program displayed on page 44?

It reminds me of the DeLorean dashboard in Back To The Future :)

ffsm82• 2 years ago

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)

https://github.com/aristocratos/btop

metadat3• 2 years ago

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.

ndegruchy• 2 years ago

It looks like btop. One of my favorites.

halJordan• 2 years ago

Looks like bashtop

davidfiala• 2 years ago

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

And worst of all:

  - "no way I'm going to even consider changing any of it"
  - "our audit logs are .bash_history"

¯\_(ツ)_/¯

Black Hat 2024: Secure Shells in Shambles [pdf]

Related Stories