SOP Bypass and CSRF via Macro

A co-worker and I have been working diligently on a CSRF exploit via a macro written in VBA. The site we have been working on allows users to send excel files back and forth. My co-worker found there is this nice little VB object called InternetExplorer.Application that basically allows you to invoke an instance of IE through a macro. The "InternetExplorer" ActiveX control gives the attacker full access to not only the persisted cookies, but also the session/temporary cookies that exist in all currently open instances of IE. Note that the "same origin policy" *does not* apply. We can grab the DOM (including persisted and session cookies) of any site/origin.

One example we did to prove this was login at a site with remember-me disabled. We ran the script which then showed all of my cookies at various domains, including the previously mentioned site which only had session cookies. Note the InternetExplorer ActiveX control respects the HttpOnly flag.

Our Proof of Concept macro will recursively iterate through all your IE Favorites and request the current available cookies to each one. If you happen to be currently logged in to that site via IE an authenticated cookie will be displayed in a popup box. We all know what this means. This means once we create this new IE.App object we can now utilize any authenticated sessions a user may have open and send requests on behalf of the user. This IE.App object does not behave like the IE browser does. If you open two instances of your IE browser it will not share session cookies between them because of Same Origin Policy (SOP) restrictions. In the case of invoking the IE.App object it bypasses any SOP security settings. The code is pretty straight forward and is simplified below:

{pseudocode}

Dim ie As InternetExplorer

Set ie = New InternetExplorer

Files = iterate(Favorites dir)

Foreach file

url = readFile(file)

ie.Navigate = url

Do Until ie.ReadyState = READYSTATE_COMPLETE Loop

' Now we get the cookie

MsgBox ie.Document.Cookie

{/pseudocode}

Obviously the code in is a much better PoC (bigger, faster, stronger), but the above is a quick synopsis. In order to have this code run, the victim must either be tricked into opening a malicious Excel/PP/Word document or have really low browser security setttings and visit a site that has VBScript which tries to instantiatethe object within the browser (this is THE WORST situation, but also pretty unlikely).

The general risk of this issue seems pretty low although it is definitely a way around any form of CSRF protection since we could potentially parse the DOM and send any CSRFToken with the request.

We understand a macro is basically unmanaged VBscript code and can do anything on the user’s system for which they are authorized, but the fact the InternetExplorer ActiveX control allows for seeing all current session cookies is a bit scary.

We thought about disclosing this to Microsoft and may still do so, but since it is unmanaged code they will probably turn their heads. If anyone has any thoughts I would love to hear them.

CSRF attack through Macros? Really?

Sitting with my co-worker and wondering what our next move would be at exploiting another XSS attack we both turned our minds toward Microsoft Excel. We had seen cases where we could get XSS attacks and even Excel attacks embedded in downloaded CSV files and were presented with an application allowing for similar functionality. My co-worker starting looking for ways to embed nastiness in a macro and sure enough we came across yet another attack vector for CSRF.

Like I said the application at hand allowed users to upload excel files and actually send these files to other users of the system. We found there is a "neat" little VBA object called InternetExplorer.Application which basically allows you to open an instance of IE from a macro. This "neat" little object provides most all functionality IE does BUT since the attacker is now ALLOWED access to the file system through the VBA code this could get interesting. Oh did I mention this object allows access to a users cookies.

Lets dig a little deeper. If I was able to write a quick little VBA macro that iterated through a users "Favorites" links and request cookies for every single site, what would happen. If the user is currently logged into any of these sites via normal IE the cookie of the authenticated session would now be in the hands of the attacker. This means CSRF is happening through a macro and in this case the attacker wants a bunch of authenticated sessions. This does work.

Now what if we wanted to take this a bit further and create a worm that not only stole session information but performed a CSRF against a favorite webmail provider wherein it grabbed the contact list, created an email, uploaded an infected xls file with our macro and sent it to every one of our contacts. That is scary and a zero day in my mind.

Now the really scary thing about this is we all know macros are bad and dangerous but honestly how many times have we gotten an xls file and clicked "Enable Macros" because we were told to. Come on be honest....We have all done it and we will continue to do it until something bad happens.

So how do we protect against this. It is almost impossible without getting MS to take this functionality away. With InternetExplorer.Application we have a fully functional browser where we could send multiple requests, parse the DOM returned and grab any CSRF token we need to present with each request.

This macro will obviously work in any MS application with macros enabled. And once the macro runs the user would never know what happened. As with any CSRF attack the user would need to be logged into a site the macro knew about.