Unencrypted Windows Crash Reports a Blueprint For Attackers

An anonymous reader writes "According to Forbes online, up to 1 billion PCs are at risk of leaking information that could be used as a blueprint for attackers to compromise a network from Microsoft Windows Error Reporting (WER) crash reports that are sent in the clear. Researchers at Websense Labs released a detailed overview of the data contained in the crash reports, shortly after Der Spiegel released documents alleging that nation-state hackers may have used this information to execute highly targeted attacks with a low risk of detection, by crafting attacks specifically for vulnerable applications that are running on the network. Also interesting to think that Microsoft knows exactly what model of phones that you have plugged into your PC..."

Comments

Duh

[mythosaz]

Also interesting to think that Microsoft knows exactly what model of phones that you have plugged into your PC..."

Wait, you mean my crash reports include a list of devices?!?

The horror.

Re:Duh

[recoiledsnake]

Reading the article, it says that each time you plug in a new USB device, it automatically sends that information to Microsoft. Even if you don't send the Windows crash reports to Microsoft, your computer is still phoning home each time you install a new USB device.

Duh, how does it search for drivers on Windows Update then? Turn off that functionality and then check, if it still does, then it's news.

Next you will tell me that my browser is broadcasting an IP Address.

Re:Duh

[heypete]

Sorry; perhaps I'm being incredibly ignorant here (I'm the AC that posted above), but my understanding was that Windows came with a bunch of generic drivers for devices, and only checked Windows Update for a device if you told it to when installing the device.

Am I wrong?

Windows typically checks Windows Update for drivers for all newly-connected devices, then look for locally-installed drivers if the Windows Update check didn't find anything. Certain devices (like USB mass storage devices, for example)) are installed using local drivers first, as most people want their USB flash drives to work as soon as possible but are willing to wait a few tens of seconds for other devices.

Ignoring privacy concerns, this is a fairly sensible thing: more devices can be "plug and play" and this benefits users. Similarly, while a driver might be included on a CD that comes with a device, it might be outdated -- an online check with Windows Update can retrieve the latest driver.

Next!

[ledow]

Disabled on every machine I own, every machine I've deployed, every machine that I've been given the permission to manage.

Not because I think someone might be able to sniff them and then use them against my workplaces / PC's. Purely because they are WORTHLESS.

Reporting them, you see nothing back. All those people who get error reports upon upgrading to a duff hotfix, it takes someone to whinge to Microsoft to get it fixed. Millions of crash reports aren't acted up, from what I see. I doubt anyone reads them.

When offered to software developers, etc., I'm always told that it's easier to just get me to run a debug version rather than piss about with any built-in error reporting / dumping possible from the Microsoft tools. It gives them more information, they can debug it live, and I don't have to worry about information going back and forth.

Pretty much every time I've had one, it's been ignored, by Microsoft, developers, or myself. I learned a long time ago that debugging from any default dump or crash report - even for huge multinational companies that are trying to help solve your problem - is worthless. It's just not worth the effort.

Hence I've disabled them since day one. Not only do they not do anything useful, they don't tell me anything useful, they want to connect to the Internet (which can trigger my software firewall for a completely different process to those authorised applications I already allow through, assuming the machine is even online), and they actually make the error messages HARDER to read for my users. I disabled it entirely. "There was an error" and a hard crash is infinitely better than my users trying to debug a crashed application themselves or sending off dumps because the button says to do it, and still getting a hard crash. Hell, if the crash was because the network cable fell out (which apps will if they are based on a network share sometimes), the submission process triggers a DNS lookup which hangs the PC for 30+ seconds sometimes.

Worthless. Disabled.

Re:Next!

[drinkypoo]

Millions of crash reports aren't acted up, from what I see. I doubt anyone reads them.

They're used for two things. One, to figure out which bugs are actually impacting customers. Two, when there's a bug Microsoft has decided they care about. Either way, by never sending them in you're not voting for your bugs to be fixed.

Re:Next!

[clodney]

Several times I have gotten the little popup in the tray of Win7 telling me that there is a fix for an issue that I have had. Usually it takes the form of a driver update or a hotfix.

At one point I worked for a company that used Windows Error Reporting in our app, and MS did indeed route the crash reports to us, which we did debug and generally fix.

Re:Not everything is about software security.

[recoiledsnake]

If you're really concerned about security on your individual systems, DONT USE WINDOWS. There, fixed it for ya.

Ubuntu does the same, if not worse.
https://launchpad.net/apport

pport intercepts Program crashes, collects debugging information about the crash and the operating system environment, and sends it to bug trackers in a standardized form. It also offers the user to report a bug about a package, with again collecting as much information about it as possible.

It currently supports

  - Crashes from standard signals (SIGSEGV, SIGILL, etc.) through the kernel coredump handler (in piping mode)
    - Unhandled Python exceptions
    - GTK, KDE, and command line user interfaces
    - Packages can ship hooks for collecting speficic data (such as /var/log/Xorg.0.log for X.org, or modified gconf settings for GNOME programs)
    - apt/dpkg and rpm backend (in production use in Ubuntu and OpenSUSE)
    - Reprocessing a core dump and debug symbols for post-mortem (and preferably server-side) generation of fully symbolic stack traces (apport-retrace)
    - Reporting bugs to Launchpad (more backends can be easily added)

If you're really concerned about WER on Windows, just say no when it asks you to send crash reports.

USB rings bell, and they must know at once.

[140Mandak262Jamuna]

As you can see, within seconds of connecting the new USB device to the computer, a report is sent to watson.microsoft.com in HTTP (clear text). This report includes a considerable amount of information that is URL encoded into the request. This information includes:

Every time you plug in a device to USB port, a di-ding bell sounds. It is of utmost importance to Microsoft to know a bell has rung, so that it can promote an angel second class to angel first class with wings.

See? There is an innocent explanation for it after all.