Hackers Hijacked Asus Software Updates to Install Backdoors(motherboard.vice.com)
motherboard.vice.com
Hackers Hijacked Asus Software Updates to Install Backdoors
https://motherboard.vice.com/en_us/article/pan9wn/hackers-hijacked-asus-software-updates-to-install-backdoors-on-thousands-of-computers
75 comments
> The negligence it in the design of the system.
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.
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.
> It's just ASUS are extremely incompetent with anything software related, not just security.
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.
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.
yes, free software and open-source did wonders and I am so thankful for all the devs who made it possible, thank you!
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.
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.
That’s why you sign stuff - to
proove the software delivered not only came from the right place/server but contains the code that was packed at buildtime.
THIS is the generic update approach.
ASUS does sign stuff. The problem here is that they won't revoke the compromised certificates...
Asus was actually sued by the FTC a few years ago over poor security practices in their wifi routers.
https://www.ftc.gov/news-events/press-releases/2016/07/ftc-a...
https://www.ftc.gov/news-events/press-releases/2016/07/ftc-a...
Interesting hack, but not really a surprise that attackers are continuing to look at supply chain's to get into targets that might otherwise be quite hardened.
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.
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.
This reminds me of the Runaway Evidence episode from the Ghost in the shell series. An employee with access to the codebase for a military weapons manufacturer manipulates it for their personal reasons
Indeed, this scenario is so ubiquitous that it will certainly continue happening as far into the future as there are human beings, for whatever definition of "human being" you can come up with. One of the first things I learned in the military was that many many things -- which are so shocking as to be almost unbelievable -- never see the light of day and become news stories. It happens so often that I would be willing to bet a hundred United States dollars that your local police department has some not-insignificant percentage of employees (think five or ten percent) that regularly use their patrol car computers for personal reasons, or quasi-personal reasons. I've met more than one police officer personally who genuinely saw nothing wrong with it. They think that it's harmless, or worse, that they're justified in doing so because their intentions are good.
> Buried in those malicious samples were hard-coded MD5 hash values that turned out to be unique MAC addresses for network adapter cards.
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.
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.
It’s a MD5 hash according to the article. I wonder how long it would take to hash 281,474,976,710,656 MAC addresses into MD5? Well wouldn’t have to do all those, find the vendor id’s for ASUS and “just” hash those.
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.
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.
It would take a few seconds (at most) to brute force all of them.
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...
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...
A Nvidia GTX 1080 can do about 20-25 GH/s of MD5. This makes the whole searchspace even without taking the vendor prefixes into account, quite brute forceable. Here is a benchmark of hashcat that gives some insights into the speed of the different hashing algorithms.
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
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
The article at [1] provides both a tool and online form to verify if your MAC address is among those targetted.
[1] https://securelist.com/operation-shadowhammer/89992/
[1] https://securelist.com/operation-shadowhammer/89992/
From my security perspective, this reads to me as if you are confirming to own an Asus laptop bought in that timeframe on a public forum.
Depending how paranoid you are, or should 'secure' you should be because of for example work, I would not have posted this.
Depending how paranoid you are, or should 'secure' you should be because of for example work, I would not have posted this.
Or maybe it’s a misinformation op. Maybe they only buy from Dell and this is to throw people off the scent? Maybe they don’t even own a computer...
Some dude who works in an office in Maryland or Georgia is reading this and thinking "yup, that's us".
The details here scream "state actor".
The details here scream "state actor".
[deleted]
Or Hawaii or Texas
I don’t get it. China Israel n Korea Iran Russia uk France are not shy violets in aggressive hacking. There is also a bunch of up and comers in India and Saudi that are flexing
> Motherboard’s reporting said the backdoor was scanning for some 600 MAC addresses, matching what TechCrunch has learned, and was likely targeted to infect only a small number of victims rather than cause infections on a large scale.
It would be interesting to know what companies/orgs those mac addresses belong to. This sounds very targeted against something specific.
It would be interesting to know what companies/orgs those mac addresses belong to. This sounds very targeted against something specific.
Only 600 were targeted. Stupid question, but is there a scenarios where this isnt a state actor? Who would throw away already infected machines.
I find the precision sort of comforting. One danger of the growth of state-actor malware is that a lot of us could be collateral damage caught in the crossfire. This sort of precise targeting seems at least reasonably responsible. Stuxnet also had careful target selection.
>Stuxnet also had careful target selection.
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.
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.
Yeah, and also NSA has forever compromised part of their mission; to secure US infrastructure. No American company will trust their "help" any more since they've spent so much time subverting our own security.
This talk is all well and good between us here on Hackernews but I don't think your Joe Plumber really cares that these things are going on behind the curtains enough to vote about them, protest, or write his congressman. Look at the "uproar" Snowden caused - it just pushed these activities further under ground within US cyber intelligence.
Rest assured, you'll be caught in the crossfire when they use that targeted access to turn off your power.
Why would they only be interested in 600 MACs as oppose to the numerous others? This is casting a rather large net. Wouldn’t this imply the attacker had knowledge before this hardware was shipped? (why only 600 MAC!?)
Because the headline is misleading. This was not the work of hackers, but spies. It's called a targeted attack.
Perhaps rolling out the full attack gradually, to see if it flies under the radar. The knowledge required might be simply a modulo of the mac.
Why not do it deterministically then? 600 hashes of MAC addresses suggests that it's a very targeted group of machines, it's the size of a moderately large company, for example.
We have seen similar attacks; Stuxnet for example infected over 200,000 machines but only targeted <1000 machines.
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.
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.
"Asus has not informed customers of the vulnerability after it was discovered earlier this year."
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.
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.
According to the article, "The researchers estimate half a million Windows machines received the malicious backdoor through the ASUS update server." I use an Asus computer, but I use GNU/Linux and almost never boot into Windows. Am I affected by the malware? How can I check?
> I use an Asus computer, but I use GNU/Linux and almost never boot into Windows.
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.
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.
this is for people who install the "asus update" software, which is either found on install media cd or can be downloaded from the asus website.
to check/fix: unplug your internet, boot to windows, uninstall "Asus Update".
to check/fix: unplug your internet, boot to windows, uninstall "Asus Update".
If you encrypt your Linux partition you are almost sure to be safe. I say almost, because there could be an attack vector where the BIOS is changed, but that's very unlikely.
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.
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.
> the attack, which Kaspersky Lab has dubbed ShadowHammer
I see we're already hitting a deficit of new names for vulnerabilities.
I see we're already hitting a deficit of new names for vulnerabilities.
We need some sort of security vulnerability name generator.
A google search later and of course it already exists, hahaha:
https://paulbellamy.com/vulnerability-name-generator/
A google search later and of course it already exists, hahaha:
https://paulbellamy.com/vulnerability-name-generator/
I think it's time for my tool (https://github.com/rbanffy/nsaname) to grow beyond Vault 7 and accept patches with suggestions.
I wish Docker and Kubernetes made it simple to plug in host name generators. My clusters would de much much cooler.
I wish Docker and Kubernetes made it simple to plug in host name generators. My clusters would de much much cooler.
It’s probably easy to frame this as closed source versus open source, but honestly this can happen to anyone and I think we have numerous examples of Linux distributions also having their core servers compromised leading to similar risks in distributing malicious software.
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.
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.
I also prefer the open source concept, but I always have--in the back of my mind--the case of Azer Koçulu:
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.
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.
I've noticed how obvious security problems get "discovered" over the years, when people already knew about them. What happens is, someone new finds the bug and makes a big stink about it being exploited. Everyone realizes the bug is a huge problem and then, one by one, every software project with that bug incorporates a fix or mediation. What should have never existed soon becomes another in a line of "standard fixes" that every system afterwards has to account for.
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.
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.
> I've noticed that this mirrors real life.
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.
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.
It's certainly happened to open source projects. If I remember correctly both Handbrake and Transmission had their update mechanisms poisoned with malware.
Does anyone know where to get and verify a known good version if Asus’s software, or identify and clean a system of backdoored software? I ask as an owner of an Asus motherboard.
Depends on what the other payload did. The infected updates checked your MAC and if it matches a list of targets downloaded and executed the 2nd payload. The payload from ASUS itself seems to be pretty tame asking as you were not one of the target machines...
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.
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.
Where are you reading that they've revoked the certs? I've not seen anything that says indicates they've done so.
Sorry, I was sure I read somewhere that ASUS themselves had requested the cert to be revoked but I can't find that site I read that from now to cite other than "ASUS are no longer using that cert" with Kaspersky are saying.
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".
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".
[deleted]
I have an ASUS laptop but fortunately the first thing I did was to replace Windows with Fedora.
The behavior they describe reminds me of Stuxnet: only certain machines seem to be executing a specific payload.
I don't understand why one would allow untrusted IPs to upload software to be spread like this.
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?
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?
Well, the certs were legit. So I guess yeah, in hindsight only allowing certain IPs to be associated with a cert or something would be cool, but damn if I know how to do that on a Windows machine.
No I mean on Asus' side.
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.
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 wasn't a random computer on the internet. It was Asus's actual servers. If they are breached, and you have the ability to sign the packages, it's game-over. This wasn't a case of re-routing.
The update service inside ASUS was broken, so it doesn’t matter what ASUS intended or implemented; the attackers would have just changed that. The second stage installer was totally owned by the attacker.
Perhaps interesting to note: this is a situation where a blockchain could have been helpful.
Yeah I understand that, but how is it possible for a company to put such a service on the network so that it _can_ be breached, that was really my question.
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.
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.
> 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.
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.
Because stupid managers see security as a cost, and possible future security breaks as something that will not happen to them.
From the article it appears that the Hardware management software was hard-coded to use Asus' update servers. that's not an uncommon model from what I've seen.
Unlike Windows updates, firmware/utility/driver updates tend to come directly from the vendor.
Unlike Windows updates, firmware/utility/driver updates tend to come directly from the vendor.
Few interesting bits that are buried at the very end of the article and many might have missed it:
>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...
>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...
Can someone please tell me how I can find out if I'm infected and how to remove it?
Will they be banned just like Huawei?
Looks more like the work of the San Antonio CIA hackers, not Chinese. So most likely not. But the Chinese might try to ban it then. First the Russians will analyze the targets and then you know who did it.
A very good reason to shut down any automatic update software, moreover on a commercial OS.
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.
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.
> A very good reason to shut down any automatic update software, moreover on a commercial OS.
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.
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.
The one logic that is dangerous here is that of blind faith in signing ecosystem.
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.
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.
> 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.
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.
Whats the alternative? Building from source? But wait, what if my compiler was compromised, better build my compiler from source, but wait .... I guess every user on every computer has to write all their own programs in assembly.
Disable automatic update installs, and check if updates being suggested make sense.
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.
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.
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.