1. The Sun-Sentinel newspaper in Fort Lauderdale accidentally republishes a six-year-old news story about the bankruptcy of UAL. It wasn't on the home page, but instead buried somewhere inside the web site.
2. Google's news crawler (an automated thing, remember) finds the story and incorporates it as part of its news feed.
3. Investors see the story, and immediately react. When UAL's stock plunged 76% to a low of $3, Nasdaq shut down trading. Eventually trading resumed, and the stock closed at just under $11, losing about 11%.
4. United blamed Tribune Company (the owner of the Sun-Sentinel) for "irresponsibly" changing the date on the story and demanded a retraction.
5. Tribune Company blamed Google, claiming they've had issues with Google's crawler "for months."

Who will blame be shifted to next?

Look -- if people haven't realized by now that the Internet pretty much lacks a delete function, then (IMNSHO) it becomes the requirement of each and every one of us to pay close attention to what we're reading, to use our own big brains and fine-tuned bullshit detectors to suss out whether something makes sense.

Since this is my blog, I'm going to parcel out blame the way I see it:

• United: 0%. If the concept of "negative blame" made any sense, then I'd actually write −∞ (that's a negative infinity, in case your character set is different than mine).
• Google: 5%. How can an automated crawler know that a newly-dated story isn't really new? Well, those folks over there at Google are smart. Certainly it shouldn't be that difficult to compare a "new" article against existing ones. Content hashes won't work as a comparison tool, because the date would be included in the hash computation, thus making the hashes different anyway. Full-text comparisons? Sure, it would take a lot of horsepower. Perhaps not every "new" story needs comparison, but at least the crawler could submit to the comparator any stories that ought to be verified (say those with the word "bankruptcy" in them).
• Tribune Company: 30%. Hey guys, you changed the date on the article. Don't go blaming someone else for your screw-up.
• Investors: 65%. If you're using an automated news aggregator (remember, an aggregator is not a source of news) to make major financial decisions -- decisions that affect the livelihoods of thousands (maybe millions) of people -- well, you're a moron. You should know that incorrect information can be just as instantly available as correct information. Verify potentially damaging claims before engaging in reckless behavior.

What's this got to do with security? I don't know, maybe nothing directly related. But it certainly raises the question -- what if someone intentionally wanted to cause nearly permanent damage to a person or a corporation? Malicious content, disguised as "news," certainly seems to have become a potentially successful attack vector this week.

Worried about a social engineering attack on a massive scale? I suspect that what happened Monday (8 September) was the largest social engineering attack in history -- although I wouldn't classify it as intentionally malicious. Just you wait until the idea spreads.

From Aut Disce, Aut Discede:

Consider for a moment the state of client-side bugs 5 or 6 years ago. Attacks such as this, a multi-stage miscellany of IE and Mediaplayer bugs that resulted in the “silent delivery and installation of an executable on the target computer, no client input other than viewing a web page” were reported with regularity. Gradually these type of attack gave way to exploitation of direct browser implementation flaws such as the IFRAME overflow and DHTML memory corruption flaws. So what has become of the multi-stage attacks - have they become redundant? The answer to this, which I’m sure you can guess, is a resounding “no” and will be emphatically demonstrated in my upcoming Black Hat talk “The Internet is Broken: Beyond Document.Cookie - Extreme Client Side Exploitation”, a joint double session presentation co-presented by Billy Rios, Nate McFeters and Rob Carter.

As a teaser for that, I’m going to revisit an old attack - pre-computed dictionary attacks on NTLM - and discuss how we can steal domain credentials from the Internet with a bit of help from Java. I’m going to split it into two posts. In this post we’ll apply the attack to Windows XP (a fully patched SP3 with IE7). In my next post we’ll consider its impact on Windows Vista.

For the full article read on.

Why are you still here? Go read it.

Article Link

Since the SVN repository remained intact, we can’t go back and examine the backdoor in detail. However, we do have a newsgroup posting that sheds a little light on the situation:

> What diff do you see between the compromised version and
> the one that is there now? I see only a comment diff in one file.

it was a small block of code that checks for a $_SERVER var. If that var was present, it would redefine SM_PATH. Under normal circumstances, this would never be executed, but we have since learned how to make it execute.

In PHP, $_SERVER is an array populated by the web server that contains information such as headers, paths, and script locations. This includes some user-supplied input such as the URL query string and the HTTP headers. SM_PATH is the filesystem path where SquirrelMail is configured to be run from. So once an attacker controls SM_PATH, it’s likely that a subsequent call to include() can be exploited to fetch and execute PHP code from a remote server. This is a typical example of a Remote File Include vulnerability.

Note that the attacker backdoored the 1.5.1 distribution as well, with the same type of vulnerability but at a different location in the codebase.

I think what’s most interesting to me about this is that so many open source projects still rely on MD5 hashes for integrity checking. The minute the Xiaoyun Wang paper on MD5 collisions was released, every security practitioner in the world considered MD5 unsafe from that point forward. Even though practical attacks had not yet been formulated, the writing was on the wall. Unfortunately, the rest of the world either didn’t notice or didn’t care.

Cryptographers have since developed increasingly sophisticated attacks stemming from Wang’s original work. Recently, researchers in the Netherlands demonstrated two examples of chosen-prefix attacks which would make it possible for an attacker to take two tarballs (one original, one backdoored) and append a series of bytes to each that result in both files having the same MD5 hash. This proves beyond a shadow of a doubt that MD5 is not an effective method for verifying software integrity. There was hardly any doubt that this attack would surface eventually, so why is MD5 still in such widespread usage?

Cryptographic weaknesses aside, a lot of people completely miss the mark with hashes. MD5 or SHA-1 (or any hash function) are not very effective if the only way a user can verify them is on the same website where the download is hosted. If the download point is compromised, chances are the attacker can modify the hashes printed on the website too. Even when it’s done correctly, hashes only help identify when the distribution point is compromised. It does nothing to protect against source code compromise or vulnerabilities in the development tool chain.

During the presentation, we’ll quickly cover some high level encryption basics (asymmetric, symmetric, and one way hashes), but will spend most of our time dealing with symmetric encryption; namely how and why you configure a symmetric algorithm to encrypt the data (ECB vs. CBC).  By the end of the session, you’ll finally understand what an initialization vector (IV) is used for and the proper way to create and store it.

Don’t worry if you don’t understand what half of that meant.  I’ll be sure to explain everything as we go along. 

You can also find a fair amount of the content from the presentation here in an article I wrote a while back.