The limitation with "static" CSRF was always the fact the it was a shot in the dark - the attack enabled attackers to redirect browsers to links that perform operations on behalf of the user, but the attack could not analyze the content that returned in response to these redirections. Even partially Dynamic CSRF attack vectors relied on indirect information that might be disclosed from the user activities.
But 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 attack vector that was based on AJAX, and can 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: http://prezi.com/6vnl6so07b-c/ajax-hammer/
A demonstration of this attack was uploaded to Hacktics youtube channel: http://www.youtube.com/watch?v=JHJ1WW4Fcvw
The attack is further explained in the following whitepaper: http://hasc-research.googlecode.com/files/AJAX%20Hammer%20-%20Harnessing%20AJAX%20for%20%28Direct%29%20Dynamic%20CSRF.pdf
The following POC code can be used to understand simple AJAX based Dynamic CSRF scenarios: http://hasc-research.googlecode.com/files/AJAX-CSRF-Demo-Code.zip
The mitigation for the new attack vector are provided in the whitepaper.
Thanks to my friend Shay-Chen for this awesome article http://sectooladdict.blogspot.com