OpenSSH Alpine: lange wachtwoorden omzeilen SSH-auth

OpenSSH brengt een noodreparatie uit voor een kwetsbaarheid die vooral relevant is voor Alpine Linux met de standaard openssh-server-pakketconfiguratie. Het probleem is dat aanvallers in kunnen loggen op accounts die geen wachtwoord hebben, zoals SSH-key-only accounts. Daarbij misbruiken ze een wachtwoordlengte tussen 257 en 1.024 bytes.

Er zijn nog geen gerapporteerde aanvallen bekend, maar de impact kan groot zijn omdat een combinatie van instellingen en accounttypes de deur openzet. Daarom is het verstandig om vandaag nog te controleren en te patchen.

Wat gebeurt er precies bij OpenSSH op Alpine?

Op sommige Alpine Linux servers draait een OpenSSH-variant waarvan de authenticatie niet via PAM verloopt. In dat scenario doet sshd zelf het controleren van wachtwoorden. De kwetsbaarheid ontstaat door hoe sshd samenwerkt met musl, de C-bibliotheek waarop Alpine is gebaseerd.

In de kwetsbare situatie kan een aanvaller met netwerktoegang, een accountnaam en een speciaal gekozen wachtwoordlengte proberen in te loggen op een account dat in /etc/shadow eigenlijk geen wachtwoord heeft (bijvoorbeeld waarbij het wachtwoordveld is ingesteld op *). Slaagt de poging, dan kan de aanvaller toegang krijgen zonder dat een “echt” wachtwoord nodig is.

Wanneer is een Alpine server kwetsbaar?

Alpine beschrijft het risico als een set voorwaarden die samen moeten voorkomen. Je kunt een systeem als blootgesteld beschouwen als alle onderstaande punten gelden:

• Je gebruikt openssh-server dat is gebouwd zonder PAM (of je draait openssh-server-pam met UsePAM no).
• PasswordAuthentication staat aan (het is standaard “yes”).
• Er bestaat ten minste één account waarvan het wachtwoordveld * is (dus: “geen wachtwoord ingesteld”).
• Er bestaat bovendien minstens één ander lokaal account met een wachtwoordhash die begint met $5$ of $6$ (dat zijn gangbare hash-typen).

Belangrijk: als er één account met een wachtwoordhash met $5$ of $6$ aanwezig is, dan kan dat de blootstelling voor alle accounts zonder wachtwoord in dezelfde machine verhogen. De advisory geeft ook aan dat de aanval bij elke poging met een enkele verbinding kan slagen.

Welke accounts in Alpine hebben “geen wachtwoord”?

In de advisory worden enkele voorbeelden genoemd van accounttypes die doorgaans wachtwoordloos zijn. Denk aan:

• Key-only gebruikers die met adduser zonder password zijn aangemaakt of waarbij later een wachtwoordveld is aangepast naar *.
• Gebruikers die via een directoryservice worden geleverd met musl-gebonden componenten, waardoor ze geen shadow entry krijgen.
• De root account in bepaalde basisimages (bijvoorbeeld als root:* in de base image zit vanaf ongeveer Alpine 3.16).
• De standaard alpine gebruiker in official cloud images die via tiny-cloud zijn opgebouwd.

Let op: de standaard instelling PermitRootLogin kan root direct beperken (bij “prohibit-password”). Maar die bescherming helpt niet als een aanvaller via een blootgesteld wachtwoordloos account kan escaleren naar root, bijvoorbeeld via tools zoals doas.

Extra aandacht: tiny-cloud images en doas

In tiny-cloud images van specifieke versies (genoemd: 3.18.11 tot en met 3.24.3) staat de alpine gebruiker standaard wachtwoordloos doas toe. Bij een “schone” start is dat niet per definitie problematisch, maar de situatie kan veranderen zodra er een $6$-hash op de machine terechtkomt (bijvoorbeeld nadat een beheerder later een console-wachtwoord instelt).

Op dat moment wordt de combinatie van voorwaarden opnieuw mogelijk. Dan kan een aanvaller inloggen als de alpine gebruiker en vervolgens met doas naar root doorgroeien.

Welke omgevingen zijn juist niet kwetsbaar?

Niet elke Alpine-instantie of Linux-systeem met OpenSSH loopt risico. De advisory noemt onder meer:

• Systemen die geen sshd draaien (containers zonder sshd dus).
• Systemen waar PasswordAuthentication expliciet op no staat.
• Cloud setups die via cloud-init meteen de instelling zetten die passwordlogins uitschakelt.
• Accounts die “locked” zijn met een ! in /etc/shadow.
• Machines zonder een wachtwoordhash in de $-stijl (dus: geen relevante hash-typen aanwezig).

Daarnaast geeft de onderzoeker aan dat het probleem niet exclusief tot Alpine is, omdat het samenhangt met musl-gebaseerde omgevingen. In de technische uitwerking worden ook OpenWrt, Buildroot en Yocto genoemd om te checken. Bij OpenWrt gebruikt men echter standaard Dropbear, dat volgens de melder niet getroffen is; het risico bestaat dan alleen als OpenSSH daar daadwerkelijk is geïnstalleerd.

Wat kun je nu doen? (patchen of noodmaatregelen)

OpenSSH heeft een fix uitgebracht in versie 10.6p2. Alpine heeft bovendien gefixte pakketten beschikbaar gemaakt voor releases terug tot 3.16.

1) Update en herstart op Alpine

Omdat het upgradeproces het draaiende sshd niet automatisch vervangt, moet je na het updaten resteren. De aanbevolen aanpak is:

• Update pakketten: apk upgrade -U -a
• Herstart sshd: rc-service sshd restart

Point releases zoals 3.21.10, 3.22.8, 3.23.8 en 3.24.4 bevatten de fix al. Versies uit oudere, niet meer ondersteunde branches hebben eveneens een fixpakket ontvangen.

2) Als je (nog) niet kunt patchen: zet PasswordAuthentication uit

Kun je niet direct updaten, schakel dan passwordlogins uit. De advisory raadt aan om dit snel te doen en je SSH key-login vooraf te verifiëren. Houd vervolgens je huidige sessie open tot een nieuwe login slaagt.

Je kunt PasswordAuthentication instellen op no via een drop-in configuratiebestand of door elke relevante regel in /etc/ssh/sshd_config te wijzigen (inclusief regels binnen Match-blokken). Controleer daarna dat sshd de instelling ziet met:

• sshd -T | grep -i passwordauthentication

De advisory benadrukt dat je bij onzekerheid moet uitgaan van een compromis en verder onderzoek moet doen.

3) Check je logs op verdachte pogingen

Om te beoordelen of er al pogingen zijn gedaan, kijk je in logbestanden zoals /var/log/messages naar sshd-regels met meldingen in de trend van “Accepted password …” voor accounts die eigenlijk geen wachtwoord zouden moeten hebben (bijvoorbeeld alpine, root of een key-only gebruiker).

Bekijk daarnaast ook of doas-gebruik, nieuw aangemaakte gebruikers, en wijzigingen in authorized_keys sporen van misbruik kunnen tonen.

Waarom juist lange wachtwoorden werken

De kern van de kwetsbaarheid zit in de manier waarop sshd wachtwoorden afhandelt zonder PAM op musl-systemen. sshd gebruikt de C-functie crypt() om de poging te hashen en vergelijkt die met de waarde in het wachtwoordveld.

Accounts zonder ingesteld wachtwoord hebben in dat veld *. Dat is te kort om een volledige hash op te slaan, inclusief salt. Hierdoor “leent” sshd in deze specifieke situatie de salt van een ander account met een echte hash.

Voor hash-types $5$ en $6 accepteert musl niet alle wachtwoordlengtes. Wanneer een wachtwoordpoging langer is dan musl toestaat, geeft de crypt()-functie een * retour om een fout te signaleren. Dat * matcht vervolgens met wat er opgeslagen staat voor wachtwoordloze accounts. Daardoor kan sshd de login onterecht als geldig behandelen. De advisory noemt daarbij zowel een ondergrens (257 bytes) als een bovengrens (1.024 bytes) die ook te maken hebben met hoe sshd de maximale lengte begrenst.

De fix in 10.6p2 maakt dat sshd een match weigert als het opgeslagen wachtwoordveld te kort is (de advisory noemt dit een workaround). Stable Alpine packages bevatten daarnaast al een patch voor hetzelfde probleem.

Wat betekent dit voor jouw beveiligingsaanpak?

Deze casus laat zien dat “alleen wachtwoordloos” niet automatisch veilig is als de authenticatielaag anders werkt dan je verwacht. Juist bij standaardconfiguraties en omgevingen met afwijkende library-implementaties kan een combinatie van factoren leiden tot onverwachte toegang.

Als je je blootstelling wil verkleinen, helpt het om:

• SSH-configuraties uniform te maken (zeker PasswordAuthentication en PAM-instellingen).
• Op musl-achtige omgevingen extra alert te zijn bij authenticatiegedrag.
• Updates niet alleen “installeer”, maar ook toepassen met herstart waar dat nodig is.

Wil je breder nadenken over hoe je blootstelling prioriteert, dan sluit ons artikel over exposure prioritization goed aan.

Conclusie

OpenSSH op bepaalde Alpine Linux servers kan authenticatie omzeilen via lange wachtwoorden wanneer een specifieke set voorwaarden klopt: PAM ontbreekt, passwordlogins zijn aan, er bestaan wachtwoordloze accounts (*) en er is minimaal één account met een relevante hash ($5$ of $6$). De juiste reactie is direct patchen naar OpenSSH 10.6p2 en sshd herstarten. Lukt dat niet meteen, zet dan PasswordAuthentication op no en verifieer je toegang via keys.

Doe vandaag nog de checks en updates om te voorkomen dat je omgeving alsnog profiteert van deze omzeilroute.

Interne referentie: voor andere SSH- en authenticatiekwetsbaarheden binnen omgevingen met snelle veranderingen kun je ook kijken naar device code phishing en wat je nu doet (handig als je incidentrespons rond inlogprocessen wil aanscherpen).

Bron: https://thehackernews.com/2026/11/openssh-issues-emergency-fix-for-flaw.html