[HN Gopher] Black Hat 2024: Secure Shells in Shambles [pdf]
       ___________________________________________________________________
        
       Black Hat 2024: Secure Shells in Shambles [pdf]
        
       Author : hdmoore
       Score  : 79 points
       Date   : 2024-08-10 23:55 UTC (23 hours ago)
        
 (HTM) web link (i.blackhat.com)
 (TXT) w3m dump (i.blackhat.com)
        
       | hdmoore wrote:
       | 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
        
         | mkj wrote:
         | I didn't realise the old ssh.com codebase was patented, apart
         | from crypto patents like RSA (or IDEA?)
        
           | throw0101d wrote:
           | See perhaps:
           | 
           | * https://www.ssh.com/legal/patents/
           | 
           | * https://patents.justia.com/assignee/ssh-communications-
           | secur...
        
       | transpute wrote:
       | 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._
        
         | jcynix wrote:
         | 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 wrote:
           | Doesn't wireguard solve the same issue? Crypto key packet
           | authentication?
        
             | nwellinghoff wrote:
             | 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?
        
         | ykonstant wrote:
         | That is interesting! Is this widely used or are there downsides
         | I am not seeing?
        
           | egberts1 wrote:
           | 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)
        
         | hello_computer wrote:
         | So instead of exposing thoroughly tested OpenSSH to the web,
         | I'm exposing this thing, which can also run shell commands...
        
           | fn-mote wrote:
           | 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.
        
             | hello_computer wrote:
             | 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.
        
           | exabrial wrote:
           | 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.
        
             | hello_computer wrote:
             | 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.
        
       | tzury wrote:
       | a lot to grasp in this one. anyone know if a video is available ?
        
         | baby_souffle wrote:
         | 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 wrote:
       | > Tons of issues in the periphery
       | 
       | I wonder how TinySSH[1] compares
       | 
       | [1] https://github.com/janmojzis/tinyssh
        
       | metadat wrote:
       | What is the fancy htop-like program displayed on page 44?
       | 
       | It reminds me of the DeLorean dashboard in Back To The Future :)
        
         | ffsm8 wrote:
         | 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
        
           | metadat wrote:
           | 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.
        
             | ffsm8 wrote:
             | Glances can be started in server mode/exposed as website
             | 
             | https://glances.readthedocs.io/en/latest/quickstart.html#we
             | b...
             | 
             | 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 * _ *
        
               | metadat wrote:
               | ;) thanks for making my day ffsm8, cheers.
        
         | ndegruchy wrote:
         | It looks like btop. One of my favorites.
        
         | halJordan wrote:
         | Looks like bashtop
        
       ___________________________________________________________________
       (page generated 2024-08-11 23:02 UTC)