Cenzic 232 Patent
Paid Advertising
web application security lab

Expect Header Injection Via Flash

I probably didn’t go into enough detail the last time I talked about Amit Klein’s header injection vulnerability he disclosed with Flash. Blad3 brought my attention to this tool over at secunia that allows you to test sites for JavaScript injection via Expect headers. (I had better luck with Internet Explorer using that tool than I did with Firefox). But what it shows is that a huge chunk of major websites are now vulnerable to this. Without naming all of them, just trust me, it’s a lot.

The ramifications for this are huge. Being able to run any JavaScript you want one just about any website has some very serious issues. Of course you still need to get the user to view your Flash movie, so this has no added security issues if you always know where you are clicking, and the website itself has no cross site scripting vulnerabilities. However, if the site has XSS holes, or you are directed off site, suddenly all of your information is now able to be leaked via XML over RPC. If you happened to be logged into a major website that has the Expect issue flaw, your cookies can be stolen, any page that you have access to can be scraped. You can be used as a tool to launch XSS proxy attacks. This definitely goes into the JavaScript Malware bucket.

This is huge folks. Not just big, but huge. There’s no way of knowing exactly how many sites are vulnerable, but I’m going to go out on a limb here, and say a huge chunk of them will be until patches are issued.

Special thanks to Blad3 for making me re-visit this.

3 Responses to “Expect Header Injection Via Flash”

  1. ha.ckers.org web application security lab - Archive » Reducing CSRF Risk With Tiered Authentication Says:

    […] I’m not going to give you the full run down on how to stop CSRF because honestly, it’s a huge mess, and with things like the Expect vulnerability in Flash allowing you to read/write from a host, tons of those old methods are broken anyway. The one thing that hasn’t been broken is user interaction. CSRF works because in general it does not require user interaction. Things that rely on unique numbers outputted only work if you can’d get the user to do an XMLHTTPRequest to read the page and replay it, just like the browser would. Trust me, it works. If the site is cross site scriptable (and they almost all are) the method of using unique strings is pretty broken. But there is another way. […]

  2. Vinicius K-Max Says:

    ActivePerl error:

    V:\>perl fierce.pl -help
    Can’t locate Net/DNS.pm in @INC (@INC contains: C:/Perl/lib C:/Perl/site/lib .)
    at fierce.pl line 11.
    BEGIN failed–compilation aborted at fierce.pl line 11.

    V:\>

  3. RSnake Says:

    Yes, you need to install the libraries, as the main page says:

    Requirements: This is a PERL program requiring the PERL interpreter with the modules Net::DNS and Net::hostent. You can install modules using CPAN:

    perl -MCPAN -e 'install: Net::DNS'
    perl -MCPAN -e 'install: Net::hostent'