Digital Certificates in Microsoft Windows can be set to have a non-exportable private key so that they cannot be copied from the key store and installed on another device. This is common practice in corporate WiFi installations with certificate based authentication.
Author: THOMAS CANNON
Source: Hakin9 3/2009 https://hakin9.org
Demonstrating how to bypass this control provides us with a good example of how reverse engineering can break client side security wide open. When we design infrastructure we strive to ensure that the solution contains the appropriate security controls to protect the confidentiality, integrity and availability of the systems and data. When considering the appropriate use of controls we have to understand their inherent risks. It is always good to remind ourselves of how controls can be broken and that we should aim, where necessary, to design systems whereby the failure of a single security control doesn’t compromise the entire system. In this article we will run through a typical corporate scenario and show how we can quickly break one of the security controls with some reverse engineering. Rather than print pages and pages of disassembly we’ll take it at a pace where you can see the general approach and understand quickly the concepts involved.
A company has a WiFi solution with seamless authentication for their Windows XP user base by way of a user certificate installed on each laptop. The user’s certificate is automatically deployed to their laptop from the certificate provisioning server, once installed the laptop can automatically connect to the WiFi which gives them access to the corporate LAN. No checks are performed to identify that the connecting device is a legitimate company asset as certificates are installed only on company laptops by the provisioning server and the private key marked as non-exportable.
Either a user or attacker makes a copy of a certificate (complete with private key) and installs it on another machine giving them full remote access to the company network from a rogue device.
The theory is this: The Operating System (Windows XP in this case) does not let you export the private key of a certificate if it is marked as non-exportable. However, the OS must have access to read the private key in order to use it for signing and encrypting. If the OS can access the private key and we control the OS, then we can also access the private key.
The first step is to get a certificate to experiment with. To view the certificates run mmc to launch the Management Console and load the certificates Snap-in. For this example we will just manage the certificates for My user account.Comments
Please keep in mind that comments are moderated and
rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or it will be deleted. Let us have a personal and meaningful conversation instead.
You must be logged in to post a comment.