Would this also affect macro signatures so that this can be used to make malware documents, or do macro signatures use a different signing mechanism?
Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
51–60 of 158 posts
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#52This smells a lot like the XML Signature Wrapping Attacks known to affect SAML. In essence, the attack fools the signature check into thinking that it's checking the signature of a different document than the one it's given.
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#53I discovered a related problem before, while integrating with an enterprise customer/partner. Some critical software they used was erroneously signing&validating the wrong part/extent of a very security-sensitive message.
I raised the issue on my company's end, and we had to explain to the customer/partner their big problem.
> On macOS, we could reveal a surprising result: although Microsoft Office indicates that the document is protected by a signature, the signature is not validated.
I wonder whether someone discovered the incorrect digital signatures approach while working with the code on the occasion of a MacOS port/implementation, slammed the brakes on that while escalating the issue internally, a decision was made to keep it quiet, and the MacOS implementation was shipped just stubbing out the signature validation behavior (or otherwise made to always claim validation OK)?
I wonder whether these broken digital signatures were exploited in the wild. Were forged invoices paid, or banking details changed, while trusting the signature? Was a digital signature held up as evidence in legal proceedings? Are there any automated systems that rely upon the digital signatures in these documents?
> acknowledged and awarded our research with a bug bounty.
Rather than just uncomfortable conversations everyone wishes they weren't a part of... there's cake? :)
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#54Signed OOXML Word files are ZIP files defined by what appear to be 3 manifests: a content-types.xml file, a document.rels.xml file that maps symbolic IDs to filenames, and the "Package Info" section of the signature block, which supplies hashes for all signed files. The rendering of an OOXML Word file starts from "document.xml".
Here are the attacks, as I understand them:
1. OOXML doesn't sign content-types.xml. It also doesn't sign the literal contents of document.rels.xml, but rather appears to parse it and sign the values from the file. So: you can add arbitrary files to a signed OOXML bundle. That shouldn't matter, because none of those new files will be referenced by "document.xml", which is signed. But: there are files that Word will render without references, like "people.xml" (which describes the authors of a document); you can add that file after signing, and its content can take over the whole document render.
2. Document styles are stored in "styles.xml". You can create an OOXML file without a "styles.xml", sign it, and then later add an unsigned "styles.xml"; since the binding between "document.xml" and "styles.xml" is implicit and not cryptographically verified, if you're clever about the original document you have signed, you can use styles to change the meaning of the document later.
3. There's a tricky attack involving the interaction between .DOC and .DOCX that I don't totally follow, but the gist is: you can get a benign .DOC signed, and then write a malicious .DOCX file, and scrape the signature from the .DOC into the .DOCX file, along with the contents of the .DOC. Signature verification will follow the contents of the .DOC, but the render will be of the .DOCX.
4. There's apparently a nasty implementation bug where the verifier doesn't check to make sure that the hashes in the signature manifest are related to the signature itself, but rather just that the hashes are valid. So you can take an XML signature from any other source (a SAML token, for instance) and splice it into a self-signed OOXML file, replacing the signature but not the hash manifest. Both will verify independently.
5. You can take any signed OOXML Excel spreadsheet and inject a malicious .DOCX into it. Then rename the file from ".xlsx" to ".docx". Word will open it, prompt you to "repair" the file, and then render it as if it was signed.
The core issues here seem to be:
1. Never sign XML.
2. Never sign a file/bundle format that gives you as much flexibility as OOXML does: being able to add and remove files after a signature was applied without invalidating that signature is the root of most of the attacks in the paper.
3. When you're trying to do signatures over something as complicated as Microsoft Word documents, it's not enough to have a coherent model for signing the structure of the file format --- which, it looks like, was the brief for the designers of OOXML signatures; your model needs to take into account the behavior of the whole program ("people.xml", styles and "styles.xml", "document repair"). You can imagine a team at Microsoft that understands how signatures work getting the assignment to design this feature, and coming up with it based only on the documentation for the file format, because Word itself is a beast, and who wants to spend a year figuring out how it works?
4. You have to test these things. Attack #4 is a table stakes vulnerability that could have been a unit test for how simple it is.
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#55> For documents of prime importance, such as contracts and invoices Few in the legal world actually use cryptographic signatures for signing things. It's vastly more common to use scanned hand signatures or just /s/ and an e-mail record of sign off. Why? Because it has worked that way for hundreds of years. It's pretty uncommon for there to be a dispute about the fact of signature, and even if there is, cryptographic…
And for thousands of years humans got on with no written contracts at all. That doesn’t change the fact that as society evolves there are good reasons for agreements to evolve with it. I’m sure the first hundred years or so of written contracts there were people rolling their eyes at the idea and others “doing it wrong”. It’s possible (likely?) we’ll reach a point where strong properly implemented digital signatures are considered table stakes. This stuff is hard but probably worth it ultimately.
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#56Earlier quoted context omitted.
The question of signing generally arises with dueling forms, where there's no dispute that "a" 20-page contract was signed on June 4, 2017, and that this is page 20, with all of the signatures, but... What did that contract say in Paragraph G on Page 12? Perhaps the bank only retained page 20, and is saying that they used the same master form for every mortgage and the master form says "this" on page 12. Or one party…
On "serious" contracts, it's common to put your initials on each page, or to fan out the stack of papers and sign the margin so that each page contains part of that signature. Both are in addition to the "real" signature at the end, and provide some protection against exactly these kinds of problems. I guess a cryptographer would add a hash of all preceding pages on the last page.
> I guess a cryptographer would add a hash of all preceding pages on the last page.
That's basically how hashes and signatures work anyways. They basically take in the result of the previous block and integrate it into the new block so that if you change any part of the previous parts, the whole thing breaks.
Edit: I should specify this is how the algorithms themself work. Implementations can fuck this up (and they do a lot).
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#57I feel there are some fundamental misconceptions about signatures that are baked into many of these older standards. There have been similar attacks on XML signatures, email signatures and PDF files (with some overlapping authors).
It usually comes down to creating some complex formats where signatures are allowed to sign sub-parts of the information. This is an extremely fragile design, and should probably be considered broken unless proven otherwise.
Signatures should really just be applied to whole files or data structures, everything else should be considered dangerous.
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#58Earlier quoted context omitted.
Well. Eversign holds the key and promises to only use it when you authenticated by clicking the link in the email that was sent to you personally. eIDAS was intentionally formulated to allow such signature services, making the whole thing quite pointless from a security perspective.
> Well. Eversign holds the key and promises to only use it when you authenticated by clicking the link in the email that was sent to you personally. This method would most likely be eIDAS confidence level low. They (like many other providers) most likely offer multiple LoA variant but only advertise the lowest one online so you think you are "ok" with an easy to use variant but when push comes to shove you need to up…
eIDAS' levels of assurance are about authentication when logging in.
For digital signatures, the levels are 'An electronic signature', like /s/, 'advanced electronic signature', and 'qualified electronic signature'.
The first "shall not be denied legal effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an electronic form or that it does not meet the requirements for qualified electronic signatures."
Qualified signatures used to require that the private key was physically on some tamperproof chipcard (or similar), but eIDAS changed that. Now, you can rely on some vendor's implementation of cloud signing services that is certified to ensure(?) that "signature creation [data] [is] with a high level of confidence, use[d] under [your] sole control". Much like how many people don't manage the secret keys of their crypto wallets.
For remote QCSD the relevant spec is ETSI EN 419 241‐2 PP. It has very few requirements (8.1.8) about authentication, only that it should be resistant to guessing your PIN/password, and it should only let in the legitimate user.
Note that you can get certified as a qualified trust provider by EY or KPMG.
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#59> For documents of prime importance, such as contracts and invoices Few in the legal world actually use cryptographic signatures for signing things. It's vastly more common to use scanned hand signatures or just /s/ and an e-mail record of sign off. Why? Because it has worked that way for hundreds of years. It's pretty uncommon for there to be a dispute about the fact of signature, and even if there is, cryptographic…
The Gazette (the publication of legal record in the UK) does sign things cryptographically: Eg, for example: https://www.thegazette.co.uk/notice/4301705 (see the signatures at the bottom right). Not sure what actual legal function this serves though.
Re: Every Signature Is Broken: Insecurity of Microsoft Office’s Ooxml Signatures
#60> For documents of prime importance, such as contracts and invoices Few in the legal world actually use cryptographic signatures for signing things. It's vastly more common to use scanned hand signatures or just /s/ and an e-mail record of sign off. Why? Because it has worked that way for hundreds of years. It's pretty uncommon for there to be a dispute about the fact of signature, and even if there is, cryptographic…
> It's pretty uncommon for there to be a dispute about the fact of signature
Well, I disagree. It looks quite common to me.
You just won't see it on contract disputes, because that kind of argument is a criminal matter. But false contracts, authorizations, transactions and whatever are really common.