Three weeks since Adobe's initial disclosure on the third of October and the customer-count revision keeps moving in the wrong direction. The initial Adobe statement said approximately 2.9 million customer records had been exposed; by the seventeenth, Krebs and Hold Security had identified approximately 38 million records on the publicly-circulating breach archive; the revised number is going to settle higher still as the analysis continues. Plus the source-code component, which Adobe acknowledged separately and which includes Acrobat, ColdFusion, and (apparently) the Adobe Reader codebase. Plus customer credit-card data, encrypted but recoverable. The breach is, on present evidence, one of the larger consumer-data exposures of 2013, and the technical detail of how the exposure happened is operationally informative.
The customer-password angle is the part that has produced the most direct security-engineering reaction. Adobe stored customer passwords by encrypting them with 3DES in ECB mode — encrypted rather than hashed, which is the wrong operation, and ECB mode rather than CBC or CTR, which makes the encrypted output far more analysable than any sensible scheme would produce. The result is that the breach archive contains pairs of (encrypted-password, password-hint) for each user, and because ECB mode produces the same ciphertext for the same plaintext, users with the same password produce the same encrypted output. The breach archive is therefore amenable to dictionary-and-frequency analysis: passwords like "123456" appear thousands of times with the same encrypted output, and the password-hint field — which Adobe stored unencrypted — gives enough additional signal to recover the cleartext for many of the rest. Jeremi Gosney's analysis at Stricture Group of the top hundred recovered passwords is the cleanest single illustration of the failure mode I have seen this year. The structural lesson is the same one I wrote about for LinkedIn last year: "we encrypt passwords" is not, on its own, a credible security claim. The specific implementation is the part that matters, and the specific implementation Adobe used was wrong in three ways at once.
The source-code angle is the part that is going to take longer to assess. The leaked archive includes substantial portions of the Adobe Reader codebase, ColdFusion server code, and Acrobat. The Adobe Reader codebase is the part that interests me operationally; Adobe Reader is one of the most widely-deployed pieces of software on the public internet, has had a history of substantial vulnerabilities (the 2009-2010 PDF zero-day window was substantial), and is exactly the kind of attack surface that a determined attacker with source-code access can find vulnerabilities in much faster than they otherwise would. The implication for the Reader install base over the coming year is going to be that the rate of disclosed vulnerabilities will be elevated; the rate of weaponised exploitation against those vulnerabilities will, on present evidence from the Java-zero-day cycle I wrote about last year, follow within weeks. Operators with substantial Reader exposure should be planning patch-management infrastructure that can keep pace with what is likely to be a difficult twelve months for Reader.
The credit-card angle is operationally familiar. Adobe stored customer credit-card data encrypted, with the encryption keys held in the same general infrastructure that the encrypted data sat on. The breach exfiltrated both the encrypted data and the keys; the cards are recoverable. This is the same pattern as Heartland in 2009 and several other public-disclosure breaches I have written about over the past five years; it is the pattern I have been writing pen-test reports about for nearly a decade. The structural answer is that credit-card data should not be stored at all where the operator is not the issuing bank, that PCI-DSS tokenisation is the standard answer for cases where some persistent reference is genuinely needed, and that Adobe's storage decision should have been changed years ago. It was not. The breach is the cost.
For the engagements I run, the Adobe breach is producing two specific conversations. The first is with the Browne Jacobson IT team, who have substantial Adobe Acrobat deployment and are now asking about the operational risk of being on a Reader codebase whose source is in attacker hands. The honest answer is that the risk is real and that the patching-cadence discipline matters more than it did six weeks ago. The second is with the Hedgehog SOC detection team, who are adding Adobe-Reader-exploitation indicators to the detection content. The signatures for the most recently-disclosed Reader vulnerabilities are well-documented; what we are watching for is the next-up batch as they emerge.
The wider point I want to write down — the one that connects this to BULLRUN and the broader Snowden material — is that the trust chain in commercial software is materially weaker than the controls frameworks have been pretending. The infrastructure of widely-deployed commercial software runs on the implicit assumption that the source code will not leak, that the build infrastructure cannot be compromised, that the standards underlying the security primitives are honestly chosen. None of those assumptions has held up to scrutiny in 2013. Adobe is the consumer-data version of the same structural failure. The security-engineering response is the same response: assume that the trust chain is contested, and design defensive infrastructure to be robust against compromise of any single layer in the chain.
The next post is probably either the continued Snowden disclosures, the Target breach if the rumours of a major US retail breach in the coming weeks turn out to be substantive, or the long-form piece on commercial security and state surveillance that I have been promising for two months and that is now substantially ready for publication.