Qualys-beveiligingsonderzoekers ontdekken lek in OpenSSH-client

Beveiligingsonderzoekers van Qualys hebben een lek vastgesteld in de OpenSSH-client. Deze maakt het voor een aanvaller mogelijk om met een kwaadaardige ssh-server het geheugen van de client uit te lezen, waardoor onder andere beveiligingssleutels uit kunnen lekken.

De site Undeadly laat weten dat versies 5.4 tot 7.1 van de OpenSSH-client getroffen zijn door de kwetsbaarheid, die het identificatienummer cve-2016-0777 heeft meegekregen. Er is inmiddels een patch beschikbaar in de 7.1p2-release van de software.

De authenticatie van de host key van de server zou ervoor zorgen dat de kwetsbaarheid niet door een man-in-the-middle-aanval te gebruiken is, maar alleen via een kwaadaardige of geïnfecteerde server. Als alternatief voor de patch kunnen gebruikers 'UseRoaming no' toevoegen aan hun ssh-configuratiebestand of bij het ssh-commando via de commandline de parameter '-oUseRoaming=no' gebruiken.

De bug zou zijn ontstaan doordat experimentele code voor het hervatten van beveiligde ssh-verbindingen in de clientsoftware van OpenSSH terecht is gekomen. De code heeft het echter nooit gehaald tot in de serversoftware.

Reacties (22)

[RvdH]

De authenticatie van de host key van de server zou ervoor zorgen dat de kwetsbaarheid niet door een man-in-the-middle-aanval te gebruiken is, maar alleen via een kwaadaardige of geïnfecteerde server.

Daarbij wordt er vanuit gegaan dat iedereen die ssh gebruikt netjes de fingerprint van de host key controleert op juistheid. In de échte wereld heb ik echter nog nooit iemand meegemaakt die dit daadwerkelijk doet.

[Str1ngS]

Als je autoScaling groups op Amazon gebruikt met cyclende instances dan wordt je automatisch fan van StrictHostKeyChecking=no

[JAVE]

Dan zet je dat toch uit voor die bepaalde host?

host <hostname>
StrictHostKeyChecking no
UserKnownHostsFile=/dev/null

het is onzinnig om deze optie dan maar voor alles uit te zetten omdat er 1 host niet netjes werkt...

[Verwijderd]

Aangezien AWS Autoscaling on-the-fly servers bijvoegt en verwijdert is het onbegonnen werk om elke keer je hosts file bij te werken. Die kunnen elke keer een ander IP-adres en hostname hebben.

Ik zit met een gelijkaardige situatie:

Ik trigger met Jenkins om het uur een deploy naar AWS instances via Ansible ( = continuous delivery model). Via de EC2 tags weet Ansible welke hosts welke roles moet krijgen. Als je dit gebruikt met autoscaling, krijg je problemen als strict hostkey checking gebruikt. Dan blijft je deployment mooi hangen op nieuwe instances die via autoscaling zijn gelaunched.

[JAVE]

Je kan wildcards gebruiken in je .ssh/config file.
Je kan zowel hostname als ip adres gebruiken.
Het lijkt me sterk dat je geen definitie kan maken voor AWS.

Ik gebruik het zelf vooral voor experimenteerbakken, die op basis van hun MAC address een vast IP adres krijgen van mijn DHCP server, maar de installatie op die machines wil nog wel eens veranderen (== nieuwe host key).
Op deze manier klaagt hij niet, en voegt hij de hostkey ook niet toe aan de known_hosts file.

Voor de OpenStack cloud die we op mijn werk gebruiken doe ik hetzelfde, maar dan op basis van het domein (Dus "host *.domein.com", zodat alle virtual machines die op dat domein draaien geen strict key checking hebben).

[CAPSLOCK2000]

Ik snap dat het makkelijk is maar echt verstandig is het uiteindelijk niet.
Ik weet niet geneog van Amazon om te verklaren wat het probleem is maar ik neem aan dat het er om gaat dat je systemen on-demand aanmaakt en dus ook niet de fingerprint weet.

Een goed management-systeem kan dat voor je oplossen. Waar ik werk verzamelen we alle hostkeys en fingerprints en publiceren die centraal zodat iedereen altijd de juiste fingerprints heeft.
Thuis gebruik ik mijn deployment-tool om dit soort gegevens te verzamelen en te delen met m'n clients.
In theorie zou je zelfs de keys kunnen pregeneraten en uitrollen indien nodig.

De moderne oplossing is om je hostkeys in DNS te publiceren met een SSHFP record. Dan kan je client zelf controleren of hij de juiste fingerprint krijgt. http://nick-black.com/dankwiki/index.php/SSHFP
Om dat goed te doen heb je wel DNSSEC nodig maar dat mag tegenwoordig geen probleem meer zijn.

[Blokker_1999]

Of DNSSEC geen probleem is weet ik niet. Heb nu een plugin in mijn browser die de status voor het domein weergeeft en moet zeggen dat er redelijk wat domeinen zijn waarvan ik verwacht dat ze het hebben waarbij de indicator gewoon uit blijft. Zelf heb ik het recent ook opgezet en het valt inderdaad reuzegoed mee.

[RobinF]

En wat is de naam van die plugin?

[Verwijderd]

Dat risico is alleen bij de allereerste verbinding aanwezig. Daarna controleert de SSH client het elke keer automatisch. Dat het niet voor MITM zou werken is dus inderdaad onjuist, maar in de praktijk wel erg lastig en onwaarschijnlijk.

[eternia16]

Inderdaad, je krijgt altijd een melding als de "fingerprint" niet klopt bij een moderne ssh client. Als je deze melding na de eerste keer aanmelden krijgt dan weet je dat de shitbom gebarsten is.

[Niemand_Anders]

Ik heb de fingerprint van mijn server gewoon in de DNS als SSHFP RR staan.

Je hebt hiervoor alleen een domein nodig welke met DNSSEC is beveiligd.
ssh-keygen geeft zelfs al de volledige (BIND) regel voor je zone bestand terug:
ssh-keygen -r $(hostname)

Vervolgens moet je in /etc/ssh/ssh_config of ~/.ssh/config de volgende directive opnemen:
VerifyHostKeyDNS yes

Eventueel kun je beperken welke type hostkeys je accepteerd:
HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss

Als de DNS hostkey overeenkomt met de fingerprint van de server waarmee je connect, dan krijg je ook niet 'unknown' fingerprint warning en of je deze wilt toevoegen aan de known hosts lijst. Als de key niet overeenkomt, wordt de connectie gewijzigd en krijg je een foutmelding terug.

Deze bug is zeer lastig te misbruiken, want weinig SSH gebruikers zullen verbinding maken met een willekeurige SSH server. Man in the middle zou kunnen, maar alleen als je nog niet eerder verbinding hebt gemaakt met de originele target server. Want de MITM SSH server zal namelijk een andere fingerprint hebben en geeft de client ALTIJD de fingerprint MISMATCH melding. Deze melding lijkt op een unknown host melding, maar geeft subtiel aan dat de fingerprint anders in dan in de known_hosts.

[Qunix]

Extra info:

Howto: https://unix.stackexchang...hfp-records/121881#121881
Testen: http://dnssec-debugger.verisignlabs.com/
Info: https://en.wikipedia.org/...ystem_Security_Extensions

[CyBeRSPiN]

Maar.. als je ooit eens connected bent geweest dan krijg je daarna vaak wel een vrij duidelijke warning over een potentiele man in the middle attack als de fingerprint wijzigt.
De fingerprint wordt opgeslagen in 'known_hosts' in je .ssh folder.

[Reactie gewijzigd door CyBeRSPiN op 26 juli 2024 22:02]

[84hannes]

Totaal irrelevant bij dit artikel: als je de hostkey niet controleert heb je niets aan een SSH verbinding in het algemeen.

[looc]

Nouja goed, ik heb al mijn servers gewoon als trusted gezet, als de key dus veranderd dan merk ik dat dus ook gelijk.
MiTM begone

[Verwijderd]

Euh, dan wuif ik bij deze even naar je. Zo ben je je eerste in je leven tegengekomen. Als de fingerprint niet overeen komt dan connect ik niet meer over die verbinding en vraag ik meestal een fysiek iemand aan de andere kant om één en ander te laten nakijken.

Fingerprints zijn ook neergeschreven op een papiertje. Wanneer die zonder mijn medeweten gewijzigd zijn dan wéét ik eenvoudigweg dat er een MITM bezig is.

Als je die niet nakijkt en gewoon lukraak maar connecteert; dan ben je verkeerd bezig. Eigenlijk kan je dan net zo goed gewoon telnet gebruiken.

[Blokker_1999]

Zelf controleer ik die key inderdaad niet. Maar als bij een volgende verbinding de melding komt dat deze is veranderd dan ben ik ineens wel heel voorzichtig met wat ik doe.

[Gert]

Wij hebben verschillende partijen voor data uitwisseling en scripted deployments waar dat wel bij gedaan wordt. Dat lijkt mij ook normaal wil je op een veilige manier hier mee om gaan.

[GekkePrutser]

Ik doe dit altijd hoor.. Als ik voor het eerst connect vanaf een bepaalde computer.

[CyBeR]

Krijg net een mailtje van Debian dat dit probleem bij hen al is opgelost.

[JustHev]

In de Portage tree van Gentoo zit sinds 16:30 ook een gepatchte versie.

[goarilla]

Ja maar dat is eigenlijk alleen een workaround en geen volledige oplossing. De workaround disabled roaming in de source code (https://lists.mindrot.org.../2016-January/034680.html). Je kan ook "UseRoaming No" in je ssh config files zetten. Maar het echte probleem, de code die een server toelaat een client's private key te snoopen, die moet nog gepatched worden.