Sårbarhet i OpenSSH

En sårbarhet har upptäckts i verktyget OpenSSH, som ofta används för administrativ åtkomst till exempelvis servrar, klienter och annan utrustning. NCSC-SE informerar här för att skapa förståelse för problemet och rekommendera åtgärder.

Det är säkerhetsföretaget Qualys[1] som har upptäckt en sårbarhet[2] i den portabla[3] varianten av verktyget OpenSSH.

Sårbarheten existerar i versioner mellan 8.5p1 och 9.7p1, eller innan version 4.4p. Om en angripare lyckas utnyttja sårbarheten ger den möjlighet till åtkomst till system med administratörsrättigheter.

SSH-protokollet används ofta för administrativ åtkomst och är något som är vanligt förekommande på både servrar, klienter och olika typer av utrustning inom infrastruktur och IoT, varför en allvarlig sårbarhet i denna tjänst även om den är ovanlig måste betraktas noga.

För att ett lyckat angrepp ska kunna ske måste angriparen kunna etablera en nätverksförbindelse till det system som har dessa svagheter. Detta gör att en begränsning i den allmänna SSH-åtkomsten är en tillräcklig förmågehöjande åtgärd, men den skyddar inte om den som attackerar först i ett första steg tagit sig förbi dessa begränsningar. I dessa fall kan denna svaghet utnyttjas för eskalering av intrånget.

Även om få system är nåbara från internet finns fortfarande de som är det, och dessa måste tas om hand omedelbart.

Fyra anledningar som gör detta till en allvarlig situation

1. Vilka enheter som har OpenSSH med dessa svagheter är förhållandevis okänt i organisationer[4]. Historiskt har man arbetat över tiden med att få bort okrypterade protokoll som telnet från dammsugare, glödlampor och kylmaskiner, men samma inventering har man inte gjort med krypterad, SSH-baserad, access. Därför har dessa system inte dokumenterats och man har ingen kännedom om var OpenSSH finns och ännu mindre vilka versioner som används och därför kan inte slutsatser dras om man har de beskrivna problemen.
2. Många använder egenbyggda tjänster (inklusive egna versioner av SSH), eller har SSH inlagt som en del av en container eller en virtuell appliance, som är byggda med de delar av biblioteken som har svagheter, vilket gör att det kan försvåra att förstå i vilka system en sårbar version finns.
3. OpenSSH-projektet pekar själva[5] på att de idag demonstrerade attackmetoderna som nyttjar denna svaghet kan komma att förbättras eller utökas, varpå SSH-programvara länkad mot andra bibliotek eller arkitekturer som idag inte anses sårbara helt plötsligt kan anses sårbara. Eller att tiden det tar att utföra ett angrepp markant kortas.
4. Vi är just nu i semestertider. Detta gör att för många organisationer är det svårt med planering och resurssäkring för att hantera riskbedömningar, förändringar i IT-miljöer eller att ens göra en inventering av nätverket för att leta efter var ett visst protokoll erbjuds eller en viss teknisk implementation av detta protokoll finns.

Rekommendationer:

Omedelbart:

1. Använd system som Shodan[6] och Shadowserver[7], eller gör en egen skanning[8] av ert IP-adressutrymme från Internet. Kontrollera om ni har externt exponerad SSH-access som är tillgänglig från Internet. Åtgärda detta omedelbart, antingen genom att temporärt stänga av SSH-tjänsten eller placera den bakom en VPN-åtkomst eller annan typ av trafikfiltrering.
2. Gör en inventering av era system och dokumentera vilka som har SSH, och planera för att åtgärda dessa enligt denna CVE oavsett om de är exponerade mot Internet eller inte. Uppgradera till en säker version av OpenSSH vilket kan vara en äldre version med ändringar införda för denna CVE. Det rekommenderas att man som standard nyttjar de uppdaterade versioner som tillverkaren av utrustning eller programvara tillhandahåller eftersom dessa kan ha andra rättningar införda eller ha leverantörsspecifika tillägg. Det är därför viktigt att kontrollera mot sin leverantör vilka säkerhetsvarningar och dokumentation av uppdateringar som de tillhandahåller. Som ett andra alternativ kan man välja att använda OpenSSH 9.8p1 eller senare version. I containerbaserade system måste även uppdatering göras av alla containrar som nyttjar OpenSSH, inte bara underliggande operativsystem.
3. Begränsa möjligheten att påverka sårbara system genom att införa trafikbegränsning (rate limit) mot OpenSSH. Sårbarheten nyttjas genom att angriparen skickar mycket trafik över tid för att åstadkomma ett dåligt tillstånd (race condition) i OpenSSH och man kan fördröja tiden för lyckat angrepp genom att minska mängden trafik.
4. Se till att öka uppmärksamheten för denna typ av attacker i den övervakning som används. Övervakning och uppföljning bör tills vidare ske antingen baserat på direkta spår av attacker eller indirekta spår genom att en användare loggat in via SSH.

På längre sikt

1. Dokumentera vilka tjänster (portar) som ska vara öppna på vilka maskiner och ta i bruk automatisk kontroll av att inget annat än det som ska vara öppet är det. Detta gäller både inkommande och utgående trafik, och inte bara fysiska utan även virtuella maskiner, containrar och pod:ar.
2. I er programvaruutveckling, planera för fall där bibliotek som används upptäcks ha så kallade nolldagarssårbarheter (zero days), och öva sådana situationer.

Det ska noteras att det börjar komma enkla verktyg[9] som kan användas för att kontrollera utrustning.

Ytterligare information: https://cert.se/2024/07/kritisk-rce-sarbarhet-i-openssh.html

Hänvisningar

[1] https://www.openwall.com/lists/oss-security/2024/07/01/3

[2] https://www.cve.org/CVERecord?id=CVE-2024-6387

[3] Versionen för OpenBSD innehåller inte dessa svagheter.

[4] Jämför med det problem som många organisationer ställdes inför i samband med CVE-2021-44228, sårbarheten i Log4j.

[5] https://www.openssh.com/txt/release-9.8

[6] https://www.shodan.io

[7] https://www.shadowserver.org

[8] https://www.openssh.com/releasenotes.html

[9] Ett sådant verktyg är detta python-script som ligger på Github: https://github.com/xaitax/CVE-2024-6387_Check