Man in the Middle Attack Mitigation

[mouseover]

Hi,

Thank you for this excellent piece of software, have been using it for many years as Windows' Conky equivalent.

Recently, Rainmeter has been mentioned as a possible source for Man in the Middle attacks on Windows machines:

https://arstechnica.com/security/2024/08/hacked-isp-infects-users-receiving-unsecure-software-updates/

(Rainmeter mentioned in second paragraph)

Just wondering if there have been any developments to mitigate this with a more secure update mechanism?

Thanks again for a really well designed application.

[SilverAzide]

Hi,

Thank you for this excellent piece of software, have been using it for many years as Windows' Conky equivalent.

Recently, Rainmeter has been mentioned as a possible source for Man in the Middle attacks on Windows machines:

https://arstechnica.com/security/2024/08/hacked-isp-infects-users-receiving-unsecure-software-updates/

(Rainmeter mentioned in second paragraph)

Just wondering if there have been any developments to mitigate this with a more secure update mechanism?

Thanks again for a really well designed application.

To be very clear, your statement "Rainmeter has been mentioned as a possible source for Man in the Middle attacks on Windows machines" is not correct. The "source" is actually the compromised internet service provider (not named in the article). The attacker is then using the compromised ISP to insert himself between the ISP and the Rainmeter update. That said, this does not mean the Rainmeter update mechanism couldn't use some additional security.

[Brian]

@mouseover: Thanks for bringing this to our attention!

SilverAzide is correct. The "source" of the MITM attack was a hacked ISP, not Rainmeter.

Our updater checks a status file (hosted on github), and if a new version is available, Rainmeter downloads it (also hosted on github), checks its hash value for validity before installing the new version.

The issue seems to be how we are fetching the status file, which a middle man could hijack the status file and change the values before it gets back to the user. This is the first time I've seen Rainmeter involved with this type of attack, and since it involves a hacked ISP (or other internet access points) AND knowledge of how specific software updates, hopefully any damage done to our users was minimal.

This issue will be corrected before the next release.

-Brian

[richlee91]

Came here for the same reason. I was wondering what the plan was to mitigate. I see you have code signing, which should mitigate the MITM attack.

I did a little digging and this is what I found. I am not an expert at rainmeter and this is the first time I have looked at the repo.

Looks like it gets the status file with http:

LPCWSTR Updater::s_UpdateURL = L"http://rainmeter.github.io/rainmeter/status.json";

Ah, then it downloads anything within status.json. The SHA is also contained in that file, so a bady would only have to build and host their own status.json and rainmeter clients would get their malicious update.

I looked back 13 years and it been the same since then so this does not appear to me to be malicious coding on the rainmeter side.

I would humbly suggest retrieving the status file with https and adding a check for the signature of the signed executables before installing.

This is not a theoretical attack it is known to be happening in the wild. In the meantime I would recommend everyone disable the check for updates and ensure that their current rainmeter install is using signed code. (right click on the all of the .exe and .dll files within the rainmeter directory and ensure they are signed as below)

Thanks for your attention to this issue.
Rich

[richlee91]

Thanks for the update, Brian. Great to see you are on top of this.

[Brian]

Looks like it gets the status file with http:

Yes, this is the underlying issue. Before we did automatic updates, our status file was only a version number. It was perfectly acceptable to download it over http since it was just a number. But, once we started providing installer and hashing info in the status file, we should have changed it to https.

I would humbly suggest retrieving the status file with https and adding a check for the signature of the signed executables before installing.

Thanks for the suggestion, however, we are already doing that once the installer is downloaded (and a again just before Rainmeter starts the installer).

This is not a theoretical attack it is known to be happening in the wild. In the meantime I would recommend everyone disable the check for updates and ensure that their current rainmeter install is using signed code. (right click on the all of the .exe and .dll files within the rainmeter directory and ensure they are signed as below)

I am not sure this is quite necessary given the specifics of the attack. It will take a hacked ISP (or other internet access points) AND knowledge of how Rainmeter updates. We are also forgetting a good antivirus vendor. Hopefully whatever malware was installed is picked up by most AV's.

-Brian

[richlee91]

Here's the risk as I see it:
Anyone connecting to a public wifi (airport, airplane, etc) with rainmeter installed and check updates checked is vulnerable (1 wrong click and you are infected). Automatically apply updates would be even worse as those would be applied without a click. Badies work fast, and this is now well known. Antivirus is generally slow adapting pinpointed attacks like this and users will have to be infected for the antivirus to be updated.

Just my view.

[Brian]

Here's the risk as I see it:
Anyone connecting to a public wifi (airport, airplane, etc) with rainmeter installed and check updates checked is vulnerable (1 wrong click and you are infected). Automatically apply updates would be even worse as those would be applied without a click. Badies work fast, and this is now well known. Antivirus is generally slow adapting pinpointed attacks like this and users will have to be infected for the antivirus to be updated.

Just my view.

That's fair and not bad advice at all.

I would only add that although this is now in the "wild", it still involves some level getting hacked in one way first (connecting to a hacked access point), then having the malware payload installed and NOT caught by AV's. While AV's can be slow to "update" their detection signatures...I haven't seen anywhere that the malware installed via this issue is NEW and not a previously known piece of malware. But who knows.

Also, if our users turn off automatic updates, they won't get our fix (hopefully coming shortly).

-Brian

[richlee91]

Yeah, fair enough on the last point . Everyone will definitely want to get the next update.

[Yincognito]

Also, if our users turn off automatic updates, they won't get our fix (hopefully coming shortly).

Do you mean that an user who hypothetically has his ISP hacked would still get the "right" fix through automatic updates? Despite the automatic update being hijacked this way? Just curious, cause otherwise I never automatically update anything other than the browsers and their extensions (that force me against my will) and the AV signatures (which are necessary).