Debian arbejder på højtryk for at dæmme op for SSH-hul

For at forhindre en ondsindet udnyttelse af det alvorlige sikkerhedshul, har Debian-udviklerne frigivet flere værktøjer.

Udviklerne hos Debian havde i sidste uge travlt med at dæmme op for mere alvorlige konsekvenser af det kritiske sikkerhedshul i Debian GNU Linux' implementering af OpenSSL.

Udviklerne har ikke blot frigivet en rettelse, men har også udsendt flere værktøjer, som skal forhindre ondsindede personer i at bryde ind på servere ved hjælp af sårbarheden.

Der er tale om en alvorlig sårbarhed, da den ikke blot påvirker selve Debian GNU Linux, men også de Linux-distributioner, der bygger på Debian. Debian er den mest populære basis for distributioner og anvendes eksempelvis i Ubuntu, der således også skal opdateres.

»Konklusionen er, at det er meget meget meget alvorligt og skræmmende. Sørg for, at du både har opdateret dine systemer og har genskabt alle potentielt svage krypteringselementer,« skriver Bojan Zdrnja fra sikkerhedsorganisationen SANS Internet Storm Center.

Sårbarheden fandtes i Debians implementering siden efteråret 2006, og den betyder, at nøgler til SSH og SSL bliver skabt ud fra et regelsæt, der begrænser antallet af mulige nøgler drastisk.

Det gør det muligt for en hacker at forsøge at skaffe sig SSH-adgang ved at prøve sig frem med disse nøgler, som allerede er skabt ved hjælp af scripts.

Det bedste forsvar mod sådan et angreb er naturligvis at udstede helt nye nøgler med den opdaterede version i den seneste opdatering til Debian.

For at det skal være effektivt, skal samtlige nøgler imidlertid erstattes, og det kan være lettere sagt end gjort. Derfor har Debian-udviklerne også frigivet et værktøj, ssh-blacklist, som sortlister de nøgler, der er skabt med den sårbare metode, så de ikke længere kan bruges.

Et andet værktøj, ssh-vulnkey, blev også distribueret sammen med opdateringen i sidste uge, men systemadministratorer bør være opmærksomme på, at Debian-udviklerne frigav en opdateret version fredag, som lukkede en mindre fejl i den første udgave.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (1)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Lars Lundin

Som skrevet i et andet indlæg brugte jeg en times tid d. 13. på at opgradere en håndfuld debian baserede maskiner.

På den baggrund kunne jeg godt tænke mig lidt mere diskussion af præcis hvilke situationer det har og har haft hvilke risisci. Her er nogle muligheder, og de deraf følgende risisci, så godt jeg kan forstå dem (personligt er jeg mest interesseret i Situation 6):

Situation 1: En sårbar debian(-afledt) installation aktiverer som udgangspunkt kun ssh-klienten, men ikke serveren. Brugen af ssh-klienten giver i sig selv ingen problemer på den maskine (se dog S. 3 nedenfor), eller hvad?

Situation 2: Som ovenfor, og klienten har kun foretaget autentikering mod konti på andre maskiner med kodeord, altså ingen nøgler. Efter min erfaring, så nøjes mange (nye) brugere med denne type for autentikering. Ingen problemer, eller hvad?

Situation 3: En klient har foretaget autentikering med sikre host-nøgler, men med sårbare klient-nøgler. Klienten har altså i første omgang identificeret sig overfor den korrekte maskine, men hvis kontoen på denne maskine er kompromitteret (inklusiv en ondsindet administrator), så må den private nøgle regnes for kompromitteret. Kan nogen svare på om host-nøglerne også indgår i krypteringen af selve klient-sessionen? Hvis ja, så burde det sikre mod at udenforstående lytter med på linjen (man-in-the-middle attack), men ellers må det også regnes for givet.

Situation 4: En klient har foretaget autentikering med sikre klient-nøgler, men med sårbare host-nøgler, altså mod en sårbar debian(-afledt) installation. Sessionen er sårbår overfor man-in-the-middle attack og DNS-hijacking, dvs. klienten må regnes for at have identificeret sig overfor en falsk og ondsindet maskine (der evt. sender kommunikationen videre til den faktiskt ønskede maskine). Såvidt jeg kan se, så medfører det ikke i sig selv at den private klient-nøgle kan være kompromitteret, men den udenforstående, ondsindede part kan sende beskeder tilbage, som ikke kan ses at være falske.

Situation 5: En klient har foretaget autentikering med sårbare host- og klient-nøgler, altså mod en sårbar debian(-afledt) installation. Den private nøgle må anses for kompromitteret overfor enhver, der kan lytte med på linjen (man-in-the-middle attack, DNS-hijacking), eller som har adgang til kontoen på den anden maskine.

Situation 6: En sårbar debian(-afledt) installation kører en ssh-dæmon, med sårbare hostnøgler, men klient-nøglerne er OK, det kan f.eks. ske ved at gamle konti replikeres på en ny maskine. Hvilke risisci indebærer det? Alle mine egne maskiner befinder sig i denne kategori.

Situation 7: En sårbar debian(-afledt) installation kører en ssh-dæmon, med OK hostnøgler, men klient-nøglerne er sårbare. Et brute-force indbrud er muligt, hvis et konto-navn kan gættes (dvs. maskinen kan regnes for kompromitteret, hvis root login er tilladt). Eller hvad?

Situation 8: Som 7, men en offentlig nøgle kendes af andre. Maskinen må regnes for kompromitteret, eller hvad? Hvorvidt ssh-dæmonen bruger sårbare hostnøgler synes ikke at kunne gøre sagen værre, eller hvad?

Situation 9: Som 7, men ssh-dæmonen bruger sårbare hostnøgler. Er det værre end 7?

Iøvrigt, så viser den efterhåden relativt udbredte Ubuntu installation en stor rød/orange ikon, når der er opdateringer klar, så andelen af Ubuntu-maskiner der forbliver sårbare i længere tid tror jeg bliver lille. (selv så jeg et Ubuntu ikon med openssh opdateringeren allerede d. 13. kl. 23).

  • 0
  • 0
Log ind eller Opret konto for at kommentere