6 ms·

Another ShellShock exploit in the wild

44 points by crazydoggers 12y ago

mhurron 12y ago
Ok, let me see if I have this straight, since I'm not seeing an end of the world situation here. This requires a webserver to be running CGI (mod_cgi or whatever) and the get request has to go to a valid page, correct? So in this case `GET /cgi-bin/hello ... yada yada yada` /cgi-bin/hello has to be a valid location. So, explain to me how this is any worse than any remote execution vulnerability in something like PHP?
- yebyen 12y ago
  > explain to me how this is any worse than any remote execution vulnerability in something like PHP? Why does it need to be worse than something you might find in PHP? If it's a worm that's been found in the wild spreading by exploiting a remote execution vulnerability in bash and cgi, isn't that bad enough?
  - mhurron 12y ago
    > Why does it need to be worse than something you might find in PHP? Because that's what it's being hyped as, or more correctly hyped as "OH MY GOD IT'S THE END OF EVERYTHING" when in reality it appears that if you're not running ssh with forcecommands or a webserver with CGI enabled, you don't care, just like if you didn't run a webserver with PHP enabled a PHP vulnerability wouldn't really be much of an issue to you.
    - general_failure 12y ago
      Yeah, I am not sure why there is so much hype. From what I can tell you are affected only if you use CGI or the like somewhere in your response chain. AFAIK most people use http reverse proxies, phpfm, wsgi and the like. They are all unaffected.
      - epochwolf 12y ago
        There's a lot of older web applications that run via cgi.
      - nitrogen 12y ago
        It is not just CGI. It is any process that uses user-controlled environment variables anywhere, that later eventually happens to call something that calls something that calls system() or executes a shell script. So CUPS printer servers at universities may be vulnerable. Dhclient may be vulnerable to malicious DHCP responses. Anything that calls out may be vulnerable (lots of mail libraries actually call /usr/bin/sendmail or the like; better hope they don't use system() or a bash /bin/sh to do it). This is a big deal because there's a ton of stuff that uses environment variables that is and is not a web server, and very little time to track it all down before a black hat or oppressive regime gets there first.
    - drvdevd 12y ago
      Think of it this way: this doesn't just affect webservers. It affects most unpatched bash instances. The vector of attack is through environment variables in bash. You could argue that 90% of the worlds' PHP servers will probably contain bash, but that the converse is not true: 100% of the worlds' bash instances may not contain PHP. Therefore, the attack surface is much larger and the attack vector much more basic to the way the OS works. Since environment variables are so "leaky" -- they are often spread between processes without any sort of checks -- there are essentially innumerable ways for an exploit to reach a vulnerable version of bash, both remotely and offline.
      - mhurron 12y ago
        > It affects most unpatched bash instances But it needs something to expose bash to the outside world. Without mod_cgi (or the like) or sshd with a specific configuration, a vulnerable bash isn't going to be remotely exploitable.
        nitrogen 12y ago
        No, it doesn't. Bash is already indirectly exposed to the world by anything that calls system() with bash as /bin/sh. More library functions than you might expect are wrappers around external binaries (e.g. mail() calling /usr/bin/mail) on PHP, Ruby, etc. Their authors probably thought they were safe with escapeshellarg()-like functions, but now any user-controlled env var set for whatever reason, not just CGI, is an attack vector, and not just through HTTP and not just through headers.
        skuhn 12y ago
        It is correct that PHP's mail() function will fork a shell: sendmail = popen(sendmail_cmd, "w"); Which calls /bin/sh to execute sendmail_cmd. However, two things must also be true: 1. /bin/sh is bash 2. PHP has set environment variables with user-provided data #1 is often the case, but is much less common now than in the past. #2 is not commonly the case, PHP does not even automatically create PHP variables from user-provided data anymore (because it is a terrible idea to put untrusted data into a trusted scope without sanitizing).
- SchizoDuckie 12y ago
  It's not worse, it's equal. But the thing is that people didn't think that this would happen and now they're affected. So yes, that's quite 'drop your sandwich while you're eating it and go update your servers'
- dz0ny 12y ago
  FYI some routers, STBs run httpd with cgi-bin. It's lot worse than some PHP vulnerability, because PHP is not used on those devices but bash is.
  - yourad_io 12y ago
    Don't most routers run some form of busybox or ash rather than bash?
    - mzs 12y ago
      Yes, I'm getting really annoyed seeing comments like this pop-up repeatedly, ash has no exporting of functions even: # type foo foo is a shell function # export -f foo -sh: export: Illegal option -f
  - mhurron 12y ago
    You know, this whole thing would be a lot clearer to everyone if the following would be clearly communicated: Are you running sshd with ForceCommand? - Get Patching (when a patch is out) Are you running a webserver that uses 'old style' CGI (are you really sure you're not?) - Get Patching (when a patch is out) Are you absolutely sure neither of the above is true? Then patch bash in your next patch cycle. The super-hype vulnerabilities are getting is just muddying the waters when trying to get actual information.
    - nitrogen 12y ago
      Are you certain that no process on your system ever sets an environment variable to a user-controlled value? Get patching. Hypothetical: some GPG library is just a wrapper around /usr/bin/gpg. Maybe that library uses an environment variable to set a password that doesn't show up in ps. Maybe that library used system() instead of execve(). That password is now an attack vector. See also /usr/bin/mail called by mail() functions in scripting languages, /bin/hostname, /bin/uname, etc. If any user-controlled variable is set in the environment, those calls become potential attack vectors
- danielweber 12y ago
  It's like a remote execution vulnerability in PHP and Ruby and DHCP and Django and Perl and any of a bunch of different services all layered together. Environment variables are passed around all the time.
- thefreeman 12y ago
  I understand why its a big deal. What I don't understand is why everybody seems to think its necessary to start posting every script kiddies attempt at spreading their crappy ddos / botnet scripts via the vulnerability.
general_failure 12y ago
Can someone explain why apache cgi use bash? You can of course setup an environment without bash and execute your scripts. It's just an argument to exec*() after all.
- danielweber 12y ago
  All the modern webserver<->framework interfaces don't call bash directly, but they may end up calling it indirectly in one of a dozen different ways.
  - tlrobinson 12y ago
    And environment variables are typically inherited by subprocesses, so if the CGI script executes anything (that executes anything, recursively) that uses bash (including system() if /bin/sh is bash, e.x. on OS X) this bug becomes exploitable?
- ZoFreX 12y ago
  It doesn't necessarily. But what it does do is pass information about the request in environment variables - that's step 1: attacker controls the contents of an environment variable. Then, if at any point the script invokes bash, or calls something like system(), exec() or popen() and has bash set as the default shell, then bash will run, with those environment variables set. That's step 2, and the server is now the attacker's.
daviddede 12y ago
That's just the start. Once people start hitting cpanel servers: http://blog.sucuri.net/2014/09/bash-vulnerability-shell-shock-thousands-of-cpanel-sites-are-high-risk.html http://blog.sucuri.net/2014/09/bash-vulnerability-shell-shoc...
deleted 12y ago
[deleted]
motoboi 12y ago
This is a Perl script that connects to a IRC channel and waits for commands. Commands can be: portscan (scans a host for open ports) tcpflood (try to keep 1000 TCP connections open to a host for a specified period of time); udpflood (send UDP packets to all ports on a host with an payload of a specified number of 'A' characters for a specified period of time); httpflood( send HTTP requests to a host for specified period of time [with HTTP Keep-Alive header]); shell (execute arbitrary commands on the host); google (use google to find other hosts to infect [targets modules.php]); version (returns bot version) All commands send status back via IRC. There are several brazilian portuguese strings and comments, although is not clear if the author is brazilian. Interesting stuff.

44 points by crazydoggers 12y ago

Ok, let me see if I have this straight, since I'm not seeing an end of the world situation here. This requires a webserver to be running CGI (mod_cgi or whatever) and the get request has to go to a valid page, correct? So in this case `GET /cgi-bin/hello ... yada yada yada` /cgi-bin/hello has to be a valid location. So, explain to me how this is any worse than any remote execution vulnerability in something like PHP?

yebyen 12y ago
> explain to me how this is any worse than any remote execution vulnerability in something like PHP? Why does it need to be worse than something you might find in PHP? If it's a worm that's been found in the wild spreading by exploiting a remote execution vulnerability in bash and cgi, isn't that bad enough?
- mhurron 12y ago
  > Why does it need to be worse than something you might find in PHP? Because that's what it's being hyped as, or more correctly hyped as "OH MY GOD IT'S THE END OF EVERYTHING" when in reality it appears that if you're not running ssh with forcecommands or a webserver with CGI enabled, you don't care, just like if you didn't run a webserver with PHP enabled a PHP vulnerability wouldn't really be much of an issue to you.
  - general_failure 12y ago
    Yeah, I am not sure why there is so much hype. From what I can tell you are affected only if you use CGI or the like somewhere in your response chain. AFAIK most people use http reverse proxies, phpfm, wsgi and the like. They are all unaffected.
    - epochwolf 12y ago
      There's a lot of older web applications that run via cgi.
    - nitrogen 12y ago
      It is not just CGI. It is any process that uses user-controlled environment variables anywhere, that later eventually happens to call something that calls something that calls system() or executes a shell script. So CUPS printer servers at universities may be vulnerable. Dhclient may be vulnerable to malicious DHCP responses. Anything that calls out may be vulnerable (lots of mail libraries actually call /usr/bin/sendmail or the like; better hope they don't use system() or a bash /bin/sh to do it). This is a big deal because there's a ton of stuff that uses environment variables that is and is not a web server, and very little time to track it all down before a black hat or oppressive regime gets there first.
  - drvdevd 12y ago
    Think of it this way: this doesn't just affect webservers. It affects most unpatched bash instances. The vector of attack is through environment variables in bash. You could argue that 90% of the worlds' PHP servers will probably contain bash, but that the converse is not true: 100% of the worlds' bash instances may not contain PHP. Therefore, the attack surface is much larger and the attack vector much more basic to the way the OS works. Since environment variables are so "leaky" -- they are often spread between processes without any sort of checks -- there are essentially innumerable ways for an exploit to reach a vulnerable version of bash, both remotely and offline.
    - mhurron 12y ago
      > It affects most unpatched bash instances But it needs something to expose bash to the outside world. Without mod_cgi (or the like) or sshd with a specific configuration, a vulnerable bash isn't going to be remotely exploitable.
      - nitrogen 12y ago
        No, it doesn't. Bash is already indirectly exposed to the world by anything that calls system() with bash as /bin/sh. More library functions than you might expect are wrappers around external binaries (e.g. mail() calling /usr/bin/mail) on PHP, Ruby, etc. Their authors probably thought they were safe with escapeshellarg()-like functions, but now any user-controlled env var set for whatever reason, not just CGI, is an attack vector, and not just through HTTP and not just through headers.
        skuhn 12y ago
        It is correct that PHP's mail() function will fork a shell: sendmail = popen(sendmail_cmd, "w"); Which calls /bin/sh to execute sendmail_cmd. However, two things must also be true: 1. /bin/sh is bash 2. PHP has set environment variables with user-provided data #1 is often the case, but is much less common now than in the past. #2 is not commonly the case, PHP does not even automatically create PHP variables from user-provided data anymore (because it is a terrible idea to put untrusted data into a trusted scope without sanitizing).
SchizoDuckie 12y ago
It's not worse, it's equal. But the thing is that people didn't think that this would happen and now they're affected. So yes, that's quite 'drop your sandwich while you're eating it and go update your servers'
dz0ny 12y ago
FYI some routers, STBs run httpd with cgi-bin. It's lot worse than some PHP vulnerability, because PHP is not used on those devices but bash is.
- yourad_io 12y ago
  Don't most routers run some form of busybox or ash rather than bash?
  - mzs 12y ago
    Yes, I'm getting really annoyed seeing comments like this pop-up repeatedly, ash has no exporting of functions even: # type foo foo is a shell function # export -f foo -sh: export: Illegal option -f
- mhurron 12y ago
  You know, this whole thing would be a lot clearer to everyone if the following would be clearly communicated: Are you running sshd with ForceCommand? - Get Patching (when a patch is out) Are you running a webserver that uses 'old style' CGI (are you really sure you're not?) - Get Patching (when a patch is out) Are you absolutely sure neither of the above is true? Then patch bash in your next patch cycle. The super-hype vulnerabilities are getting is just muddying the waters when trying to get actual information.
  - nitrogen 12y ago
    Are you certain that no process on your system ever sets an environment variable to a user-controlled value? Get patching. Hypothetical: some GPG library is just a wrapper around /usr/bin/gpg. Maybe that library uses an environment variable to set a password that doesn't show up in ps. Maybe that library used system() instead of execve(). That password is now an attack vector. See also /usr/bin/mail called by mail() functions in scripting languages, /bin/hostname, /bin/uname, etc. If any user-controlled variable is set in the environment, those calls become potential attack vectors
danielweber 12y ago
It's like a remote execution vulnerability in PHP and Ruby and DHCP and Django and Perl and any of a bunch of different services all layered together. Environment variables are passed around all the time.
thefreeman 12y ago
I understand why its a big deal. What I don't understand is why everybody seems to think its necessary to start posting every script kiddies attempt at spreading their crappy ddos / botnet scripts via the vulnerability.

general_failure 12y ago

Can someone explain why apache cgi use bash? You can of course setup an environment without bash and execute your scripts. It's just an argument to exec*() after all.

danielweber 12y ago
All the modern webserver<->framework interfaces don't call bash directly, but they may end up calling it indirectly in one of a dozen different ways.
- tlrobinson 12y ago
  And environment variables are typically inherited by subprocesses, so if the CGI script executes anything (that executes anything, recursively) that uses bash (including system() if /bin/sh is bash, e.x. on OS X) this bug becomes exploitable?
ZoFreX 12y ago
It doesn't necessarily. But what it does do is pass information about the request in environment variables - that's step 1: attacker controls the contents of an environment variable. Then, if at any point the script invokes bash, or calls something like system(), exec() or popen() and has bash set as the default shell, then bash will run, with those environment variables set. That's step 2, and the server is now the attacker's.

daviddede 12y ago

That's just the start. Once people start hitting cpanel servers: http://blog.sucuri.net/2014/09/bash-vulnerability-shell-shock-thousands-of-cpanel-sites-are-high-risk.html http://blog.sucuri.net/2014/09/bash-vulnerability-shell-shoc...

deleted 12y ago

[deleted]

motoboi 12y ago

This is a Perl script that connects to a IRC channel and waits for commands. Commands can be: portscan (scans a host for open ports) tcpflood (try to keep 1000 TCP connections open to a host for a specified period of time); udpflood (send UDP packets to all ports on a host with an payload of a specified number of 'A' characters for a specified period of time); httpflood( send HTTP requests to a host for specified period of time [with HTTP Keep-Alive header]); shell (execute arbitrary commands on the host); google (use google to find other hosts to infect [targets modules.php]); version (returns bot version) All commands send status back via IRC. There are several brazilian portuguese strings and comments, although is not clear if the author is brazilian. Interesting stuff.