OpenSSH-gebruikersnamen door kwetsbaarheid te achterhalen
Een beveiligingslek in OpenSSH maakt het mogelijk voor aanvallers om op afstand gebruikersnamen te achterhalen, waarmee mogelijk vervolgaanvallen zijn uit te voeren. "Dit beveiligingslek produceert geen lijst van geldige gebruikersnamen, maar maakt het mogelijk om gebruikersnamen te raden", zegt onderzoeker Didier Stevens van securitybedrijf Nviso.
Door een misvormd public key authenticatiebericht naar een OpenSSH-server te sturen kan het bestaan van een bepaalde gebruikersnaam worden vastgesteld. Als de gebruiker niet bestaat zal er een bericht naar de client worden gestuurd dat de authenticatie is mislukt. Wanneer de gebruiker wel bestaat, zal het niet kunnen parsen van het bericht ervoor zorgen dat de communicatie wordt afgebroken. De verbinding wordt dan zonder het terugsturen van een bericht gesloten.
Volgens Stevens doet de kwetsbaarheid zich voor omdat communicatie over het niet bestaan van een gebruikersnaam zich voordoet voordat het bericht volledig wordt verwerkt. De kwetsbaarheid werd via een commit op het ontwikkelaarsplatform GitHub openbaar gemaakt en proof-of-concept-exploits zijn beschikbaar. "Er zijn momenteel nog maar beperkt updates beschikbaar om deze kwetsbaarheid te verhelpen", aldus het Nationaal Cyber Security Centrum (NCSC). Voor Debian (Jessie) 8.0 is er een update beschikbaar gekomen. Stevens laat weten dat de kwetsbare authenticatiemechanismen van OpenSSH kunnen worden uitgeschakeld totdat er een patch beschikbaar en uitgerold is.
Bij een veilig systeem kun je daarom ook nooit met de gebruiker 'root' inloggen. Je moet met een administrator account inloggen en vandaar uit root worden via een 'sudo' commando.
Maar het klopt dat dit niet een erg gevaarlijk lek is. Tenslotte moet je ook nog het wachtwoord gebruiken.
Bij een veilig systeem kun je daarom ook nooit met de gebruiker 'root' inloggen. Je moet met een administrator account inloggen en vandaar uit root worden via een 'sudo' commando.
Maar het klopt dat dit niet een erg gevaarlijk lek is. Tenslotte moet je ook nog het wachtwoord gebruiken.
Bij een veilig *nix systeem kan je niet remote met een password inloggen maar maak je gebruik van een ssh-key die voorzien is van een password .... ;)
Vreemd dat dit nog kan. Op websites is het al lang gebruikelijk om geen concrete feedback terug te geven. Enkel iets van 'de combinatie user/pass is onjuist' en niet 'gebruiker bestaat niet'. En bij een pw reset ook enkel weergeven 'als uw emailadres bestaat, zal u een mail ontvangen met reset link', ipv 'de mail die u opgeeft bestaat niet'.
Dit lijkt mij hetzelfde.
Als de aanval niet terug te vinden is in de authentication logs dan kan fail2ban niks betekenen.
De sudo mythe maakt in mijn optiek systemen alleen maar onveilig!
Het merendeel van sudo is unconfigured. Daardoor krijg je root rechten cadeau, zonder password (...). Bijvoorbeeld op OS-X.
Beter dus geen sudo OF een zeer strict geconfigureerde sudo (hetgeen heel mooi kan, restricten tot zelfs op command argumenten aan toe!).
Maar, het moge duidelijke zijn waarom de major BSD's by default zonder sudo komen.
De kern van je argument is wel juist (en ik lees dat jij naast root, nog aparte admin accounts daarvoor gebruikt):
Het is simpelweg beter als een user niet ongelimiteerd admin commands kan uitvoeren.
Maar door ongeconfigureerde sudo is het raden van een SSH username dus nu dus wel ineens een problematisch probleem.
En wat betreft OpenSSH; gebruik AllowUsers/AllowGroups/DenyUsers/DenyGroups, en specificeer welke user wel/niet van welk IP mag komen.
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.
