Forgot your password?
typodupeerror
Windows Bug Privacy Security

Unencrypted Windows Crash Reports a Blueprint For Attackers 103

Posted by timothy
from the distributed-fuzzing-attack dept.
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..."
This discussion has been archived. No new comments can be posted.

Unencrypted Windows Crash Reports a Blueprint For Attackers

Comments Filter:
  • If you're really concerned about security on your individual systems, don't send critical system information externally. Otherwise the vulnerable applications were already vulnerable before and after sending, and if your messages are being intercepted, you've got bigger security issues already.

  • Duh (Score:5, Funny)

    by mythosaz (572040) on Thursday January 02, 2014 @02:47PM (#45848261)

    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.

    • by Anonymous Coward

      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.

      • Re:Duh (Score:5, Funny)

        by recoiledsnake (879048) on Thursday January 02, 2014 @03:02PM (#45848409)

        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.

        • by icebike (68054)

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

          It does it even if the device itself supplies drivers or uses standard drivers, and even when the driver is already on the local machine and installed. Searching for drivers on windows update is completely unnecessary for about 95% of the things you will ever plug in, and usually fruitless for the other 5%.

          It defaults to always searching, and you will only see a choice the very first time, any device is installed, (even a keyboard). So chances are that 99% of computers have device driver fetching turned on

          • . Searching for drivers on windows update is completely unnecessary for about 95% of the things you will ever plug in, and usually fruitless for the other 5%.

            Reference?
            The drivers that come with the device or Windows might be outdated, buggy and/or omit new features.
            I see updates to drivers in Windows Update many times so they're quite useful to me. Even as a power user, I don't keep visiting my hardware driver websites and keep comparing driver versions. Do you do that? The other option is to clutter up the system with 15 auto updaters from 10 companies. Is hiding the hardware you use from MS(assuming they start encrypting the data, which was a bad omission) th

            • by icebike (68054)

              The drivers that come with the device or Windows might be outdated, buggy and/or omit new features.

              So your thumb drive grows new features over its life? Amazing.

              Everybody has the issue. Those that don't think its an issue are like vaccinated children, running around on the playground serving as a conduit for exposing others.

              • The drivers that come with the device or Windows might be outdated, buggy and/or omit new features.

                So your thumb drive grows new features over its life? Amazing.

                Sure it can, like encrypted thumb drives can have security fixes.

                Everybody has the issue. Those that don't think its an issue are like vaccinated children, running around on the playground serving as a conduit for exposing others.

                Most people do not need military grade security in everything, especially things like USB device info. Those that do have a mechanism to do it. That said, MS should at the least, start encrypting them over SSL, there's no excuse for that. Why are you unconcerned over search terms, email and documents being sent, stored and tracked forever in the cloud, but are worried about USB Device IDs?

                Ask a bunch of people which would they prefer if they

              • Those that don't think its an issue are like vaccinated children, running around on the playground serving as a conduit for exposing others.

                Vaccinated children are a conduit?

    • Came to say this. It is interesting in the exact same sense that it is interesting how Apple know exactly what type of operating system you install iTunes on. The AC submitter went all obvious troll in the last sentence.
  • by Gothmolly (148874) on Thursday January 02, 2014 @02:49PM (#45848279)

    Who actually lets Windows submit these?

    Also, if you don't trust your ISP not to snoop these, you shouldn't trust them not to snoop your real traffic too.

    • by Anonymous Coward

      That's the thing, isn't it? The "we're all friends" model of computer networking has been stabbed, choked and shot by the NSA. Trust was yesterday.

  • ...instead of fixing their slow and buggy web filtering software. (Ducks.)

  • Anyone who can access technical support resources can access customer data. The biggest issue is that most technical support is outsourced to other countries, which now have full technical (hardware+software version, etc.) and customer information (good for social engineering).
  • Next! (Score:5, Insightful)

    by ledow (319597) on Thursday January 02, 2014 @03:03PM (#45848419) Homepage

    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! (Score:5, Informative)

      by drinkypoo (153816) <martin.espinoza@gmail.com> on Thursday January 02, 2014 @03:10PM (#45848523) Homepage Journal

      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! (Score:4, Informative)

        by Etherwalk (681268) on Thursday January 02, 2014 @04:00PM (#45849107)

        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.

        This. It's true lots of crash reports aren't acted on--it's also true that something like 5% of users generate 90%+ of crash reports. But they give great information on "this is affecting umpteen million people so we should fix it because it will save lots of man-years" or "someone's having a problem and we should see if any of the data we have will help us fix it."

    • Re:Next! (Score:5, Informative)

      by clodney (778910) on Thursday January 02, 2014 @03:45PM (#45848921)

      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.

    • by Ravaldy (2621787)

      I can assure you they aren't ignored by Microsoft. Many fixes stem from these reports. If you were a programmer you would understand why it's important and why they don't handle every single message received.

    • by Rich0 (548339)

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

      All the good stuff you posted aside, you're still just as vulnerable. This isn't just about you leaking info to the NSA about what you have installed, but it is also about everybody else leaking info to the NSA about the bugs in Windows in general. The NSA can use that to create zero-days, which will work perfectly fine against your version of Windows since it contains the same flaws even if you aren't personally reporting them to MS.

    • Re:Next! (Score:4, Informative)

      by bmajik (96670) <matt@mattevans.org> on Thursday January 02, 2014 @05:05PM (#45849989) Homepage Journal

      fyi, I have personally analyzed WER crash dumps and used them to get the root causes fixed in the next update/release in multiple Microsoft products.

      (Dynamics AX and Visual Studio, if you're curious)

      We (Microsoft) not only look at WER data, we act on it.

      You are correct that it is often really hard to figure out what crazy thing happened, but we try anyway, and sometimes, we're able to figure it out and create fixes.

      As was mentioned elsewhere, WER data also tells us WHO is hitting a problem and how often it is being reported. That gives us valuable information about prioritizing WER responses.

      If you don't want to pay the perf/bandwidth penalty for collecting/uploading reports, that's understandable. But as mentioned elsewhere, you're abstaining from "voting" to have your issues looked at sooner/more thoroughly.

      Then, if you care about such things, there's the "social responsibility" aspect of it. I'd much rather we shipped perfect software, but we don't. WER is one of the best ways we can see issues that customers are hitting and get a sense of how painful they are for customers. If the goal is for MS to be less awful, WER is a key feedback mechanism to help us help you.

      It would be a shame if your environment produced just the right heap dump that let us understand an issue that was impacting millions of people... and it was locked on your machine. Not only would your abstention cost YOU, but it would cost everyone else as well.

      Is it your fault we ship bugs? Of course not. Would it help you, us, and millions of other people if you turned on WER? Probably.

      Thanks,
      Matt Evans
      Senior SDET, Visual Studio

      • by bmajik (96670)

        Rereading what I wrote, I should clarify this part

        WER data also tells us WHO is hitting a problem

        WER data doesn't tell us your personally identifiable information (name, email address, etc)

        What I meant by that is that it bucketizes crash reports according to different dimensions. User's language/locale, operating system revision, product binary version, etc.

        This is more valuable than you might think. It turns out that certain crashes only happen on certain languages, or that crashes happened shortly after

      • Thanks for sharing your experience, Matt

        When I first learned about this, there were two things I didn't understand: Why does Microsoft collect this data (error reports and USB insertions) and why is it sent in the clear? You and others have provided a plausible rationale for the first, but the sneakiness of the USB insertion calls home are disturbing. It still seems completely wrong to send it unencrypted. Very, very wrong in fact. Can you share why was this decision made?

        • by bmajik (96670)

          Sadly, I cannot tell you why the decision was made (or even if it was an intentional decision as opposed to an oversight). I'm not on the WER team and I haven't spoken to them. I chimed in because I'm one of many product engineers that looks at WER data after it has been collected, processed, and assigned to the right team/product for follow-up.

          That said, I can speculate, and point out publicaly available information, just like any other slashdotter :)

          - regarding the clear text -- one of the comments on t

          • by yuhong (1378501)

            Remember that this feature was released back in 2001. To put it in context, it was just after the infamous export restrictions on strong cryptography was lifted.

      • If you have any honor, either as an individual or a company, you will now encrypt the bloody things. Setting aside your a-hole buddies in the NSA, the other bad guys are exploiting these plain-text treasure troves as well, FFS.
        • by bmajik (96670)

          Please read my other response, which points out that there were some interesting comments on the original article. In short, it appears that only a portion of the WER upload is unencrypted.

          (That said, I am not on the WER team, and I have no idea if they will take action as a result of this paper or not. We'll see)

          Regarding the other point -- in my opinion, having SSL turned on isn't really relevant if you're trying to hide information from the NSA/FBI.

          The Lavabit legal documents that were made available a

    • 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.

      I look at them. So do many others here at Microsoft.

      Background: I sit on an engineering team that works with OEMs and IHVs. I formerly supported driver developers with support and posting drivers to Windows Update

      The challenge with OCA is that there are many sources of crashes. It can be caused by a bug in a Microsoft component, 3rd party driver, faulty hardware, or something else in the kernel doing something wrong (such as malware, etc). Crashes are assigned to buckets, where the hope is that there i

  • This is absolutely brilliant: Looking at windows crash reports. Just think how much data there is.
    Even if only 5% of users actually send those reports, it's still the mother lode
  • by Anonymous Coward

    Having looked at what data is actually sent, I don't see how this helps an attacker unless the system in question is already vulnerable. TFA lists some data (not entirely complete, e.g. the IP address is missing, but you get the point):

    Date
    USB Device Manufacturer
    USB Device Identifier
    USB Device Revision
    Host computer - default language
    Host computer - Operating system, service pack and update version
    Host computer - Manufacturer, model and name
    Host computer - Bios version and unique machine identifier

    In all hon

  • Double edged sword (Score:4, Insightful)

    by Kardos (1348077) on Thursday January 02, 2014 @03:15PM (#45848585)

    On one hand, it would be rather straightforward for Microsoft to push a patch to use encryption for these reports. On the other hand, now you are running closed source software that sends a bunch of data to Microsoft -- data that you can not inspect. When it is sent in the clear, at least you could sniff your traffic and see what Microsoft is getting. So with encrypted crash reports, you need to trust Microsoft more than now.

    MS Word crashed? Better send the docx file that caused the crash as well, it's not like the user(s) can call Microsoft out for it with encryption.

    • by Arrepiadd (688829)

      When it is sent in the clear, at least you could sniff your traffic and see what Microsoft is getting. So with encrypted crash reports, you need to trust Microsoft more than now.

      Sure, but when sent on the clear you need to trust everyone between you and Microsoft. I know this is Slashdot, but Microsoft may not be your worst enemy.

  • by Anonymous Coward

    Disable Windows Crash reporting. Problem solved.

  • Assumptions (Score:4, Insightful)

    by WaffleMonster (969671) on Thursday January 02, 2014 @03:30PM (#45848741)

    I'll admit to being surprised by this. I assumed Microsoft had the common sense to encrypt error reports especially given they contain at least partial contents of applications internal memory and would therefore assumed to be considered sensitive. The dialogues asking you to send certainly make this posture clear.

    In fact when I first read this the other day I was a bit confused as to how they (NSA) were getting this data...from Microsoft servers? It didn't even enter my mind these things were sent unencrypted and trivially pulled off the wire.

    While we normally have WER and associated scheduler task entries disabled there are still some machines we send the reports in the off-chance bugs get fixed...not anymore...sad.. inexcusable...

    This completes creates quite an interesting feedback loop imagine using QUANTUMINSERT to load malware or trigger crashes... if there is a problem or your not sure about the memory environment sit back and wait for the error report.

    • Considering RSA has likely granted keys to the palace, NSA probably has direct access to M$ CVS. As such it may explain why certain distro's of linux have been directly attacked in the past.

      • by dkf (304284)

        NSA probably has direct access to M$ CVS

        That would do the NSA very little good indeed; Microsoft has never used CVS for anything.

    • Reading more carefully dumps are encrypted yet certain summary data like memory offset and shared library crash occurred within are not.

  • by 140Mandak262Jamuna (970587) on Thursday January 02, 2014 @03:46PM (#45848927) Journal

    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.

    • 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.

      When an angel gets his wings, a Venture Capital firm gets demoted...

  • The Forget My Password feature many sites offer if intercepted is just as dangerous for the user. The issue isn't MS here, it's the nature of our current open infrastructure. Although I'm sure there is a solution I don't know what it is and how easy it is deployed to secure all transmissions, not just Microsoft's .

    • If well implemented the password retrieval function is not really that easy to exploit:
      • password retrieval never sends you your current password, but instead gives you the opportunity to set a new one, invalidating the old. This makes it very obvious to the user to see that a password reset has been performed.
      • password retrieval usually does not send you the new password "as is", but rather a link with a "cookie" that allows you to set it. The cookie is no longer good once you've used it to set a new passw
      • by Ravaldy (2621787)

        Yes,

        But what about initiating a reset and intercepting the email and then performing the reset yourself. The procedure is still not safe from the Man in the Middle attack.

        Any time your data can be sniffed you are in danger. This isn't an issue specific to any OS or software manufacturer. Sure, there are things we can do to limit the damages such as releasing bug free software (maybe in 3014) but until then we either live with the consequences or encrypt all network data except broadcasts intended for everyo

        • But what about initiating a reset and intercepting the email and then performing the reset yourself.

          True, but that would imply:

          1. Intercept the e-mail in such a way that it is no longer delivered (because the link cookie will be invalid once the spy has completed the reset, which would tip off the user)
          2. Complete the reset
          3. Do whatever evil need the password is needed for. This has to be right here and now, because we'll issue another reset. If a full download of the user's e-mail is needed, then good luck...
          4. Perform a second reset (whose response we allow to reach the user)

          And all this has to be done in

  • If present Guess what I know.

egrep -n '^[a-z].*\(' $ | sort -t':' +2.0

Working...