Yahoo says they’re patching servers compromised by Shellshock

UPDATE: Yahoo’s CISO, Alex Stamos, has stated that the issue wasn’t Shellshock related, and that the researcher didn’t contact Yahoo’s normal security channels as stated.

“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…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.”

Original Stroy:

Jonathan Hall, president and senior engineer of Future South Technologies, said that he uncovered a botnet running on two Yahoo servers, managed by a group of hackers out of Romania.

In a wordy outline on the situation [Google Cache], Hall said that Shellshock was the initial entry point onto Yahoo’s network, adding that the attackers were actively seeking additional vulnerable hosts.

In a statement sent to CSO on Monday, Yahoo says they’ve isolated “a handful of our impacted servers and at this time we have no evidence of a compromise to user data.”

Hall first discovered the issue after scanning the Web for vulnerable GNU Bash implementations. It was these scans that led him to WinZip.com, which was also compromised by Shellshock. However WinZip has made no statements on the matter to the public.

After running some of his own code against WinZip.com, Hall said that he discovered a Perl script running an IRC DDoS bot. When the script was analyzed, Hall said it was full of comments that were written in Romanian, and that the script focused more on Shell interaction than DDoS.

From Hall’s outline:

“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 [sic] script off and notified both WinZip and the local FBI office of the compromise. Especially considering this was one of their ‘store’ boxes, which serves as a payment gateway for WinZip purchases. Not good… 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 [sic] 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!”

Last week, FireEye released details on several proof-of-concept scripts related to Shellshock. Among their findings were scripts that allow an attacker to perform a number of tasks including, establishing a reverse shell (with or without Perl) and botnet creation.

“We suspect bad actors may be conducting an initial dry run, in preparation for a real, potentially larger-scale attack. We believe it’s only a matter of time before attackers exploit the vulnerability to redirect users to malicious hosts, which can result in further compromise,” FireEye wrote at the time.

Hall’s disclosure and outline of the incident highlights another example of how the Shellshock vulnerability isn’t a patch it and forget it bug. It’s something that should be actively monitored, as incidents related to the bug will continue to see the light of day for quite some time.

At the same time, Hall’s efforts raise interesting questions as he actively breached a victim’s servers, killing processes and running his own code, in order to discover the alleged Romanian compromise. Were his actions completely ethical / legal? Hall has been defending his actions on Reddit, an example of such defense can be seen here.

It’s unclear if Hall’s actions will lead to any negative fallout; but it’s unlikely given that Yahoo seemed appreciative of his efforts.

In an email to Hall, Ricky Connell, a threat response representative at Yahoo, apologized for difficulties in reporting the issue and thanked him for “reaching out.”

“We’ve found the tracks mentioned in your email and are working through our IR [Incident Response] process. If you find anything else we should know about, we’d love to hear about it,” Connell wrote.

The email concluded with a message that Hall’s report was not eligible for Yahoo’s Bug Bounty, but encouraged him to participate in the program if he discovers vulnerabilities in the future.

XX