Microsoft: malafide OpenSSH-versie gebruikt bij aanval op Linux-systemen
Bij een aanval op Linux- en IoT-systemen maken aanvallers gebruik van een malafide OpenSSH-versie om toegang tot het systeem te behouden en inloggegevens te onderscheppen, zo stelt Microsoft in een analyse. OpenSSH, ook bekend als OpenBSD Secure Shell, is een verzameling van netwerktools gebaseerd op het SSH-protocol, en laat gebruikers op een beveiligde manier op bijvoorbeeld servers inloggen of op afstand machines beheren.
De aanval begint met een bruteforce-aanval op verkeerd geconfigureerde Linux-systemen die vanaf internet toegankelijk zijn, aldus het techbedrijf. Zodra er toegang tot het systeem is verkregen wordt de shell history uitgeschakeld, een backdoor geïnstalleerd en de broncode van OpenSSH gedownload, aangevuld met verschillende malafide bestanden. Via deze bestanden wordt OpenSSH gepatcht, gecompileerd en geïnstalleerd.
De aangepaste OpenSSH-versie geeft de aanvallers toegang tot het systeem en maakt het mogelijk om SSH-inloggegevens die op het systeem worden ingevoerd te onderscheppen. Daarnaast doet de aangepaste OpenSSH-versie zich voor als een legitieme OpenSSH-server, wat detectie kan bemoeilijken, aldus Microsoft. Het techbedrijf waarschuwt dat de aanvallers via de gepatchte OpenSSH-versie ook andere systemen kunnen aanvallen. De aanvallers blijken ook twee rootkits te installeren en malware die het besmette systeem inzet voor cryptomining.
Beheerders en organisaties kunnen zich echter tegen dergelijke aanvallen wapenen door ervoor te zorgen dat hun apparaten goed zijn geconfigureerd. Zo moet het standaard wachtwoord worden gewijzigd en moet er geen externe toegang tot SSH zijn, adviseert Microsoft. Verder moet het systeem up-to-date met de laatste firmware en beveiligingsupdates zijn.
Reacties (17)
Merkwaardig. Er is geen sprake van default gebruikersnamen en passwords bij Linux. Waar komt de malafide OpenSSH server vandaan? Externe toegang tot SSH is geen enkel probleem mits enigszins zinvol geconfigureerd. Bij gebruik van keys is het sowieso al een stuk moeilijker. Beetje FUD? Aandacht van RDP afleiden?
23-06-2023, 13:12 door
_R0N_
Door Anoniem: Merkwaardig. Er is geen sprake van default gebruikersnamen en passwords bij Linux. Waar komt de malafide OpenSSH server vandaan? Externe toegang tot SSH is geen enkel probleem mits enigszins zinvol geconfigureerd. Bij gebruik van keys is het sowieso al een stuk moeilijker. Beetje FUD? Aandacht van RDP afleiden?
Met de Double free pre-auth vulnerability zou je geen credentials nodig hebben. He is niet makkelijk te misbruiken maar het kan wel.
Door Anoniem: Merkwaardig. Er is geen sprake van default gebruikersnamen en passwords bij Linux. Waar komt de malafide OpenSSH server vandaan? Externe toegang tot SSH is geen enkel probleem mits enigszins zinvol geconfigureerd. Bij gebruik van keys is het sowieso al een stuk moeilijker. Beetje FUD? Aandacht van RDP afleiden?
Dus even het artikel samenvattend, want heb je blijkbaar niet gelezen:
- Aanvallers krijgen toegang dmv Brute Force op verkeerd geconfigureerde SSH installaties
- Zodra er toegang tot het systeem is verkregen wordt de shell history uitgeschakeld
- Er wordt een backdoor geïnstalleerd
- De broncode van OpenSSH gedownload, aangevuld met verschillende malafide bestanden.
- De broncode van OpenSSH wordt gepatcht (met malafide code), gecompileerd en geïnstalleerd.
Dit is geen FUD maar wederom beheerders die de deuren niet in de gaten houden en zeker niet correct dichtdoen!
23-06-2023, 15:11 door
Korund
- De broncode van OpenSSH wordt gepatcht (met malafide code), gecompileerd en geïnstalleerd.
- inloggen als root
- inloggen als user die een "sudo" naar root mag uitvoeren
- gebruik maken van een zero-day kwetsbaarheid
* Inloggen als root kan op moderne Linux-machines al jaren niet meer. Alle distributies gebruiken de "sudo" manier. Maar misschien bedoelen ze dat met "verkeerd geconfigureerd".
* Inloggen als gewone gebruiker: niet alleen moet je dan achter een gebruikersnaam zien te komen, maar ook nog eens zijn wachtwoord brute-forcen. Ben je vervolgens binnen, dan moet je het geluk hebben dat het een gebruiker is die rechten heeft om "sudo" uit te voeren. Anders kun je opnieuw beginnen.
* Zero-day: als dat zo was, zou dat ongetwijfeld in het artikel genoemd worden.
Het is mogelijk de OpenSSH-service zodanig te configureren dat de root-gebruiker rechtstreeks mag inloggen. Dit staat default uit; je moet er expliciet voor kiezen. Als dat zo is, ben je als systeembeheerder fout bezig en verdien je het ook dat je systeem gehackt wordt.
Geen externe toegang? Eh... externe toegang is de functionaliteit van SSH. Wat bedoelen ze hier precies mee?
Door Korund:
- De broncode van OpenSSH wordt gepatcht (met malafide code), gecompileerd en geïnstalleerd.
Het is mogelijk de OpenSSH-service zodanig te configureren dat de root-gebruiker rechtstreeks mag inloggen. Dit staat default uit; je moet er expliciet voor kiezen. Als dat zo is, ben je als systeembeheerder fout bezig en verdien je het ook dat je systeem gehackt wordt.
- De broncode van OpenSSH wordt gepatcht (met malafide code), gecompileerd en geïnstalleerd.
Het is mogelijk de OpenSSH-service zodanig te configureren dat de root-gebruiker rechtstreeks mag inloggen. Dit staat default uit; je moet er expliciet voor kiezen. Als dat zo is, ben je als systeembeheerder fout bezig en verdien je het ook dat je systeem gehackt wordt.
Dat zeg ik: Dit is geen FUD maar wederom beheerders die de deuren niet in de gaten houden en zeker niet correct dichtdoen!
Door Korund:
- De broncode van OpenSSH wordt gepatcht (met malafide code), gecompileerd en geïnstalleerd.
Hier heb je root-rechten voor nodig. Die kun je op deze manieren verwerven:
- inloggen als root
- inloggen als user die een "sudo" naar root mag uitvoeren
- gebruik maken van een zero-day kwetsbaarheid
* Inloggen als root kan op moderne Linux-machines al jaren niet meer. Alle distributies gebruiken de "sudo" manier. Maar misschien bedoelen ze dat met "verkeerd geconfigureerd".
* Inloggen als gewone gebruiker: niet alleen moet je dan achter een gebruikersnaam zien te komen, maar ook nog eens zijn wachtwoord brute-forcen. Ben je vervolgens binnen, dan moet je het geluk hebben dat het een gebruiker is die rechten heeft om "sudo" uit te voeren. Anders kun je opnieuw beginnen.
* Zero-day: als dat zo was, zou dat ongetwijfeld in het artikel genoemd worden.
- De broncode van OpenSSH wordt gepatcht (met malafide code), gecompileerd en geïnstalleerd.
- inloggen als root
- inloggen als user die een "sudo" naar root mag uitvoeren
- gebruik maken van een zero-day kwetsbaarheid
* Inloggen als root kan op moderne Linux-machines al jaren niet meer. Alle distributies gebruiken de "sudo" manier. Maar misschien bedoelen ze dat met "verkeerd geconfigureerd".
* Inloggen als gewone gebruiker: niet alleen moet je dan achter een gebruikersnaam zien te komen, maar ook nog eens zijn wachtwoord brute-forcen. Ben je vervolgens binnen, dan moet je het geluk hebben dat het een gebruiker is die rechten heeft om "sudo" uit te voeren. Anders kun je opnieuw beginnen.
* Zero-day: als dat zo was, zou dat ongetwijfeld in het artikel genoemd worden.
Waarom denk je *zero day* ?
Alsof iedere host altijd gepatched is naar de laatste stand .
Gewoon , 380-day vulnerability kan ook prima - nog meer als het 'IoT' systeem is , want dat zijn typisch gevallen van nooit geupdate .
Door Anoniem: Merkwaardig. Er is geen sprake van default gebruikersnamen en passwords bij Linux. Waar komt de malafide OpenSSH server vandaan? Externe toegang tot SSH is geen enkel probleem mits enigszins zinvol geconfigureerd. Bij gebruik van keys is het sowieso al een stuk moeilijker. Beetje FUD? Aandacht van RDP afleiden?
Merkwaardig dat je IOT op de eerste regel gemist had. Dat staat nu niet bekend om zijn hoge veiligheid.Door Korund:
- De broncode van OpenSSH wordt gepatcht (met malafide code), gecompileerd en geïnstalleerd.
Hier heb je root-rechten voor nodig. Die kun je op deze manieren verwerven:
- inloggen als root
- inloggen als user die een "sudo" naar root mag uitvoeren
- gebruik maken van een zero-day kwetsbaarheid
* Inloggen als root kan op moderne Linux-machines al jaren niet meer. Alle distributies gebruiken de "sudo" manier. Maar misschien bedoelen ze dat met "verkeerd geconfigureerd".
* Inloggen als gewone gebruiker: niet alleen moet je dan achter een gebruikersnaam zien te komen, maar ook nog eens zijn wachtwoord brute-forcen. Ben je vervolgens binnen, dan moet je het geluk hebben dat het een gebruiker is die rechten heeft om "sudo" uit te voeren. Anders kun je opnieuw beginnen.
* Zero-day: als dat zo was, zou dat ongetwijfeld in het artikel genoemd worden.
Het is mogelijk de OpenSSH-service zodanig te configureren dat de root-gebruiker rechtstreeks mag inloggen. Dit staat default uit; je moet er expliciet voor kiezen. Als dat zo is, ben je als systeembeheerder fout bezig en verdien je het ook dat je systeem gehackt wordt.
Totdat je met IOT te maken hebt.... Op veel devices kun je trouwens gewoon zonder enig probleem verbinden met een standaard userid/wachtwoord en daarna su of sudo zonder enig probleem gebruiken. - De broncode van OpenSSH wordt gepatcht (met malafide code), gecompileerd en geïnstalleerd.
- inloggen als root
- inloggen als user die een "sudo" naar root mag uitvoeren
- gebruik maken van een zero-day kwetsbaarheid
* Inloggen als root kan op moderne Linux-machines al jaren niet meer. Alle distributies gebruiken de "sudo" manier. Maar misschien bedoelen ze dat met "verkeerd geconfigureerd".
* Inloggen als gewone gebruiker: niet alleen moet je dan achter een gebruikersnaam zien te komen, maar ook nog eens zijn wachtwoord brute-forcen. Ben je vervolgens binnen, dan moet je het geluk hebben dat het een gebruiker is die rechten heeft om "sudo" uit te voeren. Anders kun je opnieuw beginnen.
* Zero-day: als dat zo was, zou dat ongetwijfeld in het artikel genoemd worden.
Het is mogelijk de OpenSSH-service zodanig te configureren dat de root-gebruiker rechtstreeks mag inloggen. Dit staat default uit; je moet er expliciet voor kiezen. Als dat zo is, ben je als systeembeheerder fout bezig en verdien je het ook dat je systeem gehackt wordt.
Wel heel bijzonder dat als je Microsoft beheerder niet goed doet, je de wind van voren krijgt, maar als Linux beheerder ben je gewoon fout bezig.
Door Anoniem:
[knip /]
Waarom denk je *zero day* ?
Alsof iedere host altijd gepatched is naar de laatste stand .
Gewoon , 380-day vulnerability kan ook prima - nog meer als het 'IoT' systeem is , want dat zijn typisch gevallen van nooit geupdate .
Ik ken geen IOT systeem met openssh-server (wel dropbear op routers e.d.). De forte van de non-IOT systemen waarop een gerenommeerde Linux distributie draait is dat die in de regel goed up-to-date zijn dankzij een goed werkend software management systeem (RPM/Yum, dpkg/apt, enz). En waar een Linux systeem in een container draait en vanaf het Internet aanroepbare diensten draait is dat in de regel achter een firewall en reverse proxy.[knip /]
Waarom denk je *zero day* ?
Alsof iedere host altijd gepatched is naar de laatste stand .
Gewoon , 380-day vulnerability kan ook prima - nog meer als het 'IoT' systeem is , want dat zijn typisch gevallen van nooit geupdate .
Terzijde: het gebruik van het woord "gewoon" verraad vaak oppervlakkige kennis.
Door Korund:
Het is mogelijk de OpenSSH-service zodanig te configureren dat de root-gebruiker rechtstreeks mag inloggen. Dit staat default uit; je moet er expliciet voor kiezen. Als dat zo is, ben je als systeembeheerder fout bezig en verdien je het ook dat je systeem gehackt wordt.
Het is mogelijk de OpenSSH-service zodanig te configureren dat de root-gebruiker rechtstreeks mag inloggen. Dit staat default uit; je moet er expliciet voor kiezen. Als dat zo is, ben je als systeembeheerder fout bezig en verdien je het ook dat je systeem gehackt wordt.
Kennelijk verdien ik het al decennia om gehackt te worden. Mijn ssh daemon staat altijd op "PermitRootLogin prohibit-password" en "PasswordAuthentication no". Inloggen kan alleen met een ed25519 key en daarnaast staat fail2ban te brommen om sukkels die het toch proberen, direct een ban te geven.
Zelf ben ik fel tegenstander van sudo zoals het bij bijvoorbeeld Ubuntu wordt toegepast. Simpelweg omdat het een ingebouwde privilege escalation is. Gewone gebruikers doen van alles op hun prompt en dat kun je dus ook allemaal per ongeluk als root uitvoeren. Als ik inlog op mijn servers, zie ik een mooie rode prompt, zodat ik weet dat ik root ben.
Door Anoniem:
Kennelijk verdien ik het al decennia om gehackt te worden. Mijn ssh daemon staat altijd op "PermitRootLogin prohibit-password" en "PasswordAuthentication no". Inloggen kan alleen met een ed25519 key en daarnaast staat fail2ban te brommen om sukkels die het toch proberen, direct een ban te geven.
Zelf ben ik fel tegenstander van sudo zoals het bij bijvoorbeeld Ubuntu wordt toegepast. Simpelweg omdat het een ingebouwde privilege escalation is. Gewone gebruikers doen van alles op hun prompt en dat kun je dus ook allemaal per ongeluk als root uitvoeren. Als ik inlog op mijn servers, zie ik een mooie rode prompt, zodat ik weet dat ik root ben.
Door Korund:
Het is mogelijk de OpenSSH-service zodanig te configureren dat de root-gebruiker rechtstreeks mag inloggen. Dit staat default uit; je moet er expliciet voor kiezen. Als dat zo is, ben je als systeembeheerder fout bezig en verdien je het ook dat je systeem gehackt wordt.
Het is mogelijk de OpenSSH-service zodanig te configureren dat de root-gebruiker rechtstreeks mag inloggen. Dit staat default uit; je moet er expliciet voor kiezen. Als dat zo is, ben je als systeembeheerder fout bezig en verdien je het ook dat je systeem gehackt wordt.
Kennelijk verdien ik het al decennia om gehackt te worden. Mijn ssh daemon staat altijd op "PermitRootLogin prohibit-password" en "PasswordAuthentication no". Inloggen kan alleen met een ed25519 key en daarnaast staat fail2ban te brommen om sukkels die het toch proberen, direct een ban te geven.
Zelf ben ik fel tegenstander van sudo zoals het bij bijvoorbeeld Ubuntu wordt toegepast. Simpelweg omdat het een ingebouwde privilege escalation is. Gewone gebruikers doen van alles op hun prompt en dat kun je dus ook allemaal per ongeluk als root uitvoeren. Als ik inlog op mijn servers, zie ik een mooie rode prompt, zodat ik weet dat ik root ben.
Je moet de sudoers wel even africhten voor normale gebruikers en ze geen volledige root rechten geven maar alleen bepaalde commando's die per se root rechten vereisen.
Door Joep Lunaar:
Terzijde: het gebruik van het woord "gewoon" verraad vaak oppervlakkige kennis.
Door Anoniem:
[knip /]
Waarom denk je *zero day* ?
Alsof iedere host altijd gepatched is naar de laatste stand .
Gewoon , 380-day vulnerability kan ook prima - nog meer als het 'IoT' systeem is , want dat zijn typisch gevallen van nooit geupdate .
Ik ken geen IOT systeem met openssh-server (wel dropbear op routers e.d.). De forte van de non-IOT systemen waarop een gerenommeerde Linux distributie draait is dat die in de regel goed up-to-date zijn dankzij een goed werkend software management systeem (RPM/Yum, dpkg/apt, enz). En waar een Linux systeem in een container draait en vanaf het Internet aanroepbare diensten draait is dat in de regel achter een firewall en reverse proxy.[knip /]
Waarom denk je *zero day* ?
Alsof iedere host altijd gepatched is naar de laatste stand .
Gewoon , 380-day vulnerability kan ook prima - nog meer als het 'IoT' systeem is , want dat zijn typisch gevallen van nooit geupdate .
Terzijde: het gebruik van het woord "gewoon" verraad vaak oppervlakkige kennis.
Hier niet . Het is _gewoon_ een naieve aanname dat 'Linux systemen' "in de regel" (yep, jij kent het kunstje ook) volledig bijgewerkt zijn en er _dus_ sprake moet zijn van een zero-day voor privilege escalation.
Het _kan_ goed gedaan worden, en een goede distro met goed package management maakt dat goed mogelijk , maar aannemen dat dat de regel is , is wat optimistisch.
Voor de omstandigheid dat een systeeem 1) direct aanlogbaar is , en 2) er met brute force pogingen (al) ingelogd kan worden is het m.i. best bijzonder als er dan _wel_ een volledig gepatchte installatie op zou zitten , na de eerste twee indicaties van erg matig beheer.
Je moet de sudoers wel even africhten voor normale gebruikers en ze geen volledige root rechten geven maar alleen bepaalde commando's die per se root rechten vereisen.
"Je" moet "ze"? Mijn computer, maar ook mijn servers zijn allen single user computers. Moet ik mezelf africhten en rechten ontnemen en een privilege escalation intalleren zodat een eventuele ongenode gast ook bepaalde commandos als root kan uitvoeren?
Sudo is alleen handig op multi user systemen. Meestal is een desktop dat niet.
Inderdaad root toegang via het netwerk staat default uit. Als je dat aanzet en dan ook nog eens met naam wachtwoord laat authenticeren ben je bewust dom bezig. Ik vrees dat Microsoft het Windows Subsysteem voor Linux (WSL) bedoelt, dat tegenwoordig in elk windows systeem is opgenomen. Ik ken die gebruikers die default als root werken onder windows 10/11
Beetje ongeloofwaardig verhaal. Deze compileer methode werkt helemaal niet met SELinux aan. In het stuk van Microsoft wordt hier niets over vermeld. Verder moet er software (broncode van OpenSSH ) van buiten worden gedownload. Dat werkt al helemaal niet in een enterprise omdat alleen software via bv redhat satellite wordt toegestaan en servers helemaal niet of beperkt internet verkeer heeft. Kansloos dus.
Waarschijnlijk gaat het alleen over een Linux IoT device dat door Microsoft zelf is omarmt of een Microsoft WSL installatie.
Waarschijnlijk gaat het alleen over een Linux IoT device dat door Microsoft zelf is omarmt of een Microsoft WSL installatie.
Eigenlijk klopt het niet om te zeggen dat OpenSSH gebruikt wordt bij een aanval; er is eerst al een geslaagde aanval waarbij de aanvaller root kan worden, en dan wordt er OpenSSH met een backdoor gebruikt om toegang te houden. Maar dat laatste is niet erg relevant; de aanvaller die inmiddels root is, kan elk stuk software vervangen door iets wat hem handig uitkomt. Dat het in dit geval OpenSSH is, is minder relevant. Misschien wordt zelfde methode ook wel gebruikt waarbij bv mail- of webserver softwasre vervangen wordt door een versie met een backdoor.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
