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.

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

Global Sensitive Information Extraction from DOM – post DOM based XSS

DOM centered single page HTML5 and Web 2.0 applications are using GLOBAL variables to manage client side critical information. During consulting we have seen few applications managing client side session data on GLOBALS. These global objects are using JSON or Array. In some cases they are string as well.

For example,

Once user gets authenticated it gets a Script tag and along with an array like below to set global set of variables.

var arrayGlobals = ['my@email.com',"12141hewvsdr9321343423mjfdvint","test.com"];

In many cases it has sensitive information like tokens, public profile URLs, private URLs for information access, cross domain oAuth values, user/pass as temp variables etc. It has interesting set of information and it can be extracted in case of DOM based XSS. These DOM driven applications are single page and these set of values are accessible across application life cycle.

Here is an example of extracting JSON, Array and string from browser. It can be used as part of XSS testing and exploitation once it is found. It is interesting to add in XSS exploitation tools like BeeF. We are using it with node.js and customized payload for our routine test cases.

Below script will look for object and using JSON.stringfy for Firefox only else jquery plugin can help.

for(i in window){

    obj=window[i];

    if(obj!=null||obj!=undefined)

        var type = typeof(obj);

        if(type=="object"||type=="string")

        {

                console.log("Name:"+i)

                try{

                    my=JSON.stringify(obj);

                    console.log(my)

                }catch(ex){}  

         }

}

Just to fetch extracted values we are running in firebug and redirecting on console.

Really interesting stuff – check with your popular mailing and social networking sites.

CSRF with JSON – leveraging XHR and CORS

Same Origin Policy (SOP) dictates cross domain calls and allows establishment of cross domain connections. SOP bypasses allow CSRF attack vector, an attacker can inject a payload on cross domain page that initiate a request without consent or knowledge of the target user. HTML 5 is having one more policy in place called CORS (Cross Origin Resource Sharing). CORS is a “response blind” technique and controlled by extra added HTTP header “orgin” and their variants but it allows request to hit the target in one way direction. Hence, it is possible to do one-way CSRF. It is possible to initiate CSRF vector using XHR-Level 2 on HTML 5 pages and can prove really lethal attack vector. XHR establishes a stealth connection and remains much hidden, XHR connection can be set using “withCredentials” as true along with POST method. It allows cookie to replay and helps in crafting successful CSRF scenario or session riding. Interestingly HTML 5 along with CORS allows performing file upload CSRF as well. It is possible to craft a JavaScript using XHR and inject JSON payload as cross domain. If server side code on JSON library is not validating the “Content-Type” then it will process the request and allows successful CSRF.

For example,

Here is a script which will do CSRF on cross domain.

Here, we have “Content-Type” as “text-plain” and no new extra header added so CORS will not initiate OPTIONS to check rules on the server side and directly make POST request. At  the same time we have kept credential to “true” so cookie will replay.

On the wire we can see following request.

As you can see cookie is replayed and JSON POST has been initiated. We get following response back from application.

Application processed the request and sent JSON back. It is clear case of CSRF. This can be applied to other streams as well.