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.
The server's default is to only allow certain network ranges to access certain ports, e.g. from my local providers or employers networks.
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.
The swipe at "running shell commands" isn't very credible, but the second attack surface is legitimate.
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.- 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)
I wonder how TinySSH[1] compares
If you use YouTube, subscribing there should get you notified when defcon starts releasing them all.
It reminds me of the DeLorean dashboard in Back To The Future :)
Any other badass TUI dashboards out there?
I wish there were a way to expose these as webpages.
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"