Hackers Hijacked Asus Software Updates to Install Backdoors
motherboard.vice.com
motherboard.vice.com
I have an asus laptop that I use for gaming, most likely it had their cruft running at some point. What would be the most viable path to sue?
It is so frustrating and frightening to take security seriously yourself, to have taken precautions, to find out that your idiotic manufacturer has screwed it up in an idiotic way.
Their update system should never have been designed in a way to make this possible. The negligence it in the design of the system.
https://www.ftc.gov/news-events/press-releases/2016/07/ftc-a...
Not sure. It seems like a fairly generic update approach. eg a central server(s) provides available updates, with client software on the PC checking for them.
As a concept, that's what MS and Apple's update approaches (for consumers) do too.
It's just ASUS are extremely incompetent with anything software related, not just security.
Hopefully this, plus the previous fine for their incompetence, gets their leadership to change things in a positive way.
Hardware companies are extremely incompetent at anything software related, we see this in everything from PC's and phones (touchwizz, htc sense) right down to TV's and various IoT devices. I can't imagine what the PC industry would like like if luck hadn't delivered us an open platform.
On the other hand, there is a growing number of insecure and closed IoT garbage devices. It will be common to see a wifi attack coming from a breached water kettle.
From what I've seen of PC laptops, in many cases (especially with companies that don't usually have large corps as customers) they don't provide the option for corporates to enforce downloads of firmware/utilities from a company controlled source, so they'll come from the vendor's central location.
So Asus' risk profile isn't going to include good defences against high-end/state-level attackers, so it's a nice vector for one of that class of attacker to get into companies who are customers of Asus'.
It would seem like the attacker must have had some foreknowledge of what systems they wanted to target (i.e. that their target used Asus laptops) but that's not impossible to achieve.
Having access to those MAC address (or their MD5 hashes) could be interesting. I would like to verify if my MAC was among those target to do deep inpection in my whole infrastructure. I'm not sure Kapersky was able to determine all those 600 MAC addresses to contact specific companies.
EDIT: Looks like Kaspersky have published tools to check if your MAC was one of those targeted - https://securelist.com/operation-shadowhammer/89992/ don’t think they have published the whole list. Just a checker app and a webform to check. The checker app _may_ contain the whole list.
Looks like they there updating the list of MACs over time (rules out my initial thought of them targeting an purchase order to get hand full of people who would of gotten machines from that order) as it seems that Kaspersky pulled the list of MACs from about 200 samples.
The vendor IDs in a laptop/desktop would be a limited set (Realtek, Intel, Atheros, Broadcom are the big names off the top of my head), each company has a few vendor IDs but still it's a small search space. Here are my notes from the calculation:
48 bits / 6 bytes per MAC
Vendor ID is 6 hex digits = 3 bytes / 24 bits
https://www.brandonfoltz.com/2014/09/how-fast-is-md5/ 2014/09: Core 2 Duo e6550 @ 3 GHz does 427 MB/s with one process, DDR2-800 RAM
Modern cpu: 4.5 ghz @ 8 cores * 1.25x IPC and RAM improvement (RAM has come a long way since DDR2, but in the article he was CPU bound so that's probably still the bottleneck)
= 427 * (4.5/3.0) * 8 * 1.25 = 6.4 GB/s
24 bits of actual MAC left per vendor = 16,777,216 MACs/vendor
16.8 million * 3 bytes = 50.4 million bytes per vendor
6.4 GB / 50.4 MB = almost 1300 vendor prefixes per second
The website listed above provides MD5 hash rate in MB/s (on a CPU, too). A few other sources I found provided hash rates in hashes/sec instead, such as this StackExchange saying that 1.3 billion SHA-1 hashes/sec are possible on a old GPU. SHA-1 is more complex than MD5, and GPUs are still following Moore's law very well, so it would be trivial to brute force this.
https://security.stackexchange.com/a/8609
Source for vendor IDs: https://gist.github.com/aallan/b4bb86db86079509e6159810ae9bd...
https://gist.github.com/epixoip/a83d38f412b4737e99bbef804a27...
A recently released tool also allows you to do all this on AWS for quite cheap without any big investment in hardware. https://github.com/Coalfire-Research/npk
Depending how paranoid you are, or should 'secure' you should be because of for example work, I would not have posted this.
The details here scream "state actor".
It would be interesting to know what companies/orgs those mac addresses belong to. This sounds very targeted against something specific.
The NSA also had stuff like eternalblue lying around instead of getting it patched, the polar opposite being responsible. I doubt that there is such a thing as responsible hacking by state actors. They know of and are actively exploiting weaknesses that are a danger to all of us.
600 MAC’s from one vendor. I would like to have a look at that list (not gone looking for it yet).
I wonder if the MAC’s are close together, maybe just a block of 600 (I.e XX:XX:XX:XX:XA:AA TO xx:XX:XX:XX:XB:BB instead of a list of 600 hashes embedded)?
If so I would suspect that the attacker was aware of a company purchasing a number of machines from ASUS, had access to one of those machines in one way or another. Knew someone important had a machine from that batch and burnt access to a hardware vendors signing key to gain access...
But it raises so many questions. How were ASUS storing their signing keys? How did the attacker gain access to the signing key and access the updates server (though if they had crap cert/key security it’s not that much of a jump to presume they didn’t look after their updates servers either). And why would they burn that access over such a small number of possible targets (instead of say, infecting every machine with a bad update that a) stops future updates b) encrypted the users data and then wipes out the UEFI of every infected machine if a ransom isn’t paid by X date? Think of the damage to a brand if 10,000 (a low number of machines that ran the payload according to the article) destroyed and bricked it’s customers data and machine all at the same time? Would they refuse to pay up?
All I’m saying is, access to that small number of machines much of been worth a decent amount to the attackers to burn access to a large vendors update servers and signing keys...
EDIT: Wait a minute....
> The attackers used two different ASUS digital certificates to sign their malware. The first expired in mid-2018, so the attackers then switched to a second legitimate ASUS certificate to sign their malware after this.
So they were in for a fair amount of time for a code signing cert to expire on them so they needed access to a 2nd... Ouch.
This is typical of Asus, isn't it? After that Windows update last year or so broke their ROG motherboard software and it wasn't fixed for over a month, you'd think they would have learned by now.
It probably depends on whether your computer came with windows pre-installed (not good), or you've ever installed the ASUS provided "ASUS Update" utility software for Windows.
It's a specific download, that you'd need to manually install.
AFAIK, most (tech) people consider it bloatware, so don't.
If your computer came with windows pre-installed though... uh oh.
to check/fix: unplug your internet, boot to windows, uninstall "Asus Update".
If you don't encrypt your Linux disk (which you should), you're still very likely safe. It's possible but unlikely that the backdoor would check for a Linux partition and then install an extra backdoor on the Linux side.
I see we're already hitting a deficit of new names for vulnerabilities.
A google search later and of course it already exists, hahaha:
I wish Docker and Kubernetes made it simple to plug in host name generators. My clusters would de much much cooler.
That said I’d rather be running an operating system with reproducible builds based on open source software. I suspect problems like this would have been more quickly discovered, before hundreds and thousands of users were affected.
https://qz.com/646467/how-one-programmer-broke-the-internet-...
I recognize that it's a leap to go from deleting a repository to converting it toward malicious intent (although sometimes it's likely not as big of a leap as we think), but as open source continues to build libraries on top of other libraries we do open ourselves to the risk that one of those innocuous libraries, at some point in the future, could end up causing issues.
The other problem is that open source users often expect that the "crowd" will discover and identify issues fairly quickly because everyone is looking for them. But not everyone is looking for them. I can probably count on two hands the number of times I've gone through the source code of the libraries that I use, and I suspect most others are in a similar position. We all expect some bored soul in the world is doing the looking, but the truth is that they'll only start looking if something breaks.
There are things that (in retrospect) should be a standard part of all open source supply chains. Basic code vuln scanning, code signing+verifying, reproducible builds, redundant copies of code, and licenses permitting keeping code around to prevent breaking other code. But they're not standard - yet. So one by one, we have to run into these problems and break things before they're addressed and later become de-facto standards.
I've noticed that this mirrors real life. In real life you can notice that an intersection is dangerous and needs a stop sign. But until a schoolbus full of children is plowed into, nobody lifts a finger. It's the same in technology. You can't just mention the big potential problem; you have to wait for the explosion.
I spent months trying to get websites on the internet to mention that the default options they suggest for ssh-keygen are fundamentally insecure and dangerous, and while all of them acknowledge this is a fact, most of them won't update their guides. Not until someone creates a virus that finds and exposes vulnerable ssh key passwords around the world. Then all of a sudden whatever implicit bias they had against doing the work will disappear, as fear of impending consequences takes over.
This is because taking additional or remedial actions is work. That work has to be justified against a hierarchy of needs. Until that justification is credible enough, work will be allocated elsewhere.
Check you MAC here https://securelist.com/operation-shadowhammer/89992/ (which also contains infor about some of the payloads, apparently there was over 200 samples found by Kaspersky). If you dont match you “should” be fine. But who know where the “update” was installed to to purge it from the system. A full wipe may be in order (or wait a short while and allow the various AV engines get hold of the signatures of the first stage malware and allow them to scan your machine).
If you were on the target list then who knows what the secondary payload contained... Though as it was just a small number of MAC’s targeted and if you were targeted the device maybe more valuable to you and others untouched so it can be analysed then the cost of a replacement and trying to figure out why you were targeted.
As for where to get known good software. ASUS used to have an ftp site with all their stuff on it, dunno if they still do. This attack seems to be targeting the live update method so downloads from the support page for your model are probably fine... But it would be on ASUS to come clean and report on what and when got infected to be sure. They have revoked the certs used to sign the updates, you could check any downloads from ASUS to see if the cert matches just in case MS has yet to push the irrevocation to everyone or just stick with the stock drivers from MS until everything is sorted out.
ASUS are using a new code signing cert though, but it is dated from earlier today so maybe it was "ASUS are due to revoke the cert".
Putting new updates on such a system should be part of a process with many checks on the way to verify the authenticity of the software?
Unlike Windows updates, firmware/utility/driver updates tend to come directly from the vendor.
Like you should have a very specific procedure to put files on the server not let a random computer on the internet do it without an approval process.
It shouldn't have the place where you put the update files exposed to the internet at all. Unless it was an inside job somehow.
The way it's described it almost sounds like the service exposed to the internet had write access to the files.
A service exposed to the internet gets to decide what it sends to end users. Compromise that, it can replace the stuff sent on the fly.
Not saying that's what happened here, just pointing out that not having "write access to the files" isn't a guaranteed win either.
Depending on what else the attackers had access to (executables key signing pieces?), likely determines the approaches they took.
>They said they found similarities between the ASUS attack and ones previously conducted by a group dubbed ShadowPad by Kaspersky. ShadowPad targeted a Korean company that makes enterprise software for administering servers; the same group was also linked to the CCleaner attack. Although millions of machines were infected with the malicious CCleaner software update, only a subset of these got targeted with a second stage backdoor, similar to the ASUS victims. Notably, ASUS systems themselves were on the targeted CCleaner list.
>The Kaspersky researchers believe the ShadowHammer attackers were behind the ShadowPad and CCleaner attacks and obtained access to the ASUS servers through the latter attack.
>“ASUS was one of the primary targets of the CCleaner attack,” Raiu said. “One of the possibilities we are taking into account is that’s how they intially got into the ASUS network and then later through persistence they managed to leverage the access … to launch the ASUS attack.”
These attackers have planned this for a very long time. CCleaner was just collateral damage in NSA's quest to infiltrate high-value OEM targets. The NSA probably also got HDD firmware source code and certificates through a similar "shotgun" approach.
I also found this part interesting (from [0]):
>Although precise attribution is not available at the moment, certain evidence we have collected allows us to link this attack to the ShadowPad incident from 2017. The actor behind the ShadowPad incident has been publicly identified by Microsoft in court documents as BARIUM. BARIUM is an APT actor known to be using the Winnti backdoor. Recently, our colleagues from ESET wrote about another supply chain attack in which BARIUM was also involved, that we believe is connected to this case as well.
Which leads to a copy of the lawsuit filed by Microsoft against BARIUM actors [1].
I wonder what the status of this lawsuit is when the defendants are probably the NSA employees. Even Microsoft gives lots of hints about BARIUM being the NSA. They even filed it in Eastern District of Virginia, Alexandria Division, Federal Court... which is one of the favorite places where intelligence agencies file criminal complaints. I bet the US Gov will stonewall and ask the MS to drop it.
[0] https://securelist.com/operation-shadowhammer/89992/
[1] https://www.courthousenews.com/wp-content/uploads/2017/11/ba...
The whole "signing infrastructure" thing stops working when the amount of parties involved exceeds n=2.
When you have 10+ parties involved, the chance of missignage gets very real. Even if the signing is done on a "black box" as per best practice, it offers no protection if signing decision is made by a party with blind trust in incoming packages as happens in a big company setting.
This is dangerous and irresponsible general advice. 99.9999…something percent of users will be better off getting updates on a schedule more recent than “never”. Following your advice would simply mean that millions of people get rooted because they postponed the updates for things which were known threats in the wild.
The very small percentage of high-value targets are the ones who can consider this because they also have defense budgets measured in the millions and can afford to do things like inspecting updates and aggressively monitoring for changes in network activity, etc.
What it does tell you is that there is a cost to using software from companies with lax security practice such as ASUS:
> Kamluk said ASUS continued to use one of the compromised certificates to sign its own files for at least a month after Kaspersky notified the company of the problem, though it has since stopped. But Kamluk said ASUS has still not invalidated the two compromised certificates, which means the attackers or anyone else with access to the un-expired certificate could still sign malicious files with it, and machines would view those files as legitimate ASUS files.
That's a good cue to suggest that if you're security conscious you want to pick vendors who share that value.
MITM on windows update with forged certificate few years ago was just few minutes away from being a global emergency for Windows users. The only thing that kept it contained was that attackers did not figure out to hijack routing to real windows update servers.
For 99% of users using windows update, that would've been an instant virus install - so much for security.
The only security measures that are worth implementing are, obviously, the ones which work.
Which is why I don't think the right answer is taking steps which ensure users won't install security updates. The scenario you mentioned is better addressed by other means — CA pinning, certificate transparency — and, unsurprisingly, those are the measures being implemented on a wide scale.
It is even more easier for Windows users, as updates for you come in big clumps, and truly emergency level security updates do get into mainstream news.