7 ms·
So if I get this right, the attack vector here is 1) Take signed .MSI 2) Add my JAR of malware to the end of it 3) Send file to target 4) Target's computer
by cpgxiii 6y ago
So if I get this right, the attack vector here is
1) Take signed .MSI
2) Add my JAR of malware to the end of it
3) Send file to target
4) Target's computer recognizes the file as a signed MSI, ignoring the extra stuff at the end that's not part of the MSI
5) Target computer calls the JRE to launch the JAR
6) JRE ignores the MSI parts at the beginning of the file because compressed JAR files are loaded back-to-front
Obviously a major bug that signature validation ignores "extra" parts of the file, but a signature validation bug that (1) only affects specific types of files executed by a third-party runtime and (2) doesn't threaten system files (or any native executables at all) isn't an obviously critical vulnerability like an arbitrary "signature validation is totally broken" bug.
- Lammy 6y agoDisagree on lack of severity; this is the kind of thing that calls into question any signed MSI I've downloaded over non-TLS HTTP or even over HTTPS served from a possibly-downgrade-attacked HTTP→HTTPS redirect. e: or any signed MSI from a compromised system, like happened to Palemoon last year: https://news.ycombinator.com/item?id=20435699 https://news.ycombinator.com/item?id=20435699 Endless rabbit-hole of course but that's already a lot of low-hanging fruit
- cpgxiii 6y agoI don't think that follows from what's been disclosed. What seems to be the case, based on the disclosures, is that the signature validation code does a correct job validating the parts of the file the MSI header describes, but does not check parts of the file that aren't described in the header. As far as I'm aware, adding arbitrary anything to the end of an MSI doesn't do anything since it's not described in the headers, so you can't use this to compromise an actual MSI file. You can only use this bug to fake signing for specific other file types that are read back-to-front where the actual MSI parts will be ignored.
- Lammy 6y agoWell I guess the actual payloads would all be fairly individualized, so that makes sense.
- testplzignore 6y agoWhy are MSI files designed like this? Why allow for just a specific part of the file to be signed? (I have no technical experience dealing with them.)
- banthar 6y agoExtra bytes at end of file will be ignored by most formats. You generally don't want to depend on file length.
- Varriount 6y agoOther than a possible checksum calculated from the entire file contents, many binary formats use either: - Headers describing a section, including the length of a section. - Prefixing each section with a size. - Using a marker pattern (such as a null byte) to mark the end of a section of data. (there are more than these three, but these are the most common) That last one isn't used very often, and when it is, it's mostly for textual data. The consequence of using the first two techniques is that it's entirely possible to add data to the end of the format, since a parser would just read the last section and stop (assuming the format supports knowing what the last section is).
- Lammy 6y agoIf you hashed the entire file you wouldn't be able to append that hash to the file for distribution because it would change the hash of the file. That's why FOSS software signatures are usually MD5/SHAwhatever in a separate text file.
- Xylakant 6y agoIf I read the description correctly, it would need to be a jar file, though, not an msi. The trick allows to hide a malicious jar file from the scanner, not to hide a malicious msi. I think it’s better described by “take a malicious jar and prepend a signed msi to hide it from the scanner.”
- a2tech 6y agoThis is separate from anything an AV might do, so forget the scanner part. A virus scanner with a signature for this malicious JAR will still catch it. What this is avoiding is the prompt and extra scrutiny Windows throws up if you try and run an executable from the Internet. Think of the legitimate MSI and malicious JAR files as separate short stories in the same book. The 'book' comes to your computer claiming to be one thing (the legitimately signed MSI) but the second chapter is something completely different (the malicious jar file). When your computer reads the book (calculates and verifies the signature) it only does it off the first chapter. That lets the second part slide under the additional scrutiny Windows applies to files downloaded from the Internet.
- Xylakant 6y agoBy “scanner” I meant the built-in windows defender tooling, which is - afair - affected. It trusts the signature. But you’re entirely correct - a virus scanner that does not rely on the signature w could catch the malicious code. However, this blog post mentions that various security solutions trust the windows code signing, but it does not mention which ones - https://blog.virustotal.com/2019/01/distribution-of-malicious-jar-appended.html?m=1 https://blog.virustotal.com/2019/01/distribution-of-maliciou...
- pbhjpbhj 6y ago>It trusts the signature. // Wtf? Am I reading this right, if part of the file is signed by MS then it just doesn't bother running it through the detection algo? That looks exceedingly like a designed in security hole. Presumably paired with the OP "bug" means MS could, with an NSA letter say, drop malware on devices if those devices were using Windows Defender for AV. Just as well MS don't snoop on what software user's are running./s
- proactivesvcs 6y agoAnd since Microsoft still serve updates from the Microsoft Update Catalog over HTTP, let's not mistakenly think that all downloads are protected via TLS, even today.
- gruez 6y agoIs this still the case for windows 10?
- smileybarry 6y agoYes, but all updates are a specialized .MSU format and don't fall in this end-of-file parsing trap.
- proactivesvcs 6y agoThe Update Catalog is only for manual downloads, so if you mean Windows Update, this is all downloaded over HTTPS.
- pbhjpbhj 6y agoOr any signed MSI if downloaded from a country where security services can secretly oblige companies to act against their users - China, USA, and probably many others.
- skocznymroczny 6y agoIs there any technologically advanced country where that is not the case?
- melvinroest 6y agoThis vulnerability reminds me of PlayerTwo on hackthebox.eu! One of the top ranking hackthebox players summarized PlayerTwo quite neatly [1]. [1] https://www.youtube.com/watch?v=u_GkIzCmU90 https://www.youtube.com/watch?v=u_GkIzCmU90 (13 min.)
- creato 6y agoDoes (5) happen automatically when running the file as an MSI file? If not, this doesn't seem that severe. If so, it's pretty severe.
- cpgxiii 6y agoI don't see any way it would be possible for such a file to be simultaneously executed by the system as a MSI and as a JAR (you can probably always invoke the JRE on a .msi file, just not through the system file associations).
- Lammy 6y agoIt's renamed, not simultaneously-associated. From the fine article: 'Quintero said this weakness would particularly acute if an attacker were to use it to hide a malicious Java file (.jar). And, he said, this exact attack vector was indeed detected in a malware sample sent to VirusTotal. “In short, an attacker can append a malicious JAR to a MSI file signed by a trusted software developer (like Microsoft Corporation, Google Inc. or any other well-known developer), and the resulting file can be renamed with the .jar extension and will have a valid signature according Microsoft Windows,” Quintero wrote.'
- cpgxiii 6y agoExactly, you can't have it be an MSI and a JAR, it has to be a JAR to invoke the JRE automatically. In terms of practical impact, it sounds like you need a target where the JAR file will be run, but also where you'd expect Windows signatures validation alone to protect against malicious Jars.
- a2tech 6y agoThe tricky bit I imagine is the gap between step 4 and step 5 in your attack scenario. To get this to trigger you need to get the JRE to invoke on the MSI file. The JRE isn't typically associated with MSIs so you would need a secondary step to trigger the JRE to look at that file and load the malicious JAR tacked on to the end of the MSI.
- phire 6y agoNo, because the attacker renames the file to .jar before sending it to the target. Windows still sees it as a MSI file while doing signature checking. But because it has a .jar extension, the JRE runs it when you double click. Signature verification is done as a independent check, completely separate from execution. Because windows needs to know the signature is valid before even allowing the file to be executed. It also needs to show the signature check in the right-click -> properties dialog.
- Lammy 6y agoYou shouldn't assume the rename process or payload execution have to be manually triggered. That's what browser exploits are for :)
- tus88 6y agoWhy does (5) occur.
- cpgxiii 6y agoBecause you told the target "if you have trouble running it, right click and open it with Java" and you assume they'll do it? Not clear how you could automate without using a different vulnerability to invoke the JRE on the file.
- Lammy 6y ago> without using a different vulnerability to invoke the JRE on the file Funnily enough this is exactly how real attacks tend to work https://googleprojectzero.blogspot.com/2019/08/a-very-deep-dive-into-ios-exploit.html https://googleprojectzero.blogspot.com/2019/08/a-very-deep-d...
- JamesBarney 6y agoJust to elaborate since there is some confusion about when the name would occur. 1) Take MicrosoftSigned.Msi 2) Append Malway.jar to it 3) Take file and rename it as RunMe.Jar # Now you have a jar file that appears to be signed by Microsoft but contains malways. 4. Give target RunMe.jar and ask then to dbl-click it. # Usually this file would prompt the user with a "You shouldn't trust this arbitrary file from the internet" prompt, but it doesn't because Windows thinks this file is correctly signed 5. Target is now infected
- rootsudo 6y agoThat's interesting, so you literally have to add the jar file to the EOF for the MSI? I know this can be done w/ Cat. --Wow, so JAR files are read from bottom top so it literally masquerades. That's interesting.
- chupasaurus 6y agoThere's an old similar technic - concatenate JPEG with RAR, JPEG header only describes image part, for archive files they're opened from their correspondent header.
- barrkel 6y agoZip files have the index at the end of the file so that new files can be added to the archive without rewriting the whole thing. Zips can also be read from front to back, reading the header of each entry and skipping the compressed data to the next header, which is most of what zip repair utilities do (or did, not sure anyone repairs zips any more). But it's faster to read the index. And to be clear, jars are zip files.
- anonymfus 6y agoNot every zip-based format behaves like this, Microsoft's zip based container formats tend to require a proper beginning too. For example if you add docx (which is a zip file) to the end of something else and open it in Microsoft Word, it will complain that the file is corrupted, and will suggest to repair it.
- deleted 6y ago[deleted]
- burtonator 6y agoI've been thinking about the ability for neural networks to determine flaws like this. If we could describe what a 'goal' would be (executing arbitrary binary data for example) and then some of these design aspects it might be possible to determine flaws automatically. This is only 6 steps... I imagine an AI could find more.
- Kattywumpus 6y agoI imagine others are thinking about this, too. I feel as if we are headed towards either an era of radically secured code where serious vulnerabilities become rare as hen's teeth, or... the discovery that we exist in an environment of radically vulnerable code that cannot be secured at all. A world where AI script kiddies can take down civilization.