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

New OWASP Top 10 (2017) - What is NEW and final state?

Here is the view on top 10 from OWASP



Resource on OWASP - Get it from HERE

• Injections are still on the top. It makes sense since lot of attack vectors are leveraging poor validation controls. It leads to injections like SQLi, Command injections etc, and are still very common across applications.
• Broken authentication is still a very common issue, it is very easy to discover by human intelligence and sometimes difficult from automated scanner standpoint. But this control is still holding second position on the list.
• XSS used to be higher in the list but now moved to seventh position. There are several frameworks in place, which gives protection against it. Also, browsers are having controls to defend against XSS. But still XSS is very common and easy to discover across applications.
• NEW (XXE) – XXE attack is added to the list, it is not very common but still XML streaming can be injected and can cause potential danger for the application. It allows lower level access on the box. Hence, it is added and important to detect and protect.
• MERGED - Insecure Object and Missing Access Control are merged and added as a “Broken Access Control”. Again, it is very common at truly application layer. It is relatively easy to detect by humans and get missed by crawlers/scanners at large.
• Security Misconfiguration and Using Known Vulnerable components are major issues from deployment/framework standpoint. It allows possible exploitations by default before developers build up code on top of it. Hence, both of them are having place in the top stack.
• NEW (Insecure Deserialization) – HTTP is now supporting object level of streaming and it is imperative to serialize/de-serialize objects. It opens up a set of vulnerabilities and very effective attacks can be created using streams like JSON.
• NEW (Insufficient Monitoring/Logging) – Application layer doesn’t have logging and it allows attacks to go unnoticed. Hence, even though this is not an attack category but still added so developers start providing mechanism for logging across applications.
• DROPPED - CSRF and Unvalidated Redirects are dropped from the list. We still see them very commonly around applications but some protections are coming at framework layer and seems they are moved out.

HTML5 Drag and Drop abuse with ClickJacking

We came across interesting observation/article over here

https://medium.com/@arbazhussain/weaponizing-clickjacking-attack-with-click-content-jacking-ab50cb6a37ed

It is possible to Hijack content by click jacking by loading two frames coming from the same domains. If domain is the same then it is possible to drag and drop API to function between two frames. Hence, it is possible to force victim to do “drag-and-drop” followed by a Click. It can lead to “Click Content Jacking” as concept outlined in the article.

(Advisory) Patch your Apache Struts

Researchers discovered a critical and easily exploitable vulnerability in Apache Struts framework  recently. Exploitation can lead to remote command execution and complete control of the machine via web server. Web Server running on port 80/443 is not blocked by firewall and can be exploited at ease.

Here is the original note from research group -
https://lgtm.com/blog/apache_struts_CVE-2017-9805_announcement

Here is the CVE entry –
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9805

Technically speaking, vulnerability was discovered in REST plugin, REST allows processing of XML streams via XStreamHandler. It is imperative to do some filtering at the code layer before deserialization. Defect and missing protection against these types of payload must have caused this exploitable opening.

Fix your Struts (CVE-2017-9805) by upgrading to 2.5.13 or 2.3.34 along with upgrading the plugin.

Securing Legacy SaaS Accounting Software: A Comprehensive Review and Remediation

Client Overview
A rapidly growing company offering accounting software as a SaaS expanded its platform by adding features such as custom reports, cloud integrations, and API support. The platform, however, was built on legacy PHP code, and the traditional development approach, along with complex customizations, led to numerous security issues that were difficult to prioritize and resolve.

Challenges

• The platform was built on outdated PHP code, which made it prone to security vulnerabilities.
• The rapid addition of features introduced multiple layers of complexity, increasing the risk of security flaws.
• The existing development process lacked modern security practices, resulting in a backlog of security issues that were hard to address and prioritize.
• The company struggled to identify and fix security vulnerabilities efficiently, especially those related to input validation, output encoding, injections, and file uploads.

Blueinfy's Approach
To address these challenges, Blueinfy proposed a combined manual black-box testing and code review approach using their in-house tools. This approach was tailored to the specific needs of the legacy PHP environment and focused on identifying and resolving critical security issues.

1. Comprehensive Product Understanding
Blueinfy’s team took the time to thoroughly understand the product, its architecture, and the existing security measures in place. This deep understanding allowed them to tailor their approach to the unique challenges of the platform.
2. Manual Black-Box Testing
The team conducted manual black-box penetration testing to simulate real-world attack scenarios. This testing was aimed at uncovering security vulnerabilities without prior knowledge of the internal code, focusing on areas like input validation, output encoding, and file uploads.
3. In-Depth Code Review
Parallel to the black-box testing, Blueinfy’s code review team analyzed the PHP codebase to trace the root causes of the issues identified. The review focused on common security concerns such as SQL injection, cross-site scripting (XSS), and improper data handling.
4. Correlation of Findings
The code review team correlated the results from the black-box tests with the underlying code issues, identifying common root causes and providing targeted recommendations for remediation.

Results
The combined approach led to the identification of several high-severity vulnerabilities that were previously overlooked or not fully understood. Blueinfy delivered a detailed report that highlighted these findings and provided clear, actionable recommendations for fixing them.

• The report prioritized the most critical security issues, enabling the client to focus on what mattered most.
• Blueinfy’s recommendations were tailored to the legacy PHP environment, ensuring that the fixes were both effective and feasible to implement.
• The client implemented the suggested fixes, resulting in a significantly more secure application.

Conclusion
Blueinfy’s combined manual black-box and code review approach provided the client with a clear path to securing their legacy PHP-based accounting software. By focusing on both the surface-level vulnerabilities and their underlying causes, Blueinfy helped the company address critical security issues, ensuring the platform was robust and secure for its users.

Article by Amish Shah

Blind and Asynchronous injections, techniques and exploitations

Web applications and APIs are vulnerable to set of injections like SQL, command, SMTP etc. Some of these injections are easy to detect since their behavior are synchronous and visible. Synchronous and visible implies, you send simple HTTP request with payload and you get HTTP response back which has clear indication of success. Hence, request-response are synchronous and outcome of vulnerability exploitation is clearly visible.

Now moving into current scenario, we have significant evolution on application layer both in terms of technologies and implementation techniques. Applications are using Web 2.0 frameworks, JavaScripts (server/client), HTML5, APIs, Mobile stacks, JSON/XML and many other components. The way these components are utilized and implemented by developers may make them to behave in asynchronous fashion. Asynchronous injection can be preformed at time t1 but its impact/response arise at time t2. Also, it may be going on different media as well. Example, we inject SQL payload on time t1 on pageX and injection gets stored at somewhere on server. At time t2 a batch script gets generated and injection gets executed. Its response may be going to specific URL at that time. Hence, these injections are very hard to detect and needs different techniques.

Also, with these new technology stack in place, lot of messages get suppressed and not visible on the HTTP response. Hence, when we perform SQL injection then at that point we don’t see its impact in response. In this scenario we use blind injection techniques by deriving indirectly like measuring response time or Boolean behavior. These techniques help in detecting bling injections. Further, it is possible to inject payload which initiate sequence of asynchronous side channel event like firing DNS query or contacting HTTP URL. This type of behavior can help in detecting a new set of injections as well.

Over years these techniques are used by pentesters heavily during the manual testing. Automated testing has some limitation in deploying these techniques. Recently Burp has come up with new expression and implementation. They call it Out-of-band Application Security Testing (OAST) and used by Burp Collaborator. It ends up giving better results and detection over DAST, SAST and IAST. One can leverage it in manual testing and enhance vulnerability detection capabilities.

You can find more over here (http://blog.portswigger.net/2017/07/oast-out-of-band-application-security.html)

CSRF prevention by “SameSite” flag

CSRF is very deadly attack vector for the sensitive application operations like password change, profile update, banking transactions etc. It allows an attacker to set a page with payload on cross domain and mass exploitation by forcing users to compromise their session by leveraging cookie replay.

We covered this topic extensively over years - http://blog.blueinfy.com/search/label/CSRF

Web browsers are now supporting an added attribute called “SameSite” to the cookie and this attribute controls the replaying of the cookie. Before this addition, browser used to replay cookies if origin/domain is the same.

Hence, while setting up the cookie if directive is used as shown below.

Set-Cookie: key=value; SameSite=strict

This flag has a set of values as below with respective impact.

a.) If value is set to strict like “SameSite=strict” then cookie will replay only in case of same domain. Hence, if page is hosted on different domain and code on the page initiate GET/POST requests then these requests will not replay the cookie. Hence, application is protected against CSRF.

b.)If value is set to lax like “SameSite=lax” then cookie will replay in a few cases like link, rel or form with GET method. Hence, only GET request will replay the cookie in case of cross domain origin. CSRF for all other critical forms and POST requests will be blocked since browser will not replay the cookie from the browser.

Conclusion

It is imperative for critical applications to block CSRF attacks and there are several mesuares for it. One can apply tokens for every critical POST call and validate before processing the request. One can also put in place CAPTCHA to stop automated processing as well. For all these controls one needs to apply server side programming and strong defenses. “SameSite” cookie is an interesting browser side flag to kill CSRF right at the source. If cookie is not going to replay then CSRF gets killed and attacker can not host cross domain payload to perform mass CSRF exploitation.  

Top 10 Design Flaws in the Software/Applications

Application/Software carries many vulnerabilities, weaknesses and issues at their source code and deployment layer. OWASP Top 10 defines top 10 vulnerabilities/issues for web applications but those are subset of some underlying design issues.  Also, some of the vulnerabilities arising from these design issues are not covered by top 10 or other standards. Recently “IEEE Center for Security Design” came up with interesting paper where they have lined up top 10 design issues.

You can read it over here - https://www.computer.org/cms/CYBSI/docs/Top-10-Flaws.pdf

Here is the higher level view of 10 design issues -

1. Earn or give, but never assume, trust.
2. Use an authentication mechanism that cannot be bypassed or tampered with.
3. Authorize after you authenticate.
4. Strictly separate data and control instructions, and never process control instructions received from un-trusted sources.
5. Define an approach that ensures all data are explicitly validated.
6. Use cryptography correctly.
7. Identify sensitive data and how it should be handled.
8. Always consider the users.
9. Understand how integrating external components changes your attack surface.
10. Be flexible when considering future changes to objects and actors.

It is imperative to thoroughly analyze application from proper pen-testing or manual review which helps in identifying many of the above issues. Advanced issues and technologies are complex in nature and it is not possible for automated scanning be it DAST, SAST or IAST to discover some of these critical issues. Blind trust on Artificial Intelligence (automated engines) may lead to sense of security but these design controls and vulnerabilities arising from it needs human intelligence for meaningful discovery.