Recommended
More Related Content
What's hot
What's hot (20)
Similar to Watch How the Giants Fall
Similar to Watch How the Giants Fall (20)
More from jtmelton
More from jtmelton (7)
Recently uploaded
Recently uploaded (20)
Watch How the Giants Fall
- 1. Watch How The Giants Fall John Melton @_jtmelton
- 2. Agenda • intro • for each bug • understand issue • understand fix • pointers to helpful tools • wrap-up
- 3. Intro • Security bugs are just bugs • There are many types (714 weaknesses in CWE across 237 categories) • They go by many names (frustratingly inconsistent) • There is a wide range of complexity • There is no such thing as a “top 10” for you (see ecological fallacy)
- 4. A few bugs … • Account Takeover • Direct Object Reference • XXE • XSS • RCE • OS Command Injection • Subdomain Takeover • CSRF • Sql Injection • Insecure 3rd party libraries • Missing Access Control • SSRF • Parameter Pollution • Privilege Escalation • Insecure Configuration • Deserialization • Authentication Bypass • Hardcoded Password
- 5. 1 / 21
- 7. Insecure 3rd Party Libraries From Apache: “It is possible to perform a RCE attack with a malicious Content-Type value. If the Content- Type value isn't valid an exception is thrown which is then used to display an error message to a user.” (also Content-Disposition, Content- Length)
- 8. Insecure 3rd Party Libraries From NVD: “The Jakarta Multipart parser in Apache Struts 2 2.3.x before 2.3.32 and 2.5.x before 2.5.10.1 has incorrect exception handling and error-message generation during file-upload attempts, which allows remote attackers to execute arbitrary commands via a crafted Content-Type, Content-Disposition, or Content-Length HTTP header, as exploited in the wild in March 2017 with a Content-Type header containing a #cmd= string.”
- 9. Insecure 3rd Party Libraries Actual problem: Input validation fails insecurely -> throws Exception to user -> OGNL -> RCE !
- 10. Insecure 3rd Party Libraries Recommendations: • OWASP Dependency-Check (many others) • Upgrade dependencies regularly • CI/CD with tests
- 11. 2 / 21
- 13. Account Takeover “Through the endpoint at /rt/users/ passwordless-signup it is possible to change the password of any Uber user, given knowledge of their phone number (or by just enumerating phone numbers until one is found that is registered with Uber - not too hard given the number of Uber users).”
- 14. Account Takeover
- 15. Account Takeover Recommendations: • Authenticate / re-authenticate important activities • Consider behavioral analysis
- 16. 3 / 21
- 18. XXE “I've identified an XXE vulnerability in the cloudhopper sxmp servlet on sms-be- vip.twitter.com which discloses local files to an external attacker and allows web requests to be sent.”
- 19. XXE ç
- 20. XXE Recommendations: • Avoid XML processing if possible • 3rd party lib dependency mgmt steps • OWASP XXE Prevention Cheat Sheet • Proper XML lib configuration
- 21. 4 / 21
- 22. Remote Code Execution (RCE) via OS Command Injection https://hackerone.com/reports/212696
- 23. RCE “The y parameter of /edit/process endpoint (with a=crop) is vulnerable to command-line argument injection to something that appears to be GraphicsMagick utility (probably gm convert). Due to GraphicsMagick's hacker- friendly processing of |-starting filenames supplied to -write option, it leads to command execution.”
- 24. RCE
- 25. RCE Recommendations: • OWASP Injection Prevention Cheat Sheet • Strict input validation • Map commands if possible (3 -> ping) • Encode output parameters
- 26. 5 / 21
- 28. Subdomain Takeover 1. Buy a domain at a hosting site (123xyz.hosting.com) 2. Get a vanity domain (2017event.mysite.com) 3. Create cname record for vanity -> hosting 4. Hosting site expires (not needed anymore), but cname is still there 5. Attacker registers hosting domain 6. Vanity domain now points to attacker site
- 31. Subdomain Takeover Where 2340488 is the template id you want to update & url is your vulnerable target.
- 32. Subdomain Takeover Recommendations: • Actively manage network infrastructure
- 33. 6 / 21
- 35. Missing Access Control “The WP REST API WordPress plugin fails to apply access controls for the 'edit' context. This means that with a single HTTP request, an attacker can obtain the following information for every single registered user: username, email address, first name, last name, date of registration, and detailed privilege information. This is a treasure trove of information for someone planning an attack - they know exactly which email addresses to target in order to gain admin privileges and complete control over the webserver.”
- 36. Missing Access Control To replicate this issue, simply send the following request while unauthenticated:
- 38. Missing Access Control Recommendations: • OWASP Access Control cheat sheet • Use SAST/DAST tooling if possible • Centralize access control • Ensure all access paths are controlled
- 39. 7 / 21
- 41. SSRF “By sending a malformed HTTP request to alerts.newrelic.com, it's possible to trick that server into routing the request to an arbitrary location. This can be exploited by an internet based attacker to access internal services - doing a quick scan of I was able to access etc.”
- 42. SSRF
- 43. SSRF
- 44. SSRF “This code may look faultless - it takes the user-supplied URL, replaces the domain with the hard-coded backend server's address, and passes it along. Unfortunately the Apache HttpComponents server library failed to require that paths start with '/'. This meant that when I sent the following request: ” The code above rewrote this request as http://public- backend@burp-collaborator.net/ and routed the request to burp-collaborator.net.
- 45. SSRF
- 46. SSRF
- 47. SSRF Recommendations: • OWASP Injection Prevention Cheat Sheet • Strict input validation • Map commands if possible (3 -> ping) • Encode output parameters
- 48. 8 / 21
- 50. HPP “I would like to report an issue on Digits web authentication which allows attackers to retrieve the OAuth credential data of an application victims authorized.” “…the login page has 2 parameters, consumer_key and host. The former identifies which app a user wants to authenticate, and the latter specifies which domain the OAuth credential data is sent to after authentication. In order to prevent other websites to pretend to be the application, the host parameter will be validated to see if it matches the registered domain of the app. ”
- 51. HPP https://www.digits.com/login? consumer_key=9I4iINIyd0R01qEPEwT9IC6RE&host=https %3A%2F%2Fwww.periscope.tv host=https://www.periscope.tv matches the registered domain If we modify it: https://www.digits.com/login? consumer_key=9I4iINIyd0R01qEPEwT9IC6RE&host=https %3A%2F%2Fattacker.com host=https://attacker.com does not match the registered domain, thus the page will show an error.
- 52. HPP However, the validation can be bypassed with HPP (HTTP Parameter Pollution). If we supply multiple host parameters, the validation will only compare the first one but the last one is used in the transfer step instead. https://www.digits.com/login? consumer_key=9I4iINIyd0R01qEPEwT9IC6RE&host=https %3A%2F%2Fwww.periscope.tv&host=https%3A%2F %2Fattacker.com The first host (host=https://www.periscope.tv) is validated but not the second one. After authentication the second host (host=https://attacker.com) is used as the transfer origin.
- 53. HPP
- 54. HPP Recommendations: • Understand the way your language / framework / server handles multiple parameters of the same name • Understand server and client side HPP • Input validation for HPP (reject/report)
- 55. 9 / 21
- 56. Insecure Direct Object Reference (IDOR) https://hackerone.com/reports/164649
- 57. IDOR “Insecure direct object reference on studio.twitter.com. Impact: 1) Can tweet from someone else's account by simply using owner_id (user id of twitter) which is publicly available. 2) Can delete media from victim's account. 3) Can upload media from victim's account. 4) can view private media uploaded in victim's account.”
- 58. IDOR
- 59. IDOR Recommendations: • OWASP Access Control cheat sheet • OWASP Insecure Direct Object Reference Prevention Cheat Sheet • Consider an object reference map (object id - > guid)
- 60. 10 / 21
- 62. Privilege Escalation “The project export feature serializes the user objects of team members and stores it in the project.json file. This object contains the authentication_token for every user, meaning that an attacker can simply go ahead and create a project on GitLab.com, add one of the admins of GitLab.com, create an export, and obtain the authentication token for that user.”
- 63. Privilege Escalation Follow these steps to reproduce the issue: • create a test account on a GitLab instance and create a temporary repository • invite an admin of the GitLab instance as a team member to the repository • go to the repository settings and create an export • wait a few minutes until you received the export email • now go to http://gitlab-instance/account/repo/download_export • unzip the downloaded file and examine projects.json - the project_members will contain the user object that contains the authentication_token
- 64. Privilege Escalation Here's the first few bytes of rspeicher (sorry Robert) his authentication token on GitLab.com: ZyhqJr4XJZ.... Someone could get access to GitLab's admin panel by extracting the token of an admin and go to https://gitlab.com/admin/users? authentication_token=<token>. From what I've seen on my own GitLab instance, this leads to RCE and gives me access to all code in private repositories. Also, because the entire user object is serialized, the hashed password, OTP secrets, hashed backup codes, hashed confirmation tokens are all leaked into the response as well. I demonstrated the exploitability of the attack with the authentication token, because that one is stored without any form of hashing or encryption in the database.
- 65. Privilege Escalation Recommendations: • Be very careful in what you export • Authenticate/re-authenticate important actions • Use 2FA
- 66. 11 / 21
- 68. Insecure Configuration “An ACL misconfiguration issue existed on one of our S3 buckets. This misconfiguration allowed any authenticated AWS user to write to this bucket (no read access was permitted). An attacker could theoretically post a file into that bucket that may at some point be accessed by a HackerOne staff member, thinking it's been uploaded by another staff member or some automated system.”
- 70. Insecure Configuration Recommendations: • Understand the systems you are using, specifically their default configurations • Regularly audit (automate) your configurations
- 71. 12 / 21
- 73. Insecure Deserialization “I found an open JMXInvokerServlet/EJBInvokerServlet and normally I should be able to get a shell just by doing that. However I think due to some egress filtering on the box I've been having issues getting a shell to run.” Invokers: https://card.starbucks.in/invoker/EJBInvokerServlet and https://card.starbucks.in/invoker/JMXInvokerServlet Command to output serialized data to a file: $ java -jar ysoserial-0.0.4-all.jar CommonsCollections1 'cmd.exe' > serialdata This puts the serialized data for executing cmd.exe into a file that I can then paste into burp.
- 75. Insecure Deserialization Recommendations: • OWASP Deserialization cheat sheet • Secure deserialization config • 3rd party lib dependency mgmt steps • ‘transient’ keyword • Consider java agent
- 76. 13 / 21
- 78. Insecure Design “There is a vulnerability in Vimeo which allows any user to watch password video without the password. A user can like a passworded video without password, then the user can watch the video on Couchmode without the password.”
- 79. Insecure Design
- 80. Insecure Design Recommendations: • Carefully consider interactions across features • Don’t actually depend on security by obscurity • Emit as little metadata as possible
- 81. 14 / 21
- 83. Insecure Design “I found a way to become a verified GitLab team member on Slack. By doing so, I gained access to dozens of channels possibly containing sensitive information. ”
- 84. Insecure Design
- 85. Insecure Design
- 86. Insecure Design
- 87. Insecure Design
- 88. Insecure Design
- 89. Insecure Design Recommendations: • Threat Model your applications • Consider a bug bounty • Hire smart people
- 90. 15 / 21
- 92. Insecure 3rd party software “The story begins when I started looking at https://drive.uber.com/ukmarketplace/ welcome/, at the first glance I noticed that you are running WordPress 4.4.2 (which you probably know is outdated now [1] ). So first you need to update to the latest version to patch the publicly known vulnerabilities.”
- 93. Insecure 3rd party software “When I looked at the plugins, all of them were up-to- date. However, when I looked up WordPress plugins for q-and-a plugin, I could not find it. It was removed from WordPress. So I googled any known vulnerabilities in the plugin and I found that it's vulnerable to Full Path Disclosure but the technical details of the vulnerability went down when OSVDB decided to go down [2]. Communicated developers but said it's no longer supported, and contacting you without a solid bug in hand would be useless, So I decided to download the latest known version from WordPress Plugin Repository [3] -Which is the one you are running (1.0.6.2)- and try my luck.”
- 94. Insecure 3rd party software “I discovered that one endpoint is vulnerable to 2 SQL injection vulnerabilities due to non- escaping of certain parameters” “XSS … not possible to exploit remotely because the page is protected by CSRF nonce which is hard to obtain so remote attack vector will eventually fail. but since it is stored XSS, a malicious administrator can use it to inject javascript code into adminpanel.”
- 95. Insecure 3rd party software Recommendations: • You own the security of 3rd party software • Secure your supply chain
- 96. 16 / 21
- 98. Insecure Configuration “I discovered a critical information disclosure bug via an exposed Jenkins dashboard located at https://jenkins101.udemy.com. Upon navigating to this address, I was presented with a Github authentication page. After authenticating, I was surprised to find that I had complete read access to the corresponding Jenkins Dashboard. Contained within the dashboard was the complete Udemy source code, including the keys for various Udemy services.”
- 100. Insecure Configuration Recommendations: • Configure authentication properly
- 101. 17 / 21
- 103. Hardcoded Password Podfile left inside application exposes GitHub Password for Shopify. Impact: Access to all source code of all programs Shopify makes, which would not be good :)
- 104. Hardcoded Password
- 105. Hardcoded Password Recommendations: • Remove hardcoded passwords • Evaluate secure introduction options
- 106. 18 / 21
- 107. SSRF -> Key Disclosure https://hackerone.com/reports/285380
- 108. SSRF -> Key Disclosure I've found that you can SSRF to 169.254.169.254 using the domain check feature. Private keys disclosed. Simple browse to https:// www.threatcrowd.org/domain.php? domain=169.254.169.254/latest/meta-data/ iam/security-credentials/prod-otxb- threatcrowd-cluster- EC2Role-1H63H5KFD8KV4
- 109. SSRF -> Key Disclosure So what happens here is that 169.254.169.254 is your EC2 instance local IP address. The directory /latest/meta-data contains a lot of informations on the EC2 instance, like AWS keys. Using the SSRF vulnerability in the domain check functionnality, I can ask your server to get information from that local address, so you may want to add some filtering.
- 110. SSRF -> Key Disclosure Recommendations: • OWASP Injection Prevention Cheat Sheet • Strict input validation • Map commands if possible (3 -> ping) • Encode output parameters
- 111. 19 / 21
- 113. Insecure 2FA Design In short, testing out your 2FA implementation, I noticed that there is limited protection against brute forcing. It appears the only protection is rate limiting and a time limited token from the Google authenticator app. With the time drift, a token is valid for 60 seconds. It appears that initially, an attacker can submit anywhere from 10 - 19 requests to validate a 2FA before rate limiting kicks in. This then stops the attacker for, what appears to be, 30 - 40 seconds (in some tests it was less). Then an attacker can submit the username and password and submit another 9 requests before rate limiting stops them again. While these numbers may be off slightly, for arguments sake, let's say they can submit 20 request per valid token.
- 114. Insecure 2FA Design Since tokens are 6 digits long, we have a 20 in 1,000,000 chance of being right (or 0.00002). So, on that note, if we made 5,000 attempts (of 20 guesses per minute) at the token, we'd have a 9.5% chance of finding the right one at least once in 3.5 days (5,000 attempts = 5,000 minutes = 83.3 hours = 3.47 days). 10,000 attempts would take approximately 7 days and yield an 18% chance (I used this calculator http://stattrek.com/online-calculator/binomial.aspx) Compounding the issue, during the attacker, a victim and admin get no notification / impact on service. The victim can still log in and use their account while the attacker is guessing a valid token, no email is generated to indicate someone is attempting to compromise their account (at least in the 5 or 6 times I ran the test) and I couldn't find anything in the web based logs for the admin account. That said, because I'm not overly familiar with the platform and didn't run this for the full day, maybe I'm missing some notification system. If so, I apologize.
- 115. Insecure 2FA Design In addition to the above, I noticed that there is also limited protection against guessing a password. After X number of attempts at guessing a password incorrectly, an account does become locked, an email sent to the victim and the attacker is never notified. But, while the account is locked, if an attacker guesses a correct password, they are still redirected to the 2FA screen to confirm a token rather than being stopped. So, while the account is locked, an attacker still is able to confirm a victim's password.
- 116. Insecure 2FA Design Recommendations: • General rate-limiting • Limit attempts per token • Limit attempts per account • Notify the victim of attempts • Do not allow further attempts after lock
- 117. 20 / 21
- 118. Privacy
- 119. Privacy
- 120. Privacy Recommendations: • Collect as little data as possible • Delete data as quickly as you can • Comply with policies and regulations • Threat Modeling
- 121. 21 / 21
- 122. Meltdown / Spectre https://meltdownattack.com/meltdown.pdf https://spectreattack.com/spectre.pdf
- 123. Meltdown / Spectre
- 124. Meltdown / Spectre Recommendations: • Patch • ¯_( )_/¯
- 125. So … what now?
- 126. There is hope … • Follow security design principles • Keep knowledge current • Spend effort throughout SDLC • Work on prevention, but also detection and response • Patch • (try bug bounties - make some extra $)
- 127. Questions • twitter: _jtmelton • github: jtmelton • email: jtmelton@gmail.com