Security Flaw in an Apple Product? – Surely You Jest

0 | February 17th, 2010 | Posted in Device Management, Mobility Rant

I’m not the only one taking a look at provisioning the iPhone. My focus was to show it working though, and not a complete analysis of the low-level details. Good thing someone else did then :)

Heading over to http://cryptopath.wordpress.com/2010/01/29/iphone-certificate-flaws/ you can see that there are a few things that aren’t perfect with how Apple implemented settings provisioning. The reason I’m mentioning it here is that not only did I find the article quite interesting, but I also took my time commenting the article, and thought I’d maybe elaborate some points further here.

Apple has not implemented provisioning and SCEP in a proper way – we can probably agree upon that right off the bat. I have not tested all the variations of signed/unsigned/verified/unverified/etc. When I tested provisioning a signed profile, from an unverified source (I signed with a certificate from my own CA, which is not in the trusted store), the profile did not install without also doing a SCEP enrollment to the CA. (So if you had malicious intent you’d also have to setup a CA.) The behavior might be slightly different with a trusted signer. But the attack itself with signing up for trial Verisign certificates has the classic elements of social engineering as the working element nonetheless. If your users blindly accept provisioning profiles you have a problem regardless of how/when Apple fixes their implementation.

While part of me wants to add this to the list “Why iPhones should not be used in the enterprise” that still does not satisfy all the customers/end-users/businesses screaming that they want to use the iPhone. I’m afraid it’s not a big enough showstopper to bring that to a halt. My recommendation would be to still evaluate using iPhones like the flaw didn’t exist. (Yes, you still have to consider the flaw, but it doesn’t detract from the functionality side of things.) You might still reject the iPhones based on other considerations, but that’s another discussion entirely.

The trust issue exists on other platforms too though. If I wanted to compromise a Windows Mobile I could send out an OMA CP message bootstrapping an OMA DM server, and if I put the name of the mobile operator in the “From” field I’m pretty sure I could fool a user or two into messing up their devices that way. Actually this would apply to other OMA DM devices too for that matter, not only Windows Mobile devices.

Symbian had an issue last year, (or was it the year before – I forget), where a malware publisher managed to get their application signed with a trusted root certificate. While I didn’t read a follow-up story detailing a major outbreak of the malware it certainly had potential to wreak havoc.

I don’t remember if it was on Windows XP, or Windows Vista, but in one of the yearly root CA updates Microsoft removed a bunch of CAs as it was way more than what would qualify as a handpicked list of especially trusted certificate authorities. So managing trust isn’t just a challenge in mobility.

I guess what I’m saying is that it’s “just yet another security flaw”. We see these every week on the desktop. We have procedures for handling them. The mobile devices are no different :)

And as much as I disapprove of some of Apple’s choices regarding functionality, vendor lock-in, etc they are doing the right thing by implementing provisioning for upping enterprise adoption rate. Let’s hope it’s a work in progress and that it does not stop here.

Sinking Our Teeth Into SCEP

0 | January 20th, 2010 | Posted in Coding, Device Management

In my last post I provided a very high-level overview of some of the certificate related services in Windows Server 2008 R2, and said I would be digging further into the material. Looking through the archives it seems I have been able to produce at least one article pr month since I started this site and it almost looked like I wouldn’t deliver this month. Well, December and January are always busy months, but I did find some spare time to look into SCEP, (Simple Certificate Enrollment Protocol), and thought this was a good time to bring some more details.

The quick recap first; SCEP is a protocol defined by Cisco for enrolling machine certificates. SCEP is implemented in Windows Server as Network Device Enrollment Service (NDES). iPhone uses SCEP for secure bootstrapping/provisioning, and maybe it could be relevant for other devices too.

As far as installation of the NDES role I would recommend the following white paper by MSFT:
http://www.microsoft.com/downloads/details.aspx?familyid=E11780DE-819F-40D7-8B8E-10845BC8D446&displaylang=en

Let’s get down to actually using it. SCEP is implemented as a dll file called mscep.dll which you can interact with through HTTP GET commands. There are a couple of different operations you can specify as the desired action. The first one is called “GetCACaps” which is used to retrieve what operations and behavior the server supports, but this operation is optional and as far as I can tell it is not implemented by Microsoft.

The next, which is supported, and not optional, is “GetCACert”. An example URL of this would be:
https://CA/certsrv/mscep/mscep.dll?operation=GetCACert&message=MobilityDojo
(You’ll notice I’ve attached a message parameter as well, but the message part of the URL can be any random text at this point.)

If doing this in a browser you’ll see a response in the form of a file called “mscep”. Save this as a p7b file, and you will have the entire certificate chain of the CA relating to NDES. If you have a single Root CA, and do a “next-next” install of the NDES role you will have three certificates in the chain; one for the Root CA, and two for the certificate request agents. image

Before moving on to the next step, let’s take a quick de-tour looking at how this setup works on a high level:
You have three URLs that work in your browser
http://CA/certsrv/mscep & http://CA/certsrv/mscep/mscep.dll which will both give you the same html output:
image

http://CA/certsrv/mscep_admin which gives some info for the admin who enrolls the device:
image

And following this these are the steps involved in an enrollment:
- Device generates a key pair (public and private).
- Admin logs on to the admin page in his browser, and retrieves the password.
- Device generates a certificate signing request (CSR), and sends off to the SCEP/NDES server.
- NDES sends the request to the CA. (This can be on the same server.)
- A response is received by the device containing the actual certificate.

It does sound easy doesn’t it. You generate a request, and if you have it in the form of a file it will be a long Base64-string like this (I left out most lines of the string to make the screenshot smaller):
image

And you submit it to the NDES service through the browser:
http://CA/certsrv/mscep/mscep.dll?operation=PKIMessage&Message=MIID9Q=
I’ve left out most of the string here too, but it’s really just copy & paste everything from the CSR file except the first and last lines. You’ll once again get a file called “mscep” back, but it’s not going to work saving it as pfx, cer, etc.

Checking out the Event Viewer on the CA we see something similar to this:
image

Ah, but thing is, when I said generate a CSR above I left out a couple of the finer details. You see, you’re not able to just go through the certificate request process in IIS or the Certificates MMC. As the error indicates you aren’t getting all the details embedded that you need for a SCEP request. I found a neat tool called “ASN.1 Editor” (ASN is the format for CSR files), and thought I would be able to handcraft the request with this utility. Then it occurred to me that generating a valid key pair in my head, using it for signing, and inputting it in the request probably is well above my mental capabilities :) Nonetheless it is a useful utility if you’re generating CSRs and want to “debug” these. (If you have a certificate you already have on file, you can look at that too.)
Hit the link for download: http://lipingshare.com/Asn1Editor

This leaves us to the programmatic approach, and I’d love to have given you all some finished C# code as the next step. I ran into a couple of challenges while testing this though – the first being that support for crypto stuff is so-so in C#, barely present in Compact Framework, and dependent on the OS on the desktop side. Realistically you need to run it on Windows Server 2008/Vista or Windows 7. While I certainly have access to those platforms, and it is workable with some dll imports, it gave me a couple of pointers to where this had to be taken for building a proper solution, but not the solution itself. I initially thought that a client on Windows Mobile was feasible, but maybe it’s more work than it’s worth. You’d also have to go through all the same obstacles implementing it for the Android if that became a feature request, and you’d still have to adapt in some way if using it on the iPhone. (The iPhone already has native support courtesy of Apple Inc. mind you – I’ll get back to that.)

I’ll also admit that learning the crypto APIs required for this was more than I could chew through in an hour. I’ve managed to create a CSR programmatically and getting the same error as above, and I’ve managed to put together a request that crashes the program entirely when running. Basically I have to learn it proper if I want to get it working, and that’s probably an exercise better left for later on when I see a greater need for it. At the moment it’s more of a nice-to-have than need-to-have for what I do. (Man, I felt stupid trying to guess my way to something that would work.)

If you want the “algorithm” it works roughly like this:
Create a PKCS#10 request, wrap it in a PKCS#7 request with a couple of extra attributes (senderNonce, TransactionID, MessageType). Sign this with the public key from the certificate of the RA and submit.

If you want the gory details there’s no way to avoid reading the RFC:
http://tools.ietf.org/html/draft-nourse-scep-20
And this paper is also of great help:
http://www.gamingstandards.com/…/appendix_d_scep_operations.htm

So, let’s say for the sake of discussion that we have solved the coding issues – what would we do next? I’d probably start by removing one more obstacle on the server side. The default install of the NDES role on the CA will require you to use one-time passwords (remember the admin web page?). While this is a good secure by default implementation I find it slightly impractical  for our purposes, so let’s disable it. Navigate to regedit on your CA, and flip the following registry key to 0 (if it doesn’t exist create a DWORD value):
HKLM\Software\Microsoft\Cryptography\MSCEP\EnforcePassword\EnforcePassword

So, the iPhone works you say…How did I solve that since I didn’t see the coding through to the bitter end? Well, I resorted to “cheating” actually :) I installed the latest Feature Pack for an Afaria Server I’ve got running, since this adds iPhone support. The funny thing is that the technical approach I was evaluating was/is very similar to what Sybase have done. I’m not going into the details of the Sybase implementation as some elements are only relevant for the iPhone, and not SCEP enrollment in general, but it basically starts with an SMS sent to the device to trigger the enrollment process. The device generates a request, sends this to a provisioning server, and the server signs this request before passing it onto the CA. The iPhone picks up the generated certificate by talking to the CA directly though, and doesn’t do everything through the provisioning server. (I’m not entirely sure as to when the communication end-points are switched.)

What I’m thinking is that it should be possible to channel everything through a proxy web service so you don’t have to expose the CA directly to the Internet. (Yes, I am aware of a reverse proxy like ISA Server, but not published at all is even better.) This web service could also handle requests from both clients able to generate the actual request themselves, and clients who has to make do with a “light” request and have the server do the rest.

Eventually you should end up with a certificate on your device, and your CA will have it on record if you get it right:
image
Notice how the common name does not easily identify the device.

So, great, another certificate on the device. What to do with it? The iPhone uses it for signing of the provisioning profiles you send to it. You can lock down the iPhone with security policies – like enforcing Power-on-Password, removing YouTube/Camera/AppStore, and the user will not be able to remove it.

While I haven’t investigated it further I believe it should be possible to enforce restrictions like only allowing devices with the proper device certificate to access ActiveSync – while still allowing ActiveSync without the need for VPN tunnels and the like. Like so many other things – the technology is there and it’s up to you to find a use for it :)

Certificates – A Minor Technology Update

0 | December 3rd, 2009 | Posted in Coding, Device Management, Mobility Rant

A couple of weeks ago I performed an upgrade of my LAN at home. A trusty old Pentium 4 that had been doing it’s duties as a Windows Server 2003 domain controller showed signs of old age, and kept locking up at an increasing rate. I’m guessing that the hard drives, and possibly a couple of the fans had started to take enough of the abuse :) Trying to fix it wouldn’t make sense economically, and while I’ve spare parts and computers with similar specs I wanted to go 64-bit. It all ended up in me re-installing two low-end PowerEdge tower servers running Windows Server 2008 to 2008 R2. The improvements in Hyper-V was one of the reasons, but while at it I thought it would be a good idea to upgrade the domain controller too. (Note to others out there running Linux-based NAS boxes: don’t assume they like 2008 DCs just because they boast AD integration, and worked happily with 2003. Samba can bite my shiny metal ass…)

I haven’t actually upgraded the forest and domain level to 2008 yet, as most services will run with 2003 levels. I haven’t gone the whole nine yards transitioning to IPv6 either for that matter. What I have been taking a closer look at is Certificate Services. It’s been one of those components that have just been working for a long time out of the box, but the feature list said there were a couple of new bits to take note of. I’d like to provide a minor update based on a few things I have learned so far about them :)

Network Device Enrollment Service
The first “new” feature is NDES. (I say “new” because it was available previously as an add-on, but now it’s a native component of the OS.) NDES stands for Network Device Enrollment Service, also known as MSCEP, which is the Microsoft implementation of Cisco’s Simple Certificate Enrollment Protocol. The purpose of SCEP is to be able to enroll certificates to Cisco equipment like routers and switches, but it is open for others to implement too. A common feature of network equipment is that you cannot always enroll certificates the same way you do with a desktop or server – often the component cannot access the CA directly through a graphical user interface, and since you don’t like moving private keys around you don’t want to be copying pfx files around either you need a different enrollment mechanism. So basically, you “assist” the device by creating a sort of pre-enrollment request, and let the rest work itself out automagically. (Of course this is over-simplifying, but hopefully you understand what I’m getting at.)

How nice, but why are you telling us this? Do we care about Cisco in this context? No, possibly not, but we do care about the iPhone. And while it’s still a love/hate thing for many IT people the iPhone is unavoidable in more and more enterprises. As much Steve Jobs possibly classifies as a megalomaniac, the man understands that to progress further with this device in the enterprise, Apple needs to add enterprise features. The 3GS sports encryption, and the latest incarnation of the OS also supports client certificate based ActiveSync and all sorts of things. And even better, they’re taking steps towards manageability providing options for bootstrapping devices through the iPhone Configuration Utility. For a single-user scenario this tool works nicely, but you don’t want to use this en masse for deploying a large number of devices. And you don’t have too – you can create xml that can be send over-the-air much like OMA DM on Nokia devices. Based on this Good Technology has support for the iPhone in their product, and Afaria from Sybase hopefully has support coming during December if there isn’t an unexpected showstopper.

The profile can be pushed as mandatory, so the user cannot uninstall it. To accomplish this the profile is signed/encrypted with a certificate, and – you guessed it. This certificate is enrolled via SCEP. Unfortunately I do not have any slick screenshots at the moment showing how this works, but do have a look at the docs from Apple to learn more:
http://images.apple.com/iphone/business/docs/iPhone_OTA_Enrollment_Configuration.pdf

SCEP is implemented as an ISAPI plug-in in IIS, and you interface with it through HTTP POST/GET. If you want to test that it’s all working enter the following URL in your browser:
https://CA/certsrv/mscep/mscep.dll?operation=GetCACert&message=MobilityDojo
(The message part of the URL can be any random text at this point.)
You’ll be rewarded with a file called “mscep” that contains the certificate of the CA in a binary form.

To actually enroll for a certificate you need to prepare a request device side, and depending on the configuration you might need to acquire a one-time-password as well. I’m testing out how this works in a Windows Mobile context, (I don’t develop for the iPhone), so I haven’t worked out all the low level bits yet. Hoping to present something at a later time.

Certificate Enrollment Web Services
The other new feature in 2008 R2, that actually is new and not re-cycled, is Certificate Enrollment Web Services. While there’s been a web interface for enrolling certificates it has required ActiveX, needed the site to be trusted, notoriously difficult using programmatically, not really supporting mobile devices…well… a few shortcomings. But everybody loves Web Services, and it has been created to simplify enrollment from non domain-joined computers and other platforms than Windows/Internet Explorer.

While my own DojoCert utility does what it’s supposed to do there are things I’d like to see better implemented. Problem is I’ve been limited as to what I can do in C# and the .Net Compact Framework. The native C++ APIs could probably produce something, but these are also intended for enrolling via LAN/WLAN. I’m not going into all the technical details here and now, as my early experiments shows you need to perform some tweaking to use it on mobile devices. (Not there quite yet, unfortunately.)

How does it work then?
Do yourself a favor if you are interested in this topic – read the following white paper from Microsoft. Should help you out in installing it on your CA.
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=28b910f8-6374-48dd-a897-11fff62ab795

The short version is – the client will ask the Enrollment Policy Web Service what templates are available, and what requirements these templates have. Based on this the client generates a certificate request, sends it off to the Enrollment Web Service, and a response is returned. Sounds ever so simple, I know, and provided I can get it working I believe it adds value as opposed to the simpler NDES scenario. (How simple it really is I do not know the extent of yet.)

NDES/SCEP are primarily intended for machine certificates, so in a scenario where you issue certificates to both devices and users you might decide to go for both, or just the web services.

I’m hard at work looking at both these two alternatives, and I hope to get something to work. Although you never know what kind of snags you run into. Will be posting more, if I find something worthwhile :)