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."
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.
Huh... I would'a guessed they were long gone by now.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
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; }
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.