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

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

HTML5 – Hazards and Defense – Podcast with Brakeing Down Security

Part 1 -  2015-039: Hazards of HTML5

Shreeraj Shah (@shreeraj on Twitter) came on this week to give us a run-down of some of the issues with HTML5? How can a new standard actually be worse than something like Flash? And why would a standard not address existing OWASP issues, and even create new issues, like the ability of a browser to have a database inside of it managing everything?

This week we discuss HTML5 history, some of the pitfalls, and discuss some of the new technologies found in HTML5 that will create more headaches for agents of infosec.

Listen the Podcast over HERE

Part 2 -  2015-040; Defending against HTML 5 vulnerabilities

Last week, we discussed with Shreeraj Shah about HTML5, how it came into being and the fact that instead of solving OWASP issues, it introduces new and wonderful vulnerabilities, like exploiting locally stored web site info using XSS techniques, and doing SQLI on the new browser WebSQL.
So this week, it's all about defensive techniques that you can use to educate your developers against making mistakes that could get your company's web application on the front page of the news paper.

Listen the Podcast over HERE

You can find various articles on this topic and issues covered during the session over here.

1. Next Generation Application Architecture & HTML5
2. HTML5 features in a nutshell
3. HTML5/Browser Evolution and Threats
4. Cross Origin Resource Sharing Policy and its impact
5. CSRF and Cross Domain Response Extraction in Era of CORS
6. WebSocket Security - Protecting streams Over HTTP
7. Attack Vectors and Threats for HTML5 Storage (note)
8. Talks on HTML5 Security (HITB and AppSecUSA 2012)
9. XSS & CSRF with HTML5 - Attack, Exploit and Defense
10. File System API with HTML5 – Juice for XSS
11. CSRF with upload – XHR-L2, HTML5 and Cookie replay
12. Blind WebSQL and Storage extraction for HTML5 Apps
13. Cross Origin Resource Jacking (CORJacking) - DOM based attack vector
14. Top 10 HTML5 Threats & Attack Vectors

Also, at OWASP we are maintaining HTML5 cheatsheet which you can find it over.

HTML5 OWASP cheat Sheet

Enjoy!

WebSocket Security - Protecting streams Over HTTP

WebSocket is gaining popularity with HTML5 architecture and has wide support from various browsers now. WebSocket allows full duplex communication over TCP as defined in the RFC 6455. Applications need such fast connection with data push coming from servers over polling data time to time. Hence, during our testing we started getting applications running WebSocket. It is imperative to understand the threat model for WebSocket usage and some of the concerns. In this post we try to address this.

WebSocket support and overview

The WebSocket protocol has been defined in RFC 6455 (http://datatracker.ietf.org/doc/rfc6455/?include_text=1) along with the WebSocket API (https://w3c.github.io/websockets/).  Hence, it is possible to use API via JavaScript and embed code right into HTML pages. As soon as a connect call is made by the browser, the HTTP Server switches to WebSocket protocol when it come across an "Upgrade" request call from the client on the same TCP connection. Applications support WebSocket calls via specific URLs like ws:// and wss:// on the pages.

WebSocket has become an integral part of Browser's communication stack as shown below.
We covered a post in the past on new Architecture over here ( HTML5/Browser Evolution and Threats)

Following is a simple upgrade call coming from a browser to a HTTP server.

GET / HTTP/1.1
Host: x.x.x.x
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Sec-WebSocket-Version: 13
Origin: http:// x.x.x.x
Sec-WebSocket-Extensions: permessage-deflate
Sec-WebSocket-Key: Ru+jZkzO8cdIIHtoe8b80g==
Connection: keep-alive, Upgrade
Upgrade: WebSocket

Now, if the server is supporting the protocol then it will allow switching by the following response.

HTTP/1.1 101 Switching Protocols
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: uRxNF7tq3wE+y/7EJjPbk1bPB5w=

Hence, at this point a tunnel is established and bi-directional communication can begin between client and server.If we look at API, then it is simple. Initializing WebSocket object

var WS = new WebSocket(“ws://api.target.example”);

Once that is done one can go ahead and use methods like onopen(), onmessage(), send() and close().

If you want to dig more into WebSocket –
http://www.html5rocks.com/en/tutorials/websockets/basics/

WebSocket usage

We have traditional web applications running over HTTP request and response. One of the problems with traditional usage of HTTP is of refresh and reload. Ajax helped, in a way, to solve this problem by making a quick async call and updating DOM. But in this mechanism, there is polling involved and it is not truly a faster bidirectional channel between the two. To improve overall efficiency one can use WebSocket in cases like the following :

1.     Multiuser gaming or chatting applications
2.     Pushing multimedia like voice, music, videos or large blobs
3.     Real-time updates like financial tickers, sports, tracking, feeds etc.

Also, developers are becoming innovative and utilizing JSON, XML etc. over WebSocket. Hence, there is no limit to how and where WebSocket calls can be used.

WebSocket threats and security concerns

WebSocket has some inherent weakness like allowing cross domain calls and few other issues. Hence, it is important to properly assess the threat model at development stage. Here are few issues one should check during testing -

Cross Domain Calls and Origin Checking

By design, WebSocket protocol doesn’t abide by SOP (Same Origin Policy). Hence, a browser can initiate a cross domain WebSocket call to any domain on the Internet. It is not required for an application to make calls to its own domain only. This can create issues and security threats. It allows an attacker to establish a connection or force any victim’s browser to initiate a connection as well. When WebSocket makes an “upgrade” call over HTTP, it sends “Origin: domain” header in the HTTP request. The browser itself adds this particular header based on its current state of DOM/location. This header cannot be tampered with by script. Hence, to avoid DoS and CSRF type attacks one can validate this header on server side before switching the protocol. Also, it is possible to perform DoS by opening multiple socket connections. One can avoid that by passing a token to the browser before protocol switching. Hence, only if protocol/upgrade switching request comes to the server with that token the server should allow the connection. This will avoid possibility of DoS.

CSRF with WebSocket and Stream hijacking

As discussed in the previous section about “Origin”, WebSocket is not following SOP. This allows an attacker to put a dummy page on Internet and drive someone to that particular page. As shown in the below figure, an attacker can leverage the following scenario:

1. A user logs in to the system and establishes a session with proper authentication. User’s browser gets a cookie from the server for that particular application bound to the application domain. This cookie is going to replay in all other requests going from browser to the target domain.
2. Application may establish legitimate WebSocket session as and when needed as shown in step 2 of the figure.
3. Now, an attacker comes into picture and there is a page created with WebSocket calls pointing to the target application domain. If a user with an established session visits that page, like in traditional CSRF scenario, then he ends up establishing a WebSocket session since the cookie is going to replay. This allows the attacker to have a virtual tunnel created as shown in the figure. It is also important to observe over here that this session is two-way CSRF. In traditional CSRF we just get write/post access but in this case, since WebSocket is not following CORS either, the attacker is also allowed to read incoming stream from server. Hence, he ends up getting both read and write mechanism on stream. This ends up being stream hijacking.

Figure 1 – CSRF over WebSocket Streams

You can read more on this below. This attack is termed as CSWSH (Cross Site WebSocket Hijacking)
https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html

Again, for defense one can verify “Origin” and add extra CSRF tokens to validate legitimate users for stream processing.

WebSocket and SSL

It is also important to know on which tunnel WebSocket is running. One needs to make sure that it is running over SSL channel. If calls are going over a non-SSL channel then it may end up leading to information leakage and other related attack vectors.

WebSocket and input validations

A WebSocket call fetches new data from a server and dynamically loads things in the existing DOM with various APIs. It is imperative to validate incoming content before loading into DOM and protect against DOM based XSS and other types of variants. Also, it is obvious to protect server side injections and streams going over DOM calls. Burp and ZAP both have capability for evaluating WebSocket calls.

WebSocket review Cheat Sheet

Following checks and validation can be made for WebSocket review :

• Version check for browser and required support.
• Application level authentication and authorization for sensitive data transfer.
• Endpoint security with having wss://
• DOM based protection by JSON.parse() over eval()
• Validating “Origin:” at server end
• CSRF type protection in place for streams

Conclusion

The WebSocket protocol is a really good and efficient way for communication in certain scenarios, but at the same time it brings a new set of threats. Hence, developers have to keep security issues in mind during implementation both at server as well as client end. Now a days, there are many applications on the Internet which are using WebSocket heavily. Also frameworks and technologies like Microsoft’s signal.r are based on WebSocket. There are many libraries available for implementation of WebSocket on the server side, but by default they do not check for security issues. Hence, one needs to keep security issues in mind while implementing them and while performing reviews.


Article by Amish Shah & Shreeraj Shah

Impact of sensitive information sent to Analytics in modern world applications

Background:

Application analytics is becoming very important aspect from business standpoint across companies and ventures. It is even more important for consumer centric sites like eCommerece, portals, mobile apps etc. Analytics server are usually third party owned and application owner integrates the code and force browser session to push some data cross domain to those servers.

Problem Domain:

Let's take this example, application running an eCommerce portal has implemented third party analytics services like shown in figure 1. This server is well guarded by firewall and applied secure coding practices on major components across the application. Portal is utilizing analytics services and this service can be integrated with JavaScript, which needs to be implemented across various sets of pages.

Figure 1 – Analytics Deployment for Target Application

This type of scenario brings some unique threats, if application integration with analytics server is not securely done. Here is the list of issues we have observed during our consulting engagements.

• Developers may have blindly integrated code on each pages, links or visited URLs are going to analytics server for analysis. In that case, certain pages like forget password, reset password, SSO page etc. All these pages have URL with sensitive tokens. These tokens can end up providing access to the site and user sessions can be compromised. This is one of the major threats we have observed across many applications.
• Analytics server is running over non-SSL channel and it may end up exposing traffic and certain sensitive information.
• In certain cases JS implementation code of third party component is having DOM based XSS and open redirect types of vulnerabilities, which can be exploited.
• Analytics server is running with certain open ports and can be compromised in very few cases.

Conclusion

It is imperative to evaluate analytics code and their integration from development standpoint. Code should be analyzed for vulnerabilities and it should be integrated to selected pages only. No point in putting its integration on all pages and it may end up sending sensitive tokens to the analytics server. Also, deployment of analytics server with open ports, security posture and communication channel should be carefully evaluated.