One of the techniques demonstrated during the BlackHat/DefCon talk I gave with RSnake was utilizing client-side certificates. Client-side certificates allow for a client to gain a certain amount of trust for the server in which they are connecting. They are used by companies that don’t want to worry about using tokens, so instead they use client-side certificates. Client-side certificates are also used by several sslvpn devices.
To demonstrate client-side certificates, I first needed to create a few certificates so the client could connect to the server.
Using openssl, I created the certificate:
openssl req \
-x509 -nodes -days 365 \
-newkey rsa:1024 -keyout mycert.pem -out mycert.pem
Next, I needed to setup the server to use the certificate. I started thinking about he easiest way to accomplish this goal. It occurred to me that instead of using Apache, I should use the built-in webserver in openssl. This made setup easier, since I replaced Apache with a single command
Here is an example:
openssl s_server -accept 443 -cert mycert.pem -www -verify 10
Finally, I setup a client and verified that the browser contained a client-side certificate for ANOTHER server. Therefore, there is no trust relationship between the public key within the client’s browser and the openssl server. The key is the browser, will ask to send the public key everytime! The only thing an attacker needs to do, is to be listening on the wire and intercept the public key.
Now you may ask, “who cares about the information in a public key?” Well, client-side certificates can contain the following information:
- Email Address (perhaps a valid username)
- Hostname and maybe OS of the server
- Date the Certificate was Issued
- Date the Certificate Expires
Sometimes, the email address being used contains the user’s name. For example, many organizations standardize on a common email schema to construct email addresses. For example, they may use some variation of the first and last name of the employee.
Example:
- [firstname].[lastname]@domain.com
- [firstname]-[lastname]@domain.com
- [firstname]_lastname]@domain.com
If this is the case, an attacker can extract this information and now the attacker knows the user’s full name. For the purposes of achieving remote access, it is only a piece of the puzzle.
The next piece of information was the date the certificate expires. Since we know of a valid email, it is possible this is also a valid username for a network based attacks. Putting both the username and dates together means that the attacker has a greater likelihood for performing a successful attack.
Posted by Jabra 