Examining Rockwell Automation’s Firmware Signatures

2018-09-27T21:58:00+00:00

Background

Industrial automation products have long been behind the curve when it comes to computer security. Default passwords, backdoor passwords, unpatched vulnerabilities, and network protocols with no authentication have been the norm for years. Rockwell Automation, one of the more established vendors in the market, took a significant step forward in 2015 by adopting signed firmwares.

According to a Rockwell Automation slide deck, firmware signatures were first introduced in their PowerFlex 750 series of variable frequency drives. The motivation for this change wasn’t computer security concerns, but rather compliance with nuclear non-proliferation treaties. According to the presentation, the Department of Commerce updated export regulations on variable frequency drives with output frequencies of 600Hz or greater. (ten or twelve times the frequency of the electrical grid) Rockwell Automation addressed this by capping the output frequency in a software update, so that the drives weren’t subject to harsher export restrictions. This change was paired with a new firmware signature mechanism, which would enforce that only firmware images authored by the manufacturer could be flashed onto devices. Following this feature’s development for the PowerFlex 750 line, firmware signatures were rolled out to most other product lines to improve their security.

Signed Firmware

Each firmware package consists of a configuration file (with extension .nvs) and one or more binary files. In a signed firmware package, half of the binary files that get flashed to the device are DER-encoded X.509 certificates, with a .der file extension. In a typical public key infrastructure, one would expect that an X.509 certificate would be used to identify a principal that makes signatures, but in this system, the certificate file acts as the firmware signature itself, with the help of some unusual vendor-specific extensions, described below.

Extensions

Each certificate file contains seven extensions, with OIDs 1.3.6.1.4.1.95.3.1 through 1.3.6.1.4.1.95.3.7. The prefix of 1.3.6.1.4.1 is assigned to private enterprises, and 1.3.6.1.4.1.95 in particular is assigned to Allen-Bradley, which is a division of Rockwell Automation. The extension with OID 1.3.6.1.4.1.95.3.1 is particularly interesting, because it contains a BIT STRING of the SHA-1 hash of the corresponding firmware image.

Extensions 1.3.6.1.4.1.95.3.2 through 1.3.6.1.4.1.95.3.6 hold INTEGERs which might be related to firmware versions, product identifiers, or other metadata. Extension 1.3.6.1.4.1.95.3.7 holds a BIT STRING of unknown purpose.

Subject and Issuer

The issuer name of each certificate is O=Rockwell Automation. The subject name of each certificate has an organizationName field of Rockwell Automation, and organizationalUnitName and commonName fields that vary by product.

Certificate Signature

Although the distinguished names of the subject and the issuer in each certificate are different, the public keys of the subject and the issuer are identical. From a chain building perspective, these are leaf certificates, but from a cryptographic perspective, these certificates are self-signed. This mismatch suggests that the certificates aren’t being used in a traditional PKI, and the bootloader isn’t building a chain of certificates back to a root certificate when it verifies firmware signatures.

Tools for Certificate Signatures

The subject’s public key is encoded directly in the certificate body, but the issuer’s public key does not appear anywhere in an X.509 certificate, as it’s assumed to be known beforehand. However, the signature over the to-be-signed portion of the certificate is made with the issuer’s public key, so we can guess that the issuer’s public key is the same as the subject’s public key, try to verify the signature, and check if our guess was correct or not. I wrote a Python script to parse certificates and perform this verification and posted it as a gist.

If we hadn’t guessed that the certificates were self signed, we could have used a more generic approach to recover the issuer’s public key from any two certificates it signed. If we make a guess for the public exponent, raise each signature to the power of the public exponent, and subtract each padded plaintext message from the result, then the resulting differences will be multiples of the public modulus. Next, we compute the greatest common divisor of the two differences, and then divide out any small factors from the greatest common divisor to get a candidate public modulus. Finally, we check if the signatures are valid using this public key to determine if our public modulus guess was correct. I wrote another Python script to perform this calculation and posted it as a gist too.

Algorithms

Unfortunately, the firmware signature certificate files use SHA-1 and 1024-bit RSA keys. Neither of these choices would pass muster in the Web PKI today, nor would either have been a best practice back in 2015. Nation-state attackers might take advantage of novel attacks to forge firmware signatures, like how the US and Israel used an attack on MD5 signatures to forge Windows Update certificates. I would recommend migrating to SHA-256 instead of SHA-1, and either 2048-bit RSA or ECDSA. Of course, firmwares built after such a migration would have to reject signatures by the 1024-bit RSA key and signatures that use SHA-1 for this to be effective.

Serial Number

The certificates appear to gave high-entropy serial numbers, which is good for security. About half of the certificates have a negative serial number, which isn’t allowed by the relevant RFCs. As a result, some tools may not work with half of these files.

Conclusion

Based on these observations, it seems that Rockwell Automation’s firmware signatures are the product of custom, proprietary tools. By including the hash of a firmware image in a certificate extension, they have repurposed X.509 certificates as a kind of detached signature with extra signed metadata. As far as I can tell, this signature scheme should be secure, but the outdated algorithms are concerning, and the reliance on self-signed certificates (with no way to provide a cross-signed certificate chain) will make key rotation difficult.

Solving Logic Puzzles with Z3

2018-09-19T00:15:00+00:00

I’ve been attending Puzzled Pint events for the past year or so with a group of friends. These events are akin to pub trivia, except with puzzles, and they’re great fun. Two months ago, one of the puzzles was a classic logic grid puzzle set in a game of Texas Hold ‘Em. The organizers rated this puzzle as the most difficult that month; it took some effort, but we did solve it without hints.

At the time, I had mused about wishing for a SAT/SMT solver to do the puzzle for me. “SAT” here refers to the Boolean satisfiability problem, which is one of the classic hard problems in computer science. In turn, “SMT” is Satisfiability modulo theories, a more versatile generalization of the Boolean satisfiability problem. SAT solvers and SMT solvers both apply deduction, heuristics, and brute force to a formula to either solve it, prove that it has no solutions, or give up on it. Due to the particular way that both the SAT problem and SMT problem are hard, there’s no general way to efficiently solve every formula, but modern solvers can get answers on a lot of practical problems. But what of problems with no practical application?

Later in the week, after Puzzled Pint, I sat down and re-solved the poker logic puzzle using Z3, an open source and freely available SMT solver by Microsoft. I’ve enjoyed playing around with Z3, and it’s the sort of hammer that can make everything look like a nail. Z3 uses an internal language that looks a lot like a LISP, which I’m given to understand is typical in the field. I used Z3’s Python library, which makes it easy to build Z3 expressions using function calls and normal mathematical operators.

Due to terminology differences between fields, Z3 uses the term “constant” instead of “variable” to refer to symbols like x and y in the formula 4 * x + 3 * y = 27. Also, Z3 uses the term “sort” to describe what kind of value each constant can hold. To model the problem statement, I used IntSort to track the order in which the players folded, and I defined new EnumSorts for non-numerical values like names. To tie the different values together, I defined functions that mapped player names to the values of their other properties. With this scaffolding in place, I translated each puzzle clue into constraint formulas, adding a new constant each time a clue mentioned an unknown player. I then ran the solver, printed out the results, added one more constraint to rule out that particular solution, and ran the solver again to confirm that the solution was unique.

I have posted the logic puzzle solver script in a gist, along with scripts for two more similar puzzles from other sources. Each script finds the answer in well under a second. To run these scripts, you’ll need Python 3 and the z3-python package installed. The same ideas should work on any logic puzzle, as long as the constraint formulas capture the precise meaning of each clue. Enjoy!

David Cook’s Blog