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[1] (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[2]. 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.[3] 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[4]. 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.
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.[5] 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.
Suggested Reading
The Evolving Intersection of Mobile Computing and Authentication (subscription required)
Identity Bridges: Uniting Users and Applications Across the Hybrid Cloud (subscription required)
Source: Gartner Blog
