Yahoo Hacked

Thank you

Now, I'm a bit stumped how any obvious variant of the CVE-2014-6271 or CVE-2014-6278 RCE payloads could lead to accidental code execution somewhere else, since they generally produce a parser-breaking syntax error when executed outside an env-encoded function definition. Also, because of an unusual fixed-string prefix required to carry out the attack, there is not a lot you can really do to avoid any half-baked IDS/IPS. Anyway, for the sake of my idle curiosity, I secretly hope that Alex shares the buggy line of code, even though that's unlikely =)

[1] http://lcamtuf.blogspot.com/2014/09/bash-bug-apply-unofficia...

I won’t sit here and say that I think they are lying. To make such an accusation would only prove me to be a fool not having ammunition in the weapon before I fire it. I will, however, say that I believe – in my opinion – that this is a wordplay and a game of semantics. First off, there are several “shellshock” exploits. The term “shellshock” as the media has portrayed it is to execute the vulnerability or vulnerabilities recently discovered in bash by means of delivering the following payload: () { :; };

When we look at this payload, what we are actually seeing is a function definition, not the execution of or calling of that function, with the regards to the following: () { :; }; 

The actual “arbitrary code” to be executed last past that point, where we’re no longer defining a function, but instead – giving instructions to be executed on the operating system via Bash. One could inevitable argue that taking the payload, and modifying it to look like: () { whatever; }; /bin/bash –c ‘id;uname –a’ could, or even could not, be identified as “shellshock” in the manner of which it was portrayed to be by the media. However, the fact still remains that this “payload” would cause the execution of the commands proceeding the {}; 

When we look at the other SIX (6) payloads that essentially accomplish the same exact thing: https://shellshocker.net – we see that modification of the “payload” does not stop the blatant fact that the same underlying results are achieved via the same exact vulnerable code in the Bash shell. 

My response to Yahoo! : Please issue out the UNTAMPERED and UNMODIFIED apache logs, showing the payload delivered to your “sports API’s” - and other researchers, and potentially shareholders, determine what the underlying cause was. Furthermore, to state that this resulted in bypassing your “IDS/IDP” and “WAF filters” makes me wonder exactly what kind of IDS/IDP and WAF filtering you’re imploring. I’m willing to bet there were exact phrase match filters looking for what most sites have identified as the “Shellshock” vulnerability, I.e. “() { :; };” and preventing the scripts and/or bash from being executed once that string was identified. That could have been with something as simple as a wrapper for bash… And considering the IPS/IDS didn’t pick up on outbound IRC connections on port(s) 6660 and/or 6667, which NO internal server would have a reason to be connecting to, I can only say that your concept of IDS/IDP is seemingly inadequate in my professional opinion. So, once again, since the vulnerability has seemingly been “patched,” I urge you to release the details of the vulnerability in the script, and also explain why it is that the initial compromise appears to have been on a web-facing box with public access to it, and found amongst a botnet running a perl script that had self-spreading and searching capabilities based around the “shellshock” vulnerability? You are comparing apples and oranges, when in all actuality, you should be comparing “to-may-to” to “to-mah-toh."

Who do you think you are? lol.