Hackers Compromised Yahoo Servers Using Shellshock Bug 69
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."
Re:Color me shellshocked! (Score:4, Funny)
Re: (Score:1)
Most likely the reboot is actually unnecessary as well.
Re: (Score:3)
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?
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
So sys-admin only use Debian based systems?
What about RHEL, AIX, HP-UX, Solaris, Tru64, VMS, Windows/Cygwin
How about all that networking kit which use Bash for their scripting & WebUI
Can someone explain... (Score:2)
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?
Re: (Score:3, Informative)
Chroot is not a security tool.
Running as a no-shell account doesn't help when your process invokes a shell directly.
Local privilege escalation vulnerabilities are rampant.
Re: (Score:3, Informative)
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.
Yeah ... (Score:2)
If the FBI has any sense they'll reply to his emails with a search warrant.
Reply to This Parent Share
... that will fix the problem real good and stuff.
Re:Can someone explain... (Score:5, Informative)
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.
Re: (Score:2)
The easiest thing to do whether or not you can get a patched bash yet is to disable Apache's cgi-bin module.
and qmail procmail exim postfix sshd openVPN some inetds... and all the vectors that haven't been found yet.
The easiest thing to do is to fix bash - using rm if necessary
Inside View (Score:1)
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
Re:Can someone explain... (Score:5, Informative)
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.
Re: (Score:1)
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
Re: (Score:3)
Re: (Score:3)
Because /bin/sh almost always is /bin/bash on Linux [...]
On most systems - number-wise - which are Debian-based - it is not.
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
Re: (Score:1)
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
Re: (Score:2)
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.
Re: (Score:2)
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 can believe it... (Score:3)
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! :)
Re: (Score:2)
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
Hell, I have been trying to get me to buy wAtche$ for years.
Last time I looked at the headers, it was from Romania.
Re: (Score:1)
Re: (Score:2)
If somebody 30 years ago would have created a sentence like that one, they would have received nothing but puzzled stares.
Sounds like Yahoo's managers have thet problem as well.
Re: (Score:2)
In their defense, it's more like "update bash over and over again".
Yahoo Sports (Score:4, Funny)
I'm going to blame this for my fantasy football loss this week... and all previous weeks.
Re: (Score:1)
I'm going to blame Obama since I cannot pass blame on the CNN Discus boards anymore.
The Simpsons (spoilers from last night's episode) (Score:2)
At least Homer J(ay) Simpson can use this excuse after last night's episode. ;)
Yahoo still has servers? (Score:2, Informative)
FTFY (Score:2)
Last night, we isolated a handful of our impacted servers and at this time we have no evidence of a compromise to user data ... that we want to admit to
FTFY
Re: (Score:2)
OMG! (Score:2)
Re: (Score:2)
Re: (Score:2)
Baaaa! (Score:5, Insightful)
We're focused on providing the most secure experience possible for our users worldwide and are continuously working to protect our users' data."
Who else is sick of reading this sentence and its variants from faceless corporate entities? In my mind it translates to "Be calm, sheep. Be calm."
Re:Baaaa! (Score:5, Interesting)
Marketspeak (Score:5, Insightful)
"...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.
Consequences for treating employees like garbage (Score:2, Interesting)
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.
Script Kiddies Compromised Yahoo Servers Using ... (Score:2)
Script Kiddies Compromised Yahoo Servers Using Shellshock Bug
There, fixed that for you.
Re: (Score:1)
Script kiddies? They prefer pre-coded youth.
Millions (Score:2)
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!
Re: (Score:2)
Anytime anyone says that you should not bother running your own stuff and that you should just "outsource" it all to "the cloud" my response is: Yahoo.
We've been hearing a lot about this bug and people trying to allegedly take advantage of it but who is the first entity to be confirmed to actually be bit by this but: Yahoo.
Kinda curious... (Score:1)
Why does Yahoo still exist?
Nothing compared to what's coming. (Score:1)
http://krebsonsecurity.com/201... [krebsonsecurity.com]
CISO of Yahoo says "not Shellshock" (Score:1)
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.
At first I was surprised that he ca