forum.excito.com

Johannes, are you going to fix the erroneous shell setting for www-data in this patch?

Ubi wrote:Johannes, are you going to fix the erroneous shell setting for www-data in this patch?

For what reason exactly? It doesn't in any way block the spawning of a (different) shell. Only thing it would prevent is someone changing the password and then be able to get in directly through ssh, meaning that the server would need to have ssh enabled to the outside world.

That said. Is there any particular reason why Squeeze has /bin/sh in the first place?

johannes wrote:Oh, we must have missed that. The exploit info stated otherwise: http://www.exploit-db.com/exploits/29290/, I'll check with the devs on how to proceed.

Hi Johannes,

I just upgraded to 5.3.3-7+squeeze17 and retried the exploit. It now returns with a HTTP/1.1 500 Internal Server Error, so that definitely appears to fix the issue.

It is good practice and has been shown to mitigate a number of scriptkiddie attacks. There is no reason *not* to have it. But it is not a silver bullet. Same goes for other UIDs that do not need a shell.

Gordon wrote:

Ubi wrote:That said. Is there any particular reason why Squeeze has /bin/sh in the first place?

Probably because Debian has it that way see this bug report

ryz wrote:

Gordon wrote:

Ubi wrote:That said. Is there any particular reason why Squeeze has /bin/sh in the first place?

Probably because Debian has it that way see this bug report

Well yeah, but that was the question.

Ok, fix released to Elvin now, we have done a few days of testing and it looks OK. I will make a public forum upgrade announcement on monday.

@Ubi, no, the fix is just a quick php5 wrapper to stop that exploit, to make it as fast as possible. You are right that a more general security update is needed as well.

Hi guys!

I've been away for quite some time know. Good to see most of you are still here

Yesterday I noticed, by pure accident, that my B3 was under attack. The tell tale was a bot.php line when listing processes for a different reason. I also noticed a lot of /sbin/init processes running. Came here to warn you and see if anyone else have had the same attack, when I found this thread.

I have since then been going through the log files and I can see in the apache log that the attack started Nov 2. At Nov 4 there were several attempts by www-data to gain root access, and yesterday www-data tried to gain access as me and all other users on the B3. I couldn't find any cron jobs by www-data, but the log reveals there have been some the last days. For some reason they are gone now (not my doing).

Now, the system has been updated and everything seems to act normal, but is there any chance they can have put some back door on the system? I'm a complete newbie when it comes to securing webservers and locate possible threats. Any input on this matter is very welcome.

/Johan

Hi all,

I only just recently noticed this too (Novemeber 4th)
CPU was running high. top showed several "perl" processes, but they where not in the ps output.
There was a lot of stuff started by www-data via /sbin/init though.
Since then port 80 has been blocked in my firewall, I have removed tonnes of web-related shite I have carelessly installed during the years, owned by www-data. For some reason this was the last place I looked; I thought it was my own doing...
Patch is now applied, but I'm still suspicious.

This post is only really here to make sure I get an email update if there are any developments in this thread
(Sorry for wasting space...)

Cheers,

Cheeseboy

Hi again!

Still examining my B3 for back doors.

Just noticed that on my unit there is a /usr/lib/cgi-bin/php5.orig (6.9MB) along with a /usr/lib/cgi-bin/php5 (5.7kB). Is this file normal (it is a binary for ARM)? The time stamp of the php5 one is Nov 5, which is after the initial attack. It's owned by root and I can't see they have gained root access, but then I've only been skimming the log files.

/Johan

Hi Johan,

So do I: It is probably the patch you've just applied. The date would be when it was built.
Check if the c-time matches the time when you installed the patch: I do think Excito should tell us exactly what has been done though, so we don't have to worry about things like this.

Cheers,

Cheeseboy

Well I guess that with these last few posts the backdoor is exposed again (to a hacker reading this board).

you read too many spy novels.

anyway, the php5 config is identical on my system, with the same MD5. The observed intrusion @cheeseboy is no evidence that the backdoor is exposed again or even whether it is the same vulnerability. It could even be remnants of an intrusion that initiated before the patch and wasnt fully cleaned.

@Ubi Not as many as those that believe that hackers are specifically targeting B2/B3 owners.

Somewhat amazing that it took this long for people to discover that they'd been hacked. The first log entries I have on this exploit date back to June 10 and there are actually not that many. There's just 68 of them, including two today. The IP addresses are probably spoofed, but while the attempts continue I may try to alter my catch-all script to retrieve the payload of the request and see what's actually going on. If they have a terminal set up to listen for incoming connections I'll then know their real address.

Gordon wrote:Well I guess that with these last few posts the backdoor is exposed again (to a hacker reading this board).

Ahh, stupid me. I guess I realize my mistake now. I was so eager trying to find back doors I mistook the protection for a possible back door. Sorry 'bout that

Guess this is the first time I've provided too much information, it's usually the opposite

/Johan