Question for the nerds: do you think strictly from a hacker and red team perspective that if a firmware has shotty hash verification flaw in the past and it cannot be confirmed if it was patched, do you think this could be abused to push a malicious update or firmware?

#infosec #hacking #firmware #redteam

@alex02 Schrödinger's patching. From the attackers point of view it isn't patched until they try an attack and it has been patched. From the defender's point of view it has been fully patched until the day you tell the CFO, then you'll find out it isn't patched and has now been exploited by the attacker.

@alex02 That's a vague hypothetical, so with that in mind: hypothetically, yes.

The practical ramifications depend on a whole host of details: how bad was the flaw (were they using CRC as a "hash" or were they truncating the last 3 bytes of a SHA-512)? How accessible is the firmware update mechanism (local JTAG only? OTA via HTTPS? OTA via HTTP?) What is your threat model (first-tier nation states who will spend billions to target you? Large cybercrime syndicates? Casual drive-by ransomware?)

Just because a flaw exists, doesn't mean exploitation of that flaw is practical... and the definition of practical varies depending on who's doing the attacking.

@alex02 But to answerish your question, if it has been fixed in a later update and the update has been applied then you should be fine, assuming no other vulnerabilities or issues with the updates to the hash checking. If it hasn't been patched then there could be an issue if it is literally checking a MD5 (Or SHA1?) checksum.
@alex02 If there is signing and it has been implemented properly and the signature covers the whole of the update file(s) and the vendor CI/CD system hasn't been compromised and keys haven't been leaked, then it might be fine :) Oh, and if they used standard signing with OpenSSL or similar and didn't roll their own.