Hackers accidentally give Microsoft their code By Josh Taylor, ZDNet.com.au on August 26th, 2010 (1 day ago)

When hackers crash their systems while developing viruses, the code is often sent directly to Microsoft, according to one of its senior security architects, Rocky Heckman.

When the hacker's system crashes in Windows, as with all typical Windows crashes, Heckman said the user would be prompted to send the error details — including the malicious code — to Microsoft. The funny thing is that many say yes, according to Heckman.

"People have sent us their virus code when they're trying to develop their virus and they keep crashing their systems," Heckman said. "It's amazing how much stuff we get."

At a Microsoft Tech.Ed 2010 conference session on hacking today, Heckman detailed to the delegates the top five hacking methods and the best methods for developers to avoid falling victim to them. Heckman explained how to create malicious code that could be used in cross-site scripting or SQL injection attacks and, although he said it "wasn't anything you couldn't pick up on the internet", he suggested delegates use the code responsibly to aid in their protection efforts.

According to Heckman, based on the number of attacks on Microsoft's website, the company was only too familiar with what types of attacks were most popular.

"The first thing [script kiddies] do is fire off all these attacks at Microsoft.com," he said. "On average we get attacked between 7000 and 9000 times per second at Microsoft.com," said the senior security architect.

"I think overall we've done pretty good, even when MafiaBoy took down half the internet, you know, Amazon and eBay and that, we didn't go down, we were still up."

Heckman said there were two reasons why the top hacking methods of cross-site scripting and SQL injection had not changed in the past six years.

"One, it tells me that the bad guys go with what they know, and two, it says the developers aren't listening," he said.

Heckman said that developers should consider all data input by a user as harmful until proven otherwise.

That has been my experience - that a significant number of people who write code for a living are not aware of what's been happening on the Internet the last half dozen years.

Part of the problem is people who code for a living. If you get to work, write code for 8 hours, then leave and never think about programming outside that time you don't give yourself the opportunity to learn very much. Unless you work with amazing people and/or read a lot and participate in communities while at work.

That or they are really lazy.

Of course, it's open-source anyway, but still.

And does MS.com really get attacked 8000 times a second? Unless you're counting every individual attempt from each brute force script etc, that seems unreasonable even for them.

The article is about Microsoft analyzing crash reports, which include bits of compiled code that crash, and finding that sometimes those compiled bits are viruses under development.

(a) everyone @ msft takes the confidentiality of data uploaded to Watson (the crash reporting system) extremely seriously - you can't just 'look for useful stuff' in it without a good reason, and you'd be fired immediately if you were found to be reverse-engineering or copying bits of code out of it

b) on a technical level, trawling through dumps looking for 'useful stuff' would be an absurdly inefficient way to do anything. For one thing, it just crashed, which in my book is not usually a sign that you'd want to copy it.

c) your crash dump is a drop in the ocean. There are millions coming in. Nobody will ever look at it unless the system picks up that there a multiple millions of crashes occurring at the same point in the same widely-used app, in which case it's possible msft might contact the vendor (if identifiable) to offer to help fix it.

See http://oca.microsoft.com/en/dcp20.asp

Clearly, there must be some red flags which cause even small numbers -- perhaps single -- crash reports to get human attention at MSFT.

Certainly this doesn't work all the time, but even if it worked only very rarely it'd still be a pretty substantial payoff.

But then the same thing could apply to non-malicious/competitive code, too. Once it proves interesting to Microsoft, they could mine the past crash history for background info.

I can believe internal controls and culture mitigate this risk -- but sheer volume doesn't provide confidence of confidentiality for non-malware coders any more than it does for malware coders.

So it's in their best interests to keep those internal controls as strict as possible in order to avoid such a thing.

So this applies to all developers, not just to the ones writing viruses.

[0]http://www.microsoft.com/whdc/driver/kernel/64bitpatch_FAQ.m...

Now is Microsoft going to steal your code? I dunno, probably not, but it is something to think about.

I would like to know what his definition of attacked is.

That's funny. I distinctly remember noticing how those error details frequently "complete" instantly, so I've performed an experiment a number of times:

1) Get the report-crash window to pop up. 2) yank your Ethernet cord / power off your wireless. 3) submit report. 4) "success!"

The only times it's ever sent anything has been when some Microsoft core-product crashed on me, and then you get a progress bar and nearly always a link to info on a (likely) related error. And it catches less than 1/2 of the ones I've generated.

As to caching: to a certain degree, I doubt that, actually. When a Windows component has crashed, the same ones that I mention go through the whole process, it always informs me that I'm offline if I disconnect from the internet. For non-Windows ones, it always completes instantly, sends me no link, doesn't realize I've disconnected, and always says "success".

There's a disconnect here. If it's cached, it should say so, not tell you it succeeded when it didn't. Meanwhile, why do some detect internet connectivity and some don't? It's fully possible you're right, but I've seen no evidence of it.

If you swap steps 2 & 1, do you get the same result?