It'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.'
Exactly, 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.
Sure, but if you already have code execution on the target to run the rename or directly invoke the JRE, either (1) you've already exploited the target or (2) lack of signature validation (since the rename script or equivalent to invoke it wouldn't be signed) wouldn't have been a barrier to running the malicious JAR.
No way, exactly the opposite. Attacks are often described as "chains" because it usually requires simultaneous application of multiple exploits to achieve an attack's goal.
Or iOS exploit chains, some of which I've used intentionally as part of iOS jailbreak tools like unc0ver. From Project Zero's "very deep dive into iOS Exploit chains found in the wild": "Earlier this year Google's Threat Analysis Group (TAG) discovered a small collection of hacked websites. The hacked sites were being used in indiscriminate watering hole attacks against their visitors, using iPhone 0-day."
https://googleprojectzero.blogspot.com/2019/08/a-very-deep-d...
I imagine the real-world application of this MSI thing is something like:
1) Get silently-malicious MSI on to target machine (via download server compromise, poisoned non-TLS download, redirect TLS-downgrade, etc etc)
2) Got malicious "trigger" exploit code on to any web page used by the target (via web server compromise, weak human security like admin passwords, etc etc).
For example, one of them (CVE-2020-6493) is "Use after free in WebAuthentication in Google Chrome prior to 83.0.4103.97 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page". How many more of these do you think are hanging around out there, waiting for Google to get the 'okay' to fix?
I'm familiar with the concept of chaining multiple exploits to default different layers of security. That said, for step (2) to work, you need either:
a) A separate vulnerability that provides arbitrary code execution to run your trigger exploit
or
b) A vulnerability that allows you to execute a specific program/command on the target system
If you've got either of those, the ability to run a pre-existing JAR doesn't really increase your capabilities. You've already got at least user-level access. Having a way to distribute a malicious JAR in advance might be useful in some cases, but having a file sitting on disk in advance significantly increases the risk of having your exploit detected before you get to use it.
I'm glad we're understanding each other, but I completely disagree with the conclusion you reach in your last paragraph. Networks are iffy. People already expect their signed MSI installer to be multiple megabytes of binary garbage and probably wouldn't notice it being a megabyte of two larger than normal, so that sounds like one of the best possible places for a payload to hang out and wait to be triggered. No competent attacker would make their payload-delivery and their command-and-control the same thing.
Hiding your malware in some other file is a good idea, although sticking it in an executable file format is only going to invite more attention and relies on your target only using security tools that assume Windows signed == safe.
It strikes me that the primary use for this would be attacking a target that (1) has some level of system lockdown/scanning such that signing is required, (2) has Java installed on computers and uses it (not just a program that bundles in its own JRE), (3) has scanners vulnerable to the signature validation bug that assume signature OK == safe, (4) has some sort of network scanning IPS/IDS such that the "run malware" trigger needs to be small to avoid detection.
If (1) isn't the case, then there are probably easier ways to sneak your malware into position. If (2) isn't the case, your malware can't run. If (3) isn't the case, your attack risks getting detected in advance and burning any chance of using it. If (4) isn't the case, you'd probably be better off delivering the full malware via the browser sandbox escape/whatever network exploit you're using to avoid needing 1-3 in place first.
I would venture the guess that this has been used for (1) opportunistic malware intended for wide distribution with a low probability of any given target being compromised due to requiring the user to run the malicious JAR and (2) very targeted attacks on specific institutions that meet the 1-4 criteria.
I think you're making a lot of assumptions and pigeonholing the applicability of this based on things we have only passing knowledge of, like "there is a JAR of some sort". I wonder what kind of fun HotSpot exploits might be in the JAR a real attacker would use. Hopefully Oracle will get permission to fix them some day if there are :)
I don't think it's too many assumptions. The number of personal Windows users with Java itself installed (rather than programs with their own bundled JRE) is probably very low at this point, so it means targets for this are either "download eXtra_special_cod3cs_for_pr0n.exe" users, or institutions that match this specific profile.
I would actually expect a number of interesting institutions to match that profile - places likely to keep systems updated (or at least updated AV), so not guaranteed to be vulnerable to last month's patched bugs, who have some level of system lockdown and scanning such that hiding in plain sight behind file signature verification is necessary, who have some type of IDS/IPS such that the separate trigger needs to be kept to a minimum, and who rely on a set rather poorly packaged Java software. I'm sure the list of targets matching those criteria includes a number of financial institutions and infrastructure operators - targets that need to pay more that trivial lip-service to security, but where security is a "we've checked all the boxes so we're good" mindset.
> The number of personal Windows users with Java itself installed (rather than programs with their own bundled JRE) is probably very low at this point
This can depend on your country. Here in Brazil, the income tax preparation software (http://receita.economia.gov.br/interface/cidadao/irpf/2020/d...) is written in Java, and the install instructions in that page tell you to update Java, so it's probably not bundled. Since everyone with income above a certain amount (and several other situations) has to use that software to fill the tax report (the option to use the paper form has been discontinued many years ago), I'd guess a high number of personal Windows users in this country have Java installed.
Even better, those users are probably suffering from alert fatigue already due to all the security warnings about the ancient kvm software, so using a technique like this to bypass AV scans would probably be enough to compromise some major systems.
You can damage most software vendors with just #1.
Then #2 is even worse.
#3 you already own them because #1,#2 let you download a poisoned msi to the machine. You can get cleaver and dynamically change the hash per download as described year ago when signature based AV was all we had, you dont need this trick.
Or... you could just drop powershell, python and execute it and own the machine without trying so hard with just #1 and #2.
The issue is it would seem the file needs to be an MSI file to get signature validation, but need to be a .jar file to run the malicious part. Transparently going from "File passes signature verification" to "running the jar payload" seems like it would require another (more serious than this) bug or active steps from the user.
> seems like it would require another (more serious than this) bug
Yes on your first part; no on the parenthetical. One exploit to let the malicious hanger-on into your computer. Another exploit—maybe in a web page you visit regularly—to trigger it. Compare to this real-world iOS attack: https://googleprojectzero.blogspot.com/2019/08/a-very-deep-d...
'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.'