Last week, US-CERT published a vulnerability note on the Simple Certificate Enrollment Protocol (SCEP). The vulnerability was reported by Certified Security Solutions, a consulting company with extensive Windows and PKI deployment experience. The company’s summary of the vulnerability is here. This vulnerability—when combined with two additional pieces of information—enables an attacker to impersonate another user when enrolling for an X.509 certificate.
We should care about the addressing the SCEP vulnerability because X.509 certificate usage is important stitching in the Bring Your Own Device (BYOD) fabric. SCEP is the de facto standard for certificate enrollment from mobile devices. Many organizations rely upon certificates for mobile access to the internal network, email, SharePoint, virtual desktops, web applications—you name it. The attacker can impersonate an authorized user and gain unauthorized access to these applications.
When examining the origins of this vulnerability, it’s helpful to trace the origins of SCEP. Before mobile device certificate enrollment was commonplace, enterprises leveraged SCEP as an easy way to install certificates on network devices on the internal network. The enrollment process had fewer actors and the identity of the device was easily vetted.
In the era of mobility, SCEP is used in a much more complicated ecosystem with untrusted devices at the source of the enrollment request.
The vulnerability appeals more to the insider, because two pieces of information are required to leverage the vulnerability. The first thing is the SCEP shared secret, which the certificate requester uses as a credential to authenticate to the certificate authority (CA) during the enrollment process. In the case of iOS (for example), a service distributes a profile containing the shared secret. The service is typically a mobile device management MDM solution, but it can also be a simple publishing mechanism. Upon receipt, the mobile device generates the key pair and requests the certificate via SCEP. The mobile device contacts the CA with the SCEP request. The CA authenticates the request via the shared secret and—voilà—the mobile device now has a certificate. The second piece of information needed is the distinguished name of a user object that is stored in the enterprise directory. The vulnerability enables the attacker to change the distinguished name in the SCEP request before enrolling for the certificate.
For short-term mitigation of the SCEP vulnerability, organizations should use unique shared secrets for each enrollment request. Frequently many organizations use the same shared secret for all of the devices, or worse fail to use the shared secret at all. Additionally, organizations should leverage an LDAP proxy service and/or a directory synchronization service in an effort to limit exposure of the directory, which would enable attackers to query for user distinguished names.
Moving forward, organizations need to perform better user proofing prior to certificate issuance. The best approach may be the use of MDM solutions from vendors including AirWatch, Good Technology, Fiberlink, MobileIron, and Zenprise. These products replace (or proxy) the SCEP enrollment process to prevent the switch of the distinguished name. Certified Security Solutions provides an alternative solution to via its SCEP Validation Service (read about how it works here, on page 7) that enforces the coupling of distinguished name to SCEP secret via a certificate authority plugin. The SCEP Validation Service can complement an MDM solution because it enforces shared secret-distinguished name integrity for device-based SCEP enrollment.
And while we are on the topic of mobile devices and PKI security, we should talk about the risk of an attacker exporting the private key from the mobile device. The export will enable the attacker to use the certificate independently of the device. Some mobile operating systems preclude this export, but I am more concerned about the ability to retrieve the key pair from a device backup. The NFC secure element (see my blog post) will mitigate export risks, but it increases the complexity of certificate distribution.
I will be talking about the SCEP vulnerability as part of my “Mobility and Identity: Getting It Right” talk at this year’s Catalyst. It will also be discussed in my upcoming research document on IAM capabilities in MDM products.
The Evolving Intersection of Mobile Computing and Authentication (subscription required)
Identity Bridges: Uniting Users and Applications Across the Hybrid Cloud (subscription required)
 For the purposes of clarity, I am not distinguishing between registration and certificate authority PKI components. For example, Microsoft has implemented SCEP in its Network Device Enrollment Service (NDES), which functions as a registration authority for the certificate authority (Microsoft Certificate Services).
 My document on Mobility and Authentication (subscription required) describes this setup in more detail.
 This is a high-level summary of the certificate enrollment process.
 These happen to be the vendors in the upper-right corner of Gartner’s latest Magic Quadrant. No doubt, there other MDM vendors that can help with certificate issuance, too.
 I am unaware of this attack in the wild. Yet.
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
Many thanks and kudos for raising this issue to a much wider audience! In our PKI services work, we have seen several cases where customers have stepped into security problems around SCEP without realizing they have done so. In some cases it’s a matter of avoiding insecure configurations; in others the very deployment of the product itself can lead to exposure.
We’ve created a blog with more information on the factors we examine to determine whether a given deployment and configuration is vulnerable, and if so, to what extent.