I’ve been working on a white paper explaining how Windows Hello and Microsoft Passport work together in Windows 10– it’s a really neat combination. Over at my work blog, I have a short article outlining what Hello and Passport are and a little about how they work (plus a bonus demo video). If you’re curious, head over and check it out.
Category Archives: Security
This week I had the opportunity to present a session called “Cloud Best Practices” at the Alabama Digital Government Summit. I had a great time— it was fascinating to see how many different agencies in our state are putting advanced IT to work to save money and get more done for the taxpayer. However, there was one blemish on the experience that I wanted to polish away, so to speak.
Part of my talk concerned the fact that no matter where you live, your local government has lawful means to get your data: they can subpoena you, or your cloud provider, to get it. There’s nothing that you can do about it. It’s a feature, not a bug, of modern legal systems. I often talk about this in the context of people’s fears that the NSA, GCHQ, or whomever will snag their data, by lawful or unlawful means. Here’s the slide I put up:
I don’t think these are controversial assertions. However, at this point in my talk, Stuart McKee (chief technical officer for state and local government at Microsoft) flatly asserted that Microsoft does not comply with government subpoenas for customer data; I believe he used the word “never”. He went on to say that Microsoft has a pattern of resisting subpoena requests and that this “has gotten [them] into some trouble.” He concluded by saying that Microsoft’s standard action is to tell governments that they must subpoena the data owner, not the service provider.
I believe these assertions to be largely untrue, and certainly misleading. (I’ll leave aside the insulting manner in which Stuart asserted that I was wrong— after all, I am certainly wrong sometimes and generally appreciate when people point it out.) I want to set the record straight to the extent that I can.
First, Microsoft absolutely does comply with lawful subpoenas for customer data. This page at Microsoft’s web site summarizes their responses to lawful legal demands for customer information (both information about customers and information belonging to customers) across a broad variety of jurisdictions, from Argentina to Venezuela. To assert otherwise is ludicrous.
Second, Microsoft has a pattern of complying with these lawful subpoenas, not refusing them. When Stuart said that Microsoft is “in trouble” for refusing a subpoena, I suspect that he’s referring to Microsoft vs United States, where the issue at hand is that Microsoft was served a search warrant for data stored in a Microsoft data center hosted in Ireland. The data are stored there because the customer is located outside the US. Microsoft moved to have the warrant vacated, and when that failed, asked the cognizant district court to vacate it. The district court upheld the original warrant; Microsoft refused to comply and was held in contempt. Now this particular case is working its way through the US federal court system.
Let me be clear: I applaud Microsoft for standing up and resisting the overreach in the original warrant— there doesn’t seem to be (at least not to my layman’s understanding) a right of the US government, at any level, to subpoena data belonging to a non-US person or organization if it’s stored outside the US, even if it’s held in a cloud service operated by a US person or organization. The brief Microsoft filed likens this to a German court ordering seizure of letters stored in a safe deposit box in a US branch of a German bank. Having said all that, claiming that this kind of resistance is routine is overblown. It isn’t. If Microsoft were refusing subpoenas left and right, the numbers I mentioned above would look very much different.
Third, Microsoft’s policy is indeed to try to redirect access requests whenever possible. The Office 365 privacy page has this to say:
We will not disclose Customer Data to a third party (including law enforcement, other government entity, or civil litigant; excluding our subcontractors) except as you direct or unless required by law. Should a third party contact Microsoft with a request for Customer Data, we will attempt to redirect the third party to request the data directly from you. As part of that process, we may provide your contact information to the third party. If compelled to disclose Customer Data to a third party, we will use commercially reasonable efforts to notify you in advance of a disclosure unless legally prohibited.
In other words, Microsoft will try to redirect subpoenas from themselves to the data owner, where they are allowed by law to do so, and if they can’t, they will notify you, if allowed by law to do so. This is the only one of Stuart’s claims that I think is inarguable.
Finally, Microsoft proactively cooperates with law enforcement. The Microsoft Digital Crimes Unit newsroom contains press releases touting Microsoft’s cooperation with law enforcement agencies around the world (here’s just one example). This cooperation and disclosure extends to Microsoft proactively notifying law enforcement agencies when their PhotoDNA service identifies child porn images in customer’s private OneDrive data. I support their right to do this (it’s covered very clearly in the terms of service for Microsoft cloud services), and I believe it’s the right thing to do— but to claim that Microsoft never discloses customer data to law enforcement agencies while they are voluntarily doing so is both untrue and misleading.
Everyone’s interests are best served when everyone understands the specifics of the legal interaction between local and national governments and cloud service providers in various jurisdictions. This is a really new area of law in many respects, so it’s understandable that some things may not be clear, or even defined yet, but I wanted to correct what I view as dangerously misleading misinformation in this specific instance.
The bottom line: no matter what cloud service you choose, be sure you understand the policies that your cloud provider uses to determine the conditions under which they’ll cough up your data.
[note to readers: I encourage you to repost, retweet, and otherwise spread this offer. It’s legit; I am happy to help Apple in any way that I can. Since I don’t have any Apple execs on speed dial, perhaps social media will get this to the right folks. ]
Dear Mr. Cook:
We’ve never met. You’ve almost certainly never heard of me. But I’m going to make you an offer that I hope you’ll accept: I want to help you quit making such a mess of the world’s Exchange servers. More to the point, I want to help the iOS Exchange ActiveSync team clean up their act so we don’t have any more serious EAS bugs in iOS. The meeting hijacking bug was bad enough, but the latest bug? the one that results in Exchange servers running out of transaction log space? That’s bad for everyone. It makes your engineers look sloppy. It makes Exchange administrators into the bad guys because they have to block their users’ iOS devices.
These bugs make everyone lose: you, Microsoft, and your mutual users. They’re bad for business. Let’s fix them.
You might wonder why some dude you’ve never heard of is making you this offer. It’s because I’m a long-time Apple customer (got my first Mac in 1984 and first iPhone on launch day) and I’ve been working with Exchange for more than 15 years. As a stockholder, and fan, of both companies, I want to see you both succeed. Before there was any official announcement about the iOS SDK, I was bugging John Geleynse to let 3Sharp, my former company, help implement Exchange ActiveSync on the phone. He was a sly devil and wouldn’t even confirm that there would be an EAS client for the phone, but the writing was on the wall– the market power of Exchange Server, and the overwhelming prevalence of EAS, made that a foregone conclusion.
I’m an experienced developer and a ten-time Microsoft Most Valuable Professional for Exchange Server. I have experience training developers in Exchange Web Services, and I know EAS well; in fact, I was an expert source of evidence in the recent Google/Motorola vs Microsoft case in the UK. As a long-time member of the Exchange community, I can help your developers get in touch with experts in every aspect of Exchange they might want to know about, too.
It’s pretty clear that your EAS client team doesn’t know how Exchange client throttling works, how to retry EAS errors gently, or all the intricacies of recurring meeting management (and how the server’s business logic works). If they did, the client wouldn’t behave the way it has. They could learn it by trial and error… but look where that’s gotten us.
I’m in Mountain View, right up the road. Seriously. Have your people call my people.
Peace and Exchange 4eva,
One of the problems I most often run into when working with Windows machines is the way updates work. Microsoft has made great strides in improving the update experience for Windows and for Microsoft applications; compared to the steaming pile of filth that is Adobe’s updater, for example, or the mishmash of every-app-its-own-update-client behavior common on the Mac, Microsoft Update is pretty smooth.
But what about Skype? It’s now a Microsoft application, so you’d expect it to receive updates through Microsoft Update… and it does. However, it also has its own update mechanism. What gives?
Here’s a solid explanation, which Doug Neal of the Microsoft Update team was kind enough to let me republish. (My comments are italicized):/p>
While we’re still working through the best way to complement the updating system available via Skype, here are some insights that may explain the differences:
Skype 5.8 [released nearly a year ago] introduced a Skype-based auto-updating features unrelated to any Microsoft technology (and before knowledge of the merger). This updating service will remain for the foreseeable future – and is Skype’s method of offering updates on a more frequent basis than Microsoft Update. These settings and consent to update via Skype’s updating service can be controlled via the Skype | Options | Automatic Updates setting – which also provides a link to more information on Skype’s updating approach via their updater. These updates via the Skype updater can include major and incremental updates. [in other words, the Skype app can pull both minor updates and entire new versions through its built-in update mechanism, as do many other third-party apps on Windows and OS X. ]
As a new addition to the products supported via Microsoft Update, only major versions of Skype are made available via MU. Consent to automatically update via Microsoft Update is granted via Microsoft Update opt-in – the same opt-in experience available via Windows Control Panel | Windows Update | Change Settings. [So MU may offer you major versions, which is useful if you don’t now about ]
So, updating Skype via Skype’s updating service is controlled from within the Skype application. This updating experience may include various Skype-specific reminders and prompts that a newer update is available. Turning off updates here will reduced the number of incremental updates your Skype client will receive assuming Microsoft Update is still enabled to provide more major, less-frequent updates to Skype.
Updating via Microsoft Update will only occur for major versions and is controlled within the Windows Update control panel – the same place for all Microsoft product updates. Turning off Microsoft Updates is not recommended – and will result in preventing any updates from Microsoft for all 60+ products supported by Microsoft including security updates. The updating experience for Skype will be the same as you expect for all other Microsoft Updates, namely that unmanaged consumer PCs will see these as Important updates with no UI (applied automatically), or to managed PCs via WSUS/SCCM admin approval.
Having a single update mechanism, à la the iTunes App Store and the Windows Phone Marketplace, certainly seems to be the best model for end users: all app updates are packaged and available on demand in a single location. On the other hand, putting the responsibility for applying security-critical updates in the hands of end users, instead of in a centralized patch management system driven by WSUS or equivalent, is a terrible idea for the enterprise. Having a hybrid approach like this is a compromise, albeit an unintentional one, that may deliver the better aspects of each approach. Long-term I’d like to see the major OS vendors offer a flexible method of combining both vendor-specific OS/app updates with opt-in updates provided by third parties– something like the existing Marketplace combined with the controls and reporting in WSUS would be ideal. Here’s hoping…
I love the BlackHat security conference, although it’s been a long-distance relationship, as I’ve never been. The constant flow of innovative attacks (and defenses!) is fascinating, but relatively few of the attacks focus on things that I know enough about to have a really informed opinion. At this year’s BlackHat, though, security researcher Peter Hannay presented a paper on a potential vulnerability in Exchange ActiveSync that can result in malicious remote wipe operations. (Hannay’s paper is here, and the accompanying presentation is here.)
In a nutshell, Hannay’s attack depends on the ability of an attacker to impersonate a legitimate Exchange server, then send the device a remote wipe command, which the device will then obey. The attack depends on the behavior of the EAS protocol provisioning mechanism, as described in MS-ASPROV.
Before discussing this in more detail, it’s important to point out three things. First, this attack doesn’t provide a way to retrieve or modify data on the device (apart from erasing it, which of course counts as “modifying” it in the strictest sense.) Second, the attack depends on use of a self-signed certificate. Self-signed certificates are installed and used by Exchange 2007, 2010, and 2013 by default, but Microsoft doesn’t recommend their use for mobile device sync (see the 2nd paragraph here); contrary to Hannay’s claim in the paper, my experience has been that relatively few Exchange sites depend on self-signed certs.
The third thing I want to highlight: this is an interesting result and I’m sure that the EAS team is studying it closely to ensure that the future attacks Hannay contemplates, like stealing data off the device, are rendered impossible. There’s no current cause for worry.
The basis of this attack is that EAS provides a policy update mechanism that allows the server to push an updated security policy to the device when the policy changes. There are 3 cases when the EAS Provision command can be issued by the server:
- when the client contacts the server for the first time. In this case, the client should pull the policy and apply it. (I vaguely remember that iOS devices prompt the user to accept the policy, but Windows Phone devices don’t.)
- when the policy changes on the server, in which case the server returns a response indicating that the client needs to issue another Provision command to get the update.
- when the server tells the device to perform a remote wipe.
The client sends a policy key with each command it sends to the server, so the server always knows what version of the policy the device has; that’s how it knows when to send back the response indicating that the device should reprovision.
If the client doesn’t have a policy, or if the policy has changed on the server, the client policy key won’t match the current server policy key, so the server sends back a response indicating that the client must reprovision before the server will talk to it.
There seems to be a flaw in Hannay’s paper, though.
The mechanism he describes in the paper is that used by EAS 12.0 and 12.1, as shipped in Exchange 2007. In that version of EAS, the server returns a custom HTTP error, 449, to tell the device to get a new policy. A man-in-the-middle attack in this configuration is simple: set up a rogue server that pretends to be the victim’s Exchange server, using a self-signed certificate, then when any EAS device attempts to connect, send back HTTP 449. The client will then request reprovisioning, at which time the MITM device sends back a remote wipe command.
Newer versions of Exchange return an error code in the EAS message itself; the device, upon seeing this code, will attempt to reprovision. (The list of possible error codes is in the section “When should a client provision?” in this excellent MSDN article). I think this behavior would be harder to spoof, since the error code is returned as part of an existing EAS conversation.
In addition, there’s the whole question of version negotiation. I haven’t tested it, but I assume that most EAS devices are happy to use EAS 12.1. I don’t know of any clients that allow you to specify that you only want to use a particular version of EAS. It’s also not clear to me what would happen if you send a device using EAS 14.x (and thus expecting to see the policy status element) the HTTP 449 error.
Having said all that, this is still a pretty interesting result. It points to the need for better certificate-management behavior on the devices, since Hannay points out that Android and iOS devices behaved poorly in his tests. Windows Phone seems to do a better job of handling unexpected certificate changes, although it’s also the hardest of the 3 platforms to deal with from a perspective of installing and managing legitimate certificates.
More broadly, Hannay’s result points out a fundamental flaw in the way all of these devices interact with EAS, one that I’ve mentioned before: the granularity of data storage on these devices is poor. A remote-wipe request from a single Exchange account on the device arguably shouldn’t wipe out data that didn’t come from that server. The current state of client implementations is that they erase the entire device– apps, data, and all– upon receiving a remote wipe command. This is probably what you want if your device is lost or stolen (i.e. you don’t want the thief to be able to access your personal or company data), but when you leave a company you probably don’t want them wiping your entire device. This is an area where I hope for, and expect, improvement on the part of EAS client implementers.
As some of my readers may know, California is nominally where I live; however, I’ve been in Pensacola since October. California, of course, has the distinction of having extremely restrictive gun laws. Needless to say, these laws have done little or nothing to reduce gun-related crime. They do, however, make it difficult or impossible for law-abiding citizens to exercise the same rights and freedoms that citizens of other states take for granted. (But at least it’s not as bad in California as it is in DC; check out Emily Miller’s Washington Times series on DC gun ownership to see what I mean.)
(nb. This would be a good time to mention that I’m not interested in debating any aspect of firearms law. I believe that as a law-abiding citizen I have the constituionally-protected right to keep and bear arms, and that that right properly includes the ability to carry a weapon on my person for self-defense, whether or not I face an imminent threat like a crazed ex-spouse. I don’t think that criminals or the mentally ill should have guns.. but criminals get them anyway, even in places like California and DC. Feel free to disagree with me, but do it someplace else.)
Anyway, one side effect of California’s laws is that it is difficult, or impossible, to get a permit to legally carry a concealed weapon in California. Each individual county makes its own rules, and larger counties, like Santa Clara County, just flat-out won’t issue permits. (Unless you donate thousands of dollars to the sheriff’s re-election campaign. But I digress.)
However, Florida and Utah offer permits to non-residents. If you meet the legal requirements to obtain a Florida or Utah permit, you can then use that permit to legally carry a concealed weapon in the 38 or so states that have reciprocity agreements with Florida and/or Utah. That means that a Florida non-resident permit will allow the holder to legally carry in Alabama, Louisiana, Mississippi, Tennessee, Texas, and Washington– all places I travel. Of course, in each state the permit holder still has to obey the laws of that state, which vary from place to place.
Florida and Utah both require a class that covers the legal and safety aspects of concealed carry. The interesting thing is that one can become certified as an instructor qualified to teach this class, then offer it out of state. I’d been trying (though not very hard) to find a convenient class in the Bay Area, but hadn’t managed to do so before I came out to Pensacola. After Christmas, I decided to resume my search and called around to a couple of local gun shops. I quickly got the word that I needed to talk to “Captain Ron.”
“Captain Ron” is actually Ron Beermünder, who runs the Blackwater River Tactical Range. His web site contains a wealth of information on Florida’s CCW law, as well as information about the classes he teaches. I opted for the 4-hour course; for $180, you get the legal instruction that Florida requires plus the chance to shoot 300 rounds of various-caliber pistol ammunition while being coached by an expert instructor. What’s not to like? I signed up, and this past week drove out to Ron’s range to take the class.
The class itself was excellent. Ron is an engaging and funny man, with a sharp sense of humor and a large chest of war stories. We spent about 90 minutes on the legal overview; simply put, in Florida the law is that a CCW permit holder is essentially held to the same standard as a police officer when it comes to use of force. If a police officer would be justified in using deadly force to prevent or stop a crime, so too would a CCW holder, but neither a citizen nor a cop is allowed to use unreasonable or excessive force. That strikes me as a reasonable standard, and it’s easy to keep in mind. Other details we covered include what Florida law says about where you may and may not carry, under what conditions you may use deadly force, and the fact that just because the law says you can stand your ground in the face of a threat doesn’t mean you should.
The range portion was equally good. Ron had a wide variety of pistols; I shot Smith and Wesson revolvers in .22 and .22 Magnum and Glock pistols in 9mm (including the Glock 26, which is what I’d normally be carrying.) We did timed-fire drills, and I learned a great deal about trigger manipulation and indexing. My accuracy and speed both improved quite a bit during our time on the range, and I’m looking forward to getting some more practice when my schedule allows. If nothing else, I learned that the Glock has a reset trigger and how to properly use it; that tip alone made a huge difference in my second-shot accuracy.
The actual mechanics of getting the permit are straightforward if you qualify: once you’ve completed the class, you need to provide the state proof that you completed it, a registration fee, and fingerprints. You can do this via mail, but it takes up to 3 months to get your permit back. Ron suggested driving to the nearest regional office of the Department of Agriculture and Consumer Services and applying in person. (Yes, I did say “Agriculture.”) Thus I found myself driving to Fort Walton Beach in search of the nearest office; there are only 8 throughout the entire state. I had previously made an appointment, and when the appointment time arrived I filled out an on-screen form, gave the clerk a copy of my certificate from Ron’s school, had my fingerprints scanned, wrote a check for $117, and had my application notarized. 20 minutes later, I was done; now all I have to do is wait for my permit to arrive in the mail! (I should note that I have never dealt with state government employees as pleasant, efficient, or helpful as the folks at the FWB licensing office. I wish they could export their attitude to the California DMV!) Once my permit arrives, it will be valid for seven years from the date of issuance.
This is all of course rendered moot by the fact that a) I work on a military base where no one is allowed to have personal weapons and b) all my pistols are in California, not to mention that c) I can’t legally carry in California anyway. If nothing else, I’m glad to have contributed to the numbers of law-abiding CCW permit holders. There are more of us out there than you think.
You may know that Symantec recently admitted that its network was compromised and that the attackers got the source code to pcAnywhere, Norton Internet Security, and a few other products. Buried in their acknowledgement, however, was the fact that the source code leaked in 2006 and has thus been floating around in the community for quite a while.
Jonathan Shapiro’s response on the IP list seemed to hit the right note for me:
The pcAnywhere source code leaked in 2006, and in all that time nobody thought to do a serious security review to assess the customer exposure that this created? And now after five years in which a responsible software process would have addressed these issues as a matter of routine, they are having people turn the product off?
This is the company that ships the anti-virus and firewall software that you are probably relying on right now. A version of which, by the way, has also leaked. Do you want to be running security software – or indeed any software – from a company that fails to promptly report critical vulnerabilities when they occur and then ignores them for five years?
You can argue about whether Microsoft’s disclosure policy is perfect or not. I cannot, however, imagine a circumstance in which Microsoft became aware of a potential vulnerability and then didn’t fix it for five years.
So: if you’re running Symantec security software on your personal machine, your company’s workstations, or your servers… time to get rid of it and replace it with software from a more responsible (and, one hopes, more security-conscious) vendor.