Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Criminelen misbruiken Europese supercomputers voor cryptomining

Meerdere supercomputers in Europa zijn stilgelegd na beveiligingsincidenten. Daarbij werd software aangetroffen om cryptovaluta monero te minen. De criminelen kregen toegang via gekaapte ssh-logins.

Vorige week vonden beveiligingsincidenten plaats bij supercomputers in Duitsland, het VK en Zwitserland, en vermoedelijk ook in Spanje. Vorige week maandag kondigde een onderzoeksinstituut in de Duitse deelstaat Baden-Württemberg aan dat vijf van zijn clusters last hadden van beveiligingsincidenten.

Donderdag meldde het Leibniz Computing Center een computingcluster van internet te hebben afgesloten na een beveiligingsprobleem en vrijdag volgden drie supercomputers van het Duitse Jülich Research Center en de Taurus-supercomputer van de Technische Universiteit Dresden. Zaterdag bleek bovendien een supercomputer van de Ludwig-Maximilians-universiteit in München getroffen te zijn.

In Zwitserland is de externe toegang tot een supercomputer van het Swiss Center of Scientific Computations stopgezet na een cyberincident en in het VK heeft de University of Edingburgh zijn Archer-supercomputer uitgezet na misbruik van logins. Volgens beveiligingsonderzoeker Felix von Leitner is daarnaast een supercomputer in Barcelona getroffen. ZDNet zet alle incidenten op een rij.

Een verband tussen de incidenten is nog niet bewezen, maar het Computer Security Incident Response Team voor de European Grid Infrastructure rapporteert over twee incidenten en claimt dat een criminele groepering zich op academische datacenters richt om cryptovaluta te delven en van het ene op het andere slachtoffer overspringt via buitgemaakte ssh-inloggegevens.

Het responsteam heeft bij zijn onderzoek software om de cryptovaluta monero te minen aangetroffen en meldt dat is ingelogd via de netwerken van de Poolse Universiteit van Krakow, de Shanghai Jiao Tong University en het China Science and Technology Network. De groepering gebruikt verschillende technieken om de activiteit te maskeren waaronder een Linux-rootkit en log-cleaners. Ook draaien ze de miner in sommige gevallen alleen 's nachts. Volgens het team richt de groepering zich ook op instanties in China en Noord-Amerika.

Cado Security heeft een eerste korte analyse van de incidenten gepubliceerd en een werknemer van het Leibniz Supercomputing Center heeft enkele door de criminelen gebruikte bestanden ontleed.

Archer, of Advanced Research Computing High End Resource, van de univeriteit van Edingburgh

Door Olaf van Miltenburg

Nieuwscoördinator

18-05-2020 • 09:24

119 Linkedin

Reacties (119)

Wijzig sortering
https://www.cadosecurity.com/2020/05/16/1318/ :

“I work in HPC in the UK. Yesterday I had to revoke all the SSH
certificates on our system because unfortunately some f’ing idiot users
have been using private keys without passcodes. These have been used to
hop from system to system as many HPC users have accounts on different
systems. They are managing local privilege escalation on some systems and
then looking for more unsecured SSH keys to jump to other systems. They
maybe using one or more methods for the privilege escalation, possibly
CVE-2019-15666. Right now the UK national facility ARCHER is off line as
they have suffered a root exploit.

The actors are coming from the following IP addresses, 202.120.32.231 and
159.226.161.107, you get zero guesses which country these are from.”
Ligt wellicht aan in welke branch je zit voor je dit als 'natuurlijk dom' beschouwd. En ik vermoed dat hij de schrijver dit niet het enige incident is op z'n systemen en de frustratie van eerdere incidenten ook doorschemert. :)

Jaren geleden zou ik denk ik dezelfde vraag gesteld hebben, en het wellicht wat overdreven vinden. Maar het tegendeel, een key zonder passphrase op een computer die niet geheel onder jouw fysiek beheer valt, moet je eigelijk al als compromised beschouwen. (NB dus ook als deze machine tijdelijk niet onder jouw fysiek beheer valt, diefstal, douane doorzoeking etc). En dus is het best practice om simpelweg nooit een key zonder passphrase te gebruiken en daarmee bv bovenstaande te voorkomen.

Inderdaad zoals sommige schrijven, als de keyfile dmv hack op een computer bemachtigd is, dan is keyloggen tot de passphrase voorbij komt een gevaar. Maar security is niet een oplossing voor alles, het zijn de lagen op lagen op lagen security die het inbrekers lasten maken en f*ing idiot users moeilijk maakt het per ongeluk te verpesten.
Een SSH key is m.i. niet primair bedoeld om makkelijker/sneller in te loggen dan met standaard wachtwoorden. Het is bedoeld om veiliger toegang te kunnen verlenen. Het is namelijk authenticatie op basis van iets dat je weet (de passphrase) én iets dat je bezit (de private key), en niet alleen op basis van iets dat je weet (je wachtwoord). Dat lijkt me inherent veiliger. Als je het irritant vindt dat je bij elke login een passphrase moet gebruiken heb je hier ook agents voor, maar het lijkt me dat je dan wel moet zorgen dat je agent niet zomaar toegankelijk is.

Bovendien: vaak wordt een private SSH key gebruikt als een identiteit voor een host, en met die identiteit kun je dan op meerdere andere hosts inloggen. Als je een key zonder passphrase hebt, kan een kwaadwillend persoon meteen toegang krijgen tot meerdere hosts. Des te meer reden om voorzichtig te zijn met je SSH keys.

Als je machine dan gestolen wordt en je hebt een SSH key met afdoende bitlengte en met een passphrase, zou ik sowieso wel zsm de public keys verwijderen van de hosts maar je loopt veel minder gevaar.

[Reactie gewijzigd door gday op 18 mei 2020 15:31]

Passwordless ssh keys worden vooral gebruikt door automatische processen (scp/sftp/ansible). Normaal beperkt je ook de IP addressen waar de login van vandaan kan komen. Ik kan bijvoorbeeld vanaf thuis niet direct inloggen op onze servers. Ik moet daarvoor eerst een (ipsec) VPN verbinding hebben. Vanaf kantoor is er een VPN tunnel.

Het beperken van een SSH key tot een aantal IP adressen is op zich erg simpel:
Ga naar de 'authorized_keys' file en voeg 'from="x.x.x.x,y.y.y.y,z.z.z.z" toe aan het begin van de regel (voor 'ssh-rsa' gedeelte). Je kunt ook eventueel een subnet opgeven.

Alleen kun je aan een public key niet zien of bij bijbehorende private key (van de client) geen password heeft. Je kunt op elke moment het wachtwoord van je private key veranderen (of verwijderen) zonder dat dit gevolgen heeft van je public key.

Echter het gebruik van passwordless keys door natuurlijke personen is zeker slecht en zeer dom. Maar ik denk dat veel git users met een SSH credential daar ook een passwordless key gebruiken zodat ze het wachtwoord niet bij elke actie opnieuw hoeven in te voeren..

Het komt altijd neer op gemak vs veiligheid. In dat geval kun je beter geen ssh keys gebruiken voor reguliere gebruiken en terugvallen op het oude login/password principe welke nog steeds encrypted naar de server wordt gestuurd. Met PAM/LDAP heb je centraal password management. Vervolgens kun je een web interface maken welke eisen stelt aan het wachtwoord..
Tenzij je je wachtwoorden ook in een .txt naast je ssh-keys hebt staan is een wachtwoord veiliger, want dan kunnen ze niet als jou inloggen als ze botweg de file kopieren, maar moeten ze nog op jouw computer gaan proberen te intercepten wanneer jij het wachtwoord intypt. Dat betekent dat ze dingen moeten laten draaien als een keylogger, analyseren achteraf wat erin staat, en pas dan een poging kunnen doen om verder te hacken. Nu is het gewoon 'even rondsnuffelen', file kopieren en hoppa, verder. Vergeet niet dat dit soort inbraken vaak een race tegen de klok/sysadmin zijn, dus hoe meer vertraging hoe beter.
Voor het kopiëren van de key heb je alleen leesrechten nodig, voor het installeren van een keylogger heb je meer rechten nodig. Daarnaast moet de keylogger draaien op het moment dat je je ww invult. Dat zorgt er voor dat er meer tijd nodig is voor misbruik en dus meer kans op het ontdekken van de inbraak. Daarnaast ga je wel heel erg uit van jou specifieke situatie, 1 PC op 1 locatie en super encrypted. Dat is niet de 'normale' situatie waarbij dit vaak misgaat, zeker nu niet nu veel mensen vanuit huis werken.
Daarom, eerst een IPSEC VPN en daarna pas SSH.
Wat is het nut om zo'n cluster direct aan het internet te hebben hangen?
Niet dus. Niets houd je tegen om nu naar alibabacloud.com te gaan en een VPS in mainland China te huren om als proxy te gebruiken. De enige vereiste is dat je je registreert met je persoonsgegevens want real-name verificatie is een wettelijke verplichting voor het huren van een VPS in China, maar alsof criminelen geen toegang hebben tot valse identiteitsbewijzen. En zelfs dan nog, er zijn talloze resellers op Taobao die je maar al te graag zonder identiteitscontrole VPS toegang in mainland China verkopen.

Je bent dan wel gelimiteerd tot wat toegelaten is door de GFW, maar zaken zoals universiteitsnetwerken zijn helemaal niet geblokkeerd. Ik kan vanuit China gewoon inloggen op de HPC van mijn universiteit in Europa via SSH. Zonder VPN.

En zoals @supersnathan94 ook al aangaf, deze IPs zijn onderdeel van CERNET, het Chinese nationale netwerk voor onderwijs en onderzoek (vergelijkbaar met BELNET in België). Onder andere universiteitsstudenten zitten op dit netwerk. Meer zelfs: alle grote universiteiten in China hebben Eduroam. Gewoon inloggen met de inloggegevens van jouw onderwijsinstelling en tadaa, je zit op CERNET. Het is niet ondenkbaar dat in dit netwerk een aantal geïnfecteerde devices zitten die zo gebruikt zijn als proxy.

Uiteraard kunnen het ook gewoon Chinezen zijn geweest, maar dat zou wel erg lui zijn voor hackers die verschillende HPCs plat kunnen krijgen.

[Reactie gewijzigd door Joecatshoe op 18 mei 2020 12:28]

Ja. En voor bedrijven dus wel degelijk mogelijk om te gebruiken.

Maar als je de mogelijkheden hebt om in een hele berg supercomputers te SSH-en dan is de kans heeeeeel groot dat je goed weet wat je doet.

edit: zoals ik ook al dacht. met een ARIN search kom je achter een hoop details. geregistreerde gegevens bij het tweede IP adres komen uiteindelijk uit bij:

descr: CHINA SCIENCE AND TECHNOLOGY NETWORK
descr: No.4, Zhongguancun 4th South Street,
descr: Haidian District, Beijing

waarschijnlijk is men daar eerst naar binnen gedrongen.

[Reactie gewijzigd door supersnathan94 op 18 mei 2020 10:49]

Wie zegt dat ie gehuurd is?

We gaan er met zijn allen vanuit dat het hier gaat om legale activiteiten. ik heb dit argument al drie keer voorbij zien komen. Als buitenlander is het extreem simpel om met een VPN binnen te komen. Dit omdat Chinese bedrijven ook gewoon internationale medewerkers hebben en dus ook VPN verbindingen om met ineterne netwerk te kunnen babbelen.

Sterker nog er zijn gewoon onderzoeken van Chinese universiteiten over hoe je een goed netwerk opzet voor universiteitscampussen met daarin IPsec VPN technologie: https://books.google.nl/b...Y%20NETWORK%20VPN&f=false

VPN's zijn in china echt niet zo'n ding als dat je nu schetst. Dat gaat prima, mits je de juiste dingen ermee doet.
Blijft bijzonder: kun je via het 'gewone' internet met een simpele SSH inloggen op zo'n machine dan? Ik heb niet het idee dat die dingen airgapped zijn maar op z'n minst aan meerdere kanten door firewalls beschermd worden wie er wanneer en onder welke voorwaarden mag inloggen vanaf een vastgesteld IP-adres of subnet...

Dan heb je een login gekaapt, prima, maar dan nóg moet je het bijbehorende IP adres spoofen (intern) om door de firewall heen te komen, je software te kunnen uploaden (DPI anyone?) en uitgaand verkeer open zetten om ook iets aan je resultaten van de miner te hebben lijkt me.

Klinkt wel alsof er méér loos is dan alleen maar gekaapte SSH-logins.....
De werknemer die de analyse heeft gedaan probeert daar antwoord op te geven:

What all this does not show: How did the attackers get in in the first place (possibly by stealing some user's private keys on another compromised machine), how they did the privilege escalation to be able to produce a suid-root file and also, for how long they have been around. As you can see above, the files have a time stamp from over two years ago. But once you are root you can of course set this to whatever you want. But it's not clear why you wanted to back date your backdoor. I should stress that I am only a normal user on that server, so for example I don't have access to the backups to check if these files have really been around for that long.

Furthermore, the things I found are not very sophisticated. Yes, they prevented my to find out what's going on with strings by obfuscating their strings. But the rest was all so straight forward that even amateur like myself with a bit of decompiling could figure our 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 (but possibly enough to be undetected for more than two years). So unless these two files are not explicitly there to be found, the attacker will not be the most subtle one.

Which leaves the question about the attacker's motivation. Was it only for sports (bringing some thousand CPUs under control)? Was it for bitcoin mining (the most direct way to turn this advantage into material gain)? Or did they try to steal data/files etc?


Op het eerste gezicht lijkt het dus niet een echt een echt ingewikkelde hack maar we zullen meer onderzoek moeten afwachten. De privilege escalation zou het kunnen bepalen of het 'gewoon' een student was of een georganiseerde groepering.
Uit die korte analyse die genoemd wordt:
I work in HPC in the UK. Yesterday I had to revoke all the SSH certificates on our system because unfortunately some f’ing idiot users have been using private keys without passcodes. These have been used to hop from system to system as many HPC users have accounts on different systems. They are managing local privilege escalation on some systems and then looking for more unsecured SSH keys to jump to other systems. They maybe using one or more methods for the privilege escalation, possibly CVE-2019-15666. Right now the UK national facility ARCHER is off line as they have suffered a root exploit.
...dus de eerste stap is dat er private keys van gebruikers van deze supercomputer gelekt zijn - en dat deze private keys niet extra met een passcode beveiligd waren. Tja, iedereen kan z'n sleutels kwijtraken - maar dan geen passcode is wel jammer. Zou mooi zijn als dat server-side afgedwongen kan worden: alleen private keys toestaan *en* alleen als die ook passcode beveiligd zijn.

Daarna is het 'gewoon' een linux systeem met z'n kernel en bijbehorende beveiligingsproblemen. Elk OS heeft beveiligingsissues en bij dit systeem was er blijkbaar iets wat zorgde dat ze software als root konden draaien. Tja, dan ben je er wel.
Tsja, hoe het meestal gaat met dat soort systemen is dat je een SSH key gebruikt zodat je niet steeds wachtwoorden hoeft in te vullen bij inloggen.
Als je dan een phishing mail met een kit/virus-achtig iets stuurt naar onderzoekers die dergelijke keys jatten van hun PC dan gaat er vrij letterlijk een wereld voor je open.

Beveiliging bij onderzoeksinstituten is vaak relatief laks is mijn ervaring.
Beveiliging is altijd een afweging tussen bruikbaarheid en veiligheid en meestal vrijwel alleen gericht op de bescherming van data. In dit geval is het target echter niet de data, maar de rekenkracht en ik denk dat veel beveiligingsmaatregelen daar geen rekening mee hebben gehouden.

Edit/aanvulling:
Ook zitten de onderzoekers vaak over de gehele wereld verspreid, dus grote kans dat een filtering op IP-basis helemaal niet praktisch is.
Vaak log je in via een portal, dus grote kans dat daar op je account een SSH-key hebt staan en dan is het een grep in de history genoeg om te zien waar je 'moet zijn'.

[Reactie gewijzigd door TD-er op 18 mei 2020 09:38]

Alle opdrachten van studenten worden na 15 minuten gekilled. Wat ik meestal deed was op een andere cluster inloggen dan die van mijn universiteit in hetzelfde HPC project (ja dat kan) dan had je soms 30/60 minuten voordat die gekilled werken. Je hebt ook een resource limiet als low level gebruiker.

Als er iemand met priority voorbij komt (lees: postdoc/prof/phd met opdracht) dan worden alle opdrachten met lage prio er uit gegooid enkan je geen cpu tijd meer reserveren/gebruiken. Resultaat is dat je vaak vroeg in de avond (etenstijd) of ochtend het deed want dan waren de high prio taken nog niet begonnen of al klaar.

Ik vermoed dat stale opdrachten er ook uit gaan als die te lang duren, maar goed met die monero dingen kan je telkens verder gaan waar je gebleven was als je dat wilt en de boel na 15 minuten opnieuw opstarten.

edit: verduidelijking

[Reactie gewijzigd door Sloerie op 18 mei 2020 10:47]

Rechtstreeks naar zo'n HPC cluster?
Ja, waarom niet? Dit zijn universiteiten, waar talloze mensen toegang tot hebben (en elk semester komt er een nieuwe lading gebruikers bij) en dat zijn lang niet allemaal informatici; de beveiliging relatief losjes doen helpt enorm met gebruiksgemak en dat is ook wat waard.
je zou toch zeggen dat er nog een soortement van filtering tussen moet zitten.
Dat is er ook: bij simpele studenten staan de limieten veel strakker dan bij wetenschappelijk personeel; niet alleen wordt je proces na x minuten simpelweg beëindigd, ook krijg je slechts een paar cores toegewezen.

In het artikel wordt alleen gezegd dat er miners gedraaid hebben, maar niet hoeveel rekentijd verloren is gegaan. Dit soort clusters heeft al snel meer dan 10.000 cores. Het maakt nogal verschil of er een paar jobs naar binnen zijn gesmokkeld die een kwartiertje rekentijd op (bijvoorbeeld) 32 cores hebben gestolen of dat het volledige cluster urenlang gekaapt is geweest. In beide gevallen is er een probleem (ze horen helemaal niet binnen te komen natuurlijk), maar de impact van het probleem is wel van een ander niveau.


Om te kunnen reageren moet je ingelogd zijn


Apple iPhone SE (2020) Microsoft Xbox Series X LG CX Google Pixel 4a CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True