Uses and Abuses of Server-Side RequestsSeptember 21, 2016 G. Pellegrino - Uses and Abuses of Server-Side Requests 2 Uses and Abuses of Server-Side Requests An increasing number of

Uses and Abuses of Server-Side RequestsGiancarlo Pellegrino1, Onur Catakoglu2, Davide Balzarotti2, and Christian Rossow1

[email protected]

19th International Symposium on Research in Attacks, Intrusions and Defenses

Paris, September 21st, 2016

1 2

September 21, 2016 G. Pellegrino - Uses and Abuses of Server-Side Requests 2

Uses and Abuses of Server-Side Requests

● An increasing number of web applications use Server-Side Requests (SSRs) to fetch resources

– E.g., social networks, business applications, and many more

● SSRs adopted before security consequences were fully understood

– Simple to implement; severe consequences if not done properly

➔ Our work: first extensive assessment of SSRs security implication

1. Classification

2. Two new SSR-based attacks

3. Eight mitigations

Server-Side Requests


SSR Communication Pattern

ESSC

● Three entities: browser C, SSR service S, External Server ES



ESSCreq(url

ES )


● C provides urlES to S



ESSCreq(url

ES ) url

ES

SSR!



● S instantiates an HTTP client to retrieve urlES



ESSCreq(url

ES )

resES

resS

urlES



● S instantiates an HTTP client to retrieve urlES

● S can return either resES to C, e.g., resS = resES, or a transformation, e.g., resS = f (resES)


What are they used for?

● Share content in social networks● Import data in online documents● Security protocols (e.g., OpenID)

– avoid exposing sensitive data, e.g., security tokens, to untrusted users

● Feed aggregators● Others ...

urlES

resS


Simple to implement

ESSCreq(url

ES )

resES

resS

● HTTP client libs available in most popular programming languages

– PHP: e.g., cURL, and file_get_contents

– Python: e.g., urllib, httplib, and requests

urlES

$ssr = curl_init(); curl_setopt($ssr, CURLOPT_URL, url

ES);

curl_setopt($ssr, CURLOPT_RETURNTRANSFER, 1);$data = curl_exec($ssr);curl_close($ssr);

$ssr = curl_init(); curl_setopt($ssr, CURLOPT_URL, url

ES);

curl_setopt($ssr, CURLOPT_RETURNTRANSFER, 1);$data = curl_exec($ssr);curl_close($ssr);

ssr = urllib.urlopen(urlES)

data = ssr.read()

ssr = urllib.urlopen(urlES)

data = ssr.read()


The Problems of SSRs

● If not properly implemented, SSRs can be abused:1. as stepping stones to attack ES

2. to access local resources of S, e.g., file://, http://127.0.0.1/

3. to expose malicious content to C

4. resES can be used to attack S

● Popular abuse is Server-Side Request Forgery (SSRF) [1]

ESSCreq(url

ES )

resES

resS

urlES








ESSCreq(url

ES )

resES

resS

urlES 1








ESSCreq(url

ES )

resES

resS

urlES 12








ESSCreq(url

ES )

resES

resS

urlES 12

3








ESSCreq(url

ES )

resES

resS

urlES 12

43







● Popular abuse is Server-Side Request Forgery (SSRF)

ESSCreq(url

ES )

resES

resS

urlES 12

43


Server-Side Request Forgery

Attack payload

ESSC

● C aims to exploit vulnerability in ES or access local resources of S● ES behind a firewall that blocks direct access from the Internet● S is exposed both to the Internet and to the local network



ESSC

● SSR used to bypass firewalls and deliver attack payload to ES

– e.g.,

● SSR used to access local resources as well:

– e.g.,

req(attack payload)

resES

resS

attack payload

gopher://ES/X %EB%2A%5E%89v%08%C6 […] %FF%FF/bin/sh%00%89%EC%5D%C3URL encoded buffer overflow shell code

file:///etc/passwdFilename



ESSC

● SSR used to bypass firewalls and deliver attack payload to ES

– e.g.,

● SSR used to access local resources as well:

– e.g.,

req(attack payload)

resES

resS

attack payload

gopher://ES/X %EB%2A%5E%89v%08%C6 […] %FF%FF/bin/sh%00%89%EC%5D%C3URL encoded buffer overflow shell code

file:///etc/passwdFilename

Do we, now, know better?Do we, now, know better?


Awareness of Security Risks: The Present

● Reviewed of academic/non-academic literature and development best practices:

ESSCreq(url

ES )

resES

resS

urlES 12

43

Unawareness of risks, and guidelines on implementing SSRs are missing



● Academic/non-academic literature:– No attention from academic literature – Non-academic works focused only on SSRF➔ Attacks against C and S not considered

● Devel. best practices (design patterns, coding rules, and API doc.)– Default programming language APIs offer no defense mechanism– No patterns nor coding rules specific for SSRs➔ Lack of both proper ways to implement S and attack countermeasures

ESSCreq(url

ES )

resES

resS

urlES 12

43



● Academic/non-academic literature:– No attention from academic literature – Non-academic works focused only on SSRF➔ Attacks against C and S not considered

● Devel. best practices (design patterns, coding rules, and API doc.)– Default programming language APIs offer no defense mechanism– No patterns nor coding rules specific for SSRs➔ Lack of both proper ways to implement S and attack countermeasures

ESSCreq(url

ES )

resES

resS

urlES 12

43How does this lack of knowledge

affect SSR implementations? How does this lack of knowledge

affect SSR implementations?


Our Contribution

● Systematic study of security implication of SSRs

1. Propose a classification that establishes common terminology and supersedes pre-existing works

2. Present two new attack scenarios against C and S ● Web Origin Laundering and Denial of Service

3. Analyse of 68 popular online services

4. Present list of mitigations

SSR Classification


ClassificationBehavior Target

Proxy

Open Origin PolicyStorage

AmplifierBridge

Client

SSR Service

External Service

Interpreter

Probe

Flaw

Forgery

Information Gathering

Insufficient Enforcement of Security Policies

Client Side Policies

Server Side Policies

ControlRequest

Response

Destination

Content

Content

● Supersedes and includes pre-existing classifications (Polyakov’s, CWE, and SSRF bible)● Four different dimensions:

– Flaws: includes known classes plus a new one, i.e., insufficient enforcement of security policies

– Behavior (new): identified seven distinct behaviors. Most are legitimate, but the combination can lead to attacks

– Control: the control the attacker has on the content of SSRs and responses (new)

– Target: the possible target of an attack


ClassificationBehavior Target

Proxy

Open Origin PolicyStorage

AmplifierBridge

Client

SSR Service

External Service

Interpreter

Probe

Flaw

Forgery

Information Gathering

Insufficient Enforcement of Security Policies

Client Side Policies

Server Side Policies

ControlRequest

Response

Destination

Content

Content

● Supersedes and includes pre-existing classifications (Polyakov’s, CWE, and SSRF bible)● Four different dimensions:

– Flaws: includes known classes plus a new one, i.e., insufficient enforcement of security policies

– Behavior (new): identified seven distinct behaviors. Most are legitimate, but the combination can lead to attacks

– Control: the control the attacker has on the content of SSRs and responses (new)

– Target: the possible target of an attack

Elements not considered by previous works

Attacks


Attacks

● Seven attacks in four categories

– Two previously unknown: Origin Laundering and Denial of Service

– Others are already known: Reconnaissance and Bridging


Attacks

● Seven attacks in four categories

– Two previously unknown: Origin Laundering and Denial of Service

– Others are already known: Reconnaissance and Bridging


Origin-based Web Browser Countermeasures

● Web browsers implement various URL-based defense mechanisms to protect users and data from attacks/unwanted content

– E.g., Google Safe Browsing, NoScript, and AdBlock

● Security decisions based on the origin (domain and TCP port) of a resource

– E.g., accept/reject a resource, execute a JavaScript program

● Web Origin Laundering is an attack that allows to bypass web browser URL-based defense mechanisms

SCurl

res

trusted

Origin: SAccept res if origin is trusted


Web Origin Laundering: Overview

● C asks S to retrieve a resource at ES ● S behaves as a proxy: retrieves from ES and forward to C● From the point of view of C, the origin of the resource is S, not ES

➔ C will take a security decision accordingly

ESSCreq(url

ES ) url

ES

Laundering by SOrigin: S Origin: ES

res res


Web Origin Laundering: Attack 1.1

● S is trusted and ES is not (e.g., ES is blacklisted)

● req(urlES ) distributed via phishing email, web links, and/or social network

● The origin of is S (not ES), which is trusted!

➔ C accepts and display to the user: Google Safe Browsing bypass● This attack can be mitigated with Content-Disposition header (suggest a web browser to store

a resource on a file)

ESSCreq(url

ES ) url

ES

trusted untrusted


Web Origin Laundering: Attack 1.2

● Attacker distributes a link to a malicious JavaScript page that– Requests via an XMLHttpRequest– XMLHttpRequest allows to ignore

Content-Disposition header– Finally, transform response in a data

URL, that is finally shown within the browser

ESSC XMLHttpRequest

req(urlES

) urlES

1

1

+ ContentDisposition

var mal = "urlES";

var cor = new XMLHttpRequest();cor.onreadystatechange = function() { var ct = this.getResponseHeader("contenttype") window.location = "data:" + ct + "," + encodeURIComponent(cor.ResponseText);}cor.open("GET", "S?url=" + encodeURIComponent(mal), false);cor.send() ;

var mal = "urlES";

var cor = new XMLHttpRequest();cor.onreadystatechange = function() { var ct = this.getResponseHeader("contenttype") window.location = "data:" + ct + "," + encodeURIComponent(cor.ResponseText);}cor.open("GET", "S?url=" + encodeURIComponent(mal), false);cor.send() ;

Case Studies and Analysis


Analysis and Results

● Analyzed 68 online services and mapped to our classification– Social networks, business web applications, software development

tools, online image processing, and security protocols

● Built a tool

– Günther: https://github.com/tgianko/guenther

● ~73% suffer from one flaw of our classification● ~15% implement insufficient forms of URL validation

to counter SSRF● ~15% of services can be used for Web Origin

Laundering

Mitigations


Mitigations

● In the 68 services, we observed the following mitigating behaviors (yet not sufficient)

(M1) Monitoring

(M2) Avoid Acting as a Proxy or Wrap Response

(M3) Perform Proper URL Validation

(M4) Content Disposition

(M5) Limit Resource Usage

(M6) Remove Open Access Control Policies for CORs

(M7) Limit Information Leakage

● None of them solve Web Origin Laundering, we propose

(M8) Enforce (server-side) URL-Based Browser Countermeasures

Conclusion


Conclusion/Takeaway

● First comprehensive study of the security implications of SSRs● Presented a classification based on flaws, level of message control,

behavior of vulnerable SSR service, and potential attack target● Presented two new previously-unknown exploitations techniques

– Web Origin Laundering and DoS attacks

● Presented analysis of 68 popular online services● Proposed a list of eight mitigations

Documents

Uses and Abuses of Server-Side RequestsSeptember 21, 2016 G. Pellegrino - Uses and Abuses of Server-Side Requests 2 Uses and Abuses of Server-Side Requests An increasing number of