[OPD 2019] Inter-application vulnerabilities
Download as PPTX, PDF0 likes218 views
This document discusses hunting for vulnerabilities across interconnected applications. It describes two cases where the author found multiple vulnerabilities by exploring dependencies between applications. In the first case, they discovered vulnerabilities by interacting with a desktop application and related web applications from the same company, finding 5 vulnerabilities including XSS issues and information disclosures. In the second case, they used a single sign-on system across multiple applications to introduce persistent XSS vulnerabilities. The document advocates considering how applications integrate and interact to uncover "inter-application vulnerabilities" that may not be found through isolated testing.
[OPD 2019] Inter-application vulnerabilities
- 1. Inter-application vulnerabilities hunting for bugs in secure applications Marcin Szydlowski @securityksl OWASP Poland Day - Wroclaw 16th of October 2019
- 2. #whoami • Marcin Szydlowski (@securityksl) • Worked as a cybersecurity consultant (pentests, red team, etc.) • Currently responsible for secure system deployment in a global company • Bug bounty hunter & member of Synack Red Team (rank 0x03) • Participated in programmes such as Hack the Pentagon, United Airlines and number of private programmes via Synack and HackerOne
- 3. Hunting for bugs in secure applications • Changed company, started to participate in Bug Bounty programmes regularly • Regularly does not mean full-time (nor part-time) • Dark side of bug bounty programmes exists
- 4. Problem statement How to find unique vulnerabilities in web applications of security-mature companies in a limited time?
- 5. How your pentest environment looks like? HTTPS test.example.comUser
- 6. How the production environment looks like? HTTPS example.comUser mail.example.com user.example.com legacy.example.com
- 7. How the production environment looks like in 2019? HTTPS api.example.com example.com User mail.example.com user.example.com legacy.example.com Caching server/LB/WAF OAUTH other.example.com S3 example.com HTTPS HTTPS
- 8. Who covers the delta? • „Only ZYX functionalities are in scope” • „E-mail sending is disabled not to flood our helpdesk with e-mails” • „Test environment is isolated from the Internet for security reasons” • „XYZ functionality is out of scope as it is not ready yet” • „Other components have already been tested by other independent companies” • „Integration with other systems will be performed once we know our application is secure” Integration testing to the rescue?
- 9. What is in scope of integration testing? Integration testing (sometimes called integration and testing, abbreviated I&T) is the phase in software testing in which individual software modules are combined and tested as a group. Integration testing is conducted to evaluate the compliance of a system or component with specified functional requirements.
- 10. Integration testing - Venn diagram People who understand system B People involved in integration testing Pentesters (security people) People who understand system A
- 11. Integration testing – reality kicks in People who understand system A People who understand system B Pentesters (security people) People involved in integration testing
- 12. Am I exploiting the technology or the process? • Web application security testing covers only specific components of the system as it is often performed on isolated or non-fully developed environment • Pentesters often do not understand the business process behind the application • Various applications (system components) are tested by various teams (or even companies) • Responsibility for integration testing is often blurred • Security is not the first priority of integration testing PROFIT!!! Acceptance rate - 44% 27 unique vulnerabilities reported in 11 months Probably testing for less then 5 hours/week on average
- 13. The Definition Inter-application vulnerabilities - Vulnerabilities, which require playing with at least two different systems (or system components) to be exploited successfully.
- 14. Case #1 - Story of a desktop application • Major international company • Set of web applications in scope • No vulnerabilities identified in the last couple of months • Google recon identified that users e-mail addresses are disclosed via Google searches as they are transmitted in GET parameter • It was not possible to identify that particular endpoint during application walkthrough Some other application component must exist
- 15. Money for nothing and XSSes for free • Desktop application of that vendor publicly available for download after registration • Most of the functionalities were not resulting in any requests being sent to the web server, but... • License renewal and forgot password functionalities resulted in HTTP requests with the parameters never encountered before. • Two XSSes with <script>alert(1)</script> payload right away (Bounty! X2). • Forgot password mechanism - root cause of e-mail address disclosure identified (Bounty!) • More was yet to come...
- 16. Fun part begins • So how this license renewal mechanism actualy works? POST /license.aspx Host: renewal.example.com ID=123456 renewal.example.com User Here is your license number! AVX123ZSAJ1213124 I’m redirecting you to buy.example.com And by the way here you also have license numbers of other users as this is clearly vulnerable to IDOR... This is my license number and I’m authenticated as Marcin I want to renew my license. buy.example.com Redirecting you to payment page where you have info on subscribtion days left
- 17. What confidential actually means? • So we have a huge number of license IDs – potentially all of them. • Do not mix license IDs with license keys. • Who really knows if some data is confidential? What makes it confidential? • License numbers allows you to get more info on product type and number subscription days left • Not really confidential data :( • But...
- 18. Inter-application dependency kicks in! • There is one more web application of the same vendor, which allows (surprise surprise) to renew licenses • So you are authenticated in the application, you provide your license ID and you are redirected to the very same payment page. • But what happens when you are not authenticated?
- 19. Inter-application dependency kicks in! POST /license.aspx Host: renewal2.example.com LicenseID=AVX123ZSAJ1213124 You need to authenticate. Let me redirect you to the login web page. I will provide the e-mail address associated with this LicenseID to speed up authentication process. renewal2.example.com User Insecure direct object reference leads to disclosure of e-mail addresses of all customers (Bounty!)
- 20. We are not done yet. So we are redirected to authentication web page and our e-mail is automatically submitted. How does it work? GET /redirect.aspx?email=ksl@test.com&othe rparameters... Host: renewal2.example.com renewal2.example.com User You need to authenticate. Let me redirect you to the SSO web page. I will provide e-mail address associated with this LicenseID automatically. Login page with your email sso.example.com 302 – let me redirect you to sso.example.com?code=base64string (not decryptable)
- 21. We are not done yet. So we are redirected to authentication web page and our e-mail is automatically submitted. How does it work? GET /redirect.aspx?email=”><script>alert(1 )</script>&otherparameters... Host: renewal2.example.com renewal2.example.com User You need to authenticate. Let me redirect you to the SSO web page. I will provide e-mail address associated with this LicenseID automatically. Login page with your email. XSS in e-mail field! sso.example.com 302 – let me redirect you to sso.example.com?code=base64string (not decryptable) Reflected XSS on login page (Bounty!)
- 22. Case #1 - Summary • 3 Reflected Cross-Site Scriptings on critical subdomains • One IDOR vulnerability leading to complete disclosure of customer database (e-mails) • Incorrectly set indexing protection leading to disclosure of user e-mails in Google • 5 bounties for 5 vulnerabilities identified only by downloading a single desktop application • Identified XSSes were exploitable with basic XSS payload - <script>alert(1)</script> • 4 out of 5 were well-known vulnerabilities - listed in last 3 editions of OWASP TOP 10...
- 23. Case #2 - Single-sign on, multiple XSSes • Major sports web page • Set of web applications used for different purposes (subscriptions, estore, auctions, etc.) • Payouts were offered only for high/critical vulnerabilities (SQLi, RCE, Persistent XSS) • WAF in place for certain subdomains
- 24. That tricky registration mechanism • Number of applications in scope of program allowed to create account in the application • Account created in any of these web apps was valid for all the other applications in scope • User e-mail address was published in each of these web applications – in most cases it was encoded • Filtering mechanism existed during registration, emails address needs to be provided in a valid format But what actually is a valid format for e-mail addresses?
- 25. What actually is a valid e-mail format? • E-mail address format is defined in RFC 5321 and RFC 5322 • Better explained in Wikipedia • This makes ”<script>alert(1)</script>”@gmail.com address completely fine from the RFC perspective • Most of the web pages does not allow to register yourself with these addresses.... But some do
- 26. Let the persistent XSSes begin! • One of these web pages in scope allowed to register yourself with ”<script>alert(1)</script>”@gmail.com address, however it encoded malicious characters properly • However, some other web page in scope did not allow funny e-mail addresses, but output encoding mechanism was not there • Remember that tricky registration mechanism? • Most likely the only impacted person would be the account owner... • ... but you never know - Persistent XSS in Profile Overview section (Bounty!) ??? PROFIT!!!
- 27. Moar XSSes!!! • Seems that certain well-known applications which are often integrated with web pages also allow to use „quoted” e-mail addresses • Application in scope supported PayPal payments and PayPal supported „quoted” e-mail addresses Let me purchases that item store.example.comUser How do you want to pay? PayPal. And here is my PayPal account which is ”<script>alert(1)</script>”@gmail.com OK, mail address seems valid, I’m redirecting you to PayPal web page
- 28. Moar XSSes!!! • Seems that certain well-known applications which are often integrated with web pages also allow to use „quoted” e-mail addresses • Application in scope supported PayPal payments and PayPal supported „quoted” e-mail addresses paypal.comUser I can see that you are ”<script>alert(1)</script>”@gmail.com and you are coming from store.example.com. Authenticate yourself to pay with PayPal. Changed my mind, I’m cancelling the payment. No worries, let me redirect you back to store.example.com
- 29. Noone expected the scope change! • store.example.com has a full list of successful/unsuccessful transactions with details about success/failure • PayPal e-mail address used during transaction is presented in transaction details and is not encoded • Persistent XSSes which have no clear impact on other users were excluded from program scope ??? NO PROFIT!!!
- 30. Case #2 - Summary • 2 persistent XSS identified and 1 bounty received for simple vulnerability • Excellent example why input filtering might not be enough to secure your web application • It also seems that this company does not rely on pre-approved code snippets for e-mail verification, as mechanism worked differently between applications
- 31. Case #3 – E-mails, e-mails everywhere • It is more series of cases related to e-mail sending functionalities • Web applications in scope? Pretty much everything – ecommerce, airlines, FMCG, cybersecurity • Thing in common? All of them were sending emails from the application to the end user
- 32. Case #3.1 – Me, myself and I • Well-known international web page • Couple of months without any vulnerability reported • Just by knowing Bob’s temporary e-mail address i can spoof Alan’s messages. • Bob’s temporary e-mail address is not visible in the web browser, but it is visible in JSON responses... • I can negotiate prices and contract terms with myself, non-repudiation is being affected (Bounty!) ecommerce.comBob I want to Chat with Alan! POST Msg=Chat message:Hello World! Alan Message from: Bob <gasr23basd1axne@ ecommerce.com> Hello World! Reply to: Bob <gasr23basd1axne @ecommerce.com> Hello Bob! Chat with Alan Bob: Hello World! Alan: Hello Bob!
- 33. Case #3.2 – Spidering does not work anymore • Applications send multiple e-mails (newsletters, password reset, account activation, notifications) • URLs (functionalities) which are embedded in these e-mails are often vulnerable to numerous attacks – „Unsubscribe” functionality – vulnerable to reflected XSS (Bounty!) – IDOR in „Newsletter settings” functionality leads to unauthorized data modification (Duplicate) – „Welcome” e-mail contains URLs with parameters never encountered before (Bounty!) – Hyperlink included in e-mail vulnerable to IDOR and ultimately leads to account takeover (Bounty!) – Password reset e-mails contain URLs. User e-mail address is sent in GET parameters. Google indexes these URLs and e-mail values (Bounty! X2)
- 34. Bug Bounty Hunter/Pentester – Quick wins #1: • Register an account in your application with ”<script>alert(1)</script>”@gmail.com • Go to „My profile” section or equivalent #2: • Subscribe to all newsletters, notifications, promotions, gift cards. • Create new account, forget password, restore password, unsubscribe, delete account. • Check received e-mails for hyperlinks with fancy parameters. Look for XSSes, IDORs.
- 35. How to avoid these issues? - Basics • During testing process analyze all the application interfaces and non-standard way of inputting data • Make sure that Integration tests cover security aspects • Use defense-in-depth principle • Make sure that your TEST environment is as similar to PROD environment as possible and that scope of your security tests include all of the system components and functionalities.
- 36. How to avoid these issues? - Advanced • Ensure that you security testing team understands the business processes supported by the application and has a good understanding of the entire tested ecosystem • Regularly perform Google dorking to identify any cases of unintentional public access to sensitive data or functions • Analyze any cases of cross-system data dependencies. Implement cross-system segregation of duties wherever possible.