Slashdot Mirror
Many Hackers Accidentally Send Their Code To Microsoft
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.'"
Maybe the report includes a dump of working memory?
Just a thought, thought that would make it kind of big.
The Digital Sorceress
Fucking script kiddies...in MY day, we actually HACKED.
Wait, I was born in '84...
Living With a Nerd
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.
Yes, that's because they live in basements where windows wouldn't be of any use anyway.
The Tao of math: The numbers you can count are not the real numbers.
why don't they respond quicker?
What makes you think that any of those 7k script kiddie attacks on MS's public-facing web presence actually show with anything the least bit new?
Don't disappoint your bird dog. Go to the range.
I'm guessing it's because the real "hackers" don't accidentally click the send button.
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?
That explains why they enter through the back door.
They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance. - Terry Pratchett
Crash dumps sent to Microsoft can contain memory used by the Windows process that was hosed by the virus writer, which could very well include whatever machine code was injected in to the process's memory or the invalid input that caused the crash . No phoning home via Visual Studio is required (amazing FUD with your speculation there, by the way,) the nature of the attack means the code/data is going to be exactly in the place it needs to be for MS to get at it without doing anything nefarious.
From the summary
On average we get attacked between 7000 and 9000 times per second
If they get attacked that often, it shouldn't take long for them to find and confirm security holes in Windows. Yet they have been noticeably slow in patching some of those holes; why don't they respond quicker?
In what possible way does an attack across the internet at Microsoft.com translate to exposing a flaw in the Windows operating system? That's like saying submitting an angry letter to the editor of your newspaper exposes the fact that one of the side windows on your house doesn't close properly.
compiled byte code in the utilities they use would do you little good unless you were extremely patient
Many people in the Windows OS team only debug at assembly level. For e.g. Raymond Chen.
http://blogs.msdn.com/b/oldnewthing/archive/2004/11/11/255800.aspx
"1. Once the optimizer has messed with your code source level debugging falls apart.
2. Most debugging is done remotely. When you have to debug a customer's machine 5000 miles away over a 56k modem, you can't tell them, "First, I want you to install Visual Studio on your domain controller..."
3. Installing a GUI debugger on the test machine changes the system configuration and therefore influences the test itself. Imagine if Windows XP had some horrific bug that goes away when you install Visual Studio. If all test machines had Visual Studio installed on them, then this bug would never be found!
4. Just today I had to debug a problem that occurred only immediately after installing the OS. No chance to install VS even if you wanted to.
5. If you're debugging the OS itself (say the window manager), then you can't use a GUI debugger since it needs the window manager to draw its UI!
Conclusion: Since so much debugging is done in situations where GUI debugging is not possible, you are quickly forced to become an expert at command line debugging. At which point the incremental benefit of a fancy debugger is rather small.
"You can't possibly debug any significant size project in this fashion."
Shhh, don't tell the Windows team. Not all debugging is done at asm-level, but a significant chunk is. They'd be pretty disheartened to learn that what they're doing is impossible.
Thousands of hackers across the globe send their malware, virii, and trojans to Microsoft, where it is collected, pieced together and compiled. Then MS puts it in a box and calls it an OS.
If you notice, there is a direct correlation between the number of hackers sending their code to MS and the amount of bloat in each new software package released by MS.
Another mystery solved! You're welcome.
If telephones are outlawed, then only outlaws will have telephones.
The article is talking about two things: developing virus (and sending crashdump to Microsoft) and attacking Microsoft.com. These are not the same thing.
And a crashdump containing virus does not mean it's the hacker that sent it. It could well be the victim. So while the speaker wants to say something entertaining, I wonder how truthful it actually is.
Not necessarily. Microsoft uses to reports to fix Windows problems or problems with their own products (or third party drivers, etc). They have that source and symbols. All they need from the user is the memory space and exceptions of the faulting process and which version of symbols were used.
I don't think Microsoft really cares about fixing application crashes other than for their public perception. They would be concerned that a Windows crash was possible in some particular way, and didn't recover/fail gracefully - and this boils down to the code that is sitting below the application code so they wouldn't need your source.
The only data that could be sent would be data currently in the memory space. So if the process had *str1= "Need to buy groceries: meat, eggs, cheese" , *str2 = "Assassinate the president at 17:30 on Tuesday", they would be able to see that by debugging through the stack variables and looking at where it's stored (i.e. heap). I'm not precisely sure how minidumps are configured - they may not include heap information.
Interesting.
One of the first things I do on a fresh install is turn off error reporting. It has always amazed me that I have never seen a corporate network turn it off. Everyday tons of proprietary information is transmitted to Microsoft in error reports.
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.
Out of modpoints but really liked a post? 1BDkF6TtmmeZ3yqXbz9yhdYVqRYnwFoXDj
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.
Hackers and Developers are both lazy. This is why things haven't gotten any worse and also why things haven't gotten any better.
You're incorrect, though the summary is confusing so I see how you could get lost.
The summary is talking about 2 things
1. "Hackers" who are testing malware that crashes systems often unintentionally send the report of the crash and what caused it to Microsoft.
2. Microsoft.com is often attacked via the web, to the tune of 7000-9000 times per second.
These two things are largely unrelated. Go back and re-read TFS.
RTFA
But it's all the way in Australia!
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.
it doesn't explain how the "error details" comes to be "including the malicious code". He goes on to say
"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."
System crash implies a bluescreen - which further implies a memory dump -- but R-ing TFA doesn't answer the question one way or the other.
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
Actually, Microsoft does fix bugs based on these reports. http://blogs.msdn.com/b/oldnewthing/archive/2010/08/04/10045651.aspx
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.