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
Ik veronderstel dat een key niet zomaar gebruteforced kan worden via SSH met een dictonary.
Maar als je op een machine geraakt via een exploit zijn natuurlijk wel alle private keys vulnerable.
Jawel, als ze de key hebben dan is het vrij eenvoudig om simpele wachtwoorden te achterhalen dmv een dictionary. Dus ook hierbij geldt dat een sterk wachtwoord aan te raden is.
Ik antwoordde op RoestvrijStaan en ik bedoel, als je enkel met een ssh keypair kan inloggen, is dat veiliger dan via paswoord. Hier zal je niet kunnen bruteforcen. Dus het is nog steeds aangeraden om met keypair te werken.

De passphrase dient enkel om als men dan toch is binnen gedrongen op de server, en men alle private keys copieert, deze alsnog te beschermen.
Het voordeel van SSH keys, is dat je het zo kan opzetten dat je het password maar één maal hoeft in te geven voor alle toekomstige sessies. Zie de ssh tools ssh-agent en pageant.
...of een hardware keylogger. Zie bv Keelog.

Persoonlijk zie ik er geen graten in om een key zonder passphrase te gebruiken maar het hangt natuurlijk steeds af van de situatie. Ik vind het in mijn situatie zelfs veiliger om een key zonder passphrase te gebruiken als die maar gecombineerd wordt met TOTP 2FA op je smartphone. Natuurlijk met een goede pincode op je telefoon en/of de OTP app.
Keys belanden vaak onbewust op straat o.a op GitHub kan je er vinden. Of mensen verliezen een usb-stick die de keys bevatten.
1 woord,

PAW, SAW

oftewel privilege of clean source de nr1 counter measure om dit soort issues te voorkomen.

https://www.microsoft.com...secure-admin-workstations
Het is in elk geval geen best-practice. Het kan zijn dat de gebruikers niet beter weten, maar dan wordt het dringend tijd dat er een deftige security-training wordt voorzien voor deze mensen (eigenlijk zou elk bedrijf of overheidsinstantie een security-training moeten voorzien voor hun werknemers).

Zelf heb ik mijn private key op een YubiKey gezet en gebruik die voor authenticatie. Ik heb nog wel een offline backup in een safe voor als ik een nieuwe YubiKey moet provisioneren (in geval van van verlies/diefstal of gewoon een nieuwe gekocht). Je hoeft zelfs aan de server-kant niets aan te passen hiervoor.
Ik dacht eigenlijk andersom. Ze zouden de informatie over medicijnonderzoek kunnen stelen, of saboteren.
En waarom niet allebij, eerst de zaak leeghalen op nuttige data en daarna de machines voor eigen gebruik herinrichten...
Het is eerder om data te jatten van eerder gedaan onderzoek.
Vreemd dat die IP adressen nog niet op een blacklist staan. Alleen 159.226.161.107 staat op een Deense lijst als spammer.
you get zero guesses which country these are from.”
Maar als je nul keer mag raden kun je het dus niet raden, ook al weet je het 8)7
Ok ik ga weer...
Een firewall kan beperken waar je vandaan inlogt.
Niet handig als de onderzoekers en studenten vanaf allerlei locaties toegang moeten hebben.
En DPI uitvoeren op het verkeer.
DPI op een encrypted SSH tunnel?
Maar goed, dat is achteraf en dan moet er nogal wat ingericht zijn vóórdat je dat kan doen.
Tja, achteraf een hoop drie-letter afkortingen roepen.....
Succes met forward secrecy ciphers en DPI aanzetten. Maar ben benieuwd welke tooling jij gebruikt om SSH te DPI-en.
https://blog.sonicwall.com/en-us/tag/dpi-ssh-en-us/

https://sc1.checkpoint.co...ket%20Inspection%7C_____5

https://security.stackexc...ssh-deep-inspection-works

Zijn 3 oplossingen genoeg? Ik heb meer te doen vandaag....

Ook gelijk even een mention voor @Zer0 ...

[Reactie gewijzigd door DigitalExorcist op 19 mei 2020 07:47]

Touche. Wel zijn er limitaties. Of je maakt er key-technisch er het equivalent van de server van, of je verlaagd de cryptografie. Maar goed, is al meer dan ik kende. Weer wat geleerd.
Tsja. Optimaal is anders, maar het kán best...

Volgende interessante puntje waar ik zelf nog even over moet nadenken is DNS-over-HTTPS ... zelfde principe natuurlijk, maar dat vergt ook wel weer de nodige voorbereiding.
Nu de volgende vraag, waarom zou je DPI toepassen op binnenkomende SSH verbindingen? Je kunt makkelijker op de systemen waar de verbindingen termineren monitoren...
Dat kan, maar als je SSH daemon een exploit bevat waardoor eea. niet gelogd wordt (of een logcleaner gedraaid wordt) heb je niks aan die monitoring toch? Dus óók gewoon op de firewall monitoren én op je server(s).. :)


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