Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Security Risk Advisors - BSides Philadelphia 2017 - MFA: It's 2017 and You're Still Doing It Wrong

542 views

Published on

We can all agree that having single-factor remote access gateways (VPN, Citrix, Remote Apps, etc.) exposed on the internet is a poor decision and a large security risk. These portals, can allow for a direct connection into the internal corporate environment. Once there, an attacker can begin to identify internal vulnerabilities, move laterally, escalate privileges, persist, and hoover out all the data they want. Fortunately, these portals are increasingly behind a multi-factor solution (phone call, hard/soft token, certificate, etc.). While this does help to reduce the attack surface from a direct brute force (username and password), there are often overlooked options or misconfigurations that can allow an attacker to bypass this solution or directly disrupt business operations. In this talk we’ll be covering methods that we’ve used to bypass MFA solutions to obtain internal network access from the internet.

Published in: Technology
  • Be the first to comment

Security Risk Advisors - BSides Philadelphia 2017 - MFA: It's 2017 and You're Still Doing It Wrong

  1. 1. MFA: IT’S 2017 AND YOU’RE STILL DOING IT WRONG
  2. 2. Who We Are Dan Astor @illegitimateDA Position: Senior Consultant Focus: Offense Chris Salerno @secrisk Position: Director Focus: Defense
  3. 3. Agenda › MFA Overview › Email › Self-Service › RemoteApps › Shared MFA › Social Engineering › Internal MFA Bypasses
  4. 4. 1. Overview
  5. 5. Overview › MFA: Multi-Factor Authentication › “Something” in addition to a password › Push, Call, Soft Token, Hard Token, SMS, Email, etc. › Certs? › External & Internal Services
  6. 6. Why Are We Having This Talk? ›We’re Past This... (sorta) 1.https://www.youtube.com/watch?v=UduILWi2p6s
  7. 7. Why Are We Having This Talk? › External > Internal is still a thing › Your Disaster Recovery VPN is still a VPN › You have a group of users where MFA “just won’t work” › But really…it’s because…
  8. 8. 2. Email
  9. 9. It’s Just Email… › We see many environments with MFA on all the “remote access portals” but not on email. › O365, OWA, Notes, etc. › Password Spraying always works. › Rarely detected
  10. 10. Attacks on OWA › Usually easy to identify › autodiscover › If you cannot identify the “web portal” try to connect to the Exchange service with a thick client or other tool o https://github.com/sensepost/ruler o https://github.com/dafthack/MailSniper
  11. 11. OWA web portal is 2FA; using a client to connect to the exchange service is only 1FA though. Use Ruler or other OWA service bruteforce tool to perform password spraying.
  12. 12. Attacks on O365 › Easy to identify, use any O365 login (portal.office.com) › Redirects to correct URL or logo appears › PowerShell modules for MSOL & AzureAD › Harvest all the info you can (Users, Groups, etc.)
  13. 13. Using the AzureAD Modules to connect to the environment and pull all users (can also get cloud groups) https://technet.microsoft.com/en-us/library/dn975125.aspx https://docs.microsoft.com/en-us/powershell/azure/active-directory/install-adv2
  14. 14. Mailbox Pilfering › Usually contain interesting files › Search for: password, RSA, Duo, MFA, VPN, etc. › VPN soft-tokens emailed  › MailSniper
  15. 15. Perform searches for sensitive information and attachments (VPN tokens, etc.)
  16. 16. Outlook Attacks for Shells › Forms - create a malicious form in the users inbox o https://sensepost.com/blog/2017/outlook-forms-and-shells/ › Rules – create a rule that will execute your code (or trigger your form) o https://silentbreaksecurity.com/malicious-outlook-rules/
  17. 17. 3. Self-Service
  18. 18. I’ll Just Help Myself… › Self-Service portals are for users to help themselves out instead of calling the service desk. › External self-service for MFA… What could be bad about that?
  19. 19. Example RSA self-service portal
  20. 20. Self-Service Attacks › Register a new device (your device) › Obtain an emergency access token (EAT) › Great post from Alex Leary from NetSpi on EAT’s o https://blog.netspi.com/targeting-rsa-emergency-access-tokencodes- fun-profit/
  21. 21. After authenticating we attempt to register a new device. Once approved, we get the email to import our token.
  22. 22. 4. Microsoft RemoteApp
  23. 23. Microsoft RemoteApp Servers › RemoteApp concept is very similar to something like Citrix XenApp › Users login to a portal, and can launch individual applications hosted on the server. Applications are accessed over RDP.
  24. 24. Example RemoteApp login
  25. 25. RemoteApp Auth › RemoteApp supports auth from SSO (pass-through), but can also do direct MFA (i.e. Duo plugin) on the login. › If you can directly connect to the connection broker, you can bypass the MFA (TCP 3389)
  26. 26. You can use the built-in RemoteApp client to connect to the service. This will bypass the SSO as it connects directly to the service (Similar to OWA slide).
  27. 27. 5. Social Engineering
  28. 28. The Scenario › Do OSINT for employees that fit the role you want to use. › Identify the helpdesk #’s (may have to call other numbers to obtain) › Attempt to get a password or MFA token reset › Don’t forget about web based chat
  29. 29. Helpful Tips for Calls › Play dumb. Like really dumb… › They want to get you off the phone › The more frustrated they get the more likely they’ll just do what you need. › Once had a rep tell us, “it’s a thinking problem”
  30. 30. Using web based chat, we get a password reset and MFA token setup with our device. Helpful to have the most common MFA solutions on a device with you (RSA, Duo, Symantec, etc.)
  31. 31. Using our device code and the password that was reset, we can now authenticate to the MFA portal.
  32. 32. 6. Shared MFA
  33. 33. Story Time… › Password spraying on what appeared to be a 1FA portal. › Several successful accounts, but then 2FA stopped us. › Randomly some accounts just always allow us in?
  34. 34. Further Inspection... › The account we found exhibiting this behavior was confirmed to be configured with 2FA. › Account owner had told interns, “If this phone ever rings, answer and hit 1.” › Don’t’ crowdsource your MFA… ¯_(ツ)_/¯
  35. 35. 7. Internal MFA
  36. 36. Remote Desktop › Place MFA on a “jump host” (RSA, Duo, etc.) for interactive logins › When using RDP you are forced to enter a passcode › Network logins are still 1FA (map share, execute commands remotely)
  37. 37. When using RDP, you get prompted for your passcode. When doing a network call to the host, no MFA is required.
  38. 38. Hypervisors › Highly sensitive zone is completely segmented from the user network. › MFA jump boxes are the only way into the zone and ACLs are properly configured. › Look for hypervisors (vCenter, vSphere, XenCenter, etc.) that may control the zone from a zone you have access to.
  39. 39. Access to vSphere was 1FA. Once in, the “sensitive” servers are all accessible through the hypervisor. Also, they had open sessions.
  40. 40. Dual NIC Monitoring Servers › Highly sensitive zone is completely segmented from the user network. › MFA jump boxes are the only way into the zone and ACLs are properly configured. › Look for system monitoring servers (ie. Nagios)
  41. 41. Identified a Nagios server that was dual NIC’d into the zone. Use a port forward script to punch a hole through from our VM to the target host (mssql database). https://securityriskadvisors.com/blog/post/plastic-beach-gaining-access-to-cdes/
  42. 42. 5 Things to Remember 1. MFA all the things 2. Test your service desk and self-service 3. Monitor your logs 4. Expire your OTP’s 5. Think like an attacker
  43. 43. THANKS! Any questions? You can find us at: @illegitimateDA · @secrisk Presentation template by SlidesCarnival

×