Friday, September 8, 2017

(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.

Wednesday, July 19, 2017

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)

Saturday, April 1, 2017

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.  

Thursday, February 9, 2017

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.

Tuesday, November 29, 2016

JSON Hijacking & Two Way CSRF (update)


CSRF is a common attack vector when forms are not validated for the origin of the requests and not having unique tokens attached to the identifity. In modern times it is also possible to hijack streams like JSON.  It creates possible scenario to do a two way CSRF using XHR/HTML5 methods.

You can go over slides for that as below.



In the past, it was possible to use tricks and vulnerabilities like object overloading/overriding (get/set) for <script> as discussed below slides. 



In past few years lot of research and tricks being developed to hijack JSON streams with CSRF. Recently, researcher at Burp (@garethheyes) came up with a way to steal JSON stream by hijacking cross domain calls.

Here is the write up - 
http://blog.portswigger.net/2016/11/json-hijacking-for-modern-web.html (here)

Alos, slides can be found over here - 
https://www.owasp.org/images/6/6a/OWASPLondon20161124_JSON_Hijacking_Gareth_Heyes.pdf (Here)

It is important vector to cover in pentesting and SDLC defense.




Sunday, December 13, 2015

Side Communication Channel integration, weaknesses and vulnerabilities for applications


Applications are no longer working in an isolated environment governed by synchronous behavior involving communication with the target (self) only. Instead, applications are well integrated with various different sources and channels in the era of Web 2.0, Mobile and HTML5. Also, SOA (Service Oriented Architecture) with third party API integration has added new communication channels to the application layer. As shown in the figure below, there are few side channels for communication for applications. They serve several different purposes like two factor authentication, password reset, information validations, third party data integration, sync option for mobile apps etc.

This new set of channels opens up integration challenges both at architecture and implementation stages. Hence, it ends up adding weaknesses and vulnerabilities at the application layer and possible opportunities to exploit.

Also, it is important to note that simple automated scanners or tools do not detect these vulnerabilities. It needs meticulously crafted observation, behavior analysis, access to side channels etc. to discover this set of vulnerabilities. Doing manual observation and assessment only can expose and reveal some of these vulnerabilities.

Figure 1 – Side Channels for Web Applications

Let’s see some of these issues, which we have discovered during our recent manual assessments across application verticals with examples.

Email Channel

Consider an application using email as a channel to communicate with users in asynchronous off-line mode. Hence, certain features and functionalities would send emails to the user with some information. This information goes over a side channel and it is not a typical synchronous scenario. Hence, if the scanner is not accessing the content of mail and acting on it, then a vulnerability may get missed in that part.

An example of this is an application having “forgot password” functionality. When a user clicks on it, at that point the application sends a link for the user over email and that particular link is vulnerable and can be used to access or reset other user’s passwords with tampering a parameter (say “id” – sequential).

There are several other use cases across verticals like financial, health care etc. using the email channel to communicate with the application user and they can be vulnerable to this set of attacks. One needs to access the content of email and evaluate its impact from a security standpoint.

SMS/Text-Message Channel

Text-messaging is another interesting side channel for application communication and access. Applications are using various tokens for second factor authentication and validating over web applications. For example, banks are using One Time Password (OTP) for transactions or portals are using tokens for authenticating users on the portal and so on.

These tokens are integrated into the web application workflow and in certain cases open up vulnerabilities. For example, consider an application running on 3 step authentication processing for clearing a transaction and validating tokens. One can analyze the work flow and when a token is passed in the second step and sends a response back to the browser, one can trap the response and modify “FAIL” to “SUCCESS”. Now this will go to step three and at this step there is no other validation in place. Hence, a user can actually get access and force a transaction even not having the right token. This is clearly an asynchronous and manual leveraged attack. Automated testing where testing is synchronous by nature can’t perform these attacks.

Mobile/APIs Apps

Mobile applications are using different API based interfaces to access web applications. It is possible that there is a single application which gets accessed by different interfaces like web, android, and iOS based mobile applications. For example, a “todo” application often allows the application to be accessed by a browser through mobile, plug-ins created for Chrome/Firefox as well as an iOs/Android mobile application. This particular application keeps doing “sync” between all these different application components. Mobile applications are using APIs to do constant syncing of tasks. Now this channel becomes side channel communication for the application layer and there could be interesting vulnerabilities in using push or pull for sync function. The token used can be tampered and can allow access to other user’s todo tasks.

Conclusion:

Side channel communication attacks are going to be a reality and it is imperative to have these communication channels along with their integration to the main web applications analyzed thoroughly. This area, in many ways, is untouched and under-assessed during pen-testing. Automated scanners and tools cannot co-ordinate with asynchronous and side channels. The vulnerabilities involved can be of traditional types like SQL injection or abuse of business logic.

Article by Amish Shah & Shreeraj Shah

Tuesday, November 24, 2015

Tampering HTTP responses – exposing inner secrets of apps

Ajax, HTML5 and mobile-based applications are bringing in some significant changes to next generation application architecture. Hence, it is important to understand HTML5 to get a better security perspective. HTML5 allows applications to run in a thick client environment, have its own file system, SQL database, local variable storage and socket within the browser framework. Whether this instance of the browser is a part of desktop or mobile is immaterial.

Traditional applications have clear layers like presentation, business and data access. Typically, only the presentation layer would run on the client side and the other components would exist on the server side. Hence, the business logic and data access are server side.

In an HTML5 application things can be coded differently. It can have its own powerful business and data access layers. Hence, the developer can migrate some of the server side components to the client side by leveraging these features. As shown in figure 1, the shaded corner rectangle is an overlap, this is the component, which runs on the client side in the browser or mobile (app) and executes within the client framework. This is a significant change; it allows applications to run in offline mode as well. At the same time, some of the server side implementations are now exposed to the client and some threats and security issues can emerge by tampering HTTP responses. HTML5 has a powerful presentation layer with newly added tags and markups. At the same time, mobile’s native applications written on iOS or Android are having great capabilities to host thick features on client side. It also encompasses an effective business layer by having strong APIs accessible by JavaScript or native (mobile) along with the data access layer.

Traditionally, penetration testing of the application is relying on the HTTP request fuzzing and tampering. Not much focus is given to changing and tampering HTTP response streams but things are now changed with modern and mobile architectures driven in API frameworks. With modern browser baked with HTML5 and powerful JavaScripts libraries, it is possible to do a lot more at client side as part of the browser as well as on mobile apps. Some key decision making parameters are coming from server as part of HTTP response and these can be tampered to discover vulnerabilities and get into different flow of application at the browser/mobile end.


Figure 1 - Hybrid layers of modern architecture both for web and mobile apps

In current context, JavaScript libraries are allowing to write business logic on client side. During our pen-testing and JavaScript reviews, there have been instances where the response modification and tampering opens up the new functionality on presentation side in complex JavaScripts running on browser or mobile ends. It is new keys to the kingdom and surprising in many cases. It allows attacker to do range of things form abusing functionalities to privilege escalations both on mobile and browser front. Following are some of the examples observed across browser as well as mobile applications, we are sure there are many other outcomes of this technique where focus is kept on HTTP response streams like JSON, XML, Flags etc.

a.) Privilege escalation and role change
Typically, the application would have multiple roles to deal with privileges and authentications. Based on the user role, the application design would serve different user interfaces to the browser and mobile layers. In this case, the application was setting a numeric value once user logs in to “3” for a normal user in the JSON call. User interface will take decision based on this value and build dynamic look over HTML5/mobile interfaces. If the value of the parameter is changed is set to “1”, the application ends up escalating role and now having access to a few more menu items both on web and mobile interfaces. These menus and access are designed for admin only. Hence, major breach is now possible since any user can escalate its role to the admin user as shown below.

Figure 2 - Privilege escalation and role abuse

b.) Abusing password functionality
There are certain applications which would have multiple steps on single page to offer change password functionality. In first step user gets a prompt to enter the old password. If the old password matches on the server side, the application redirects user to enter new password and if old password does not match, the application redirect user to enter old password again. This opens up a way to abuse HTTP responses, if attacker modifies the server response from FAIL to SUCCESS in first step, the application redirects user to enter the new password even though old password is incorrect. There is possibility to abuse this scenario as well.

c.) Unauthorized access to mobile screens on device

Many mobile applications are coming up with login screen at the start point and after authentication it sends large JSON stream back as response. Based on various parameters defined on the stream, application loads various pages from mobile device to the end users. This JSON stream coming from response can be polluted and poisoned by tampering values. Hence, application ends up providing set of support and escalated state of the user. Using these cards/pages, user can access various set of paid functionalities, which are not open for free users. This technique is very effective for mobile based applications.

d.) Enabling buttons using java script modification

For example, the application is having a view user profile functionality, which displays the user details including email address as userID with "Save" and "Cancel" buttons. As user has only view permission the "Save" button is disabled. By analyzing JavaScript, one can identify the disabled button. But by modifying the JavaScript in response or in-browser, it is possible to enable "Save" button and submit the record to the server. This allow us to see actual HTTP traffic build and generated by Ajax call as well. Now, it opens up new doors for HTTP request tampering as well.

Conclusion
In this blog write up we have covered four scenarios but there are many more we can identify in Single Page Applications and mobile apps, which are responsive in nature for web based applications. Both mobile and web based applications are leveraging HTML5 and JavaScript heavily along with customized response streams like JSON, XML, JS-Objects etc. Hence, in the era of modern and mobile applications it is not enough to fuzz request streams only, it is imperative to fuzz and tamper response streams as well. It is important to understand role and value of manual penetration testing over automated since automated tools are not using response tampering in usual cases.

Article by Hemil Shah & Shreeraj Shah