Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Beyond the Borders of Scope

JR0ch17
August 01, 2020

Beyond the Borders of Scope

JR0ch17

August 01, 2020
Tweet

More Decks by JR0ch17

Other Decks in Technology

Transcript

  1. GET /agenda HTTP/1.1 • How do I approach a new

    target? • Using out-of-scope assets to find bugs in main applications • Bug examples
  2. DO NOT HACK ON OUT-OF- SCOPE ASSETS If you do,

    I’m not responsible for it!
  3. GET /approach HTTP/1.1 1. What’s the app’s purpose? 2. Focus

    areas & bonuses 3. CTF mindset 1. Create your own flag 2. Do what it takes to find it 4. Other hackers have looked at this app 1. What did they miss? 2. What did they not think of and didn’t try 5. Find bugz 6. Get bountiez
  4. GET /out-of-scope HTTP/1.1 • Follow the rules, don’t hack on

    out-of-scope targets • We can still do passive recon though • CSP? • Who built the site? • GitHub, Stack Overflow, etc • Is the target application interacting with other applications? Any integrations?
  5. GET /bugs HTTP/1.1 • Recon on out-of-scope assets • RCE

    • Expanding your attack surface with 3rd party apps and integrations • Privilege Escalation, Information Disclosure • Adding the missing piece • XSS • Posting links to my website • IDOR, Privilege Escalation, RCE
  6. GET /bugs?id=1 HTTP/1.1 • Odd domain in CSP • Doing

    recon on it led to finding a PDF file which contained credentials • Those credentials actually had admin access => RCE
  7. GET /bugs?id=1&page=2 HTTP/1.1 With AEM, once you have admin rights,

    it’s easy to get an RCE https://github.com/0ang3el/aem-rce-bundle shout out to @0ang3el
  8. GET /bugs?id=2&page=2 HTTP/1.1 • Provides larger attack surface, especially apps

    that allow write access • Sometimes result in privilege escalation and information disclosure
  9. GET /bugs?id=3 HTTP/1.1 • Only the core app was in

    scope (app.domain.com) • Cookie-based XSS (Self XSS) • API calls were done on separate subdomain: CORS allowed all subdomains *.domain.com • Needed a way to turn this self XSS to a valid XSS • Asked the program if they’d allow me to look for a reflected XSS elsewhere to complete my chain • They gladly accepted!
  10. GET /bugs?id=3&page=2 HTTP/1.1 Attack scenario: 1. Reflected XSS on OOS

    subdomain 2. Cookie Stuffing 3. Redirect to cookie-based XSS endpoint 4. Make an XHR to the API subdomain 5. Leak information from API endpoints since all subdomains are allowed
  11. GET /bugs?id=4&example=1 HTTP/1.1 • Looking at an app (forum type)

    that used UUIDv4 everywhere • API endpoint: /api/v1/user/11bf5b37-e0b8-42e0-8dcf-dc8c4aefc000 • Web: /dashboard?user=11bf5b37-e0b8-42e0-8dcf-dc8c4aefc000 • It was possible to interact with other users • Vulnerable to IDOR but can’t brute force or guess UUIDs • Couldn’t find any way to leak other users’ UUID • The UUID was present in many places in the Referer header • What if I create a post with a URL to my site?
  12. GET /bugs?id=4&example=1&page=2 HTTP/1.1 • When a user would look at

    my post and click on the link, their UUID would leak in the Referer header • Captured a few UUIDs in my logs • IDORs confirmed
  13. GET /bugs?id=4&example=2 HTTP/1.1 • Improper authorization checks: read-only users could

    write content • Made me wonder if the admin panel was configured the same way • Didn’t know the path to the admin panel though • Directory brute force • Blind XSS • Referer header leak by putting a URL in the “Contact Us” form for a technical bug • Accessed the admin panel
  14. GET /bugs?id=4&example=3&page=2 HTTP/1.1 • Application had lots of features that

    required admin approval • Admins = Employees • GitHub recon lead to finding an internal Jenkins subdomain • jenkins.internal.domain.com • SSRF • Are admins able to access Jenkins for me? • Access request containing link to my site
  15. GET /bugs?id=4&example=3&page=3 HTTP/1.1 • Jenkins URL in the access request

    would’ve been fishy • Link to my site which redirected to the internal Jenkins RCE PoC • A while later…