3 ms·

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) l

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.

Lammy 6y ago
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. Here are a bunch of great real-life examples from the Playstation 4 hacking scene: https://www.psdevwiki.com/ps4/Working_Exploits https://www.psdevwiki.com/ps4/Working_Exploits 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-dive-into-ios-exploit.html 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). 3) There is no step three. With this in mind we can look at even very recent real-world news—like the simultaneous patching of five Chrome exploits in June 2020—and instantly see how it's not just hypothetical: https://www.cisecurity.org/advisory/multiple-vulnerabilities-in-google-chrome-could-allow-for-arbitrary-code-execution_2020-077/ https://www.cisecurity.org/advisory/multiple-vulnerabilities... 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?
- cpgxiii 6y ago
  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.
  - Lammy 6y ago
    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.
    - cpgxiii 6y ago
      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.

Lammy 6y ago

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. Here are a bunch of great real-life examples from the Playstation 4 hacking scene: https://www.psdevwiki.com/ps4/Working_Exploits https://www.psdevwiki.com/ps4/Working_Exploits 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-dive-into-ios-exploit.html 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). 3) There is no step three. With this in mind we can look at even very recent real-world news—like the simultaneous patching of five Chrome exploits in June 2020—and instantly see how it's not just hypothetical: https://www.cisecurity.org/advisory/multiple-vulnerabilities-in-google-chrome-could-allow-for-arbitrary-code-execution_2020-077/ https://www.cisecurity.org/advisory/multiple-vulnerabilities... 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?

cpgxiii 6y ago
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.
- Lammy 6y ago
  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.
  - cpgxiii 6y ago
    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.