Windows crash reports may help hackers claims research

Security research group, Websense, has published preliminary findings of a study conducted to highlight the vulnerabilities of the Windows crash reporting system which claims that the information contained in the reports can be of great use to hackers in getting the blueprints of the targeted networks.

Windows error reports collected and sent by the Dr. Watson service, are not encrypted unless they contain user-specific data and are sent using regular HTTP protocol, which makes them vulnerable to interception by hackers or government agencies during transfer. Conceptually, a traditional man-in-the middle technique implemented at the ISP level can aid wiretapping for agencies such as the NSA. As reported recently, Windows error reports have been used as a way of gaining device identification information by the NSA in wiretapping and surveillance in addition to sideloaded spyware.

According to the research published by Websense, when a USB device is connected to a Windows computer an automatic report is sent to Microsoft containing the device identifier and manufacturer, the Windows version, PC model, BIOS version and a unique machine identifier. As a proof of concept, the research group was able to establish that an iPhone 5 had been plugged into a Sony Vaio notebook, and even get the laptop's machine ID by comparing a publicly available database of devices and identifiers.

The group has urged Microsoft and others who use telemetry to gain usage information to implement at least SSL encryption to protect the user data. Alex Watson of Websense will be presenting the complete findings of the research at the RSA Conference in San Fransisco on February 24.

Image via Microsoft

Report a problem with article
Previous Story

Google puts Rap Genius back on top of searches after SEO spam

Next Story

Lenovo reveals ThinkPad 8 Windows 8.1 tablet

35 Comments

Commenting is disabled on this article.

this has been known for a long time. in fact any error reporting from any company can be leveraged since many crash errors, at least in the c++/win32 world can be exploited to take over execution of a program and in some cases, take over the machine.

TRC said,
I always disable error reporting. It's annoying and I doubt they even read them.

Watch the Defrag Show (http://channel9.msdn.com/Shows/The-Defrag-Show) and Defrag Tools (http://channel9.msdn.com/Shows/Defrag-Tools) from Channel 9. They're constantly analyzing these crash reports sent in by users, and constantly reminding people to send them in as this is what drives crash prioritization.

As for the subject at hand...

These reports are sent in the clear, so people are complaining this helps hackers. If they were encrypted, then people would complain they can't see what data is being sent to Microsoft and they can't be trusted. Damned if you do, damned if you don't.

_dandy_ said,
These reports are sent in the clear, so people are complaining this helps hackers. If they were encrypted, then people would complain they can't see what data is being sent to Microsoft and they can't be trusted. Damned if you do, damned if you don't.

I didn't even think of it but that's quite an interesting and valid point you make. I'm sure the conspiracy nuts will come out in force about how the OS is supposedly sending all sorts of details about users directly to the NSA...

This is one pet peeve I'm glad is getting a bit of public light. This is something we brought up to Microsoft several years ago and as a result we use internal servers or disable WER on installations.

They were really good about addressing encryption of any time of user or application data that might have personal information, but they were less concerned about hardware identification and configuration being publically known.

One could argue that there are other ways to obtain this information besides just looking for WER CABs being sent across the internet. For example, browsers provide a lot of information to sites that is just as dangerous, but since it is common, most of the world thinks this is ok.

Microsoft also has specific reasons why part of it is encrypted and part of it is not, as the encrypted part is kept locked even at Microsoft unless there is authorization to open the encrypted user data portion, meaning that it has to be relevant to the error and obtain the chain of command to get the key.

However, there is no reason they can't do a more generic security wrapper around the entire data being sent. Which is something we complained about a long time ago, so maybe this will push Microsoft to wrap this up to be more secure.

WER Side Notes...
There is a good argument for the existence of WER, specifically when you measure the stability from XP to Windows 8. (XP was a grand learning period for Microsoft, and WER helped.)

Prior to WER, there was a lot of crap software and Microsoft had no idea specifically what this software was doing. With WER they could address the problem with the software vendor and/or add in options to the compatibility database in updates to work around the problematic code as it executed.

The compatibility architecture of Vista/7/8 deals with multiple layers of 'compensation' for bad code that the OS simply sees and fixes as it executes in real-time, and a lot of these entries and information are collected from WER.

The compatibility system in Windows is far beyond just the Shortcut options must users see. 3rd party software can be nasty and rather than fight with developers, it is easier for the OS to just virtualize or correct calls on the fly and make the software seem to run flawlessly.

This system is even self aware and self adjusting, so if you execute a bad application and it fails, if the OS can spot why it failed, the next time you run it, this flaw will immediately be compensated for and allow the application to continue until it hits another hard error. So if you have software XYZ that crashes, run it a few time and see if it don't just start working after the OS learns how to correct the bad code. (This is where Windows can be quite clever to keep software running for users, even if it is crap software. )

Yeah, good post. I had no idea Windows attempted to fix bad code like that. It's really saying something when a program just never works then. LOL

Mobius Enigma said,
This system is even self aware and self adjusting, so if you execute a bad application and it fails, if the OS can spot why it failed, the next time you run it, this flaw will immediately be compensated for and allow the application to continue until it hits another hard error. So if you have software XYZ that crashes, run it a few time and see if it don't just start working after the OS learns how to correct the bad code. (This is where Windows can be quite clever to keep software running for users, even if it is crap software. )

Can you provide a TechNet or MSDN link that goes over this?

_dandy_ said,

Can you provide a TechNet or MSDN link that goes over this?

This is going to be a long post to explain...

The information you seek would be in the older stuff, as this tech was introduced with Vista and improved upon with Windows 7. It is also going to be scattered in various whitepapers and blogs and writings from 2006-2013.

The best bet would be to hit some of the more technical Channel9 videos with Mark Russ. and previous NT and Windows geeks, and just do some search on TechNet.


This information isn't going to be in one simple area, for example:

http://blogs.msdn.com/b/cjacks...tibility-assistant-pca.aspx

This only talks about a few things, leading into changes in exception handling from Vista to Windows 7. Even beyond what this article talks about, Windows 7 had other changes to not just swallow the error if the Application ignored the exception. This moved on to a new set of technologies to try to figure out the exception and correct it and ways to correct it. This was later expanded to use the compatibility database for attempted 'corrections'. Then the database was modified to use this information to allow subsequent runs to just run in a 'corrected' mode. This expanded to distribute these corrections via updates so if a user ran Application XYZ, the OS would preemptively correct it. This technology was then merged with API call corrections and lower layer and even kernel level real-time code correction, which also brought in and uses the memory management flags for tracking errors and on and on and on.

So you find a 'piece' of this information in this article, but there is an ongoing story that can't be sourced in just one article.

The information will be scattered through tens of hundreds or more documents and still only create a grainy sketch of what is going on until you digest enough to see how all the pieces fit together and where they come from, why they exist, and how they evolved to work in the release and current versions of Windows 7/8.


Studying and researching this stuff for nearly 20 years is one of the things I do. Maybe I should expand my teaching and services to a wider audience someday.

Facts, information, and knowledge are easy, being able to see the 'big picture' and 'understanding' how and why things work and exists is my specialty and where my passion exists.

There is a beauty to the 'craftsmanship' of technologies, and it isn't just the final product where end users hate or love a product; it is the process of getting the product made and the brilliance that exists outside what most developer or end users will ever see or realize it making things better for them.

Windows and NT is truly beautiful in how it works and why it works the way it does, and is something of craftsmanship. It was designed based on solid foundations and some very untested theories of the time, that proved to work even more brilliant that people theorized.

I follow a lot of technologies, and find brilliant craftsmanship in a lot things, even other OSes like Linux and OS X.

However, there is special place in my heart for NT. There is not currently a mainstream OS technology that is even close to being as elegant and advanced as Windows NT.

A lot of it is stuff people will never notice or see, but reap the benefits from. There are even people on the Windows team itself that don't get the brilliance that is happening at layers they don't deal with, and that is a shame.
(It is also why Mark Russ. and his SysInternals partner was brought into Microsoft to educate the teams on things outside of their scope.)

Gotcha. This is all built into the app compat stuff--tweaking the environment so apps can be coerced into running into an environment they weren't designed to run it. I've read Mark Russinovich's Windows Internals books, and I couldn't remember anything that did anything similar to what you were describing. Methinks you were trying to oversell it a bit. :-)

Ultimately, any time you have an actual bug, there's still nothing the OS can do to get it to run. An unexpected null pointer will always lead to a crash. And frankly, I wouldn't want it to work any other way.

I appreciate the elaborate response.

The most irritating part of the compatibility subsystem that I happen to encounter regularly when running portable apps especially is that when the app terminates, Windows pops up a dialog asking me if it "installed" successfully or not and whether I want to re-run it with compatibility settings applied. I wish they could improve that bit somehow because currently Windows seems to often get confused about whether an app is an actual installer or not.

I read the book "The Old New Thing" (Raymond Chen, I think. He has a blog of the same name.)

It was in there that I read about these 'shims' and the effort Microsoft makes to make crappy software work. There is also some rather interesting stuff on blue screens, and how they get thrown when the system passes errors down to the kernel and the kernel just says "F**k it!" and puts the blues screen up.

I'm no techie, mind (just an enthusiast!!), and Mr Chen explains it a lot better than I lol

_dandy_ said,
I've read Mark Russinovich's Windows Internals books, and I couldn't remember anything that did anything similar to what you were describing. Methinks you were trying to oversell it a bit. :-)

Not sure what you mean.

I do specifically remember a few Vista and Windows 7 timeframe videos Mark did on Channel9 where he talks about a bit more technical information and tries to make it understandable.

There are a LOT of brilliant minds at Microsoft, so picking out one as the 'best' would be foolish.

Mark is someone I give credit of having a lot understanding beyond just the technical details and can make it understandable to a *non-technical audience.


If people here want truly a lot of technical 'nuts and bolts', pick up the SDK and DDK and read; however, it comes without a bigger picture or understanding, and also doesn't always explain why things are being done, just that they are.

Romero said,
The most irritating part of the compatibility subsystem that I happen to encounter regularly when running portable apps especially is that when the app terminates, Windows pops up a dialog asking me if it "installed" successfully or not and whether I want to re-run it with compatibility settings applied. I wish they could improve that bit somehow because currently Windows seems to often get confused about whether an app is an actual installer or not.

It isn't just for installers. Also, for this box to appear, something specifically that is happening in the execution of the App is getting noticed by Windows. (Touching something it shouldn't, using an older call, etc.)

You should also be able to dismiss this dialog with 'It worked' and not get bothered by the popup in the future. (Unless the Application is doing different things that were tracked before.)

_dandy_ said,

Ultimately, any time you have an actual bug, there's still nothing the OS can do to get it to run. An unexpected null pointer will always lead to a crash. And frankly, I wouldn't want it to work any other way.

PS Not exactly... There are times that Windows can 'record' the crash if it thinks it can redirect the call or prevent it by even adjusting the pointer.

This is why some truly 'buggy' Applications can be run, and on the next launch get further without crashing as Windows was waiting for the bug and compensated for it.

Running the buggy Application several times in a row, if it keeps making progress, may allow it to fully run without noticeable problems.

There is also a 'line' of where Windows can and cannot compensate, but I don't know off the top of my head exactly where it is in Windows 8. Some of this stuff can be corrected by fixing an API call, virtualizing something that is protected, adjusting a reference, etc.

Also MS added catching to the NT kernel around the time Windows 7 was released that can even fix/adjust some code before it execute directly on the CPU. (This I don't remember a lot of off the top of my head and would be talking out my rear if I even attempted to explain what little I know about it beyond stating I know it exists.)

Mobius Enigma said,
You should also be able to dismiss this dialog with 'It worked' and not get bothered by the popup in the future. (Unless the Application is doing different things that were tracked before.)

Or unless I use the portable apps on multiple PCs and have to dismiss the same damn Program Compatibility Assistant dialog repeatedly. Or unless I update the apps so they have a different signature, which happens fairly frequently. I also don't like all the AppCompatFlags added to the registry on every PC every time I dismiss the dialog with different versions of the apps. I wish there was some way I could get it to completely ignore anything executed from a specific location or device.

Romero said,

Or unless I use the portable apps on multiple PCs and have to dismiss the same damn Program Compatibility Assistant dialog repeatedly. Or unless I update the apps so they have a different signature, which happens fairly frequently. I also don't like all the AppCompatFlags added to the registry on every PC every time I dismiss the dialog with different versions of the apps. I wish there was some way I could get it to completely ignore anything executed from a specific location or device.

Instead of blaming Microsoft for 'letting' a incompatible bit of code continue to run, you should be complaining to the developer of the software that has the bad code.

Microsoft at least 'compensates' and lets the software run.

I've complained to both, neither did anything about it. I'm also not "blaming" MS but wishing the installer detection routine was a bit more intelligent since it keeps complaining about the app not 'installing' correctly. It's not a legacy app and otherwise works fine except for this persistent niggle. I'm not absolving the app dev of anything, but why are you so up in arms anyway defending MS? Do you honestly mean to say all of their code is 100% perfect and there's absolutely no way the compatibility subsystem can be improved? I know how important backwards compatibility is to them, but that doesn't mean existing error detection and mitigation strategies cannot be enhanced further to prevent repeated useless dialogs being displayed to end users (cf. how UAC was modified to be less in-your-face after complaints).

Romero said,
I've complained to both, neither did anything about it.
[...]
It's not a legacy app and otherwise works fine except for this persistent niggle. I

Name and shame. What's the app?

It's obvious Microsoft needs to adjust Windows Error Reporting to perhaps use AES 256-Bit Encryption. But what puzzles me is that Windows Error Reporting has been in use since Windows XP and although it been updated through various iterations of Windows, the fundamentals and underlying code and remained the same apart from newer API's. So Why has it taken till now for this information to be brought to light. If this method is as easy as they say then surely hackers would have been using this method long before now.

Think NSA first or other government bodies and then well funded Grey Hat companies, not some little kid in their bedroom. It probably has been going on for years we just never heard about it.

I do. It's there for a reason, if it didn't help Microsoft improving stability, reliability and security it wouldn't be there anymore. Since it is, I assume it's helpful. And it doesn't cost me anything, I'm offered a choice between "Send" and "Don't send". So why not?

wojtekmaj said,
I do. It's there for a reason, if it didn't help Microsoft improving stability, reliability and security it wouldn't be there anymore. Since it is, I assume it's helpful. And it doesn't cost me anything, I'm offered a choice between "Send" and "Don't send". So why not?

Exactly. Why complain about a crash, but do nothing to help resolve it? LOL

Why not? I've actually had it provide a fix for me a couple of times after submitting it. Theoretically, it should also help Microsoft identify common issues people are encountering with their products, and hopefully, patch them via Windows Update. I don't know if this has ever happened, but I like to think they do.

I've not once, ever received a response (since Windows 3.1 on up). And whenever I did see such a screen, I could never duplicate the scenario after a reboot. Unless the problem can be replicated, there's no point in reporting anything.

And now, especially after knowing your data is not encrypted, let some other poor sap report the issue. MS doesn't have the resources to investigate every report. They look at ones with multiple, identical issues. One less report won't matter and you stay safe.

Rohdekill said,
And now, especially after knowing your data is not encrypted, let some other poor sap report the issue. MS doesn't have the resources to investigate every report. They look at ones with multiple, identical issues. One less report won't matter and you stay safe.

So what happens when everyone assumes someone else will do it?

(BTW, I fully agree that the information should be properly encrypted.)

Wait they only just worked this out? Crash a network + sniff it for data loads of goodies in these reports i bet.

Pretty sure apple jailbreaks did stuff like this (allowed all crashes to be sent to cydia and such). They hoped it would help aid in finding overflows and such.