Hacker News Reader

Comment by cpgxiii | Hacker News Reader

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.

View on HN

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

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

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...

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

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.

Depends if the attack is targeted to specific users: sysadmins for example will often have jre installed to run clunky old kvm clients.

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.

> 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.

You see the problem right?

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.

Reply on news.ycombinator.com