Slashdot Mirror
Hackers Compromised Yahoo Servers Using Shellshock Bug
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."
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! :)
You're not a very good sysadmin, you'd know that you'll never see "fixed!" becuase the reboot will terminate the rest of the command before it can run.
Do not look into laser with remaining eye.
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.
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.
I'm going to blame this for my fantasy football loss this week... and all previous weeks.
Nostalgia isn't what it used to be.
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.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
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."
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?
Mielipiteet omiani - Opinions personal, facts suspect.
"...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.
Proverbs 21:19
Yahoo treats their employees like garbage. To wit, Yahoo uses "stacked ratings" 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.
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.
No, the bug IS related to subshells. Environment variables are "exported" to make them available to subshells to use. POSIX defines the mechanism (and the environment is passed in as parameteres to the exec() family of functions)
Now, bash has a design flaw in how it exports FUNCTIONS to subshells, namely if it starts with () { then bash treats it as a function declaration.
Of course, the problem is not related to subshells - but it stems from there. Because if you invoke bash, and pass it a function declaration like that, bash will think it's inheriting a function (which could've been started many, many processes ago because exported functions in bash look like exported environment variables).
So you can do the bash-->httpd-->bash thing and if you export a function in the partent bash, even though you're going through httpd, the sub-bash (probably started as CGI) will see the parent exported function.
And CGI typically calls system() to perform the script execution, which by definition launches the system shell to run the command you passed to system().
The bug originates from a design flaw in POSIX that fails to specify how to securely pass in exported functions, so the bash devs made up some method. Shellshock basically relies on this feature.
The best way, of course, is to disable exporting of functions, but there may be many reasons why this may not be possible - including entrenched software that relies on this behavior and has for many years (it's a design flaw dating back over 20 years). And one should also note that 20-30 years ago, Unix security was practically non-existent.
Things like this were a product of a different era.
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 - NIH - I suspect.
All hope abandon ye who enter here.