Opdater: Fejl i OpenSSH kan lække krypto-nøgler

Alvorligt sikkerhedshul i udbredt SSH-protokol giver hackere adgang til hukommelsen på tilsluttede computere.

Ifølge Ars Technica har sikkerhedsfirmaet Qualys afsløret et sikkerheds-hul i en af de mere udbredte secure shell (SSH) protokoller. Hullet giver ondsindede servere adgang til krypteringsnøgler og RAM hukommelsen på tilsluttede computere.

Sårbarheden skyldes en kodefejl, der giver adgang til eksperimental roaming i OpenSSH version 5.4 til 7.1. Fejlen ligger ikke på de versioner af protokollen som bruges på servere, men alene i den version slutbrugeren anvender for at forbinde sig til servere.

I en officiel meddelelse fra OpenSSH skriver man, at brugere af den sårbare udgave bør opdatere deres program straks, og at de, der ikke er i stand til at opdatere, bør deaktivere roaming ved at:

Tilføje UseRoaming no til den globale ssh_config(5) fil eller under brugerkonfigureringen ~/.ssh/config eller ved at taste UseRoaming=no på kommandolinjen.

Qualys oplyser på seclists.org at hullet alene kan udnyttes, efter at slutbrugeren selv har bekræftet sig over for serveren, hvilket mindsker risikoen betydeligt for, at sikkerhedsbristen kan brede sig.

Regenerering af SSH nøgler anbefales

Udviklere hos Qualys mener dog, at hackere muligvis allerede har gjort brug af hullet hos kompromitterede servere med det formål at sikre fortsat adgang i tilfælde af, at deres oprindelige adgang skulle blive opdaget og lukket.

Sammenlignet med en anden sikkerhedsbrist i OpenSSL i 2014 (Heartbleed), som gjorde det muligt for hackere at udnytte stort set enhver hjemmeside kørende OpenSSL, så kan OpenSSH-hullet alene udnyttes, efter at en slutbruger selv har oprettet forbindelse til en ondsindet konfigureret server.

Oven på afsløringen af sikkerhedsbristen oplyser Qualys, at højt profilerede hjemmesider eller brugere kan have behov for at generere nye SSH-nøgler.

Følg forløbet

Kommentarer (7)

Peter Valdemar Mørch

Oven på afsløringen af sikkerhedsbristen oplyser Qualys, at højt profilerede hjemmesider eller brugere kan have behov for at generere nye SSH-nøgler.

Er det ikke noget vrøvl at en hjemmeside kan have en SSH nøgle? Det er SSH nøgler ikke HTTPS certifikater.

Brugere ja, hjemmesider nej.

Peter Valdemar Mørch

Men så er det vel stadig brugerne af disse services, og ikke hjemmesiderne, der skal have nye nøgler. SSH nøglerne findes slet ikke på hjemmesiderne men "hjemme" hos hver enkelt administrator/bruger. (Ellers er der et helt andet, mere seriøst sikkerhedsproblem.)

"Brugere ja, hjemmesider nej." holder stadig så vidt jeg kan se.

Ars Technica artiklen siger:

"This information leak may have already been exploited in the wild by sophisticated attackers, and high-profile sites or users may need to regenerate their SSH keys accordingly," they wrote.

Så vrøvlet er ikke opfundet af Version2, men vrøvl er det vist stadig ikke desto mindre, og er ikke blevet fanget af Version2.

Jonas Iversen

Det ser ud til den nyeste version af OpenSSH er "OpenSSH 7.1p2 released Jan 14, 2016"...dvs. den er meget ny!
Hvis jeg har en Linux server (webserver), så skal jeg altså opgradere all OpenSSH pakker på denne?
(tvivler på de allerede ligger i de forskellige repositories)...hvad gør man så?
Og når OpenSSH så er opgraderet, så laver man nye client nøgler....er det rigtig forstået?

Jonas Iversen

...og hvad med de forskellige cloud udbydere (AWS, Google etc) hvor man forbinder via SSH....kan man forvente at de allerede har opgraderet OpenSSH (hvis det er dét de bruger) så man kan lave nye nøgler, eller skal man venter et par dage?

Morten Krøyer

Nu er jeg ikke super stærk i kryptografi, men begge parter i en sikker kommunikation har vel et nøglepar - og hvis serverens er blevet kompromitteret kan nogen opsnappe kommunikationen og udgive sig for at være den

Peter Valdemar Mørch

...begge parter i en sikker kommunikation har vel et nøglepar - og hvis serverens er blevet kompromitteret kan nogen opsnappe kommunikationen og udgive sig for at være den

Netop. "... hvis serverens er blevet kompromitteret ..." - og det er de ikke.

Fra Ars Technica artiklen:

The vulnerability resides only in the version end users use to connect to servers and not in versions used by servers. A maliciously configured server could exploit it to obtain the contents of the connecting computer's memory, including the private encryption key used for SSH connections.

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen