Server Side Request Forgery (SSRF) Attack and Defence

Server Side Request Forgery (SSRF) is an interesting vulnerability, which can have potential impact on internal infrastructure residing behind firewall. In this case, HTTP server running over ports like 80/443 becomes an entry point for an attacker to enter into internal network over as legitimate HTTP/HTTPS tunnel.

To understand this vulnerability in detail, let’s assume we have a vulnerable application running on a hypothetical domain www.victim-example.com having a resource named “profile.php”. It is having a parameter named “propic” and it seems to be fetching picture from a resources as below.

GET /profile.php?propic=http://www.someserver.com/mypicture.png&id=9826739HTTP/1.1
Host: www.victim-example.com


Now, looking at the parameter propic, it is taking URL and fetching file from third party server. What if we can tamper with it and try to fetch something else instead? To try it out, we make a following request.


GET /profile.php?propic=http://www.myblueserver.com/foobar.html HTTP/1.1
Host: www.victim-example.com


This example server www.myblueserver.com belongs to us so we can see the logs of it. We can see this entry in it.

<IP of www.victim-example.com> - - [14/Dec/2017:00:06:28 -0700] "GET /foobar.html HTTP/1.1" 404 113 "-" "<Client type>"


Hence, clearly we got out-of-band call from the application. Application is processing propic (URL)parameter and making call to external app or resources. Application page may have lines like below.

$getpicurl = $_GET['propic'];
$profilepic = fopen($getpicurl, 'rb');


Now, this opens up various exploitation opportunities for an attacker. One of them is shown in figure below.



An attacker can start scanning internal hosts and network with reverse HTTP calls like below -
 
GET /profile.php?propic=http://192.168.100.X HTTP/1.1
Host: www.victim-example.com


It may get access to internal files and resources. This type of vulnerability is known as SSRF. It is like abusing HTTP calls with request forgery.

Exploit scenarios:


This functionality can be abused and following types of exploitation can be done.

•    Internal resource scanning and stealing.
•    Using file:// schema to access sensitive resources/files like /etc/passwd or other resources from the same server.
•    One can use other schemas like "ftp://", “dict://” or "gopher://" to abuse vulnerability further.
•    Attacking some other ports as well with cross protocol requests if possible and given scenario.

Conclusion:

SSRF is relatively easy to detect by DAST specially using manual pentesting. One can fuzz requests and look for 200 OK coming from the same server with content coming from different server (internal/external). It may require out-of-band testing setup in some cases if there is a blind SSRF. If vulnerability is identified then it brings major threat to internal resources and should be fixed immediately by proper validations, whitelisting and other secure coding practices.

XXE Attack – A4 of OWASP Top 10

XML External Entities (XXE) issue is added to newly listed OWASP Top 10 vulnerabilities list. In current world, number of applications is using XML streams or Web Services (SOAP) for back-end processing. Hence, browser or client can make this simple XML call over HTTP POST and fetch XML response from the server as shown in the figure -



Once XML stream hits to the application server, it needs to process through XML parser. This opens up an opportunity for attacker to inject malicious payload. XML processing or parser may be weakly designed (DTD or XSD parsing) or not properly configured; it allows external entity attributes to get processed. This can lead to access to file system, network drives, network resources or other OS level access.

As shown in the above diagram, one can craft following XML document where XXE is defined to read “/etc/passwd”.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE test [
<!ELEMENT test ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<test>&xxe;</test>


Hence, if an attacker can successfully execute the above payload then application end up serving /etc/passwd as HTTP response (XML stream). It is also possible to inject internal URL or causing DoS (/dev/random file call). In certain cases, parser breaks with error while sending data back into XML stream. One can overcome that by (i) an attacker can call content by using “CDATA” wrapper in case getting error from the parser while displaying content. (ii) by sending data to external system (out-of-band) injection.

Conclusion:

Though XXE is not very common issue but the nature of vulnerability is very serious and can have devastating impact on the target application/infrastructure. By leveraging this issue, an attacker can launch SSRF, steal file/source-code/confidential-information from the system or DoS the system. Hence, it is imperative to provide mitigation by proper patching, verifying XML streams and validations.

Insecure Deserialization Attacks – OWASP A8 2017

HTML5 and Web 2.0 applications are using modern architecture and modelling for web programming. It has opened up relatively different ways of attacking and exploiting. One of the issues, which are easy to detect and exploit by manual analysis, is called insecure deserialization. This is not new attack category but OWASP Top 10 came up with this vulnerability into their current list and started to get noticed.

Web programming language uses objects extensively and at some point in time, it is required to store these objects or transfer them over network. Hence, simple mechanism is developed; it is called serialization and deserialization.

Serialization – Converting an object instance into simpler form like XML, JSON, text or binary.
Deserialization – Converting XML, JSON, text or binary back into Object for consumption.

In web applications, these converted streams go back and forth between browser and servers. It goes over HTTP(S) and can be dissected at client end. It opens up opportunities for attacker to understand and tamper these object streams to exploit programming weaknesses. Here is a quick look at possible attacks and exploit scenarios.

1. Command Injections
- Object streams get handled at two layers – framework and programming (developers). At framework layer, in some cases, it gets parsed by using underlying operating systems resources to make some modifications. This opens up an opportunity to inject OS commands.

2. Privilege escalation
- Object stream may contain tokens or reference about ACLs (Access Control List). In some cases, an attacker can decode the information and manipulate it to gain higher level of access.

3. Reverse engineering
- In modern day applications, developers are using these objects on the fly and in some cases, they store very sensitive information. Data contained in these objects become a rich source of information for reverse engineering. By dissecting and decoding these objects, one can build a set of possible attack vectors. Hence, these streams coming to browser opens up bundle of opportunities for reverse engineering.

4. Authorization bypass -
Objects coming to the browser ends are having some tokens to access information time to time. These tokens can be guessed, reverse engineered or tampered, it can be sent back to server with mutation. It certainly opens up opportunities for authorization bypass and access to other user’s information.

5. Object stealing from browser space
- Objects are serialized and get stored in browser memory space. Libraries and developers are using HTML5 features like localStorage and file APIs to store these objects. If application is having XSS or DOM Injections then it can lead to information extraction from the browser. Also, developers build object maps via JavaScript within browser, one can enumerate entire object map and extract information from it via XSS. Hence, it is imperative not to have XSS across application to avoid this type of exploitation.

Conclusion

In this article, we have a brief overview of this attack vector (A8), which is newly added to OWASP. Top 10. There is more research going on in the area and we may end up seeing innovative way of both detecting and exploiting this mechanism. You can read more about it over here.

OWASP top 10 (A8) - https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf

Untrusted streams - https://www.owasp.org/index.php/Deserialization_of_untrusted_data

Cheatsheet - https://www.owasp.org/index.php/Deserialization_Cheat_Sheet