Hackers misbruiken actief een kwetsbaarheid in OpenSSH die bekendstaat als SSHole. Het lek, geregistreerd als CVE-2026-123158, maakt onder specifieke omstandigheden authenticatie-omzeiling mogelijk op bepaalde Linux-systemen die musl gebruiken. Volgens meerdere beveiligingsbedrijven zijn sinds 5 november exploitpogingen gezien, kort nadat publieke exploitcode beschikbaar kwam. Een dag later werden ook succesvolle aanvallen gemeld.
De kwetsbaarheid is relevant voor organisaties die lichte Linux-distributies inzetten in cloud-, container- of virtualisatieomgevingen. In het bijzonder wordt Alpine Linux genoemd, een distributie die vaak wordt gebruikt vanwege de kleine footprint. Het lek raakt niet ieder OpenSSH-systeem, maar de combinatie van OpenSSH, musl en specifieke account- en authenticatie-instellingen kan voldoende zijn om toegang af te dwingen.
Bevestigd: misbruik kort na publicatie van exploitcode
De kwetsbaarheid werd vorige week openbaar gemaakt door beveiligingsonderzoeker Ozgun Kultekin. OpenSSH-beheerders hebben het probleem verholpen in versie 10.6p2, die op 5 november verscheen. Ongeveer vier uur later kwam proof-of-conceptcode beschikbaar. Beveiligingsbedrijven melden dat aanvallers diezelfde dag begonnen met pogingen om het lek uit te buiten.
Het Finse beveiligingsbedrijf Defused zag in het weekend een beperkt aantal actoren dat SSHole probeerde te misbruiken. Het bedrijf omschreef de activiteit niet als wijdverspreid. GreyNoise registreerde op 7 november om 00:46 UTC de eerste succesvolle exploitatie binnen zijn eigen meetomgeving, ongeveer veertig uur na het verschijnen van de patch. Het bedrijf benadrukt dat zijn waarnemingen niet noodzakelijk representatief zijn voor alle activiteit rond SSHole.
In totaal zag GreyNoise 16 succesvolle exploitatieketens tegen netwerken die door het bedrijf worden gemonitord. Die activiteit kwam van zes bron-IP-adressen en was gekoppeld aan handelingen na de initiële compromittering. Daarnaast registreerde GreyNoise op grotere schaal 27,5 miljoen scans op poort 22 en 20,1 miljoen pogingen tot SSH-sessies, maar die aantallen zijn niet bevestigd als SSHole-aanvallen.
Ook Previdian, een bedrijf voor netwerkbeveiliging, bevestigde succesvolle exploitatie op basis van eigen sensordata. Daarin ging het om 20 pogingen vanaf 13 aanvallende IP-adressen in negen landen. Offensive security-bedrijf watchTower meldde op 6 november dat het SSHole zag worden misbruikt in aanvallen die samenhangen met botnets en cryptominingactiviteit.
Hoe de kwetsbaarheid werkt
SSHole treft OpenSSH op bepaalde musl-gebaseerde Linux-systemen. De kern van het probleem zit in de afhandeling van wachtwoordverificatie bij accounts waarvan het wachtwoordhashveld op een sterretje (*) staat. Zo’n waarde wordt normaal gebruikt om wachtwoordlogins voor een account te blokkeren.
Bij het aanbieden van een te groot wachtwoord kan de password-hashingfunctie van musl bij een fout eveneens een sterretje teruggeven. OpenSSH kan dat vervolgens ten onrechte behandelen als een overeenkomende waarde met het opgeslagen accountveld. Daardoor kan een aanvaller onder de juiste omstandigheden inloggen op een account waarvoor wachtwoordlogin juist onmogelijk zou moeten zijn.
Volgens de toelichting van Kultekin vereist uitbuiting specifieke authenticatie-instellingen. Accounts met geldige wachtwoordhashes worden niet door deze specifieke fout getroffen. Wel kan de impact groot zijn als het overgenomen account zonder wachtwoord administratieve rechten mag gebruiken; in dat scenario kan de aanvaller roottoegang krijgen.
Waargenomen gedrag na compromittering
De aanvallen die GreyNoise onderzocht, gingen verder dan alleen toegang verkrijgen. De aanvaller voerde verkenning uit op systeem- en containerniveau, deed pogingen om cloudmetadata-services te bevragen, probeerde wachtwoordhashes en root-SSH-sleutels te lezen en wijzigde SSH-bestanden voor authorized_keys om blijvende toegang te regelen.
In één geval wist een aanvaller rootrechten te verkrijgen en TAC Agent te installeren, een command-and-control-agent geschreven in Python. De implant kon echter geen verbinding maken met zijn C2-server op tac.vpnla[.]org en ontving daardoor geen opdrachten. Analyse van de payload laat zien dat TAC Agent shellcommando’s kan uitvoeren, uitgebreide systeemverkenning ondersteunt, bestanden kan uploaden en downloaden en zichzelf kan bijwerken.
De agent bevat volgens GreyNoise geen eigen persistentiemechanisme. Daarom probeerden de aanvallers die persistentie te bereiken door een opstartservice te configureren. GreyNoise merkte daarnaast op dat commentaar, logs en foutmeldingen in de implant in het Chinees waren. Dat kan samen met andere indicatoren helpen bij attributie, maar vormt op zichzelf geen hard bewijs voor herkomst.
Analyse: kleine fout, grote operationele impact
De technische randvoorwaarden maken SSHole geen universeel OpenSSH-lek, maar de combinatie van OpenSSH, internetbereikbare SSH-diensten en veelgebruikte cloudimages maakt het risico toch concreet. Vooral omgevingen waarin tijdelijke, lichte Linux-systemen snel worden uitgerold, kunnen kwetsbaar blijven als patchbeheer of configuratiecontrole achterloopt.
De snelle overgang van patch naar proof-of-concept en vervolgens naar waargenomen exploitatie onderstreept opnieuw hoe kort het venster voor verdediging kan zijn. Aanvallers lijken niet alleen op initiële toegang te mikken, maar ook direct op credentialdiefstal, cloudcontext en blijvende SSH-toegang. Dat maakt detectie na een mogelijke inbraak minstens zo belangrijk als het installeren van de update.
Wat beheerders moeten controleren
Beheerders van mogelijk getroffen systemen doen er goed aan OpenSSH zo snel mogelijk bij te werken naar een versie waarin het probleem is verholpen. Voor systemen die onder de kwetsbare voorwaarden vallen, is het uitschakelen van SSH-wachtwoordauthenticatie eveneens een relevante maatregel.
Daarnaast is controle nodig op onverwachte succesvolle wachtwoordlogins bij accounts waarvan het /etc/shadow-wachtwoordveld een sterretje bevat, op onbekende SSH-sleutels in authorized_keys en op aanwezigheid van TAC Agent-bestanden of ongeautoriseerde opstartservices. Zulke sporen kunnen wijzen op misbruik dat al heeft plaatsgevonden.
Bron: bleepingcomputer.com
