OFFENSIVE | DEFENSIVE | WIKI | ABOUT

<<



GENERAL INFORMATION

- The attacker might cause the server to make a connection to internal services within the organization's infrastructure.
- This can be in the vulnerable application, or on other back-end systems that the application can communicate with.

WHY happens ?

- access control bad configurations allowing to bypass.
- recovery purposes configuring the admin access as backdoor.
- connectivity from server and not from external users.
	


COMMON ATTEMPTS

Inspection of the requests are crucial, sometimes the request are sending or using variables to call more URL's. 
It can be IPaddresses, hostnames, etc. So any URL can be called to check results. For example, a delete user URL action was founded 
checking code, it can be attempted to remove the user. 

** enumeration is key.

SAMPLE:

URL=http://localhost/admin/delete?user=machetevault
URL=http://192.168.80.7/admin/delete?user=machetevault

	

CIRCUMVENT SSRF DEFENSES

:: blacklisted input filters

some common controls can use list of common words, uri paths and more to block requests. however, exist some ways to by-pass those 
controls. it is common to see some requests with "blocked" responses, that means some control is preventing the access. 

for example, 

1. if is it an IP address, you can attempt to obfuscate the ip address using other encode method. 127.0.0.1 >> obfuscated will be
2130706433 | 017700000001 | http://127.1/ (decimal / octal)
2. you can add a new DNS entry to resolve to something else. 
3. obfuscate using URL encoding or other encoding method [burpsuite encoder/decoder] even changing a letter can do a big difference.
single or double-url-encoding. 
4. change HTTP method [HTTP / HTTPS]

:: whitelisted input filters 

NOTE: same techniques can be applied. first attempt is with the localhost/127.0.0.1 values
	
[goal]: to by-pass this exploiting inconsistencies in URL parsing is key.

1. some apps only allow specific strings, values, etc. to match a whitelist.
2. it normally look to match at the beginning or in within in it.
3. Important to check for differences in @ / #, also, the goal is to make a internal call, so localhost can be used to trigger it.

SAMPLE: URLcall=http://127.0.0.1:80%[email protected]/admin/delete?username=carly

ways to by-pass it:

ONE: embed credentials in URL before hostname using @ value
SAMPLE: 
https://known-host:fakepass@badactor-host
http://[email protected]

TWO: usage of # to fragment URL's
SAMPLE: https://badactor-host#wellknown-host

THREE: leverage of DNS hierarchy to place required input to something you own
SAMPLE: https://expected-host.evil-host

FOUR: URL encode characters to confuse URL parsing, useful if the code that implements the filter handles URL-encoded 
characters differently than the code that performs the back-end HTTP request.

FIVE: Double URL encoding. [use burpsuite decoder tab]

NOTES: 
1. combination of techniques can be used!
2. test each way and compare results, for example between @ and #
3. use burpsuite decoder but also cyberchef

:: bypassing filters via open redirection 

to acomplish this one it is needed to first find a open redirection vulnerability. it can be something similar to the following
code,

GET /product/nextProduct?currentProductId=7&path=/product?productId=8 

the path section is providing or calling another URL, so that can help to test if exist an open redirect vulnerability. simple
way to test it is to type or call a simple url: 

GET /product/nextProduct?currentProductId=7&path=https://www.google.com

if the site is loaded, it means theres an open redirection vulnerability to exploit. so use the request vulnerable to SSRF and 
combine both to exploit.

- manual inspection of the URL is needed, it wil be each time the app is validating the source but not the entire URL. so, 
the URL open redirection can be vulnerated. not necessarily you will see the entire URL, it can the URI path.

So, one way to test is to check if there are controls in place to prevent changing URL's to call.
	
	

BLIND SSRF

occur if you can cause an application to issue a back-end HTTP request to a supplied URL, but the response from the back-end request is not 
returned in the application's front-end response. It is needed to use some kind of tool to check for responses. 

techniques to use:

- trigger an HTTP request to an external system that you control (burp collaborator)
- it can be DNS request as well.
- if defenses are in place, techniques to obfuscate will be needed.

	

GO BACK