There is much to write about the disclosure of vulnerabilities in X509, independently found by Moxie Marlinspike and Dan Kaminsky. There was some overlap in their discoveries, but also unique aspects. One worth highlighting is Moxie’s attack on defeating OCSP with a single byte.

Online Certificate Status Protocol attempts to verify the validity of web site certificates by contacting an OCSP responder, operated by the certification authority (CA) and asking the question “is the certificate with serial number #123 still valid?” This is one of two approaches to doing revocation checks– the Achilles heel of PKI. The other option is CRLs or certificate revocation lists. In that model the CA publishes a list of revoked certificates periodically and client download these (hopefully in advance, so that by the time you have to check it is locally cached) and look for the certificate in question there.

Now since the revocation status of a certificate is critical bit of information, the answer from the CA, whether packaged into a CRL or generated on-demand in response to an OCSP ping, has to be somehow protected. Otherwise the bad guys– on top of having obtained a bogus certificate and private key– can simply forge a response to suggest that all is well with the certificate.

It’s tempting to say “download the CRL / run the OCSP check over SSL” but that would create a circularity for boot-strapping. Not to mention that SSL is a very expensive solution to the problem of content integrity. Instead CRLs and OCSP responses are digitally signed, typically by another certificate that chains up to the issuing root CA.

Now if that had been the entire story revocation checking would be sound.

But Moxie noticed that by design OCSP allows unauthenticated responses, namely the set of responses collectively dubbed non-authoritative. This includes conditions such as an internal error with the service, malformed request  and “try again,” suggesting that the server might be overwhelmed with demand at the moment. These replies do not require a signature– by design. It’s in the RFC. In these cases a single byte indicating the response status is a valid OCSP response.

Of course this defeats one important security guarantee: when a non-authoritative response is received, the client can never be sure if it came from the OCSP responder. An attacker pulling of a man-in-the-middle attack could always forge one of these respones. Granted such an attacker could also drop the traffic and make it appear that the OCSP responder has vanished from the surface of the Earth. The bottom line is that in the absence of a signed response, client can not make any conclusions about the status of the certificate.

Of course implementations of OCSP must deal with this condition. They need to report what went on, and the buck stops somewhere along the application stack, where one developer decides what to do with these non-authoritative error codes.

Moxie’s discovery is for both Windows CAPI and NSS, that decision is to treat the “Try Again” response with code 3 as a successful revocation check. That means IE and Chrome (built on top of CAPI) and Firefox (built on top of NSS) are trivially confused in OCSP checks… with a one-byte response containing “3.”  Neatly summed up by one of the money slides in the presentation: a giant three interposed over the OCSP RFC.

Granted this is not the entire story: starting with Vista there is a complex revocation checking logic in CAPI that will load-balance between OCSP and downloading CRLs. CRLs are more efficient at scale: If every user in the world started hammering Verisign’s OCSP responder for every SSL request, Verisign would fall over in a matter of seconds. But they are highly inefficient in the short-term: in order to check the status of a single certififcate, the client is tasked with downloading a massive document, in the middle of setting up a connection. Vista tries to solve this problem by looking for frequent revocation checks and scheduling CRL downloads for them. Once a non-expired CRL has been downloaded, in principle the OCSP check is not required because looking at the locally cached document is faster and will reveal the revoked status of the certificate. In other words there may be edge cases to the Moxie attack where it stops working, depending on the past history of revocation checks.

Still a remarkable way to cap off a  series of attacks against X509 parsing.

cemp

The arrest of a disgruntled programmer trying to walk away with code for automated trading at Goldman Sachs raises questions about the value of intellectual property and challenges in protecting it.

First Goldman Sachs got very lucky in this case because the attempted theft was a case of amateur hour gone awry. The programmer may have been motivated and even knowledgable on quantitative modelling but clearly he was no security expert. The choice of exfiltration tactic, attempting to upload source code to a Germany, could have been easily detected by monitoring at the network perimeter or even internal machines. No doubt vendors specializing in the latest brand of snake oil, data-leak prevention or DLP, will capitalize on this opportunity for free advertising. But DLP is a case of we-catch-the-incompetent-ones. It is not possible to look at a stream of bits leaving the company network and decide if they correspond to intellectual property or harmless personal browsing. Techniques such as steganography make it possible to hide messages inside other, innocuous seeming messages that provide cover.

The second point is more disturbing: what was the corrupt insider  planning to do with the source code? How would he capitalize on the IP theft? Is he planning to set up his own trading system? Or is he planning to sell the code to another firm?

First option seems very likely. The latest trend in automated trading systems is high-frequency trading. Decision time between discovering market prices and placing trade order is on the order milliseconds here. In fact the servers are often  co-located near the exchanges themselves in order to reduce latency from order placement to execution. While the trades each earn small amount of revenue, but the ability to repeat this thousands of times for each market inefficiency allows quant hedge-funds to generate steady revenues. What all this means for potential disgrunted employees: it would be almost impossible for one individual working out of a basement or a bunch of guys sitting around Bloomberg terminals to capitalize on knowledge of the models. Even if they could predict the exact positions the model would take, the chances of front-running it are slim to none. Even given same speed, without massive capital to spread between thousands of trades, it simply would not scale enough to present a threat.

Since the speeds here are too high for human reaction times, the next option is to selling the software to another company with an existing system for low-latency trading in place. This is where a different problem emerges: no respectable company would touch stolen IP. Especially not one with deep pockets and an already viable line of business. The potential liability, both in lost revenue from the likely fines and direct personal culpability of senior ranking executives would all but guarantee that no serious player will take the risk. (Granted the case of Bernie “Made-off” Madoff provides evidence that highly dishonest operations exist in this space.)

Most likely option for monetizing such stolen IP then is a combination of individual risk and plausible deniability for a major competitor. The aspiring crook pretends that he/she came up with the trading strategy on his/her own (or perhaps the inverse strategy, since front-running is going to be a challenge, they can instead attempt to take the exact opposite positions.) The new employer is pleasantly surprised that the strategy is generating handsome returns, and appropriately rewards the brilliant quant, while HR departments pats themselves on the back for a great hiring decision. This is a case where the new employer may not be motivated to ask questions about the unexpected success.

One final aspect is that even in the absence of any reasonable way to monetize the stolen software, Goldman Sachs would be wise to give up on that particular model. The possibility itself that others may have studied the model and derived their own conclusions from it is enough to cast doubts on its future effectiveness.

cemp