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:Can this be done with just router hacks? (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:Can this be done with just router hacks? (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:Can this be done with just router hacks? (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:Can this be done with just router hacks? (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:Can this be done with just router hacks? (Score:2)
And then access to that repository becomes a gatekeeper for offering anything for those platforms.
Re:Can this be done with just router hacks? (Score:2)
you can add your own repos to an repo system
Re:Can this be done with just router hacks? (Score:0)
Yes. It's the normal mode of operation for commercial routers from "security" companies like BlueCoat, Cisco and Fortinet to intercept DNS and SMTP traffic to fuck with them. Sounds like the ISP may have been using one of those and it was helpfully reconfigured by the hackers.
Comment removed (Score:1)
Re:It's shocking... (Score:3)
Re:It's shocking... (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 have plenty of out-of-App-store things installed myself, and update them regularly. Some do self-updates like this, but more often they just send you to the web site where you download and install things like normal (mount a disk image, and drag to Applications, or run an installer) and you have to once again override the normal security.
Comment removed (Score:1)
Re:It's shocking... (Score:2)
Comment removed (Score:1)
Re:It's shocking... (Score:2)
Comment removed (Score:2)
Re:It's shocking... (Score:-1)
As an example, the 5KPlayer app uses an unsecure HTTP connection rather than an encrypted HTTPS one to check if an update is available
Idiot.
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: It's shocking... (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: It's shocking... (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 package managers do this.
Comment removed (Score:1)
Re: It's shocking... (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.
Comment removed (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?
Comment removed (Score:2)
Re: It's shocking... (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: It's shocking... (Score:2)
Or require DNSSEC, already supported by the OS?
Re: It's shocking... (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: It's shocking... (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: It's shocking... (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 an older legitimate version that was vulnerable to attacks. (I.e. A downgrade attack.)
Re: It's shocking... (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: It's shocking... (Score:2)
Re: It's shocking... (Score:2)
Re: It's shocking... (Score:1)
The solution is cryptographically signed updated. You'll notice that no Linux distros were implicated in this incident.
Re: It's shocking... (Score:1)
updates*
Re:It's shocking... (Score:0)
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 unsigned code that you have to override, and presumably even after you got the bad update you'd have to force it to run again...
Comment removed (Score:2)
Re:They do not... (Score:0)
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.
I've not checked how securely they update, but one would hope that they follow industry norms of code-signed packages that are validated before installation.
Re:They do not... (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:this is what you get (Score:0)
Does MS charge an excessive margin?
Of course they do.
Can you imagine projects having to pay to be in the Debian repos?
Your typical Linux distro tires to include as many packages as possible, because they want the users to have software.
Re:this is what you get (Score:0)
Your typical Linux distro tires to include as many packages as possible, because they want the users to have software.
No, your typical Linux distro has a community of volunteers that support packages they use. This is important because they then know if the app works properly. The typical end user doesn't file bugs, they simply don't use the app if it has issues or move to another distro.
Can you imagine projects having to pay to be in the Debian repos?
No app has to actually be in an official repo if the package manager is properly designed. Take Plex Media Server for example. They've had a repo for years for RPM based distros and for at least two years its been broken on several distros that don't accept packages signed with only SHA1. So no, app makers don't need to pay anyone to be in official repos but it does help if your apps repo follows the standard set by major distros package managers.
Re:this is what you get (Score:0)
Microsoft is a company owned by that group, like intel, for example. Of course they are going to charge an outrageous fee for anything, still perform poorly, outsource their core tasks to cheaper and cheaper subcontractors, deny any shortcomings until they're impossible to hide, blame everyone else for anything, lock you out at random whenever they feel like you or anyone you've ever known said something bad about their group, buy out any competitor with cheap money from your group's friends in Wall St., lobby your way with your group's senators in DC and still fail to produce a good and secure product with reliable maintenance. Everything they do is constantly changed to make more money, lock in customers more, make them own less, gain any advantage, no matter how small, with any trick, no matter how despicable and underhanded, lie, trick, steal and then just for good measure, lie lie lie some more and deny even the most obvious things. If anything doesn't perform, they'll relentlessly kill it, rename it, rebrand it until it does. The people in this group routinely change their own names and countries like you and I would change t-shirts and they do the same with their branding and product names.
Instead, like all their group's companies, they're focusing all their money on marketing, psychology, CYA, legalese and CEO bonuses. And when the CEOs are rotated out of the company for whatever reason, they get another 200 million severance pay and the chance to participate in one of the group's innumerable "NGO" and "philantropy" spinoffs either hell-bent on promoting mass migration to replace the people in the West and / or make them exclude themselves from any future gene pools one way or another or make their procreation harder - or take a specific and laser-focused approach on "caring" for weakly attached, orphaned or war-torn children, who often go missing later.
So of course they would LOVE nothing more than to take over software distribution onto their platform, so they can charge insane fees for this service and switch off any competitor at will for bogus violations of poorly defined terms and conditions, But as all their group's projects, it is hampered and ultimately crashed by insufferable greed and neurotic control freakery meeting terminal incompetence.
Imagine that you asked the worst IQ 120+ antisemite imaginable in 1970 how they would predict how Microsoft and intel would start their business and rise to world dominance and what their leaders would do while CEO and afterwards.
Re:this is what you get (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:DNS over HTTPS (Score:2)
Re:DNS over HTTPS (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:DNS over HTTPS (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:DNS over HTTPS (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:DNS over HTTPS (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:DNS over HTTPS (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 transit.
Re:DNS over HTTPS (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:Something seems fishy... (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 means something got fucked up on the client's side, and it had nothing to do with your code.
what this did is completely remove issues with the install vector, hijacks, and such.
If the code isn't signed, then this won't help you much. As the attack in the summary shows, a host can be tricked by the network into downloading unintended data. The real question here is why updates are allowed over random untrusted connections by default, but then again, this is digital signature crap we're dealing with. (Which aren't really trusted by the majority of end users let alone any sysop worth their pay to begin with.)
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.
Again, this won't help you in the summary's attack. The packets meant for the CDN will be redirected just as much as anything else. At best, a company network might help you in this case assuming the attacker didn't redirect internal subnet traffic and your corporate servers are on a non-public subnet.
Finally, a list of signed hashes is slapped on the website, just in case.
Which could be stripped off or replaced. (Think about downgrades to older legitimate versions that are vulnerable to attacks.) A saved copy of the site from archive.org might be enough here. Unless the downloader also checks that the version on the site isn't older than the one it has installed currently.
To be fair this kind of attack is rare. Normally, DNS is the target and not the network's routing table. The latter of which requires very privileged access to said network. That being said there's not much that can be done here without radically changing how networking works at layer 3. (Either some new replacement protocol like China's proposal or mass IPSec deployment, both of which have their own problems.) That or preventing idiots from running updates on insecure networks. (Which is probably the easier option.)
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:DNS attack details (Score:2)
Google how does DNS spoofing or poisoning work. Here's an example: https://www.imperva.com/learn/... [imperva.com]
Re:DNS attack details (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 can target an intermediate name server and exploit weaknesses in its caching system to perform a Man-in-the-Middle (MITM) attack.
For instance, ARP effecting which DNS servers are used, while reasonable, shouldn't impact people who have manually pointed their DNS at 8.8.8.8 unless the route the ISP was sending traffic on was hijacked to think Google/Cloudflare was somewhere else. (Which would be pertinent info)
Modifying the authoritative DNS server's records, now this could happen sure, but doesn't sound to be what happened in the article where it was capturing everyone on the ISP.
Intermediate name server absolutely makes sense, but again I'm not seeing how this would affect the results of people who actually are pointing their DNS to 8.8.8.8 for instance. This would again only impact people who are using the ISP's DNS.
But as the article said on the attack:
> 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.
Which again, brings me back to, what specific method was being used to intercept, and manipulate, the packets being sent back from Google or Cloudflare. I'm not saying it's impossible, I'm saying I want to know the CVE for the router exploit that was used, as it's pertinent information for anyone and everyone else with routers that reach the public facing Internet.
Re:DNS attack details (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 to your computer before the real DNS server has a chance to reply.
NOTE: I can't confirm that's literally what they did, but it sure sounds like it.
FWIW, this is similar to some of the enterprise IDS/IPS systems that sit network level. Traffic doesn't route *through* them, so it can't directly block traffic. However, it listens to all traffic on the network and can respond when it detects offensive patterns. When it does, it can do things like issue forged packets to close the connection (sending the correct TCP packet to your computer to tell it to close the connection).
As an example, a company I had worked for ran into an issue with some of the FTP accounts - turned out to be the IDS/IPS.
The connection would be established with the FTP server.
Username passed in - that was fine.
Password passed in - connection would be closed.
Turns out, a long FTP password was a pattern used in some ancient FTP server exploits, so the IDS/IPS saw that and sent a connection close to the FTP server and back to the user.
I mention that because it could just as easily inject a forged DNS response.
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:How do you/we secure DNS lookups? (Score:2)
Data security (Score:1)