Archived Blog

Wget Denied

09.15.2008 - 5:56 PM

Lately we've been analyzing a lot of malicious Flash files. In a recent instance, I was investigating a situation where upon receiving a SWF linked URL in an email and clicking it, a user was automatically redirected to a spam Web site. When I used GNU's Wget utility to fetch the page, I got a "403 forbidden" response. I initially thought that either the attackers had blacklisted my location or they were being crafty and checking all HTTP header attributes.  The cookie was set, and everything else seemed like the transaction was being conducted as if a user clicked on the swf file as opposed to visiting the page with a simulated browser (Wget).

In order to verify this, I wrote a quick PERL script (zipped copy).

First, I put all the headers a server would expect if a user were to click on the the swf file and be directed to the spam Web site.

I received a "200 OK" server response with the spam content.

I then tried to verify that the server was looking at the HTTP REFERER, but was surprised to see that the response was the same with or without the correct REFERER. After playing with the headers for a few minutes, I noticed that it was simply looking at the user-agent. If the user-agent was Wget, it returned "403 Forbidden."...not as interesting as I had orginally thought.

Malicious Web pages are tracking more and more visting IP addresses and user-agents and randomizing the content served so that they can prevent security companies and other researchers from proper analysis. A simple thing to do on the research side of things is to create programs using LWP or curl to randomize your headers to look more like a real browser. Alternatively you could just change the user-agent in Wget using the "-U" option, but it may take more than this in the future..

Security Researcher: Stephan Chenette

Bookmark This Post: