Beware! This post is more than 3 years old, it may be outdated or incorrect! Please check elsewhere for accurate information!
A few weeks ago, shellshock made the news as the new Heartbleed. Most of the sysadmins in the community ignored it, since they claimed not a lot of servers would be vulnerable. They were wrong.
Jonathan Hall, of Future South Technologies, has been monitoring a Romanian group of hackers that have been automatically hacking servers and then turning them into botnets that would listen for commands on a IRC server. Jonathan used a script to scan Google for pages that have cgi-bin in the name, or have an extension of cgi, sh or pl. He then started scanning the Internet for servers that are vulnerable.
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… I analyzed [the 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. 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.
This indicates that there are already exploits that use Google Search and similar search engines as a way to discover new websites to infect. Additionally, they exibit worm-like properties, spreading code on other servers that then hacks more and more servers. Even if the systems are patched, the bot may stay on the server and continue receiving commands from the bot master.
He noticed that WinZip.com’s server had responded to his commands. WinZip is a program that’s been around since 1994, and is generating over $800,000 per year in ad revenue alone. Also, the software contacts WinZip.com to check for updates. He got into the server, and he noticed a Perl script called “a.pl” (script source here) that’s been listening to commands on an IRC server. He killed the script, and notified both WinZip and the local FBI office, since that server was the one serving purchases of WinZip.
He analyzed the script and noticed that the IRC server it was listening for commands on also had a lot of high profile domains, including Lycos and Yahoo! The “dip4.gq1.yahoo.com” and “api118.sports.gq1.yahoo.com” servers were fully rooted (the attacker had the highest possible privileges) and we’re listening to the commands from the group that was monitored by Jonathan.
Jonathan has expressed his frustration with FBI, claiming that they “seemed intrigued by this, in my opinion, they aren’t moving with any form of haste”, and that this is a severe issue that needs to be addressed immediately.[reklama]
He emailed Marissa Mayer, CEO of Yahoo!, and she appears to have forwarded the email to Ricky Connel, from Yahoo’s security team. Response below: (screenshot)
Thanks for reaching out, sorry that you had trouble finding us to get us this message, but glad that you managed to find a way :)
If you find anything else that we should know about, we would love to hear about it. You can reach me out directly, email [email protected], or throw things at our bugBounty program (even if this sort of thing isn’t eligible, we have people looking at that pretty regularly).
WinZip and Lycos have not answered at this time. If anything changes, this post will be updated.
Don't forget to scan your website, because you never know who might stumble upon it.
Original post by Jonathan Hall here.
Updated at 07 October 2013
Yahoo has responded to this, officially, on Hacker News.
I’m the CISO of Yahoo and I wanted to clear up some misconceptions. Earlier today, we reported that we isolated a handful of servers that were detected to have been impacted by a security flaw. After investigating the situation fully, it turns out that the servers were in fact not affected by Shellshock. Three of our Sports API servers had malicious code executed on them this weekend by attackers looking for vulnerable Shellshock servers. These attackers had mutated their exploit, likely with the goal of bypassing IDS/IDP or WAF filters. This mutation happened to exactly fit a command injection bug in a monitoring script our Sports team was using at that moment to parse and debug their web logs. Regardless of the cause our course of action remained the same: to isolate the servers at risk and protect our users' data. The affected API servers are used to provide live game streaming data to our Sports front-end and do not store user data. At this time we have found no evidence that the attackers compromised any other machines or that any user data was affected. This flaw was specific to a small number of machines and has been fixed, and we have added this pattern to our CI/CD code scanners to catch future issues. As you can imagine this episode caused some confusion in our team, since the servers in question had been successfully patched (twice!!) immediately after the Bash issue became public. Once we ensured that the impacted servers were isolated from the network, we conducted a comprehensive trace of the attack code through our entire stack which revealed the root cause: not Shellshock. Let this be a lesson to defenders and attackers alike: just because exploit code works doesn’t mean it triggered the bug you expected! I also want to address another issue: Yahoo takes external security reports seriously and we strive to respond immediately to credible tips. We monitor our Bug Bounty (bugbounty.yahoo.com) and security aliases ([email protected]) 24x7, and our records show no attempt by this researcher to contact us using those means. Within an hour of our CEO being emailed directly we had isolated these systems and begun our investigation. We run one of the most successful Bug Bounty programs in the world and I hope everybody here will participate and help us keep our users safe. We’re always looking for people who want to keep nearly a billion users safe at scale. [email protected]
This post was last updated on October 5th, 2014.