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.”
some f’ing idiot users have been using private keys without passcodes
private keys zonder ww zie ik heel veel voorkomen. Is dit echt zulke "bad practice" om ze "f'ing idiot users" te noemen?
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.
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).
Wat win je dan pratisch met het gebruik van private
SSH keys, waarvan nu dus blijkt dat je die toch een wachtwoordzin moet geven, t.o.v. een wachtwoord wachtzin voor SSH?

Het is niet uit te sluiten dat je machine ooit gestolen wordt of dat er ooit door een huiszoeking je opslag wordt meegenomen of gecloned (wat vroeger en nu legaal is, kan in de toekomst illegaal zijn. Zoals filesharing en roken).
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]

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.
Zou er ook bij dit soort organisaties niet gewoon 2FA moeten zitten als je vanaf een nieuwe pc inlogged?

[Reactie gewijzigd door SpiceWorm op 18 mei 2020 14:21]

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..
ik zou zeggen van niet. Op het moment dat iemand jouw private ssh sleutel kan bemachtigen, dan ga ik er vanuit dat hij ook wel jouw wachtwoord voor die sleutel kan bemachtigen.

Om mijzelf als voorbeeld te nemen. Ik heb een LUKS encrypted harddrive, met daarop de laatste Fedora Linux. SELinux op enforcing, grootste deel van alle applicaties in Flatpak containers. Als het jou dan alsnog lukt om van buitenaf de ssh sleutels uit mijn home folder te plukken, dan moet ik er vanuit gaan dat je ook wel een keylogger hebt kunnen installeren.

Edit. Iemand die 'ja' antwoordde, kun je beargumenteren hoe het veiliger is met wachtwoord?

Edit 2. Ook grappig. Oudere versies van Ubuntu (tot 16.04) hadden zelf standaard een keylogger in de main repository: http://manpages.ubuntu.co...enial/man8/logkeys.8.html

Edit 3. Dank u. Goede punten inderdaad. Het koopt tijd tegenover een aanvaller, en het geeft extra beveiliging voor alle gevallen waarin anders de beveiliging niet optimaal is, of waarin mensen liggen te slapen.

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

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.
Of op een usb stick
Op je mobile telefoon
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.
...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.
Dan ga je uit van een veilige opslaglocatie van je what-you-have factor.
Een beetje onkunde of non-kennis en het certificaat staat op een onbeveiligde plek, zeg een gedeelde *-Drive folder, of een publieke Github repo.

Als je dan geen 2FA hebt door middel van een wachtwoord op het certificaat, dan ben je de sjaak.

[Reactie gewijzigd door AceAceAce op 18 mei 2020 10:27]

Backups zijn ook altijd mooi.
Dichtgetimmerde home, en dan deze vervolgens in een zip of tgz zetten die net wat minder zorgvuldig weggezet wordt.
(Meestal dan geen ingerichte backups, maar een user zelf die even snel een tar trekt van z'n home).
Draai de vraag eens om: wat is de moeite om het wél te doen? Er zijn veel redenen om aan defense-in-depth te doen, maar de belangrijkste reden voor mij is dat de aanvaller zich niet laat kaderen door de strekking van jouw fantasie. Je kan een bestand onversleuteld laten slingeren omdat je denk dat je een fantastisch beveiligd netwerk hebt, zal er bijvoorbeeld net een aanvaller zijn die de usb stick aan jouw sleutelbos vervangt voor een replica met rubber-ducky hardware.

Deze beveilingsfuncties worden aangeboden, er is geen reden om er geen gebruik van te maken.
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
Met een wachtwoord bekom je in essentie 2FA. Iets dat je hebt (de sleutel) en iets dat je weet (het wachtwoord). Is het bad practice? Dat hangt echt van de omgeving af. In een thuisomgeving kan je het perfect zonder doen. Weinig waarde te vinden over het algemeen. Maar van zodra je verbinding maakt met systemen van een ander, zeker als er waarde achter die systemen zit, dan wil je eigenlijk je beveiliging ook wel verhogen en ja, dan is het bad practice als je geen wachtwoord op je keys hebt staan.
Met een wachtwoord bekom je in essentie 2FA.
Niet echt, aangezien de private key op hetzelfde device zit als waar je je wachtwoord op invult is het nog steeds 1 factor. Iemand die je private key kan bemachtigen kan net even gemakkelijk ook een keylogger installeren en je wachtwoord bemachtigen. De enige situatie die ik me kan bedenken waar in dit nuttig zou kunnen zijn is wanneer iemand zijn keys op een usb stick heeft staan en die ook in niet trusted devices steekt.

Edit: of natuurlijk een gestolen, niet versleutelde laptop.

[Reactie gewijzigd door Goderic op 18 mei 2020 10:32]

[...] kan net even gemakkelijk ook een keylogger installeren en je wachtwoord bemachtigen. [...]
Als het een extra stap is, dan is het nooit 'net even gemakkelijk'. Er zijn legio manieren om aan een bestand te komen en er zijn legio manieren om een wachtwoord te onderscheppen, maar er zijn maar weinig manieren waarbij je in een keer allebei hebt zonder enig extra werk.
Misschien niet zonder enig extra werk, maar niet veel en zeker niet genoeg om het de naam 2FA waardig te maken. Als je de rechten bemachtigd hebt om ssh keys uit te lezen heb je ook de rechten om een keylogger te installeren.
2FA heeft niks met het aantal apparaten te maken. Standaard authenticatie gaat op basis van wat je weet (wachtwoord), wat je hebt (certificaat/apparaat), of een eigenschap die aan jou verbonden is (emailadres, ID kaart, rijbewijs).

2FA houdt is dat je exact 2 van die principes combineert: wachtwoord en token, wachtwoord en email bevestiging, wachtwoord en certificaat/smartcard, pincode en pinpas (ook certificaat), enzovoort.
True, het is gewoon in-band authentication i.p.v out of band (extern apparaat).
Een keylogger installeren is in veel situaties wat moeilijker en makkelijker te detecteren dan een key file bemachtigen.
Je geeft zelf al een voorbeeld.
Het zijn niet mijn woorden, ik haal ze aan uit de link. Maar punt is ook wel dat de bron ip adressen genoemd worden. Lijkt me relevante informatie.
Het zijn niet mijn woorden, ik haal ze aan uit de link.
ik zeg ook niet dat het jouw woorden zijn, ik reageer gewoon op de quote
het is een enorme bad practice ja. Da's zoals codesigning certificates ergens opslaan zonder wachtwoord op de private key. Een disaster waiting to happen.
Ja dat is het :)
Je hebt dan een key die je alleen maar hoeft te kopiëren als bestand en je kunt deze gebruiken om in te loggen.
Nee joh, typische systeembeheerder-betweterigheid (ik ben er zelf ook eentje (geweest)).

Dit is wel een van de gevolgen van het massale thuiswerken. Dat is nou eenmaal inherent een minder goed beveiligde omgeving en kleine beveiligingsissues worden dan makkelijker grote beveiligingsissues.

Ondanks dat ik hier geen werkplekbeheerder ben, heb ik zelf voor werk een korte guide geschreven "hoe je WiFi te beveiligen" en druk bezig om de policies voor updates te benadrukken.

Ergens ben ik blij met de resource www.laatjeniethackmaken.nl, maar ik vind die nog niet eindgebruikers-vriendelijk genoeg.

[Reactie gewijzigd door Keypunchie op 18 mei 2020 10:26]

Is als een kluis dicht doen maar geen code instellen. Ziet er het veilig uit maar is het niet omdat je er zo in kan
Ja natuurlijk, dat is net zo erg als een passwords.txt op je desktop waar al je passwords plaintext in staan.

Nog erger zelfs want SSH keys staan in de meeste gevallen ook nog eens op een vaste locatie.
Op dit level van beveiliging is dit echt een belachelijke fout. 'Fing idiot users is natuurlijk niet professioneel, maar 'wel terecht. Super computers van de overheid moeten natuurlijk gewoon ultiem beveiligd worden.
Zeker, je kan ook ssh-agent gebruiken om een soort van single sign-on te creëren maar dan met een juiste context.
Yes je kan het 100 iemand zeggen (een user) maar het gebeurt nooit en uiteindelijk heb je dit soort dingen. F*cking user is zachtjes gezocht. Het zijn ook altijd dezelfde mensen die gaan zeiken dat de spullen down zijn (zelfs als zij de genen zijn die het veroorzaken.)
Ja.

Nou vooruit, je wil een toelichting :)
Of er ooit plek is voor krachttermen is een andere discussie, maar keys zonder wachtwoord is inderdaad een erg slecht idee. En volgens mij is het niet te veel gevraagd om in deze wereld het besef te hebben dat als je ergens kan inloggen zonder een wachtwoord of andere actie dat er iets niet klopt. Ook vind ik dat als software vraagt om een wachtwoord op te geven en iemand er voor kiest om dat niet te doen, die persoon wel moet kunnen overzien wat de gevolgen daar van zijn. Als iemand die gevolgen niet kan overzien en toch tegen de waarschuwingen in kiest voor een key zonder sleutel, dan vind ik dat een idioot.

Nu zal er vast wel iemand reageren dat hij op zijn computer ook nooit hoeft in te loggen, of dat websites cookies gebruiken om gebruikers eindeloos ingelogd te houden. Dat zijn ook voorbeelden van "bad practice" en dus geen excuus.
Ja.

(sorry er is hier weinig ruimte voor nuance.)
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.
Daarom, eerst een IPSEC VPN en daarna pas SSH.
Wat is het nut om zo'n cluster direct aan het internet te hebben hangen?
Volledig akkoord. Als we ons bij het nut van het koppelen van een koelkast aan Internet al vragen stellen, maar vervolgens toegang verschaffen tot zo een mega dure supercomputer ( de vm's ervan dan toch ) door ze via SSH toegang aan't Internet hangen, dan zijn we ergens niet goed bezig. ( Intel HT vulnerabilities iemand , om maar 1 voorbeeld te noemen ) ?
FYI: 202.120.32.231 en 159.226.161.107 komen uit China.

[Reactie gewijzigd door Cristan op 18 mei 2020 11:51]

Ik vind het wel grappig dat dan de conclusie ook is dat deze mensen uit China zouden komen. Alsof er daar geen VPN services bestaan?
Gezien de "Great Firewall of China" mag je verwachten dat alle VPN services die daar werken alleen maar werken met de expliciete toestemming van de Chinese overheid.
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]

Nou lijkt het er wel op dat er een aantal dingen gewoon een beetje in elkaar geknutseld zijn met deze aanval, maar nog steeds is het best een "hack" van formaat. Met onderzoek naar de gebruikte exploits willen ze kijken of dit echt georganiseerde groeperingen zijn (veel zero-days, eigen R&D) of een paar studenten/scriptkiddo's (standaard exploits waarvan de tutorials online staan).

Ik heb echter het idee dat er binnen CERNET daadwerkelijk devices compromised zijn geraakt. Dit is geen IP-rij van een willekeurig bedrijf of huisadres, maar een rij die ook daadwerkelijk logischerwijs toegang zou kunnen hebben op een HPC. Ik weet niet of dergelijke partijen met whitelists werken, maar ik kan me dan weer goed voorstellen dat een dergelijke aanval niet zou werken vanaf mijn eigen IP-adres en dat dus dit netwerk een key target is om de aanval succesvol te laten zijn.
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]

Jawel, maar die zijn in China geregistreerd. In China een VPN huren is natuurlijk net zo makkelijk en anoniem als hier.
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.
Wie zegt dat dan? enige wat ik hier zie staan is dat de IP's uit China komen veder staat er niks over welke nationaliteit deze personen dan zouden hebben. Waarom moet je een ander verwijten wat jij zelf nu doet?
Ook dat heb ik niet gezegd. Ik zeg alleen dat er geinsinueerd wordt dat de aanvallers zich mogelijk in china bevinden (mag van mij best een nederlander zijn). De originele poster die bij die supercomputer werkt is er echter stellig van overtuigd dat hij met Chinese hackers te maken heeft. Terwijl het ook gewoon Britten kunnen zijn die een VPN tunneltje hebben ingezet.
Waar in het artikel wordt er verwezen naar de nationaliteit van de "f*king idiot users" ? Ik kan maar 1x in het artikel "Chinese hacker" vinden en dat gaat om Chinese hack aanvallen op systemen die met covid research te maken hebben.

Daarnaast is een VPN in China alleen mogelijk als de Chinese Communist Party deze aan de organisatie verleent. Hoeft niet direct de regering te zijn maar gezien alle bedrijven in China staats eigendom zijn van de CCP.

Dit en vederen digitale aanvallen en stelen van covid research, expres misleidende informatie verspreiden en gewoon oprecht liegen, troll fabrieken die reacties uit het buitenland vertraagde, het spier ballen vertoon in de zuid chinese zee, en het express verspreiden van covid door tijdens hun eigen lockdown mensen naar het buitenland te sturen en nog veel meer. Lijkt het mij een HEEL LOGISCHE conclusie om te zeggen dat China hier toch echt van weet en toch echt aanstuurt
Lijkt het mij een HEEL LOGISCHE conclusie om te zeggen dat China hier toch echt van weet en toch echt aanstuurt
Tsja en ik denk dat er een of andere rus is die de ballen uit z'n broek lacht met z'n 40K monero omdat ie leest dat wij allemaal de chinezen verdenken. Dit zijn precies de vieze spelletjes die gespeeld worden door heel veel verschillende partijen. Precies omdat het net te makkelijk is om daarmee china de schuld te geven. En inderdaad als je met zo'n lijstje aankomt heel geloofwaardig.

Nee ik wil graag gewoon helemaal geen vingertjes, maar gewoon harde feiten. Het boeit mij niet dat een IP adres uit china komt. Dat is niet zo moeilijk. Die hele block range komt officieel namelijk uit australië wist je dat?. Maar als je dus eerst naar een computer in china SSH-ed en daarvandaan dus weer naar de UK dan is het logisch dat het lijkt dat al het verkeer uit china komt. Daarom is het ook belangrijk om te weten waar het verkeer dan exact vandaan komt. En dan zie je dus dat het IP adres geregistreerd staat bij een onderzoekscentrum. Dikke kans dus dat een onderzoeker daar gewoon zijn security niet op orde heeft.
Dat is wat je er zelf van maakt, in de tekst staat gewoon dat de IP adressen die gebruikt zijn uit China komen. De conclusie dat de daders ook uit China komen maak je helemaal zelf.
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.”
Nou niet doen alsof je neus bloed ;) beetje tussen de regels lezen mag wel.
Ik vind het grappig wanneer de narative wel duidelijk is, dat je nog steeds bewijs moet hebben dat het niet zo is. Uiteindelijk zullen we het nooit zeker weten, maar wanneer het een gegeven feit is dat bij verre Chinezen verantwoordelijk is voor dergelijke praktijken al dan niet met overheidssteun, mag je je toch wel afvragen waarom zou het dan ook niet zo zijn.

En toevalligerwijs met betrekking tot VPN services in China, deze dienen voor commerciele services geregistreerd te worden bij de overheid/China Unicom/Telecom dus het zou wel heel apart zijn wanneer dit niet Chinezen zijn. (Ik weet niet eens of dit uberhaubt mogelijk is).
Het is prima mogelijk. Zeker als je dingen op dit formaat weet neer te zetten.

Als je kijkt naar de IP adressen dan komt er 1 van een onderzoeksinstituut in Bejing. Waarschijnlijk zijn zij ook gewoon gehacked.
Ik vind het grappig wanneer de narative wel duidelijk is, dat je nog steeds bewijs moet hebben dat het niet zo is. Uiteindelijk zullen we het nooit zeker weten, maar wanneer het een gegeven feit is dat bij verre Chinezen verantwoordelijk is voor dergelijke praktijken al dan niet met overheidssteun, mag je je toch wel afvragen waarom zou het dan ook niet zo zijn.
Dat heet omgekeerde bewijslast. het zijn juist dit soort assumpties die er voor zorgen dat fake nieuws werkt. Check het gewoon even zelf.
Maar het is wel logisch. Crypto is groot in China omdat het een manier is om geld het land uit te krijgen.
Dan is Cryptomining nog niet het ergste. Dit soort computers zijn ook populair voor het ontwikkelen van medicatie, klimaatonderzoek, of het bestuderen van kernwapens.
als ze nou die supercomputers hadden gehackt voor het ontwikkelen van medicatie of klimaatonderzoek, dan had dat ten minste nog iets kunnen doen voor de mensheid in het algemeen. Het minen van bitcoins is puur voor de persoon die ze gemined heeft.
Niet dat het daarom minder erg zou zijn, maar het zou toch een nuance aan brengen
Ik dacht eigenlijk andersom. Ze zouden de informatie over medicijnonderzoek kunnen stelen, of saboteren.
Saboteren van medicijnenonderzoek is naar mijn idee het zelfde als poging tot moord, zo niet moord.
Die medicijnen kunnen ten slotte levens redden en elk uur dat zo'n medicijn nog niet bestaat is kwalijk.

Het stelen van zo'n onderzoek is inderdaad ook jammer omdat iemand anders uit eindelijk winst maakt over de rug van een ander, maar aan de andere kant als dit voor een doorbraak kan zorgen waardoor een medicijn eerder op de markt beschikbaar komt, dan is de vraag hoe erg is dat.

Misschien zouden dit soort onderzoeken ook niet door bedrijven gedaan moeten worden, maar door overheden of misschien zelfs een globale non-profit organisaties die dit soort onderzoeken onder elkaar delen. ik heb niet echt een idee hoe je er voor zou kunnen zorgen dat iedereen die bij die organisaties werkt hun uiterste best zouden doen, maar op die manier kun je misschien wel de kosten van de medicijnen drukken, omdat er geen winst marches meer worden gevraagd. (al stijgen de kosten wel weer)
Saboteren van medicijnenonderzoek is naar mijn idee het zelfde als poging tot moord, zo niet moord.Die medicijnen kunnen ten slotte levens redden en elk uur dat zo'n medicijn nog niet bestaat is kwalijk.
China is op dit moment actief bezig met een ethische zuivering van Uyghur Moslims dus ik vermoed dat ze het doden van blanke westerlingen vast ook wel over hun hart kunnen krijgen.

Hoe het huidige octrooi en auteursrecht in elkaar zit, en hoe dat macht consolideert bij enkele grote multinationals, is mij ook een doorn in het oog. Je kunt geen goede persvrijheid, cultuur, onderwijs of gezondheidszorg hebben als de middelen daartoe allemaal in handen zijn van een dozijn bedrijven. Nu gaat het opeens over vaccins omdat we zelf nogal te lijden hebben onder Corona, maar er gaan jaarlijks miljoenen mensen dood aan te dure of niet beschikbare zorg. Probleem is dus al wat ouder en ik vermoed niet dat we dit binnenkort gaan oplossen.
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.
some f’ing idiot users have been using private keys without passcodes
Hoe zou je het kunnen enforcen en controleren, dat mensen een wachtwoord gebruiken?

Daarnaast word ssh vaak gebruikt, om automatische processen aan te sturen, wat een key met wachtwoord weer lastig maakt.

Ik denk dat de betreffende persoon beter had kunnen zeggen "Welke f*ing, admin heeft zijn systemen op deze manier aangesloten op internet?
Maar voor die automatische processen genereer je een unieke key die je enkel voor dat process gebruikt. Dan wordt er hoogstens 1 andere machine gecompromiteerd als die key in verkeerde handen valt. Als het je persoonlijke key is die je gebruikt om in te loggen op verschillende systemen en die valt in verkeerde handen dan heb je direct enorm veel systemen die kwetsbaar zijn.
Aangezien het gebruik van een passcode/word/phrase optioneel is in het aanmaken van SSH sleutels, kan je het volgens mij alleen forceren door de remote users niet de SSH sleutels te laten aanmaken, maar dit centraal doen waar er altijd een wachtwoord wordt geforceerd. Maar dan moet je de lijn eindgebruiker - server ook dichttimmeren.
IP komt van: Shanghai Jiaotong University (sjtu.edu.cn).
Arme studenten willen gewoon zakcentje verdienen ;)
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...
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.
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.
Een oudere file is minder opvallend dan een file met een recente timestamp.
Om te zien of het echt een oude file is, moet je het vergelijken met een backup en dat is meer werk.
Lijkt me dus een prima middel om een tikkeltje minder snel ontdekt te worden.
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.
Helaas kan dat niet. De server ziet alleen de (decrypted) public key, maar de client moet de private key hebben voorafgaande aan de uitwisseling. De private key komt nooit bij de server, zowel in ge-encrypte als plaintext vorm.
Dat dacht ik eigenlijk al. Da's wel jammer.

Een alternatief dat waarschijnlijk wel server-side kan is om zowel private key als password nodig te hebben voor een login. Niet gebruikersvriendelijk, maar het dwingt wel 2FA af: iets wat je hebt (private key, al dan niet password protected) en iets wat je weet (een password voor de traditionele login).

Maar goed, dat is mosterd na de maaltijd in dit geval.
Dit kan al via SSH, en is naar mijn mening een hele goede oplossing. Er zijn ook plugins voor OpenSSH waarbij je een google authenticator code moet invoeren. Daar naast kun je ook andere authenticatiemethodes implementeren.
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.
Ja in rekenclusters kunnen/moeten ze qua kernel updates/security patches wat traag zijn - of het gewoonweg niet doen. De jobs moeten immers kunnen finishen.
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]

Mijn ervaring, maar dat is al even geleden, is dat dit voor studenten en pdh'ers via radius servers gaat (Surfnet login).

Ofwel: Ja met een gekaapte login kom je binnen.

edit: IP blocking heb je niet veel aan want die accounts hebben ook VPN toegang

[Reactie gewijzigd door Sloerie op 18 mei 2020 09:38]

Rechtstreeks naar zo'n HPC cluster? .... dat zou wel opmerkelijk zijn. Misschien technisch onontkoombaar hoor, daarvoor heb ik er te weinig kennis van :) maar je zou toch zeggen dat er nog een soortement van filtering tussen moet zitten. Stel dat je op een of andere slinkse wijze als student al dan niet per ongeluk een infinite loop introduceert en zo'n cluster op z'n knieën dwingt... ("ga maar even volle bak aan de slag om Graham's Number uit te schrijven" of zo).
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.
Ik heb er geen verstand van, dus dit is puyr gokwerk. Maar is het nut van een supercomputer niet juist dat er veel verschillende partijen hun werk op kunnen doen? Dus samenwerken met allerlei teams vanaf verschillende locaties om een oplossing te vinden voor een probleem / problemen.

Het lijkt me dan enorm lastig om zo'n ding dicht te timmeren. Als van een gebruiker van een supercomputer de inloggegevens buitgemaakt zijn, of misschien hún systemen gecomprommiteerd zijn, heb je toegang.

[Reactie gewijzigd door CykoByte op 18 mei 2020 09:38]

Ja dát is wel de bedoeling, maar niet 'ongefilterd' toch. Dat er veel verschillende partijen bij kunnen is één ding, maar je wil als organisatie toch weten wélke partijen dat zijn en wat ze uitspoken? Je reserveert toch 'CPU-tijd' op zo'n cluster, dan kun je toch ook wel bijhouden wie dat doet? Kijk, tegen logcleaners en rootkits doe je dan niet zo bar veel, maar dan is tenminste duidelijk wie er wanneer iets uitspookt op je miljoenen-kostende-systeem....
En daar heb je dus die keys voor. Jij krijgt toegang. Jouw user ID wordt gekoppeld met je public key zodat jij met je private key toegang kunt krijgen. En doordat het een sleutelpaar is dat enkel jij volledig bezit is men zeker van jouw identiteit. Totdat je dus je private sleutel "verliest"
Ja, maar zoals ik al zei, je hangt je HPC-cluster toch niet rechtstreeks aan het internet? Er moet tussentijds toch wel 'iets' van controle zijn? Tussenliggende systemen, firewalls, SIEM for all I care..? *Iets* moet toch weten dat jij inlogt, en of dat nou via gestolen keys is of niet doet er dan niet zoveel toe, er zijn toch wel tussenlagen waar iets op te zien moet zijn (geweest)? Dat is meer een retorische vraag hoor. Ik vind het gewoon opmerkelijk dat er 'iets' kan gebeuren op een HPC zonder dat er érgens een alarmbel gaat rinkelen, ongeacht of er gestolen keys zijn gebruikt en logcleaners hebben gedraaid.

Die mining tool bijvoorbeeld, heeft toch ook weer toegang tot internet nodig om een workload op te halen of resultaten ergens af te geven? Dan moeten firewalls dat toch óók zien...?

Maar goed, we zullen 't niet te weten komen vrees ik.
Ik vind het gewoon opmerkelijk dat er 'iets' kan gebeuren op een HPC zonder dat er érgens een alarmbel gaat rinkelen
Lijkt me niet dat je zomaar (tijdens de job) data kunt downloaden, maar als je een account hebt op zo'n machine, dan heb je daar ook een homedir en daar kun je data opslaan die jouw jobs kunnen gebruiken.

Normaal gesproken is de beste "alarmbel" voor een miner dat je CPU load opeens naar 100% schiet, maar op deze clusters kun je geen alarm zetten op "deze job vreet wel erg veel rekentijd", want dat is precies het doel ervan; zo'n alarm zou voor zo ongeveer elke job afgaan.
Ik denk dat het grootste probleem hier is dat gebruikers hun eigen toegang konden regelen (die opmerking over de key zonder password). En ik weet wel dat dat standaard SSH gedrag is, maar de vraag is of je dat ook moet willen op zo'n cluster.
Die supercomputers zijn ook systemen die als gevaarlijk bestempeld kunnen worden. Zo'n bak rekenkracht is ook wat waard, en daar mag wel een adequate beveiliging tegenover staan.
Daarnaast snap ik ook niet dat er geen 2 traps raket is; dus en eerste user toegang tot een VPN, uitgegeven door een admin, en daarna SSH toegang met de mogelijkheid tot keys die de gebruikers zelf aan kunnen maken.

SSH met 'normale' gebruikers icm. het aan het internet hangen is gewoon link.
Die supercomputers zijn ook systemen die als gevaarlijk bestempeld kunnen worden.
Omdat elke idioot zijn kernbom door kan rekenen...? Nee, ik zie niet in hoe een supercomputer "gevaarlijk" zou zijn.
Zo'n bak rekenkracht is ook wat waard, en daar mag wel een adequate beveiliging tegenover staan.
Totdat iemand miners bedacht viel dat eigenlijk wel mee toch? Dat ze nu binnengekomen zijn betekent dat de beveiliging niet goed genoeg was, maar als ze nu pas binnengekomen zijn (ik kan me geen soortgelijk nieuws herinneren terwijl bitcoin al flink wat jaren bestaan), dan was de beveiliging niet hopeloos ontoereikend.
Er zijn in de afgelopen jaren veel bugs in ssh gevonden, als je niet update (wat vaak erg achterloopt met dit soort omgevingen) heb je zo je eerste gaten te pakken.
Maar het ging me dan ook vooral om de manier om bij SSH te kómen :) firewalls, packet inspections, dat soort dingen. Meerdere lagen van beveiliging om SSH héén.

Het is niet alsof iemand in hun router poort 22 forward rechtstreeks naar de controller in zo'n HPC toch.

.......

Toch?
Het is niet alsof iemand in hun router poort 22 forward rechtstreeks naar de controller in zo'n HPC toch.
Van wat ik er van gezien heb is dat toch wel hoe het gaat.
Deze systemen worden gebruikt door hele gewone wetenschappers zonder speciale middelen.
Typisch heb je bij zo'n supercomputer wel een onderscheid tussen reken-nodes en controller-nodes en komen gewone gebruikers alleen op die controllers, maar die zijn min of meer direct verbonden met internet via doodgewone SSH.
Het zal van organisatie tot organisatie verschillen hoeveel slimme firewalls en monitoren er om heen hangen om gek gedrag te stoppen, maar de toegang wordt opzettelijk laagdrempelig gehouden. Werken met dit soort systemen is al lastig genoeg zonder draconische inlogprocedures.
Dat of jij hebt niet het hele beeld, en beoordeeld nu de beveiliging op basis van 1 nieuws artikel?
Nja, het nieuwsartikel rept niet over firewallbreaches en spoofing en dergelijken. Het claimt dat de hack veroorzaakt is door gekaapte SSH logins. Ja dat zal de kern van het probleem zijn, maar er is méér aan de hand dan alleen die gekaapte logins. Dan zijn er genoeg fouten gemaakt in meerdere processen rondom de beveiliging vermoed ik zo.
Wat hadden de firewalls en dergelijke dan moeten doen? Er wordt met een gekaapt ID ingelogd, dus volgens de firewall, IDS etc is het gewoon een legitieme verbinding.
Een firewall kan beperken waar je vandaan inlogt. En DPI uitvoeren op het verkeer. En DLP en APT scanning doen waardoor mogelijke ‘persistent threats’ zoals coinminers geblokkeerd hadden kunnen worden.....

Maar goed, dat is achteraf en dan moet er nogal wat ingericht zijn vóórdat je dat kan doen.

[Reactie gewijzigd door DigitalExorcist op 18 mei 2020 17:02]

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.....
DPI over SSL kan prima. Kwestie van een certificaat deployen.

* Edit: ok, iets méér dan alleen een certificaat, maar het principe blijft overeind.

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

Niet relevant, want het gaat over SSH
Ummmm? SSH gebruikt TLS. TLS werkt met certificates.
So? Hoe denk je dat het web werkt? Denk je echt dat iedere call volledig assymetric is?

De call wordt opgezet, en met de assymetric key en cert wordt een symmetric key gebouwd die wordt gebruikt tijdens de sessie.

Het zijn juist de keys en de certs die het toelaten om mee te luisteren.

Wanneer je connect met een nieuwe server in SSH zegt jouw machiene: ik ken deze fingerprint niet. Vertrouw je hem of niet. Die fingerprint is de fingerprint van het certificate.

[Reactie gewijzigd door Snake op 18 mei 2020 22:44]

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).. :)
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 Jiaotong 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.
De implicatie is dat de betreffende accounts root rechten hebben, dat er (ongepatchte) kwetsbaarheden zijn gebruikt of dat systemen niet veilig geconfigureerd zijn. Het probleem is dus niet enkel dat er credentials zijn buitgemaakt, maar dat de betreffende instituten ook niet hun autorisatiesystemen op orde hebben.

Verder kan men natuurlijk multi-factor authenticatie implementeren om het risico op misbruik van buitgemaakte credentials te verkleinen.

[Reactie gewijzigd door The Zep Man op 18 mei 2020 09:54]

Nu ben ik wel benieuwd wat de hashrate was en de verschillen tussen de supercomputers!
Hierbij een artikel op de crypto-insiders.nl site van begin dit jaar op de cryptovaluta die werd gemined. https://www.crypto-inside...erd-aldus-europol-expert/
Kleine nuance: Archer is de nationale supercomputer van het Verenigd Koninkrijk die gehost wordt door de University of Edinburgh, maar het is niet de supercomputer van de universiteit. De UoE heeft een eigen supercomputer genaamd Eddie.
Hoeveel crypto (bitcoin bijvoorbeeld) zou hierdoor in bijvoorbeeld een dag gemined kunnen worden? Iemand?


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