Posted
by
samzenpus
on Monday October 06, 2014 @01:33PM
from the protect-ya-neck dept.

wiredmikey writes Hackers were able to break into some of Yahoo's servers by exploiting the recently disclosed Shellshock bug over the past few weeks. This may be the first confirmed case of a major company being hit with attacks exploiting the vulnerability in bash. Contacted by SecurityWeek, a Yahoo spokesperson provided the following statement Monday afternoon: "A security flaw, called Shellshock, that could expose vulnerabilities in many web servers was identified on September 24. As soon as we became aware of the issue, we began patching our systems and have been closely monitoring our network. Last night, we isolated a handful of our impacted servers and at this time we have no evidence of a compromise to user data. We're focused on providing the most secure experience possible for our users worldwide and are continuously working to protect our users' data."

It is.I ran a sanitised version of the initial exploit in a virtual Konsole, updated and ran it again in a new Konsole. The second time the attempted exploit was rejected, no reboot required.

This was early last week, the day the update became available. What made these muppets wait until they were attacked? Do they have some cretinous system in place where even security-relevant updates have to be scheduled a week in advance?

Dude..... you just hosed production.
You're getting written up, and also, nobody is going home until everything is back up, and the Myisamchk --safe-recover on the 5.6 TB mission-critical can NEVER go down or we lose $50000 an hour database you just broke is finished, oh, and by the way, you'll be getting the bill.

...the process from poking unusual commands at Apache or another web daemon to how that allows control of the box?

When I ran web servers I ran the daemons as unprivileged accounts that had no shell, and in a couple of instances there was chroot sandboxing to further help to mitigate penetration even if someone managed to exploit a vulnerability in the web daemon.

No, people are not following best practices. Bash is a DISASTER for tight security, and shouldn't even be on a box facing the Internet.

Look at the code used by John Hall (http://www.futuresouth.us/yahoo_hacked.html). It is Bash itself that is pinging back to Mr. Hall's box. No other executables were required for this. I wouldn't put it past someone to make an evil client-server system with nothing but Bash scripts sent over in headers.

The primary method is to send a browser user agent string that starts with "() { : ; } ; " and try to run a stupid (as in stupid people never remove them out of default installs) CGI script. Then when the shell gets invoked (either for a shell script CGI, or a dumbass system() call from another language CGI), the bug causes bash to execute whatever is on the end of the user agent string, before doing anything else. This is because the cgi-bin module takes all the various parameters of the HTTP request and sticks them into environment variables, and the bug executes environment variables before doing what it's been called up to do.

The easiest thing to do whether or not you can get a patched bash yet is to disable Apache's cgi-bin module.

Yahoo does, in fact, make extensive use of chroots jails, both on BSD and RHEL. Mainly, this is to isolate the platform software from the OS software from what I've seen -- but I'm not a security guru.

There's also the human problem of churn that goes on in the valley. Many things Just Work (TM), guy who write it leaves, still works, and then a bug like this comes out with no one to ask "Doing this vulnerability affect X?" because the person working on X hasn't worked here for years. There may be some adm

...the process from poking unusual commands at Apache or another web daemon to how that allows control of the box?

When I ran web servers I ran the daemons as unprivileged accounts that had no shell, and in a couple of instances there was chroot sandboxing to further help to mitigate penetration even if someone managed to exploit a vulnerability in the web daemon.

How is this working? Are people not folliowing good practices?

First off, let's clear the air - the apache or whatever HTTPd is being used is still running unpriviledged.

Second, what hackers are doing is exploiting CGI - because CGI data is often passed as environment variables, people are setting their User-Agent and Referer headers to exploit this: "() {:; }; command" being common (with command being ping a certain address).

What happens is the CGI gateway takes those, then sets environment variables like "REFERER=() {:; }; ping..." and "USER_AGENT=...", then calls system() to run the appropriate CGI script.

system() calls fork() and starts/bin/sh -c "command" and therein is the problem. Because/bin/sh almost always is/bin/bash on Linux, that means bash starts up, and it starts looking at the environment variables to set up the environment. It runs across REFERER and USER_AGENT, and sees that it's how bash passes exported shell functions to subshells, so it creates those functions. Unfortunately, the bug means that when those functions are defined, bash continues parsing - it sees the semicolon and the parses it as a regular command while it's still parsing environment variables.

This lets bash execute anything as the afflicted user.

So what can you do? Everything httpd can do - which may include accessing databases, or loading in other scripts and then getting those to run to get at databases, or dumping the server files.

You may not be able to write/etc/passwd, but you can certainly try to dump the user database for the web application.

It's a pretty deep bug because it's a design bug - POSIX doesn't specify how exported functions are passed from shell to subshell, so bash uses environment variables in a special format. One patch to fix it makes it so all functions must be declared as _BASH_FUNC_name= which helps limit exposure. There are going to be many other patches because fixing this is hard.

It isn't a matter of "subshell" -- which gets a copy of the parent process's memory from fork() -- but how functions are exported for use by future shells. For example, your shell (bash) runs less or vi (or python or php...), and from there a shell is started. That's not a subshell, it's a new process; it wasn't created by fork() so it doesn't have a copy of the original bash memory. The logical question is why anyone would need that functionality? In general, no one does, but it does offer some optimizatio

It isn't a matter of "subshell" -- which gets a copy of the parent process's memory from fork() -- but how functions are exported for use by future shells. For example, your shell (bash) runs less or vi (or python or php...), and from there a shell is started. That's not a subshell, it's a new process; it wasn't created by fork() so it doesn't have a copy of the original bash memory. The logical question is why anyone would need that functionality? In general, no one does, but it does offer some optimizatio

But on the RHEL, the golden boy of corporate uni-culture, it is. The UNIX reborn.

Let that be a moment of the appreciation for all the work Debian and Ubuntu people do behind the scenes. (Yes, Ubuntu too: the transition to dash was actively supported by Canonical since they wanted Ubuntu to boot faster and Debian folks were in agreement with the goal.)

P.S. Why RHEL hasn't picked up all the work Debian/Ubuntu has done for them? The usual

Yeah and who exactly is this afflicted user? Right, normally apache or some other unprivileged user who has relatively little power though granted you don't even want unprivileged users logging in from the Internet

So what can you do? Everything httpd can do - which may include accessing databases, or loading in other scripts and then getting those to run to get at databases, or dumping the server files.

Yeah and who exactly is this afflicted user? Right, normally apache or some other unprivileged user who has relatively little power though granted you don't even want unprivileged users logging in from the Internet

You are one setuid/SUID utility away from total system compromise. Even one such utility that invokes bash (or the default shell which is bash on Fedora and RH systems) and your box isn't yours any more.

Shellshock is *also* a privilege escalation vulnerability when exploited locally. Granted, you need to find such a setuid utility. But the utility does not need to be vulnerable by itself. It just needs to invoke the shell through system() or similar.

Yeah and who exactly is this afflicted user? Right, normally apache or some other unprivileged user who has relatively little power though granted you don't even want unprivileged users logging in from the Internet

For some, the ability to run their own code on a server with high bandwidth outward connection to the internet is all the power they need/want.If the server is an authorised mail source for a domain (e.g. spf) then so much the better.If the user has access to some writable disk space that can be used to host some interesting files, then there are uses for that.If the user can read the web site source or config files that may have value in itself or may lead to further penetration - but I'm sure you've never

I have gotten spam mail from myself several times the last few weeks (From Yahoo to Gmail), and have gone into the stupid yahoo site to change passwords several times. They were obviously compromised as hours after changing passwords, I would get more spam. Little point to changing passwords if they have total access to them. Might be time to finally drop them.

They were all a fictional job offer, that I guess I was going to give to myself for big bucks... Sounds like something I would do!:)

Did you check the email headers? On multiple occasions I have received emails showing my email address as the From, but the email headers showed the email originated from machines in foreign countries. Spoofing the From part of an email is trivial. This is a common technique by spammers to avoid spam filters since the account's own address is normally considered trusted. Now if the header says the email really did originate from Yahoo or Gmail, then that is a different matter, but again read the headers

No didn't bother, very well could be that. I use that as my throw away account. However that said, spoofing would be random. One would have to access my Yahoo address list to get my Gmail account. So unless spoofers used my Yahoo account and sent it around the world, it would be pretty coincidental that using my Yahoo address would hit my Gmail address several times in the last couple of weeks, and as I said, within hours of me changing passwords. Otherwise how would they know to use one against the other.

No, not random. Today malware will commonly harvest a person's address book (among many things to exploit what it can get off a person's machine), and once the address book has been harvested, sold to spammers. The spammers send emails to people in the address book with the email pretending to be from another person in the address book. The theory is that if both addresses are in a person's address book then there is a good chance they know each other, or they will have received legitimate email from tha

Maybe if you bothered to look at the relay logs in the header, you'd probably know they were sent from a fictional server pretending to be you (or totally legit from an exploit), but since said note was absent in your comment, I'm assuming you didn't know about spoofing email, which any script kiddie could do trivially.

Secondly, I can't say about Yahoo, but google has 2 factor auth to avoid said problems. Third, Google has account access history so that if 'bad people' were logged into the account, you'd at

I've seen the same thing, but as a couple of responders said, the emails are not actually coming from my account, but are coming from somewhere else. You're probably changing your passwords unnecessarily.

No, the real problem is this is the same response you would get from a company no matter what happened so it is meaningless. You screwed up but don't want to admit it? Say you are committed to security and it was a fluke. It really was a one time fluke by someone exploiting a near-zero-day? Say you are committed to security and it was a fluke. You deliberately sold out your customers and someone noticed their info was in the wild? Say you are committed to security and it was a fluke. Since it is always the same no matter what happened, what real use is the statement? Yes, I know it is to persuade those who don't know better.

"...We're focused on providing the most secure experience possible for our users worldwide and are continuously working to protect our users' data."

Marketspeak. I guess communications majors are taught to always do this. The problem is, we've heard crap like this so much, we've become inured to it. Nowadays, the minute I see a sentence like this, I assume everything else the spokesperson has said is a complete fabrication.

Yahoo treats their employees like garbage. To wit, Yahoo uses "stacked ratings" [allthingsd.com] which results in backstabbing and good employees getting fired.

When Yahoo's employees are spending all their time making sure someone else gets fired when the next employee reviews are made, instead of actually being able to do their job, it comes as no surprise that basic crap like updating security on servers falls by the wayside.

There are millions of servers out there that have not been patched yet.

To be more precise: There are uncounted servers out there that have a teeming population of parasites anyway.

But Yahoo has always been and still is the most incompetent of the big players, every time they screw up I'm surprised they still are around, since I never hear from them in between. There's not even a Yahoo phone... Not even that!

Alex Stamos, the CISO of Yahoo, posted an in-response bulletin [ycombinator.com] on Hacker News to clear up the rumor that this breach was caused by Shellshock.

Straight to the point, he states that it was not Shellshock that the system was vulnerable to but a separate command-injection vulnerability in their log parsing scripts. Though... Shellshock itself is a command-injection / parsing vulnerability so I'm sure many will skip over the technicalities and consider them one-in-the-same.