Dear Readers,
today we want to share a method on how to test an OCSP over HTTP validation service with Burp and some Python magic. First a little background about OCSP (Online Certificate Status Protocol): the main purpose of OCSP is to validate the status of an X.509 certificate.
The OCSP responder is the key part of the system. It is run by the certificate authority and responds with one of three possible different answers. The first one is “good”, which indicates that the certificate is not banned, “revoked” means that the certificate is banned, and “unknown” simply says that the status could not be determined, because the issuing CA of the Cert is not known to the responder.
For more details you might have a look at RFC 2560. During a recent pentest we developed a python script which generate valid X.509 certificates and connect to an OCSP Service. During those kind of tests it is very handy to have a script that will generate you a valid response, since it’s a pain to do it yourself every time.
In order to use this script, it is mandatory to install some required Python packages: “PyASN” for storing and exchanging data between the client and the OCSP Application, the “requests” packet for handling and building the http POST requests between the application and the Burp Proxy. All of those extensions can be installed within the easy_install python package manager. The settings part of the script is highly dependent on your setup: The url part is the location of the OCSP application service you want to test, and the Proxy part is the default Proxy Burp is listening for incoming requests. Once you have set your variables correctly you should be all set. The first thing you want to do is start your Burp Proxy and intercept all incoming requests on port 8080. If you have set everything properly, you will receive an incoming response similar to the one below:
POST http://yourhost.tld/ocsp HTTP/1.1
Host: yourhost.tld
Content-Length: 105
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: python-requests/2.7.0 CPython/2.7.6 Windows/7
Connection: keep-alive
Content-Type: application/ocsp-request
0g0e0>0<0:0 +
What you see here is the binary certificate request to the OCSP service. If you pass the request to the OCSP service, it will validate the certificate and send an answer such as:
HTTP/1.1 200 OK
Content-Type: application/ocsp-response
Date: Mon, 29 Jun 2015 18:22:10 GMT
X-Cache: MISS from
Via: 1.1
Connection: keep-alive
Content-Length: 5779
0‚Â
–Snip–
As it’s not easy to read or understand what the response is actually meaning 😉 we’ve implemented a decoder right in the script. If you look at the terminal, you will see the response located at the top and middle of the decoded payload.
certStatus=CertStatus:
unknown=
As shown above, the response of the application was “unknown” as of RFC2560. The “unknown” state indicates that the responder doesn’t know anything about the certificate being requested. If the OCSP service is correctly handling all the incoming requests, you should be able to modify the script and insert your own malicious certificates to be examined. If you want to have a closer look on the security implementation of the OCSP Service you have to look at the mechanism that validates your certificate. For example try to use a revoked certificate and see if the OCSP service still accepts it (which would of course constitute a vulnerability…). Another thing you want to look at is so-called OCSP stapling. OCSP stapling is an enhancement to the standard OCSP protocol which delivers OCSP responses from the server with the certificate, eliminating the need for relying parties (web users) to check OCSP responses with the issuing CA every time. This has the effect of reducing bandwidth, improving perceived site performance, and increasing security for everyone involved in establishing a secure session. Improving the service with stapling will also reduce the risk of Denial-of-Service. Furthermore keep in mind that the OCSP service is running a cryptographic signing hash over every certificate you provide to it. So with sufficient computing power of the Service-Operator it may be vulnerable to DoS attacks. If you are testing the service with burp try to evaluate how many OCSP requests can be performed simultaneously. At the same time, if possible, have a look on the OCSP Server and see how the average load of the server increases (or not).
To summarize there are quite some attack vectors against OCSP servers which have to be kept in mind when operating such a service.
Here’s the Python script we used, for testing: