forum.excito.org

I just sent this message to Johannes:

Dear Johannes,

Please check out the following post:

http://forum.excito.net/viewtopic.php?f=9&t=4633

This may need some serious attention from the Excito crew. Wewill off course do our best to help, but the problem needs fixins soon!

Yours,

Martijn

Martijn,

Thanks, was thinking about this too....

Deleted www-data cronjob came back very soon, 2 times deleted now.
I hope is won't be back but i'm not sure..

Puma

Ok, sorry for not seing this until now, and thanks Binkem for the notification. We'll try to look into this asap, and if any of you guys know anythiing we can do right now, please let me know.

To be perfectly honest I'm a novice in these matters and our two guys knowing about security (Tor and Carl) has left the company, so I'd really need some help here:

1) I guess an update covering up the hole would be a remedy, but this is just long-term, right now people are (getting?) exploited and since we cannot force updates this is not a 100% perfect fix. In any case, what would this update be? Change of access rules?

2) Figuring out the point-of-entry (if there is one common) would be really interesting. Can any of you more knowledgeable people help me here? @Ubi, if you suspect anything in particular I don't mind giving you access. (However, can someone explain how for instance the forum would point them to b3 users? Checking post IP's? Somehting else?)

I have checked the 6 B3's I have access to (a few private and a few at work) but all are OK (nothing in www-data's crontab), so at least we are not all affected.

A million thanks for being so alert and helping out, to all of you.

Considering we have reports of different attack vectors that use the same exploit I agree with Gordon that this is not a dedicated attack on the B3 group. However we all share the vulnerability thus it seems like we are attacked as a group. But the reality is that it doesnt actually matter at all whether or not this attack is targeted. The machines are vulnerable and should be fixed.

Now the only *solution* here is an update to PHP, everything else is treatment of symptoms. Second is that any symptom treatment also requires an update, as most users wont know how to use the shell.

If i understand this thing correctly, the attack uses malformed urls to execute commands. It also uses the ability of wwwdata to run scripts and set crontabs. This suggests that sanitizing input and removing shell and cron access from wwwdata should be a good first step. But because of all the redirects in bubbaadmin its a bit of a trick where to put these in the config files.

Im on an ipad now so typing the shell scripts is a bit difficult. Below could be redhat syntax too, so please test and report.
* crontab -r www-data
* echo www-data >> /etc/cron.deny
* usermod -s /bin/false www-data

The rewrite cant really be done via command line. Needs a whole new config file or a patch i guess...

Slight correction to Ubi's first command:

I think there may actually be a very straight forward solution. Since the exploit is about targeting the CGI version of PHP all you need to do is delete that CGI! Neither the default used mod_php and the Fastcgi method for the admin pages are affected and it will be very unlikely that one would break any web application by removing hat CGI.

Really? I never bothered to check whether this cgi was actually used, just assuming it was because it was there.... Wouldnt that mean a simple rename or chmod of the php executable would do the job? Can anyone have a go at this?

It's just there because it belongs to the PHP install. Up from there it is up to the admin to determine whether PHP should be run as a CGI or through mod_php (if running Apache).

Looks like I got hit again yesterday afternoon. Different code this time though. www-data crontab:
contents of /tmp/update:
So putting the rewrite condition in the apache config didn't help. I have since removed the shell and cron permissions from www-data so hopefully that will help in the future.

I guess this will do most of the work then

Ubi wrote:I guess this will do most of the work then

Code: Select all

chmod 644 /usr/lib/cgi-bin/php5
crontab -u www-data -r
echo www-data >> /etc/cron.deny
usermod -s /bin/false www-data

Just like to note that this is a change that will completely break the scheduling in Homeautomation for those of you that use it. We rely on cron-jobs running as www-data.

I've completely commented out the cgi-bin scriptalias and directory stuff from Apache config now, I guess that would do the trick? Any idea what that would break (tried doing everything that I normally do and it seems to work).

/Daniel

I think it breaks the upload from the file manager.

just out of interest, why is homeAutomation running as Apache?

That is correct. The upload.cgi is in that same folder.

Ubi wrote:I think it breaks the upload from the file manager.

I can live with that

Ubi wrote:just out of interest, why is homeAutomation running as Apache?

Because it's a web gui. It's running entirely in PHP. We've been thinking about making a daemon for the scheduling instead of jobs in cron/at, but right now that's how it works. It's almost platform independent, just a few lines differing between Windows and LInux versions.

/Daniel

I did some further digging into whether it is safe to delete /usr/lib/cgi-bin/php5 and I found that it is. With mod_php enabled, as it is, there should be no reason to run the CGI version, which in fact offers less performance.

The reasons to run the CGI are:

• Because you're not running Apache
• Because you want PHP to run as the directory owner, using suexec (hosting providers)
• Because you want to use this exploit

Okay. There's a fourth reason and that is because you want to run it as root. You can't use suexec for that however (I think...) but will need the Fastcgi plugin. On the B2/B3, this is how the Bubba admin pages are served. There's no need for alarm here as well, because the PHP instances required for this are not taken from the cgi-bin location but from /usr/bin.

So the answer is yes. It is safe. Just delete it, rename it or remove the executable flag from it.