Lame script-kiddie attacks

[Guest LH91325]

The latest issue on my site(s) today, more lamerz crawling every site hoping to find a vulnerability: //wp-login.php/wordpress//wp-login.php/wp//wp-login.php Just what about "//" makes this a legitimate URI? (Same dude or dudette already hit 3 of my sites today, of course all my sites on the same shared host/IP.) I filter all my URIs and whenever I see a double slash I just send it to my error handler and tell it to 400 the visitor. That's a 400 response header and "Bad Request: The request could not be understood by the server due to malformed syntax." It makes me wonder why script kiddies are running flawed scripts like this, or why those who operate websites accept URIs with double slashes. I've never seen a valid URI with two slashes although I guess you could do it if you want to. (I'm not referring to the double-slash after the protocol e.g. http: or etc.) I'll say that 90% or more of these scans come from web hosting services. That's where the lamerz get cheap accounts, maybe shell accounts although I can't see any reason this type of script couldn't be run from any non-shell account with the right script. I almost never seen this type of scan run from ordinary home accounts with cable or DSL access like most of us run. These attacks come from shared hosting accounts. This particular access came from the client domain secureserver.net which is owned and operated by GoDaddy.com LLC. Thanks GoDaddy. Who's your daddy? I suppose I should just report them to the GoDaddy abuse contact. I would be spending many hours a week if I reported every kiddie running a script on my site trying to find a weakness. It's easier to just fix it from my end: // = 400 error, bad request. Why do script kiddies even write this drivel? What does your site do when faced with a double-slash URI?

Edited May 17, 2012 by LH91325

[boen_robot]

Maybe there's some sort of old Apache or PHP vulnerability regarding this, and they're testing for it alongside with the test for WordPress. Like maybe a variant of this issue.What I do with regards to any file path is to resolve it "manually" with realpath(), and then check if the result is within the expected base folder, and return 404 if not (or if realpath() fails because the file doesn't exist). This gives you maximum fault tolerance, while still eliminating attempts for access outside the web root. If I had WordPress anywhere, this approach wouldn't stop people from accessing it though.

[Guest LH91325]

I guess I've done a similar thing except using my own code. All my site visitors come through my index.php, including error pages. In fact the only other file in the directory is .htaccess. No directories except my main site wihch has a directory for images. I just 404 or 400 things that make no sense in terms of my normal site traffic. It's the old security via obscurity although that's purely accidental. I can't help it if my software is a one-of-a-kind custom application, but at least there aren't any known vulnerabilities because it isn't known. It doesn't even have a name. As soon as I saw those // accesses they looked like the old ../../../../ stuff so I put an end to it real quickly. It's annoying that so many of these script kiddies get access to hosting accounts and then run vulnerability scanning scripts, crawling the web looking for illegitimate access to honest peoples' sites.

[davej]

I think it's obvious why they would put these on a site rather than do this from home. They want plausible deniability. Some Bulgarian must have hacked into their site and put that code on there.

[justsomeguy]

Psh. Damn Bulgarians.

[Guest So Called]

I think it's obvious why they would put these on a site rather than do this from home. They want plausible deniability. Some Bulgarian must have hacked into their site and put that code on there.

They put their code on hosting accounts, often "shell" accounts (where they can run executables) on their shared server so they can run it 24/7, for as long as they like. Their result is a list of websites that may have the vulnerabilities. They can then hack those sites from somewhere else, home, proxy, whatever. I'm not sure there is even anything that can be done to people running these scripts, and it probably doesn't even violate any laws in itself. It is the hacking later that is illegal, and may not even be illegal depending on what country the hacker or script kiddy is located in. This is why so many MP3 servers were hosted in RU (Russia). Russia didn't recognize the international copyrights. Selling MP3 downloads wasn't illegal there (selling them without consent of the copyright owners). I don't know if that practice still continues. A few of the music CDs I bought from private sellers on Amazon turned out to be Russian forgeries. Obvious forgeries, even to a non-expert like me. (I sent them back to the seller and got a refund. Amazon DOES NOT like that.) Sorry to say, people will steal anything, particularly if they're in hard to reach countries or if they can drag their tracks through such countries. Also sorry to say, some people think hacking is funny even if they're doing it for no reason other than fun. And web designers and content creators like us have to defend ourselves from these bad people. They'll hack your server and deface your web pages just for fun.

[boen_robot]

I think it's obvious why they would put these on a site rather than do this from home. They want plausible deniability. Some Bulgarian must have hacked into their site and put that code on there.

Psh. Damn Bulgarians.

:lol:my lungs... the pain... gotta stop laughing:lol: