My Benign URL

Recently, while playing with an XSS and trying to get execution with as little interaction as possible in Firefox (confined within div tag), I discovered a neat (lame?) trick in one of my tangents. “Discovered” probably isn’t the right word since I’m sure it’s probably old/known, but I didn’t look very hard to see if anyone else had written anything else about this topic. If anything it might be either new or forgotten. The result of this tangent ended up not being applicable to my XSS, but I realized it could be useful as the first link in a chained attack.

Getting to the point, as attackers, getting people to click on things is a necessity of many client-side attacks. Since a major use case of “the Internet” is pretty much clicking on links, it’s arguable that’s a pretty trivial requirement to satisfy no matter what, but security awareness has made some people paranoid (thanks, Rick Rollers). Turns out there’s an exploitable association many Internet users (I think) make with what a safe URL is versus one that might be dangerous. For example, when I see links to text files or images, I’d consider it pretty safe. Even a link to an audio file I’d consider that at worst it might be exploiting a vuln in my mp3 player.

So I’ll be honest, I would have clicked (or copy/pasted) these thinking it’d be fine.

http://www.hackeroutfit.com/screenshot.jpeg

http://www.hackeroutfit.com/license.txt

In short, the browser will automatically and correctly handle certain file types (images) for you in some cases, like loading only images within <img> tags in an HTML response, but will rely on the server-provided mime type for direction on handling files directly requested in a URL. This means that an attacker-controlled server can specify any content-type for any file extensions, which is the intended flexibility. The intention being that the content-type header will provide the right information so that the user agent can make a decision about how to present the content (Ref: www.w3.org/Protocols/rfc1341/4_Content-Type.html).

Configuring your attack web server is pretty trivial. For example, you could add the following in the configuration file for Lighttpd:

mimetype.assign = (
        ".html" => "text/html",
        ".txt" => "text/html",
        ".jpg" => "text/html",
        ".jpeg" => "text/html",
)

Your web server will now send the “incorrect” content-type:

GET /license.txt HTTP/1.1
Host: www.hackeroutfit.com

HTTP/1.1 200 OK
...
Content-Type: text/html
...
...

For offensive security testing, this has immediate uses if your targets will more readily click links for what they believe are for specific, safe file formats. In addition to serving up a dummy text or picture file that the victim might expect to see in your link, other payloads could be hidden in the response that might conduct the attacks you’d normally serve up, like:
CSRFs
Browser autopwn / drive by downloads
NTLM relaying
DNS rebinding
Clickjacking? (Some people like to click / highlight text as they read)

Your (malicious) JavaScript could do some of the usual things too (though remember it executes only in the context of your site; it’s not XSS).

Is there, or will there be any fix? I wouldn’t think so, no, since it’s not really a vulnerability. It’s just an abuse of the way things are supposed to work.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s