Honeynet Delineates Web Application Threats

An anonymous reader sends us to a technical white paper written by the Honeynet Project & Research Alliance: Know Your Enemy: Web Application Threats. Based on analysis of malware collected by the project, the paper outlines a number of HTTP-based attacks against web applications and some ways of protecting Web servers. Included are code injection, remote code-inclusion, SQL injection, cross-site scripting, and exploitation of the PHPShell application.

Comments

Not malware or a bot, but still an attack.

[suso]

I swear sometimes that Slashdot articles follow my life. Just an hour ago I realized that some jackass had posted a link to a 5MB image on Bloomingpedia over 300 times in a comment he made on a myspace page. This was obviously an attempt to disrupt things either on Bloomingpedia or on the myspace page. So I decided to teach this jackass a lesson and use a rewrite rule that turns those image requests into humiliating messages about himself. Some people may have thought I went too far, and maybe that would be the case if he had posted just a few links to the image in his comment, but 300 is excessive. If you're going to do something like this, don't do it from your real account.

Re:Not malware or a bot, but still an attack.

[Anonymous Coward]

How exactly does posting a link 300 times do anything? Maybe it will get the image 3 hits (and chances are the image will be cached after the first 2), but, as stupid as myspace users can be, they do have the capacity to learn.



On a the C&A comic strip forum (galactanet.com/forum) there was recently this asshat lfucker which spammed the forum with threads displaying every single comic strip (of more than 600), probably in an attempt to cripple the site,

Re:Not malware or a bot, but still an attack.

[Anonymous Coward]

You have quite interesting cyberwar going on there! Very on topic. Now, could you send us a link to your MySpace page so that we can make you our friend?

Re:Not malware or a bot, but still an attack.

[Ambush Commander]

Aesthetically speaking, it's not very pretty, and even one 5 MB image can be pretty devastating to a cable connection. And I doubt the ability of whatever image-host it was to cache the image properly: you need the right headers to be sent and so many people get these things wrong.

There are also cases where people crash entire operating systems by using up all the video card's memory, see ha.ckers.org/imagecrash.html (WARNING: may crash you, though latest version of IE is not affected).

You could also use the technique to take down an image-hosting provider: use the large image as your signature in a popular webforum and use up all their bandwidth.

Re:Not malware or a bot, but still an attack.

[Anonymous Coward]

So I decided to teach this jackass a lesson and use a rewrite rule that turns those image requests into humiliating messages about himself. [...] If you're going to do something like this, don't do it from your real account./i>

What makes you think he did? For all you know, he goaded you into attacking somebody he doesn't like.

Re:Not malware or a bot, but still an attack.

[Anonymous Coward]

some jackass had posted a link to a 5MB image on Bloomingpedia [bloomingpedia.org] over 300 times in a comment he made on a myspace page [myspace.com]. This was obviously an attempt to disrupt things either on Bloomingpedia or on the myspace page. So I decided to teach this jackass a lesson and use a rewrite rule that turns those image requests into humiliating messages about himself.

Great, but... ... posting a link to that guys page on /. will disrupt more than a few people having 299 of the 300 references hit the browser cache.

Just IMHO.

Re:Not malware or a bot, but still an attack.

[tooyoung]

How exactly does posting a link 300 times do anything?

Well, talking about it will give you a nice slashvertisement for Bloomingpedia.org, whatever that is.

Re:Not malware or a bot, but still an attack.

[binaryspiral]

Suso... that was way to nice of a graphic to place in their.

So so many nasty internet images, so few myspace morons to mess with.

Re:Not malware or a bot, but still an attack.

[Anonymous Coward]

Linking to an image once or 300 times on the same page doesn't make a difference, the browser will load it once, and cache it for the next request.

Why do you have pics that are 5mb big on your website anyway?

Uh . .

[OverlordQ]

Based on analysis of malware collected by the project, the paper outlines a number of HTTP-based attacks against web applications and some ways of protecting Web servers.

chroot and run it as nobody?
Install mod_security?

Re:Uh . .

[Beryllium Sphere(tm)]

Well, don't use "nobody", use a non-shared account with a name like "www". And chroot won't help you with a SQL injection attack, especially if the scripts log in as "sa" (don't laugh, I've seen it done).

If it's the apps being attacked and not the server, the first line of defense is to sanitize user input.

Re:Uh . .

[flyingfsck]

Se Linux is probably a better idea than chroot.

Re:Uh . .

[garaged]

and grsecurity is even a better idea !

Re:Hear that silence?

[arlo5724]

I was thinking the same thing but then I thought, "What is there to say about this?" The answer appears to be nothing unless, like you, the reader has some relevant personal experience.

Web applet security is certainly an important matter, just not one that stirs up a great deal of controversy.

Hear that understanding?

[Anonymous Coward]

Or maybe like the science articles the subject flies over most heads. Just because it's called "news for nerds" doesn't mean that the majority have a nerds understanding. Now the YRO section is more illustrative of what slashdot has become.

Re:Hear that understanding?

[Anonymous Coward]

It might have went over non-web developer's heads, I'm not arguing over that (I'd still expect the chair/soviet russia/does it run linux/imagine a beowulf cluster/whatever memes to be here though).

But for the other part of /.'ers that develop web apps, this stuff is rather obvious. The same old issues:
-register globals - 'nuff said
-SQL injection (rather crappy explanation, and an extremely basic one here - there's FAR better articles on this!)
-people not validating stuff before they use it
-XSS
etc.

Along with the same old attacks we've been seeing in server logs for ages (as long as it's updated and secured properly, it shouldn't be a problem), and more of the TOTALLY obvious (blog comment spam? o rly? people creating accounts for phishing? how surprising!)

There's really nothing new here at all. And it's all rather basic. There's nothing to argue over.

If you're a web developer and any of this (basic web app security) is new to you, then your apps shouldn't be exposed to the internet!

I suppose you're right though. We see a lot more comments when it's about the (RI|MP)AA, DRM, GPL, SCO and the like. Kind of sad IMO. Haven't seen too much good articles in the developer section in a while either... Actually, there hasn't been any interesting articles (or comments to mod up) in the last couple days.

What I got out of it was...

[band-aid-brand]

Based on descriptions of the attacks in the article it looks like your general attacker is some kiddie that wields Google like a broad sword. Sure, they did have some attempts to recruit the honeypot into a bot net or set up a phishing attempt but most of the attacks just overwrote index (with text from a tutorial no less) or moved around in the file system. I didn't know the ratio of kiddies to people who know what their doing was so out of whack.

Re:What I got out of it was...

[Anonymous Coward]

I think the unspoken point of this paper is to show how young search engine attacks currently are. Look at the "Trends in Evasion and Anonymity" to see how poorly obscured the attacks.

The honeynet was able to identify only 40 (.01%) attacks making use of the Tor service.

Interesting...

Re:Hear that silence?

[Anonymous Coward]

don't know where you got the numbers, I heard that only 2 F-22's we're silenced.

Not malware or a bot, but still an attack-WMB

[Anonymous Coward]

Well at least he didn't link to the goatse.cx image 300 times. The massive barfing would have been a D.O.S. on bathrooms everywere.

Re:Hear that silence?

[DigitAl56K]

Web applet security is certainly an important matter, just not one that stirs up a great deal of controversy.

<voice="theatrical">Ohhh yes it does!</voice>

Patch! Patch! Patch!

[gbulmash]

The basic theme of this seems to be "patch! patch! patch!". A lot of the scripts they discussed (AWStats, phpBB, etc.) are ones where the people who use them don't have the expertise to dig into their code and fix problems themselves (or possibly even understand what the problems are).

The three rules of running a web app you didn't write:

• 1: Subscribe to the announcements mailing list
  
• 2: Apply patches immediately
  
• 3: Back-up your shit regularly, because even if you do 1 and 2, you might get hit and then you're going to need your backups.
  

Rule three is sort of universal for any webmaster, whatever they're running, even if they wrote it all themselves and have security certifications up the wazoo. Not running back-ups is about as wise as putting your 401k funds into lottery tickets.

- Greg

Related work

[Beryllium Sphere(tm)]

It's a good article for people who aren't focusing on security professionally. It shouldn't be news to anybody who keeps up with trends, though -- is anyone really still using register_globals?!

Michal Zalewski pointed out a cute hack some years ago. Search engine spiders have to follow links that end in queries, like "toparticle.php?page=1". Barring extraordinary and ultimately impossible care in the coding of the spiders, they could also follow URLs that include attack code after the question mark. In _Silence on the Wire_, he imagined a crook building a long list of links to potentially vulnerable systems, appending attack code to each, and leaving the list someplace where Googlebot and its colleagues will find it. Googlebot could twist the doorknob on 1.5 million PHPBB systems a lot faster than the crook possibly could.

Re:Related work

[Anonymous Coward]

Googlebot could twist the doorknob on 1.5 million PHPBB systems a lot faster than the crook possibly could.

He also mentioned using options like no-index.

Re:Related work

[MrTrick]

No-index is not the issue here.

As GP stated, you could publish on any webpage a list of links that contain malicious code in them. When Google, Yahoo, and other spiders crawl the links, *THEY* end up doing the attacking. That is rather dangerous, I'd say - it'd be very difficult to track down the person responsible, especially if the original webpage was posted on a zombie server.

It reminds me of this DailyWTF story: http://worsethanfailure.com/Articles/The_Spider_of _Doom.aspx

Re:Related work

[Qzukk]

He also mentioned using options like no-index.

The spider wouldn't see that until AFTER they followed the link to http://www.sucker.com/admin.php?user=default&pass= default&deleteallrecords=confirmed

Open Source

[trimCoder]

I dont want to start a flame war.. but here goes.

This is my fundamental issue behind open source. I much prefer custom applications for this reason. Lets face it, most of the open source web applications get about 10% of the functionality used. Under commercial use I would rather write customer apps to achieve this 10% than using open source with vulnerabilities. I know people will say patch. But lets face it, how many installations of un patched web apps are online at this minute.

Re:Open Source

[Anonymous Coward]

Open source isn't the problem. It's php. Unfortunately, php makes it extremely easy to write very insecure code. It's whole db access encourages bad design resulting in sql injection exploits. Look how Perl handles databases for example:


$sth = $dbh->prepare("SELECT * FROM users WHERE userID=?");
$sth->execute($userID);
$result = $sth->fetchrow_hashref();


Most crappy php scripts out there would look like this:


$result = mysql_query("SELECT * FROM users WHERE userID=$userID");


Or at best:


$result = mysql_query("SELECT * FROM users WHERE userID=" . addslases($userID));


Often, though, I see scripts reinvent their own bad "sanitation" libraries that I can see an exploit in.

Plus, most php scripts I look at don't bother with validation or do it badly. It doesn't help as most tutorials ignore this very important issue. Hell, read some tutorials. Many times I see security flaws in them, which n00bs then copy into their own code.

Writing php that isn't easy to exploit is much harder, it's actually just easier to learn Java and avoid a whole class of security issues.

I for one..

[Anonymous Coward]

I for one welcome our ursine overlords.

A Real web attack honeypot project

[mrkitty]

By The Web Application Security Consortium "From a counter-intelligence perspective, standard honeypot/honeynet technologies have not bared much fruit in the way of web attack data. Web-based honeypots have not been as successful as OS level or other honeypot applications (such as SMTP) due to the lack of their perceived value. Deploying an attractive honeypot web site is a complicated, time-consuming task. Other than a Script Kiddie probing for an easy defacement or an indiscriminant worm, you just won't get much traffic. So the question is - How can we increase our traffic, and thus, our chances of obtaining valuable web attack reconnaissance? This project will use one of the web attacker's most trusted tools against him - the Open Proxy server. Instead of being the target of the attacks, we opt to be used as a conduit of the attack data in order to gather our intelligence. By deploying multiple, specially configured open proxy server (or proxypot), we aim to take a birds-eye look at the types of malicious traffic that traverse these systems. The honeypot systems will conduct real-time analysis on the HTTP traffic to categorize the requests into threat classifications outlined by the Web Security Threat Classification and report all logging data to a centralized location." http://www.webappsec.org/projects/honeypots/

Re:A Real web attack honeypot project

[Anonymous Coward]

worms wouldn't hinder themselves by using open proxies. if they did, they'd probably hook into an onion routing network anyway for the availability and the added plus of anonymity, so a proxy honeypot could work in there. worms and botnets are usually where the end game is these days regardless of various vulnerabilities, aside from gaping database bugs

the paper seems to use low interaction solutions so they would be ez to make... if they emulate ecommerce bugs, then the 'perceived value' is super high

Re:A Real web attack honeypot project

[Anonymous Coward]

/bared/borne/

Re:A Real web attack honeypot project

[textstring]

FTFA: "About 6% of attacks were detected as using a proxy server."
you're not too far along are you?

Don't forget Cross site request forgery

[mrkitty]

The Cross-site Request Forgery FAQ http://www.cgisecurity.com/articles/csrf-faq.shtml

Compromised server

[tttonyyy]

Unfortunately I know about this all too well, the hard way.

Take your eye off the ball and lose your server, it's as simple as that.

If you have a server with a lot of PHP applications running, you need to watch them all. I forgot about a CMS installation on my server that was being preserved for historical reasons (not even linked from the front page, but obviously visible to google), and sure enough, it got exploited via a remote inclusion attack and was used for nefarious perposes for a while without being noticing.

Checking the logs, the definite path of attack was a google for a known vunerable version of the CMS system, and then application of a perl script to perform the hack. Clearly the vunerable system goes into a database of known vunerable systems that gets shared, because to this day, despite the CMS system being backed up and taken offline, my server get attacks about once every 20 minutes from perl scripts targeting that CMS.

I also regularly see bots automatically filling in registration forms with spam, and wikis getting referrer comments added to them or even the content changed by bots.

Looking after even a smallish webserver has proven to be a royal pain in the proverbial.

Regarding PHPShell, I'd hope most people hash their password in the config file rather than leaving it plain-text, and also hide it away somewhere non-obvious (maybe behind another level of protection to keep the webcrawlers from spotting it). But even with hashed passwords, logging in still uses a plaintext password, and is thus equally vunerable to good old ftp and telnet password sniffing. The Joomla extension to provide a plugin PHPShell is a worrying development, and I'm sure will lead to more PHPShell discoveries on servers.

Really the only way to avoid being compromised if you have a semi-busy site, is to learn how to compromise websites yourself, and try it on your own site (and it also teachs you what to look out for in logs). This in combination with regular patching seems to be the best way to stay one step ahead.

And yes, keeping the evidence is good - it gets stupid kids kicked off their ISPs when you send them the proof. ;) Now *that* is some satisfying karma. :)

from the article...

[Anonymous Coward]

The Google Translate service now forwards the IP address of its users. Attackers still using the Google Translate service against the honeynet are exposing their source IP address.

Now this is something that is really getting on my nerves. In basically every security-related paper the author seems to imply that the IP she's seeing is the IP of the attacker. If "3133t-v1l41n" is attacking a machine, I consider "3133t-v1l41n" to be the attacker, not the last visible machine (to the defender) that the "3133t-v1l41n" attack used. That IP address is probably the IP address of a compromised Windows machine, probably accessed through another compromised machine and so on.

This is probably not the IP of the attacker. I'm tired of reading such nonsense in papers from supposedly security-aware people.

Do what I do?

[Anonymous Coward]

I created a /images php script that takes files like /image/header.png and sends the correct file. If it detects that the graphic is being loaded offsite (ie, MySpace), it sends goatse.