Many Hackers Accidentally Send Their Code To Microsoft 220
joshgnosis writes "When hackers crash Windows in the course of developing malware, they'll often accidentally agree to send the virus code straight to Microsoft, according to senior security architect Rocky Heckman. 'It's amazing how much stuff we get.' Heckman also said Microsoft was a common target for people testing their attacks. 'The first thing [script kiddies] do is fire off all these attacks at Microsoft.com. On average we get attacked between 7000 and 9000 times per second.'"
How Does It Encapsulate the Source Code? (Score:2, Interesting)
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.
I understand how this would be able to hand you their script or interpreted file but all the compiled byte code in the utilities they use would do you little good unless you were extremely patient. I don't know what percentage of exploits exist in the way scripts are interpreted (unless we're talking Internet Explorer) but I always assumed the really good and juicy exploits are those compiled down -- you know like a fake DLL that needs to be placed in the system path.
Crash reports probably include the script that was running and maybe the binary file running but how could it access the source code of an arbitrary task/thread/program? Are you saying that they're actually developing this stuff in a Microsoft IDE (like Visual Studio) that actually phones home source code upon program crash? That sounds like a guaranteed way to keep me away from Visual Studio.
Furthermore, how can you tell if this is a malware developer or the first unfortunate victim? Or even an outlier victim whose machine was luckily not correctly configured for the attack?
One thing's for sure: I hope Microsoft is bright enough to log everything they get so that when an exploit is found in the wild sans source code they can do a Hamming distance or some such analysis on it to pin down its origin and also look at the deltas to figure out what the developer was changing between releases so they can better understand the exploit.
Re:How Does It Encapsulate the Source Code? (Score:4, Interesting)
Maybe the report includes a dump of working memory?
Just a thought, thought that would make it kind of big.
So now crackers have a new way to attack Microsoft (Score:5, Interesting)
An application that generates random gibberish that "look" like a script, then sends it embedded in a fake crash dump to Microsoft for analysis.
"Fuzzing" isn't limited to code on the local machine any more - you can now try it on Microsoft employees.
Then add further fake crash dumps from legitimate apps that didn't crash; enough of them, from enough machines, and Microsoft will be looking for non-existent bugs.
Re:So then what's with the wait? (Score:1, Interesting)
Re:How Does It Encapsulate the Source Code? (Score:5, Interesting)
According to TFA Heckman gave a presentation of XSS and SQL injection attacks. So, I imagine that what we're talking about here is Microsoft receiving a dump of IE process memory, which of course will include the malicious script.
If you get a sequence of error reports from the same IP within a short period of time, where the only difference is that the script bringing IE down has been modified slightly, you've probably got the developer at the other end of the line. (Online source control on a budget? ;-)
Where did that come from?
Everyone ignores error reporting. (Score:4, Interesting)
Re:7000 - 9000 / sec ?? (Score:5, Interesting)
Those numbers seem suspiciously inflated. I'm going to guess the majority of these packets are icmp from bots checking ping.
There are what, 1-2 billion people currently on the internet at any one time (probably exceeds that) Let's say 99.9% don't develop malware.
That would put the number of currently active malware developers at 2,000,000. If 10% of them write a program that tries to attack microsoft.com, that's 200,000 programs. If each one of those only tries once every 10 seconds, that could be 20,000 individual programs attacking microsoft.com every second.
Ok, so maybe somewhere those numbers are inflated. Cut it down by another order of 100. That would be 200 unique pieces of malware.
Now the magic: It's not 0.1% of the internet users developing malware that targets microsoft.com. It's 40-60% of the internet users whose computers have been compromised and are attacking microsoft.com.
So 10k attacks per second? Not a stretch at all. These things scale.
Re:So now crackers have a new way to attack Micros (Score:4, Interesting)
Interesting. Then add time as a variable to further complicate detection. Each machine in the botnet sending a report every rand(168) hours. For a large enough set of compromised machines, the statistics of which reported crashes float to the top of the queue would certainly be messed up.
Plus If they were to filter these botnet machines at the IP level for a particular app then it would block real reports from coming in, further skewing the stats. There are real users sitting behind these compromised machines after all.
Ouch.
Re:So now crackers have a new way to attack Micros (Score:4, Interesting)
That Windows Error Reporting actually has an unexpected side effect - spikes in crash reports often indicate a new virus is on the loose...
http://blogs.msdn.com/b/oldnewthing/archive/2008/05/21/8525411.aspx [msdn.com]
Re:Of course! That's how windows is written. (Score:2, Interesting)
Re:So now crackers have a new way to attack Micros (Score:5, Interesting)
Do you really think that Microsoft has a team of people searching through these reports and actively fixing bugs based on them?
Being one of those people (as pretty much any other developer in MS), I definitely think so :)
The system is much more complicated, of course. You can imagine the sheer amount of reports MS is receiving every day (cue the 95 BSOD joke here). Clearly there needs to be some sort of automated processing for it, and there is.
For starters, there are always those folk running the original pristine IE6 on XP SP1 or something, who are hitting bugs that have been fixed ages ago. Obviously you don't want to investigate that, but it's possible to forward people to a webpage explaining the issue and urging to update (typically a KB for a security vuln on TechNet ;).
Then it needs to figure out which reports are dupes of which. For "popular" bugs, you can easily have several thousand people hit it in quick succession. I won't even pretend to know how WER (Windows Error Reporting, which is what the mechanism is called) does that kind of analysis. It looks at the nature of the problem (e.g. segfault, stack cookie corruption etc) and at the call stack, that's for sure, but it goes way beyond that. There is a dedicated team somewhere which works on it, and it's the kind of place where you put the sign "dragons and bearded men in glasses be here". Well, or maybe "SkyNet be here" would be more apt these days. Anyway, by liberal application of pixie dust (from employee's grinded iPhones, the rumor goes!), reports are grouped by specific issues, and the product and area within it is tentatively identified for each.
At that point, it actually lands up in the pile of stuff to do for the team responsible for that area, and stuff goes same as for normal bugs from there - triage, assignment to individual developers, investigation, and (hopefully!) fix.
Now, mind you, I'm not saying that any bug exposed via a WER report is going to be fixed. In fact most probably aren't. The problem is, this kind of post-mortem debugging is hard - oh, it catches stupid mistakes really well (uninitialized pointers, that kind of thing), but those are exceedingly rare in practice. And for more complicated stuff - especially when anything asynchronous is involved - the code that caused the issue can be very far from where the crash actually happens, and all you get from WER is a report at the latter point. Sometimes you can try to look at it and guess the sequence of user actions (and other conditions) that led to this crash, and actually repro it, and then debug live. Sometimes you can carefully put the pieces of the puzzle together to form enough of the picture to pinpoint the code right away. Often, though, you can't really do much given what you have - and, for privacy reasons, we cannot try to contact people who send the reports.
Still, I personally fixed a bunch of issues that came in from WER, so it's a net positive.
Re:How Does It Encapsulate the Source Code? (Score:1, Interesting)
Yes but you can blame the journalist for that. They are obviously talking about the "Program X has encountered a serious error and needs to close. Would you like to report the problem to Microsoft?" dialogs. Those ones presumably send in the working memory of the crashing program only, which would be relatively small when compressed, if the exploit code is small, which it usually would be. Code here means machine code, which contrary to popular belief, is actually quite easy to turn back into a mostly readable assembly file, if it contains debugging symbols. Which it will, if it is still being developed.
Also don't forget that these things work by exploiting bugs and causing crashes. If, for example, you're trying to overflow a buffer to inject code, it might take you a while before you find the right things to overflow with before you find the set of input that causes it to crash in the way you want.
Also "script kiddies" is wrong by definition since script kiddies don't write exploits, they download them from the internet.
Dunno why I am bothering to write this since nobody reads AC comments anyway.