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
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.
Re: (Score:2, Insightful)
Re:How Does It Encapsulate the Source Code? (Score:5, Funny)
RTFA
But it's all the way in Australia!
Re:How Does It Encapsulate the Source Code? (Score:5, Informative)
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.
Re: (Score:2, Informative)
The reason the article doesn't explain how Microsoft crash dumps work is because no one understands them.
This guy seems to be closest to understanding of anyone I've found:
http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx [wintellect.com]
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: (Score:2, Insightful)
Wouldn't a corporate policy change that major require a filing with the SEC?
Re: (Score:2)
Doubt Microsoft employees directly run the code... they instead look at the assembly code to see what the reason for the crash was. Even otherwise, I am sure they use VMs with network access which are wiped and rolled back once testing is done.
Re: (Score:2)
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: (Score:2)
Do you really think that Microsoft has a team of people searching through these reports and actively fixing bugs based on them? It's more a metric of how bad a known bug is, that is, how many people are reporting crashes from known bug A as opposed to known bug B.
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:So now crackers have a new way to attack Micros (Score:4, Informative)
Actually, Microsoft does fix bugs based on these reports. http://blogs.msdn.com/b/oldnewthing/archive/2010/08/04/10045651.aspx [msdn.com]
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: (Score:2)
Yeah, here is when you sign up for that. And people are encouraged to do so - it's better to provide a single unified UI for the users to do the same thing across many apps, not to mention the quality of analysis tools that MS already has is likely better than what most organizations can afford to develop on their own.
Re: (Score:2)
Link swallowed in another post, sorry. Here:
http://www.microsoft.com/whdc/winlogo/maintain/StartWER.mspx [microsoft.com]
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?
Re: (Score:3, Insightful)
The visual studio thing is actually an interesting question. If, in the process of writing code you crash visual studio, or the whole OS and then send an error report to MS will it contain your source code? To some degree the same applies to any application, if you crash notepad++ and send a crash report to MS it would make sense that it contain well, whatever was being typed in notepad++. if you crash your copy of Mafia 2 does it send the savegame?
It's somewhat outside the scope of the article, but reall
Re:How Does It Encapsulate the Source Code? (Score:4, Informative)
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.
Re: (Score:3, Informative)
Windows Error Reporting only sends mini-dumps. You won't see code or contents of notepad/word etc. You get the callstack for all running threads, exception information that caused the fault, list of all loaded modules and processor context for all threads.
Re: (Score:2)
It is possible for a developer investigating a WER report to request that further reports also include the heap of the offending process. It is only used sparingly, to investigate tough issues where some crucial information is on the heap, because it significantly increases the size of the report, and the amount of time it takes to upload it (and therefore the likelihood that the annoyed user will just click "Cancel" before it completes). But it is possible. And heap dump will likely include the "code or co
Re: (Score:2)
Score: 5, Muppet
Did you miss the bit where Windows asks if you want to submit the data? Apparently so.
Re: (Score:2)
To be fair, so do everyone who send in the data.
Re: (Score:2, Informative)
Nice to think being a muppet is worth modding up.
Also, you have to trust the optional submission isn't buggy, and does what the user wants. Yeah, that's clutching at straws, but I can think of at least one instance of proprietary software privacy raping when it shouldn't have been. Real, years ago, was "accidentally" uniquely identifying installations of its player when it declared them anonymous.
The data collected via crash reports and update checking mechanisms could have commercial worth to the vendor. T
Re: (Score:2, Informative)
So, you gave up on bugfixes and new features for MP3Tag because they added an optional update checking mechanism...
Yes, yes I did avoid bugfixes and new features, as the principle of privacy is more important to me.
The choices are use an old version of the software, use a current version and live with a lower level of privacy (the application notified the developer each time the application was run, IIRC), or use a different product. As I quite like MP3Tag, I took the first choice, though have been keeping my eyes peeled for something to fit category 3.
MP3Tag, even though it is freeware, isn't OSS. I would rather use Fr
Re:How Does It Encapsulate the Source Code? (Score:5, Informative)
Re: (Score:2)
amazing FUD
Remember folks, here at Slashdot, asking a question is Fear, Uncertainty and Doubt.
Actually I think he meant Fuzzy Underwear Daemon. But I'm not positive.
Re: (Score:2)
I guess they find it when Microsoft analyzes the crash logs and is able to see the assembly code trying buffer overflows etc. Think core dump in Linux. I wouldn't think Microsoft would send the source code to themselves.
Re:How Does It Encapsulate the Source Code? (Score:4, Informative)
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 [msdn.com]
"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.
Re: (Score:2)
Anal retentive? I've been called a lot of things, but not that. Perhaps you should re-read what I said. "In any REAL OS, the window manager isn't part of the OS. All a window manager is supposed to do is - like - you know - MANAGE THE WINDOWS!"
Now, bear in mind that even with Windows, you can change out the shell under which you are working. That is, change out the window manager for something more to your liking. Nextstep or some such a thing. Sure, it relies on the Windows OS to run - but it's a com
Re: (Score:2)
No, I'm trying to point out that a window manager is NOT PART of any operating system. If you really think that Windows won't run without a window manager, then you don't know Windows - or any other OS. For most people, a windows manager is a crucial part of the DESKTOP - but that doesn't make it part of the OPERATING SYSTEM. I'm not even trying to define DOS for you. (just to head off some asinine commentary on MS-DOS x.xx or any other - DOS means Disk Operating System)
The OPERATING SYSTEM need not eve
Re: (Score:2)
It's just a completely random dig at Microsoft for absolutely no reason.
Of course it is. The discussion was about how it's impossible to debug Windows with a graphical debugger especially when it's the Windows Manager you are debugging. The fact that the said Window Manager is tightly integrated into the system is irrelevant.
The fact is that, if it runs in the GUI, a debugger tends to be unresponsive when the GUI is stopped on a break point.
Re: (Score:2)
some programas can be "decompiled" into a more human readable text.
if you have a *NIX/linux box around, try running something through strace. see all those system and library calls? that and an automated analysis of how the program flows can give you something close to the original source program. now, if the binary still have the debug symbols (i.e. it's not a stripped binary), it's even easier.
Re: (Score:2)
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.
Let me try to explain how this works.
WER (Windows Error Reporting) applies to any application you run on Windows. If something crashes, you'll be offered to send a report. In fact, third-party application developers can register [microsoft.com] to directly receive reports for their apps through the same system. For MS apps - including Visual Studio - the data ends up at MS.
The "phone home" process, as of Win7, works that way with the default settings: the initial "phone" on crash is automatic (you will see the "Windows che
To Be Fair (Score:3, Insightful)
Re: (Score:3, Insightful)
Yes thats a great idea. And I want to improve my marksmanship so I'm going to go shoot up some banks and a few police stations. I'm sure they will understand I'm only trying to improve my skills.
Re: (Score:2)
Re: (Score:2)
This isn't about arresting people, it's about fixing exploits. It doesn't matter how pure or foul their intentions were; if they send the exploit to Microsoft then Microsoft can detect and fix it.
::head shake:: (Score:5, Funny)
Fucking script kiddies...in MY day, we actually HACKED.
Wait, I was born in '84...
Re:::head shake:: (Score:5, Funny)
Re: (Score:2)
I'm totally going to use that...awesome :-)
Re: (Score:2)
Re: (Score:3, Funny)
Re: (Score:2, Funny)
I was born in 83. Gimme ur lunch money, kid!
1976. Now get off my lawn.
Re: (Score:3, Funny)
Re:::head shake:: (Score:5, Funny)
Re: (Score:2)
1950... Get Off My.... what was I thinking about???
Re: (Score:2)
'69. You may be older, but I'm holding Woodstock on your lawn whether you like it or not.
Re: (Score:2)
Darned kids today! Why, back in my day, we didn't have no fancy computer or nothing. We had to count on our fingers! In a raging snowstorm! And we liked it that way!
Rassum fassum mumble grumble darned kids...
Now git offn' my lawn!
1962
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
'86 - Basic on a TI-99/4.
That said, coding never really caught my interest.
What about the competition? (Score:2)
Re: (Score:2)
Re: (Score:2)
Microsoft doesn't look at application crashes for applications they didn't develop. If the vendor is a member of OCA, they pass the crash on to the vendor.
Microsoft *will* look at a crash if Windows crashed.
7000 - 9000 / sec ?? (Score:2)
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: (Score:3, Informative)
Or even better, of which 40-60% are malwared and target MS.com?
That would imply that those 1-2 billion concurrent user all use a Windows computer.
Please share your references used with us
Windows has an 85% market share (conservative estimate) It's general common knowledge sourced in a great many places.
As for infection rates? Here is a simple graphic. Again a search will turn up more info.
http://i.zdnet.com/blogs/apwg_pandasecurity_crimeware2.jpg [zdnet.com]
from: http://www [zdnet.com]
Re: (Score:2)
Why is the average a range? Why not just say "On average we get attacked 8000 times per second.'"
Or are they just making stuff up?
-CF
Of course! That's how windows is written. (Score:5, Funny)
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.
Re: (Score:2)
I wonder if enough virii and separate malware are compiled together if it can form some kind of evolving ecosystem (and yes, it was in xkcd, but the idea is far older than that). The next version of Windows will be watching you... you know... more than normal.
Re: (Score:3, Funny)
Holy crap, my kingdom for a mod point.
Re: (Score:2, Interesting)
Very confusing article (Score:5, Insightful)
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.
Re: (Score:2)
Maybe they're testing it live. Admittedly, 7k-9k reports/sec seems high even if you factor in Internet Worm-style growth. Ignoring the setting up and tearing down of connections, those bug reports are presumably non-trivial in size (especially if they include any core-dumps). Even if no actual code gets sent, and the article implies otherwise, searching a database for similar (but not necessarily identical) reports and properly digesting them at the rates described would be murder. There aren't many databas
Everyone ignores error reporting. (Score:4, Interesting)
How did MS use these virus snippets? (Score:2)
"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.
And when asked what Microsoft does with these code snippets, Mr Heckman said, "We promptly use it everywhere we could. Otherwise Vista would have been delayed even more. We include all these viruses as BHOs [Browser Helper Objects] in our default distribution. Why should the user endure the trouble and torture of visiting a malware site to acquire the user experience of getting buggy crashing software? We provide it first hand from within Windows itself. We take pride in being backward compatible with eve
The Gist I Got Of The Article (Score:5, Funny)
Hackers and Developers are both lazy. This is why things haven't gotten any worse and also why things haven't gotten any better.
They report it !? (Score:2)
Making a little lemonade there? (Score:2)
I'm thinking that saying that the script kiddies are sending you their code is a little like saying that the people throwing bricks through your windows (no pun intended) are giving them to you for your new backyard BBQ pit.
And one surely hopes that this is not a large part of Microsoft's security research thought it might explain how so many Windows vulnerabilities are announced after they're already seen in the wild.
Re: (Score:3, Funny)
Maybe their servers run Linux?
Re: (Score:3, Informative)
I know you're jesting, but aside for their download/msdn sections sometimes being hosted by a third party who actually does run Linux, Microsoft.com for the most part runs on IIS. Not only that, but its actually hosted on SharePoint.
Re:So then what's with the wait? (Score:5, Insightful)
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?
Re:So then what's with the wait? (Score:5, Insightful)
Re: (Score:2)
Real "hackers" would probably just disable WER entirely [howtogeek.com].
Re: (Score:3, Insightful)
Re:So then what's with the wait? (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
You are hilarious! Do you do stand up? :)
Microsoft, good security standards... You are killing me.
Re: (Score:2)
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?
Do you really think any of those 7000 to 9000 attacks actually got through? No, so therefore they are already fixed. These are just stupid script kiddies learning to be terrorists. They are probably just modifying code fond on the net that has long since been protected against.
Re: (Score:2)
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?
Smart attackers do not aim new types of attack at MS or other targets where there is likely to be clueful attentiveness. As anyone who is engaged in clueful attentiveness to external attacks against heavily-attacked systems knows, the actual risk is not evenly spread across all attacks and the overwhelming majority of attacks are completely harmless for minimally protected systems. For example: I have managed systems that have seen SSH password guessing attacks bursting into the hundreds/second order of m
Re:But (Score:5, Funny)
Yes, that's because they live in basements where windows wouldn't be of any use anyway.
Re:But (Score:5, Funny)
Re: (Score:2)
Re: (Score:2)
Maybe they do fix these 7000-9000/day attacks. Maybe there are yet more attacks that the developers are smart enough not to tip off MS about, and those are the ones that they are not patching.
I'm not saying this is the case, but it's a possibility.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I spell it "crHackers". The popular press has bastardized our word, so we need a new one.
Re: (Score:2)
Microsoft already has tools like "code analysis" that can pick up buffer overflows and stuff. .NET code for things like unsafe handling of inputs, incorrect use of SQL (i.e. using it in ways that leave you open to SQL injection) etc and warn people of potential bugs or security problems.
There is no reason Microsoft couldn't produce tools designed to check
Re: (Score:2)
Re: (Score:2)
Really?
I can't tell you how many times I seen jokes, with no informative content or even a good point, get modded all of the way up to "5".
My light hearted joke was modded down because of a fanboy culture
Re: (Score:2)
True, but I happened to think it was witty and that others would find it so. Of course, I am biased.
It is a sad statement about tech culture that it had to be modded down so that other people wouldn't see it and get their panties bunched up. A more mature culture would have simply ignored it if they did not find it funny.
Re: (Score:2)
No, you are not. Those are attacks sent to microsoft.com. System crashes are a different number which are probably going to a different place.