Mac and Windows Users Infected By Software Updates Delivered Over Hacked ISP (arstechnica.com) 68
An anonymous reader quotes a report from Ars Technica: Hackers delivered malware to Windows and Mac users by compromising their Internet service provider and then tampering with software updates delivered over unsecure connections, researchers said. The attack, researchers from security firm Volexity said, worked by hacking routers or similar types of device infrastructure of an unnamed ISP. The attackers then used their control of the devices to poison domain name system responses for legitimate hostnames providing updates for at least six different apps written for Windows or macOS. The apps affected were the 5KPlayer, Quick Heal, Rainmeter, Partition Wizard, and those from Corel and Sogou.
Because the update mechanisms didn't use TLS or cryptographic signatures to authenticate the connections or downloaded software, the threat actors were able to use their control of the ISP infrastructure to successfully perform machine-in-the-middle (MitM) attacks that directed targeted users to hostile servers rather than the ones operated by the affected software makers. These redirections worked even when users employed non-encrypted public DNS services such as Google's 8.8.8.8 or Cloudflare's 1.1.1.1 rather than the authoritative DNS server provided by the ISP. "That is the fun/scary part -- this was not the hack of the ISPs DNS servers," Volexity CEO Steven Adair wrote in an online interview. "This was a compromise of network infrastructure for Internet traffic. The DNS queries, for example, would go to Google's DNS servers destined for 8.8.8.8. The traffic was being intercepted to respond to the DNS queries with the IP address of the attacker's servers."
In other words, the DNS responses returned by any DNS server would be changed once it reached the infrastructure of the hacked ISP. The only way an end user could have thwarted the attack was to use DNS over HTTPS or DNS over TLS to ensure lookup results haven't been tampered with or to avoid all use of apps that deliver unsigned updates over unencrypted connections. As an example, the 5KPlayer app uses an unsecure HTTP connection rather than an encrypted HTTPS one to check if an update is available and, if so, to download a configuration file named Youtube.config. StormBamboo, the name used in the industry to track the hacking group responsible, used DNS poisoning to deliver a malicious version of the Youtube.config file from a malicious server. This file, in turn, downloaded a next-stage payload that was disguised as a PNG image. In fact, it was an executable file that installed malware tracked under the names MACMA for macOS devices or POCOSTICK for Windows devices. As for the hacked ISP, the security firm said "it's not a huge one or one you'd likely know."
"In our case the incident is contained but we see other servers that are actively serving malicious updates but we do not know where they are being served from. We suspect there are other active attacks around the world we do not have purview into. This could be from an ISP compromise or a localized compromise to an organization such as on their firewall."
Because the update mechanisms didn't use TLS or cryptographic signatures to authenticate the connections or downloaded software, the threat actors were able to use their control of the ISP infrastructure to successfully perform machine-in-the-middle (MitM) attacks that directed targeted users to hostile servers rather than the ones operated by the affected software makers. These redirections worked even when users employed non-encrypted public DNS services such as Google's 8.8.8.8 or Cloudflare's 1.1.1.1 rather than the authoritative DNS server provided by the ISP. "That is the fun/scary part -- this was not the hack of the ISPs DNS servers," Volexity CEO Steven Adair wrote in an online interview. "This was a compromise of network infrastructure for Internet traffic. The DNS queries, for example, would go to Google's DNS servers destined for 8.8.8.8. The traffic was being intercepted to respond to the DNS queries with the IP address of the attacker's servers."
In other words, the DNS responses returned by any DNS server would be changed once it reached the infrastructure of the hacked ISP. The only way an end user could have thwarted the attack was to use DNS over HTTPS or DNS over TLS to ensure lookup results haven't been tampered with or to avoid all use of apps that deliver unsigned updates over unencrypted connections. As an example, the 5KPlayer app uses an unsecure HTTP connection rather than an encrypted HTTPS one to check if an update is available and, if so, to download a configuration file named Youtube.config. StormBamboo, the name used in the industry to track the hacking group responsible, used DNS poisoning to deliver a malicious version of the Youtube.config file from a malicious server. This file, in turn, downloaded a next-stage payload that was disguised as a PNG image. In fact, it was an executable file that installed malware tracked under the names MACMA for macOS devices or POCOSTICK for Windows devices. As for the hacked ISP, the security firm said "it's not a huge one or one you'd likely know."
"In our case the incident is contained but we see other servers that are actively serving malicious updates but we do not know where they are being served from. We suspect there are other active attacks around the world we do not have purview into. This could be from an ISP compromise or a localized compromise to an organization such as on their firewall."
Can this be done with just router hacks? (Score:2)
Can this be done with just router hacks?
Re: (Score:3)
Sounds like they setup rules to route the packets destined for IPs of legitimate update servers to IPs of servers controlled by the threat actor. So yes, router only, you were not being routed to where you think.
Re:Can this be done with just router hacks? (Score:4, Informative)
Sounds like they setup rules to route the packets destined for IPs of legitimate update servers to IPs of servers controlled by the threat actor. So yes, router only, you were not being routed to where you think.
For loose interpretations of those words, sure. But in the context of a router, I would not say that they were routing the packets to a different destination. They poisoned the DNS results to point names to different IPs. It's essentially: ... out to the internet for the DNS result[^1] ... traffic is routed normally, but you're sending it to the wrong/hacked IP
* > You -- (dns query) -> router ->
* < router replies quickly with its poisoned result (Ex. saying corel.com is on the IP with the hacked updates)
* > You -- (fetch the files from the hacked IP) ->
* < Real DNS result eventually comes back. Your computer will simply ignore it because you already got that response
As TFS and TFA noted, this wouldn't work if those updates had been served over SSL/TLS. The only reason this works is because those software updates are being served over plain old HTTP, which is just stupid in this day and age, especially for any automatic updates (on manually downloaded software, one could make an argument that people should be verifying checksums from official sites - hopefully verified by HTTPS). Had SSL/TLS been employed, the process would have been:
* > You -- (dns query) -> router -> ... out to the internet for the DNS result ... they won't have a valid SSL certificate, so the TLS later will not be established and the HTTP request will never be issued in the first place. No data returned.
* < router replies quickly with its poisoned result (Ex. saying corel.com is on the IP with the hacked updates)
* > You -- (connect to hacked IP over HTTPS) ->
* < Real DNS result eventually comes back. Your computer will simply ignore it because you already got that response. But you were protected already, so this doesn't matter.
[^1] I don't know if they just quickly send the forged result while still allowing the actual DNS request to be sent, or if they truly MitM the DNS query, but the result is the same - poisoned DNS result, not a change to the routing table.
Re: (Score:2)
Well, I did answer the question, yes this is possible with just router hacks.
The summary says "this was not the hack of the ISPs DNS server" - I guess if you only consider the server and not the full functionality of DNS. Well it was a mitm of the DNS responses, tantamount to a DNS server hack by being in effect the same thing. Hackers in your infra is a real problem no matter their approach.
Re: (Score:2)
"Because the update mechanisms didn't use TLS or cryptographic signatures to authenticate the connections or downloaded software,"
In a case where the other side and/or the data is not validated, yep.
Re: (Score:1)
And that's the problem with the windows/mac model of every piece of software having its own update mechanism.
With a standardised repository system you can see at a glance what repositories you're using, and what protocols they use - plus wether they use additional authentication over the top such as gpg signing of packages.
Re: (Score:2)
And then access to that repository becomes a gatekeeper for offering anything for those platforms.
Re: (Score:2)
you can add your own repos to an repo system
It's shocking... (Score:1)
Re: (Score:3)
Re: (Score:3)
The OS itself doesn't even know when a file write constitutes an application update. So as things stand, there isn't much the OS can do if 5KPlayer, Quick Heal, Rainmeter, and Partition Wizard go ahead and apply unsigned updates.
MacOS knows when it is writing into the Applications folder and privileged places like that. It may be the case that applications are allowed to write into their own directories there, though. None of this is going through the normal Software Update facility that is used for updating system software or apps that came from the App Store. The user had to override security with an explicit exception, and do several other admin access things, just to install these rogue apps in the first place.
I know because I
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Re: It's shocking... (Score:2)
What's a solution here? Not allow programs to write to storage? The programs doing the update are in fact verified.
Re: (Score:3, Insightful)
What's a solution here?
First, name the damn ISP! If somebody can, please do, as a public service. We need to demand more transparency. Secrecy only makes the problem worse and more suspicious
Re: It's shocking... (Score:4, Insightful)
What's a solution here? Not allow programs to write to storage? The programs doing the update are in fact verified.
I would argue that the programs doing the update were not verified. Any program that does it's own update scan really only be verified on the original install as done by the user. At that point in time the user performing the install has the opportunity to check signatures or checksums on the installed software. When software updates itself, unless it presents an opportunity for the user to validate updated files, the user has to trust that the software will "do the right thing" and perform validation itself.
The solution is to blame the applications for not using and verifying secure connections to their update servers, and not verifying that the data they transferred had not been tampered with. In this case the programs in question did not "do the right thing" and did not verify that they were able to download their updates intact.
The technology to do this (HTTPS) has been in place for decades, and using HTTPS has been a best practice for at least a decade. It is irresponsible and negligent to perform software updates over a non-protected (HTTP) connection. Note that "using HTTPS" is only the first part of the equation, the certificates used must also be validated by the client - lots of software fails to do this...
In addition, some operating systems, such as Microsoft Windows, have the built-in ability to cryptographically sign executables and verify those signatures prior to execution. Failure to sign binaries and validate those signatures, is another irresponsible shortcoming of these applications.
The Internet is a network that isn't really owned by anyone specific and there is no way of telling which routers and systems your data will go through. The implementation of redundancy and non-predictable routing is a design feature. Due to this feature, that should be well known, protection of sensitive data is a requirement.
Re: It's shocking... (Score:2)
I agree. I was wondering about what the OS can do to prevent this from happening.
Re: (Score:2)
Although, it would break the practice of using an un-encrypted network connection but then cryptographically verifying the downloaded binary with a checksum, which is not a bad option when you want distribution of trusted files through untrusted channels, such as mirror sites. Open-source
Re: (Score:1)
I bet Microsoft & maybe MacOS have these package manager features but charge developers &/or users extra to use them.
Re: (Score:2)
That only works if the update happens via the package manager. What if a program runs with root privilege and updates some of its files without using the package manager? Like an antivirus updating its database, or pi.hole updating its blacklist, I'm sure there are many more examples. Then the package manager is irrelevant to the discussion, since updates happen via other means.
Re: (Score:2)
Re: It's shocking... (Score:2)
I'm not sure I understand your answer here. Do you think that Debian inspects every line of code in everything it packages? If not, how does it prevent these packages from downloading compromised files?
Re: (Score:2)
Re: (Score:2)
I agree. I was wondering about what the OS can do to prevent this from happening.
As noted in TFS, use DNS over HTTPS or DNS over TLS. That would be an OS level change that would have prevented this exploit.
Re: (Score:2)
Or require DNSSEC, already supported by the OS?
Re: (Score:2)
I have nothing against DNSSEC, but it may not have prevented this issue. It only works if the domain has it configured. These download sites didn't even have HTTPS enabled; Why would we expect them to have DNSSEC configured and enabled? That's also a two party solution (both sides have to do it), whereas any end user can move to DNS over HTTPS (though I wouldn't do that personally - I run my own local fully recursive DNS resolver, which also gets around this situation).
Re: (Score:2)
In addition, some operating systems, such as Microsoft Windows, have the built-in ability to cryptographically sign executables and verify those signatures prior to execution.
Unfortunately, this capability has been turned into a revenue generator. You can get a code signing certificate (which today, requires it to be hardware based -- so a USB dongle -- more money), but Windows will still flag binaries signed with this certificate as suspicious. Or, you can pay more and get an "extended validation" certificate, which Windows will accept without question. The rules for getting an extended validation certificate haven't been updated for the effects of Covid and the move to WFH.
Re: (Score:2)
The technology to do this (HTTPS) has been in place for decades
I'll say it again: HTTPS wouldn't help you here. If the data isn't checked before executing it, you may as well had a user download and run virus.exe.
HTTP is perfectly safe for downloading updates as long as the downloaded data is properly checked and verified before it is used. The latter is what was missing in TFS and is the reason why the attack was successful. HTTPS wouldn't have saved you from that attack vector. Especially if the "secure" downloader could be tricked into downloading and installing
Re: (Score:2)
(properly implemented) HTTPS absolutely would have stopped the attack in question, because as soon as you were redirected to the malicious server the certificate would be invalid.
Re: (Score:2)
Re: It's shocking... (Score:2)
Re: (Score:1)
The solution is cryptographically signed updated. You'll notice that no Linux distros were implicated in this incident.
Re: (Score:1)
updates*
They do not... (Score:1)
Windows & MacOS allow unverified, unencrypted updates.
Neither Windows nor MacOS allow unverified, unencrypted updates,
Only a few applications were able to be comprised in this way, that did... but they are obviously using a custom update mechanism, as any Mac App Store app for example could not be attacked in this way.
How is either Windows or MacOS supposed to prevent apps from custom updating schemes? To the system it's just some arbitrary network traffic. MacOS already prevents you from running unsi
Re: (Score:2)
Re: (Score:2)
Do you use Docker, Firefox, LibreOffice, SourceTree, Ultimaker Cura or Visual Studio Code? Those are just six examples of Linux applications that ignore whatever package manager your distro is using to perform their own self-updates.
Not sure about other software but Firefox and LibreOffice, since very popular and often preinstalled in many Linux distros, don't (always) self-updates. They are configured by Linux distros to get updates through the same managed manner like other preinstalled software.
this is what you get (Score:2)
Re: (Score:2)
You don't need centralized update for protection against this kind of attack. You only need the web server that host the updates get a free-as-in-beer Let's Encrypt certificate for HTTPS connection.
Or you implement a signature check in your app to check against update files. Then cryptographic sign your update files AND make sure you don't post the private key to public.
DNS over HTTPS (Score:2)
This article prompted me to investigate DNS over HTTPS and make sure it is enabled.
Re: (Score:2)
Re: (Score:2)
This article prompted me to investigate DNS over HTTPS and make sure it is enabled.
You'd still be screwed because you didn't read the summary.
What part? Certainly not THIS part of TFS:
"The only way an end user could have thwarted the attack was to use DNS over HTTPS or DNS over TLS to ensure lookup results haven't been tampered with or to avoid all use of apps that deliver unsigned updates over unencrypted connections."
Re: (Score:2)
The only way an end user could have thwarted the attack was to use DNS over HTTPS or DNS over TLS to ensure lookup results haven't been tampered with
*Assuming that said DNS over HTTPS or TLS enabled resolver wasn't configured to automatically fallback to another resolver if the chosen host couldn't be contacted, and that the attacker hasn't managed to get a cert signed by a CA the resolver trusts. Merely enabling DNS over HTTPS or DNS over TLS isn't enough in this case.
tampering with software updates delivered over unsecure connections
avoid all use of apps that deliver unsigned updates over unencrypted connections
"Just don't do something stupid" is rarely a comfort in hindsight. Especially if the doing part is a decision that's not under your control.
Re: (Score:2)
The only way an end user could have thwarted the attack was to use DNS over HTTPS or DNS over TLS to ensure lookup results haven't been tampered with
*Assuming that said DNS over HTTPS or TLS enabled resolver wasn't configured to automatically fallback to another resolver if the chosen host couldn't be contacted, and that the attacker hasn't managed to get a cert signed by a CA the resolver trusts. Merely enabling DNS over HTTPS or DNS over TLS isn't enough in this case.
You've got your priorities mixed up. Merely enabling DNS over HTTPS or TLS _WOULD_ have been enough for most, if not all, involved. The only subset of those users that would still fall prey in this instance would be those who: ... and chose to use one that wasn't over HTTPS or TLS, even though they had explicitly chosen one over HTTPS/TLS as their primary, likely for a good reason??? I call BS on that being a likely situation. ... this is an entirely different issue and was not part of this problem. You're moving the goalposts now. ... and I don't think this would have worked in this situation, based on how they were poisoning DNS (the requests still went to the proper DNS resolver; they merely injected forged result packets before that resolver could answer)
* configured a fallback resolver
*
* or the attacker managing to get a cert signed by a recognized CA for the specific domains in question.
*
*
Also, you never said what the fuck this has to do with it:
You'd still be screwed because you didn't read the summary.
I'm betting nothing. Eat crow, already.
Re: (Score:2)
>> didn't read the summary
Was there something specific in the summary you think I didn't read? Or you are just blabbering.
Re: (Score:2)
The apps affected were the 5KPlayer, Quick Heal, Rainmeter, Partition Wizard, and those from Corel and Sogou.
"That is the fun/scary part -- this was not the hack of the ISPs DNS servers," Volexity CEO Steven Adair wrote in an online interview. "This was a compromise of network infrastructure for Internet traffic.
Unless those apps are somehow using the OS resolver to issue a DNS over TLS / HTTPS request, it won't help you under normal conditions. In TFS case, there's absolutely nothing to prevent a compromised router from redirecting the cleartext non-encapsulated requests at the layer 2 / 3 level to an attacker controlled server that responds with a Let's Encrypt verified cert. (Or any other cert accepted by the resolver.) The router and the attacker's server will simply rewrite the packet headers in t
Re: (Score:2)
I understand your point now, thanks. But why would you assume that those apps are not using the OS resolver?
Something seems fishy... (Score:3)
This seems fishy, because regardless of channel, if an executable is run, it needs to be signed to pass GateKeeper or Authenticode. Was the malware signed by a rogue key, perhaps?
Running over "raw" HTTP shouldn't be an issue. Ubuntu has done that for a long time until recently. The issue is validating packages. Corel is a big one.
Maybe they can take a page from how software was packaged at one of my previous jobs:
* The notarytool was run on a separate Mac. Notarizing software isn't 100%, but it ensured the code was signed. GPG stuff for Linux was signed with the key on a HSM, same with Microsoft AuthentiCode.
* Ideally, the software was put on the Microsoft Store, a Linux repository that is known and good, Homebrew, or the Apple App Store. Yes, some sandboxing is needed, but what this did is completely remove issues with the install vector, hijacks, and such. Some software that needs functionality that can't be sandboxed may need direct downloads, though.
* If it has to be directly downloaded, then a good CDN is used like Akamai, and all stuff goes through SSL/TLS. It is a lot harder to hack a large CDN repo than something on a company network.
* Finally, a list of signed hashes is slapped on the website, just in case.
Re: (Score:2)
This seems fishy, because regardless of channel, if an executable is run, it needs to be signed to pass GateKeeper or Authenticode.
Go tell that to all of CloudStrike's victims. A data file can just as easily be read into memory and executed in place by a trusted app, and you won't be banning that anytime soon. (JS and every other interpreted language would pretty much break instantly if you tried. Not to mention virtual machines or emulators.)
The notarytool was run on a separate Mac. Notarizing software isn't 100%, but it ensured the code was signed. GPG stuff for Linux was signed with the key on a HSM, same with Microsoft AuthentiCode.
Good.
Ideally, the software was put on the Microsoft Store, a Linux repository that is known and good, Homebrew, or the Apple App Store.
If the code is signed, it doesn't matter where you download it from nor how. The system determines if the signature is valid, and if it is invalid the system doesn't run it. Anything less
similar to how? (Score:2)
TURMOIL or TURBULENT works? (which one was the malware injection tool?)
DNS attack details (Score:2)
Does anyone have a link to anything describing **how** the results to say, 8.8.8.8 were being changed to be not from 8.8.8.8. They keep talking about the infrastructure of the ISP, but I assume that means something got installed on the routing equipment that was modifying the resulting packets as they came back through? Surely there's a CVE they can link to about what happened at the infrastructure level?
Re: (Score:2)
Google how does DNS spoofing or poisoning work. Here's an example: https://www.imperva.com/learn/... [imperva.com]
Re: (Score:2)
So I mean, I've run a DNS server for close to 30 years, and have read these papers before. What I want to know, is specifically what was happening here. The methods listed in the link you gave don't seem to cover the likely problems here:
> A malicious actor may use address resolution protocol (ARP) to access router traffic and alter the domain name resolution records.
> The attacker can modify an authoritative DNS server’s records, redirecting traffic to the fraudulent website.
> The attacker
Re: (Score:2)
Regarding the specific CVE, or similar disclosures, I don't know and I share your interest in hearing those :-)
Regarding how this could have been done (which seems likely based on the details seen), see this: https://slashdot.org/comments.... [slashdot.org]
Basically, the exploit on the router can see all the traffic, but it's not changing the routing.
When it sees a DNS request for the specific subdomains it can hijack (the update servers for those handful of companies), it forges a packet with a DNS reply and sends that t
Mu Update Process (Score:2)
I think my process for updating software on my PC provides strong protection.
First of all, I block pushed automatic updates. Instead, I download a complete off-line installer file. I scan the installer file with three different unrelated anti-malware applications that I keep current. If nothing amiss is found, I disable my Internet connection and then execute the installer file.
If it is your ISP ... (Score:1)
.. like hell you want to know! Playing it down:"Adair declined to identify the hacked ISP other than to say itâ(TM)s âoenot a big huge one or one youâ(TM)d likely know.â."
I live in a small country with small providers.
How do you/we secure DNS lookups? (Score:2)
Guessing DNSSEC or whatever, but I don't know the details of it. Or if it helps clients who just know the IP of a server they want to use... Seems you'd have to record certificates and do lookups (which might need DNS) to be able to trust what is received.
Seems a chicken or the egg kind of deal. Or does anything important just rely on IP addresses for everything?
Re: (Score:2)
Data security (Score:1)