XSS in Zagat, exploiting a XOR-based obfuscation algorithm

Vote on HN
Share on Facebook

written on

This is a very interesting vulnerability I internally reported, and is now fixed. I find it interesting because it is not the usual XSS, but it exploits a XOR-based obfuscation algorithm of a user-controlled input.

Steps to reproduce

Go to http://www.zagat.com/newsletters/process?email=A2d5QgFwUzZRclE%2B VXcAcQ8wV2JQbF02BnACIQ0gBTUOPgxuAiUDZAJiAGkAdlZ%2BATNQOVRpDmAEb F1sfAVwQgMoASUDZQwqDDoPflB2NQEDRlA2AS1TNlFvUTo=

alert(document.cookie) was executed directly.

Details of the vulnerability

Zagat uses a XOR and position-based obfuscation for passing the email address that is then output to a HTML page on the same domain as a confirmation.

I reverse-engineered the obfuscation function, by exploiting the fact that passing 128 NULL ( 0 ) characters base64 encoded (http://www.zagat.com/newsletters/process?email=AAAA ... A=) to the above URL outputs the repeating 20-chars long encryption key ;) - old trick - XOR with NULL reveals the key.

Knowing that, I found out that there was another step, likely dependent on the difference between chars in the string. Using a clever bruteforce script, also thanks to collisions (several chars in email collided to the same output char), it is possible to make it output arbitrary HTML (and thus JS) to the page, without any user interaction.

Screenshots

Finding the XOR repeating key providing NULL bytes to reveal it

Finding the XOR repeating key providing NULL bytes to reveal it

Using Burp Suite to reverse the obfuscation algorithm

Using Burp Suite to reverse the obfuscation algorithm

Testing the Javascript payload with Burp

Testing the Javascript payload with Burp

Boom!

Boom!

This vulnerability was fixed in a matter of days, and now a proper protection is in place.

blog comments powered by Disqus