High-performance computers across Europe have been shut down, to clear out malware infestations. There’s also evidence of attacks in the U.S.
The outages are delaying research into COVID-19. Some analysts are pointing the finger at China.
The motive seems to be to steal cycles for mining cryptocurrency. In today’s SB Blogwatch, we drive off in our Fiat. [You’re fired—Ed.]
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Kailo nano-babble.
HPC Monero Malware
What’s the craic? Jai Vijayan reports—“Supercomputing Service ARCHER Still Offline After Monday Attack”:
Security and IT administrators at ARCHER, the UK’s national supercomputing service, are still working on restoring services … days after cyberattackers forced it offline. [It] came amid US accusations of … the Chinese government attacking systems and networks belonging to academic, pharmaceutical, and healthcare organizations involved in COVID-19 research.
ARCHER provides supercomputing services to academic researchers and industrial users who need to run large calculations and simulations such as those involved in modeling the COVID-19 outbreak. … When service eventually resumes, all users will be required to use … a password and an SSH key with passphrase to access it.
Its core hardware comprises a Cray XC30 massively parallel supercomuter with 111,080 Intel Ivy Bridge processing cores. [It] is currently being transitioned over to a new 28 petaflops Cray supercomputer with 748,544 AMD cores.
ARCHER said the intrusion on its systems appears to have been part of a broader campaign that had impacted systems across the academic community in the UK and across Europe.
A broader campaign? Catalin Cimpanu has more—“Supercomputers hacked across Europe to mine cryptocurrency”:
Security incidents have been reported in the UK, Germany, and Switzerland, while a similar intrusion is rumored to have also happened … in Spain. … Attackers appear to have gained access to the supercomputer clusters via compromised SSH credentials.
Making matters worse, many of the organizations … had announced in previous weeks that they were prioritizing research on the COVID-19 outbreak, which has now most likely been hampered. …
- bwHPC, the organization that coordinates research projects across supercomputers in the state of Baden-Württemberg, Germany, also announced … that five of its high-performance computing clusters had to be shut down due to similar “security incidents.” …
- Security researcher Felix von Leitner claimed … that a supercomputer housed in Barcelona, Spain, was also impacted … and had been shut down. …
- The Leibniz Computing Center [in Bavaria] disconnected a computing cluster from the internet following a security breach. …
- The Julich Research Center … shut down the JURECA, JUDAC, and JUWELS supercomputers following an “IT security incident.” …
- Malware … infected a high-performance computing cluster at the Faculty of Physics at the Ludwig-Maximilians University in Munich. …
- The Swiss Center of Scientific Computations … also shut down external access to its supercomputer infrastructure following a “cyber-incident.”
Who are we blaming? James Campbell and Chris Doman analyze the “Recent Attacks”:
The details [of the incidents] are all clearly related. They refer to a file called “fonts” used as a loader, and a file called “low” used to clean logs and hide traces of the attacks.
Reportedly it is common for users at different High Performance Computing (HPC) facilities to have logins for other institutions – making it easy for attackers to compromise a number of facilities. … We have identified possible additional victims in the United States.
Logins [were] from andromeda.up.krakow.pl – a compromised host at the University of Krakow. … Compromised machines talk to a crypto-currency pool server at 18.104.22.168. … Another server is 22.214.171.124 – the server at China Science and Technology Network.
Indicators of Compromise … are available in OTX.
Ah, the C-word again. YetAnotherJoeBlow thinks they know why:
The most important process in China at the moment is to be first with the vaccine at all costs. … Their families, their homes, their livelihood, and their liberty all depend on being first.
So some sophisticated hackers, then? Robert C. Helling thinks not—“High Performance Hackers”:
Linux systems … were compromised and the attackers left files in /etc/fonts. … The things I found are not very sophisticated. … Even amateurs like myself with a bit of decompiling could figure out what is going on. Plus leaving your backdoor as a suid program laying around in the file system in plain sight is not very secretive.
If you have an account on one of the affected machines … you should revoke all your secret keys that were stored there … everywhere, not just on the affected machines. And you should consider all data on those machines compromised. … If attackers had access to your ssh private keys, they could be as well on all machines that those allow to log into without entering further passwords/passphrases/OTPs.
Oh. But why so easy? Junta has these educated guesses:
There are a lot of users with access to many of those systems … with just endless attack vectors to get an individuals private data. I don’t even think passphrase protected would have worked because odds are that they would have an ssh agent running during an attack and be able to use that to ssh in. If no agent running, I wouldn’t be surprised if they got a keylogger going to get the key password.
A lot of these systems are lax about security updates, so there is a high chance of a privilege escalation being possible. … I wager this is the impetus to change that norm.
You can gather tons of user private keys. … Then you have more latitude to request compute time as a lot of users.
Wait. Pause. Did Helling imply people were sharing their private SSH keys, for convenience? s2bu furiously facepalms:
Dear g*d no, that’s not how it’s supposed to work AT ALL.
But jabuzz says it’s not uncommon:
Note there are many guides out there on the internet (as I have discovered in the last week) that ****ing recommend not setting passphrases on private SSH keys. This includes bloody RedHat for crying out loud.
Tomorrow I [will] disable all SSH key authentication on the HPC system I administer. I will be replacing all the authorised key files with one owned by root which will then be set immutible.
But what data did they steal? Here’s @PatrickBeuth:
At least 11 supercomputers in Europe were compromised: SSH keys and credentials were stolen, but no other data (as far as we know). Theft of COVID-19 related data was very likely NOT the goal of the attackers.
Some speculation about crypto-mining but no proof. Attackers seem to have hopped from one HPC facility to the next via stolen SSH credentials.
Crypto-currencies? Mr. Dollar Ton has been there, seen that:
I’ve seen quite a few coinminer operations on scientific systems of various sizes. The most endearing one was one a small cluster, where intruders had fought for dominance and one group had won over.
They apparently ran their own maintenance – cleaned up the competition, updated and patched … regularly, set limits on the science computation jobs so that they would run slow and not block the mining.
Really good housekeepers. Too bad the university won’t allocate a budget to hire them, and instead has to rely on things like the cooperation and the outdated knowledge and skills of a random old fart like myself.
Most miners aren’t like that – they take over, kill everything, run the machines at max and get caught quickly by the whine of the jet turbines that do the cooling these days.
Meanwhile, rinie9’s got 99 problems, but indecision ain’t one:
The world’s future is at risk. Countries that both promote and turn a blind eye to these hackers need to grow the **** up and crush these morons.
You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or firstname.lastname@example.org. Ask your doctor before reading. Your mileage may vary. E&OE.