Category Archives: Security

An offer for Tim Cook

[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,
-Paul

11 Comments

Filed under Security, UC&C

Skype automatic updates: in-app vs Microsoft Update

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…

Leave a comment

Filed under General Tech Stuff, Security

Man-in-the-middle attacks against Exchange ActiveSync

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.

1 Comment

Filed under Security, UC&C

Pistol-packing Paul: in which I get my Florida concealed-weapon permit

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.

1 Comment

Filed under General Stuff, Security

Don’t use Symantec security software

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.

 

1 Comment

Filed under FAIL, Security, Smackdown!, UC&C

1394, DMA, and BitLocker

The IEEE 1394 spec (also called FireWire by Apple and briefly, i.Link by our friends at Sony) specifies a high-speed interface for connecting peripherals. One of the reasons 1394 offers high speeds is that it supports the use of direct memory access, or DMA. Normally, when a peripheral device is performing I/O operations, the system CPU has to be involved. For example, to read a block of data from a disk drive, the CPU sends commands to the disk controller, then stores the resulting data into a block of system memory. (This is a somewhat simplistic description, I know, but it’s good enough for now.) That means that I/O operations could end up being CPU-bound, or they could negatively affect CPU performance.

To fix this some bright stars came up with the idea of DMA, which allows the peripheral controller to read from and write to system memory without the CPU’s involvement (and, often, without its knowledge or supervision.) Sounds neat, right? It is, but it also introduces a security threat: a malicious device can read valuable data out of memory… like, say, an encryption key.

The basic attack is simple: the attacker walks up to a BitLocker-protected computer, plugs in a custom 1394 device, and steals the key. (The details of how the attacker finds the key are interesting, but unimportant here.) Key in hand, the attacker can then decrypt the protected volume.

Not all BitLocker-protected machines are vulnerable to this particular attack. If you have a TPM, but are not using an additional authentication factor like a PIN or a USB token, this attack may succeed. However, even if you do use an extra authentication factor, if you leave your machine powered up or on standby, an attacker who gets physical access may be able to steal your BitLocker key.

This isn’t a huge threat for systems that are kept in physically secure locations, but it is worrisome for mobile users. That’s why the Data Encryption Toolkit that I helped write counsels you to be very careful about leaving portable computers powered on and unattended, and it spends some time going over the different security issues with standby, sleep, and hibernate modes. You should read it. Trust me, I’ve been to the doctor Smile

This is all a somewhat long-winded way of explaining that Microsoft has released a KB article describing how to turn off DMA for 1394 ports to reduce the threat of a DMA attack against BitLocker on TPM-only machines. The article, 2516445, describes how you can turn off the driver that provides DMA for 1394 devices. Given that very, very few Windows machines are ever connected to 1394 devices, this is probably something that you should implement if you have sensitive data on your BitLocker-protected machines.

If you’re not running BitLocker, well, why not?

1 Comment

Filed under Security

SecureDoc full-volume encryption for Mac OS X

Windows users have more security options, and that’s just the way it is. Or is it?

Let’s start with the obvious: I love BitLocker and I cannot lie. Despite its faults, it remains a great example of a real-world security feature that delivers immediate value. It’s fully supported by the OS manufacturer, meets government security standards, and doesn’t have to rely on skanky hacks to work its magic.

Windows laptop users can also take advantage of Seagate’s Momentus FDE line of disk drives. These disks, sometimes called self-encrypting disks or just SEDs, perform hardware encryption, and they are qualified by the US National Security Agency as meeting NSTISSP #11. Unfortunately, these drives require support in the BIOS. Since Apple’s laptops all use EFI instead of the standard x86/x64 BIOS, you can’t just plop a Momentus FDE into your Mac and expect it to work.

The only solution I’ve found to get an SED to work in a modern Mac laptop is from WinMagic. Their SecureDoc product is essentially a full-volume encryption tool that competes directly with BitLocker, as well as with other FVE products from PGP, PointSec, and so on. The big difference: the Mac version of SecureDoc supports Momentus FDE disks. Naturally I had to try it.

Installation is simple: you run an installer, which adds a couple of kernel drivers and modifies the boot loader. If (and only if) it detects an unlocked Momentus FDE as the boot volume, it will ask whether you want to use hardware or software encryption. (The installer also tells you that it will change the system’s hibernation mode, but let’s not get ahead of ourselves yet…)

When you’re done, you must reboot, at which point you see the new (and quite ugly) SecureDoc login screen. When you log in here, the SecureDoc bootloader unlocks the FDE disk and the normal Mac OS X boot cycle proceeds.

The docs ask that you turn off pagefile encryption by unchecking the "Use secure virtual memory" option in the General pane of the Security preferences tool. This makes sense: there’s no reason to ask the OS to encrypt the page file if the disk on which it lives is already encrypted. You must also turn off the "Put hard drive to sleep whenever possible" checkbox, as the OS doesn’t deal well with having the disk go to sleep (and thus get locked) while you’re using it.

In my test install, I ran into an odd problem: the machine would freeze when waking from sleep. The cursor and keyboard would work normally, but I’d get the spinning rainbow pizza of death. After doing some digging, and with the help of WinMagic’s tech support folks, I determined that the system’s hibernation mode wasn’t properly set by the installer. (Page 4 of this document is the only place I’ve found the different hibernation mode codes explained.) Uninstalling the SecureDoc software, manually setting the hibernation mode with the pmset tool, and reinstalling it fixed the problem and it has worked flawlessly since.

The standalone version of SecureDoc doesn’t have the same set of management or control features that BitLocker does. Of course, that’s because WinMagic wants you to buy their server-based toolset, which uses a group policy-like mechanism to enforce whatever encryption policies you choose. Without having tested either the server tool or the Windows version, I’m not ready to pick a winner between BitLocker and SecureDoc, but for the Mac it’s a low-impact solution that does what it says, and I’m happy with it so far.

Comments Off

Filed under General Tech Stuff, Security