Dynamic (Direct) AJAX CSRF - the evolution of Dynamic CSRF in 2012
I didn't believe it at first... I had the usual "It won't work" response... but the guy was determined, and decided to try anyway...
As it seems, stubbornness can be very useful, and after a few bright insights, we had a working, feasible dynamic CSRF attack vector that was based on AJAX and response analysis, which under the right conditions, could do everything that static CSRF could not.
Now why would we need another CSRF attack vector?
The limitation with "static" CSRF was always the fact the it was a shot in the dark - the attack enables attackers to redirect browsers to links that perform operations on behalf of the user, but the attack can't analyze the content that returns in response to these redirections.
Even the partially dynamic CSRF attack vectors (presented at blackhat) relied on indirect information that might be disclosed from the user activities or from other attacks.
Many CSRF prevention mechanisms attempt to protect the user by requiring session-specific tokens or custom headers as additional input for action performing modules, and since "normal" CSRF can't analyze responses (at least not directly), these mechanisms managed to prevent most of the instances of these attacks...
Too bad illusions eventually tend to dissipate...
Let's assume that somehow, CSRF attacks could analyze the response.. what could the attacker do if the content that returned from redirected requests could be analyzed by the redirector, even if the redirection target was a different domain?
That was the question that lead Oren Ofer (http://twitter.com/oren1ofer) of Hacktics ASC to ignore the normal boundaries and try harder, to see if the current limitation is a fact or an illusion.
And lo and behold, it appears that the limitation really is an illusion (and for technical guys, yes, regardless of permissive CORS policies).
Last week, In a local OWASP chapter meeting, Oren revealed a new dynamic CSRF technique that can be used execute CSRF attacks in a dynamic approach, and enable attackers to analyze the content that is returned from each and every redirected request.
The attack can be performed with the following restrictions:
- The attacking web site must be accessed through an intranet domain name format.
- The attacked browser must "support" permissive intranet policies (relevant for several types for browsers, as presented in the whitepaper & presentation).
- The attacked browser have active intranet settings (the common case for several types of browsers, as presented in the following prezi presentation).
- The target host must reside on the same port as the origin port of the malicious AJAX CSRF code.
This new technique is based on existing intranet policies and the effect they have on AJAX same origin policies, which causes these policies to be less restrictive, as long as certain conditions are met.
The uses of the new Direct, AJAX based Dynamic CSRF attack vector are numerous:
- Attackers no longer need to know in advance what is the structure of the application they are trying to perform CSRF on (!), especially since the code can dynamically locate the CSRF target entry points and send notifications on the application structure to the remote attacker, creating an HTTP "command line" scenario!
- Attackers can use this vector to bypass any CSRF prevention mechanism which is based on non-consistent form-specific tokens or custom header requirements, by locating anti-CSRF tokens in pages that precede a CSRF protected entry point, by mimicking complex content delivery methods (JSON, XML, etc) and by forging headers to bypass server side custom headers verification.
- Attackers can obtain sensitive information on the user by analyzing the server responses.
- Attackers can use this attack to replay obligatory dynamic fields such as VIEWSTATE, EVENTTARGET and EVENTARGUMENT; fields that might have prevented simpler CSRF attacks.
- Attackers that managed to inject this code in an internal vulnerable off-the-shelf product (via persistent XSS or similar methods) can use this vector to map (some of) the structure of an organization internal network (!), with certain restrictions which are based on origin port and protocol.
This attack is also explained in a short, informative and cool online prezi presentation:
A demonstration of this attack was uploaded to Hacktics YouTube channel:
The attack is further explained in the following whitepaper:
The following POC code can be used to understand simple AJAX based Dynamic CSRF scenarios:
- Disable the intranet settings in all the browsers in the organization.
- Implement an efficient CSRF prevention mechanism that requires Anti-CSRF tokens for every internal entry points, and not just for action-performing entry points.