De Terrapin-aanval begrijpen
De Terrapin aanval, ook bekend als CVE-2023-48795, is een potentiële bedreiging voor de veiligheid van SSH verbindingen. Het werkt door het afkappen van het onderhandelingsbericht voor extensie (volgens RFC8308) dat wordt uitgewisseld tussen de client en de server. Dit kan mogelijk de veiligheid van je verbinding in gevaar brengen, maar niet in alle gevallen.
Hier is een diepgaande analyse.
Welke clients/servers zijn kwetsbaar?
Bijna alle implementaties zijn gevoelig voor deze aanval, behalve degene die een specifieke fix hebben geïmplementeerd.
Lopen al mijn SSH-servers risico op een Terrapin-aanval?
Niet noodzakelijkerwijs, of als dat wel zo is, slechts in zeer beperkte mate. De mogelijke aanvallen en hun vereisten worden in de volgende secties besproken.
Wat voor soort aanvallen kunnen worden uitgevoerd?
Er zijn drie soorten Terrapin aanvallen die uitgevoerd kunnen worden:
1. Misbruik maken van een kwetsbaarheid in de AsyncSSH-server.
2. Het uitschakelen van de toetsaanslagtiming tegenmaatregelen die door elke server zijn geïmplementeerd. Veel servers implementeren deze maatregelen echter niet vanwege de complexiteit en het lage succespercentage van uitbuiting, vooral als er sterke wachtwoorden worden gebruikt.
3. Het forceren van enkele zwakke algoritmen, voornamelijk SHA-1, op elke server. Hoewel SHA-1 als zwak wordt beschouwd, is het niet kwetsbaar wanneer het binnen het SSH-protocol wordt gebruikt, waardoor het beveiligingsrisico zeer beperkt is.
Wat is er nodig om een Terrapin-aanval uit te voeren?
De Terrapin aanval vereist een man-in-the-middle aanval, wat betekent dat de aanvaller toegang moet hebben tot het lokale netwerk van de client of server. Een client die verbinding maakt met een malafide Wi-Fi op een openbare plek is voldoende. Als een server alleen toegankelijk is via SSH vanaf het bedrijfsnetwerk of een VPN, kan de aanval alleen worden uitgevoerd door een insider.
Hoe kan ik mijn SSH-server beschermen tegen de Terrapin-aanval?
Hier zijn enkele oplossingen:
1. Upgrade uw clients en servers om “strikte sleuteluitwisseling” te ondersteunen. De meeste servers, vooral die ingebed zijn in een Linux-distributie, ondersteunen deze protocoluitbreiding momenteel niet. Zowel de client als de server moeten deze uitbreiding ondersteunen om veilig te zijn.
2. Schakel alle zwakke algoritmen op je server uit. Dit zorgt ervoor dat zelfs als de Terrapin aanval slaagt, het niet in staat zal zijn om je beveiliging te verlagen.
3. Dwing sterke wachtwoorden of sleutelauthenticatie af. Dit blokkeert de exploitatie van de Terrapin-aanval.
4. Schakel de algoritmen uit die de Terrapin aanval mogelijk maken: ChaCha20-Poly1305 en CBC-Encrypt-dan-MAC. Behoud in plaats daarvan de sterkste: aes256-gcm & hmac-sha2-512.
5. Beperk SSH toegang vanaf het internet. Door een VPN verbinding af te dwingen voordat je je server bereikt, blokkeer je alle aanvallen van buitenaf; alleen een insider zou de aanval kunnen uitvoeren.
Implementeer deze algemene best practices voor verbeterde beveiliging, ongeacht de Terrapin aanval, met uitzondering van de eerste aanbeveling.
Richtlijnen voor verharding
De mogelijkheid om algoritmes in of uit te schakelen is inherent productafhankelijk. Voor het doel van deze discussie zullen we ons richten op Linux, gezien het wijdverspreide gebruik ervan.
Er zijn typisch twee methodes om cryptografische algoritmen te configureren: via de sshd service of via beleid op systeemniveau. Elke methode heeft zijn eigen voordelen.
sshd Configuratie (/etc/ssh/sshd_config):
– Deze aanpak is universeel en toepasbaar op alle platforms.
– Het vereist de specificatie van toegestane algoritmen; het staat niet toe om specifieke algoritmen uit te schakelen.
Cryptografisch systeembeleid:
– Niet alle platforms bieden deze functie.
– Hiermee kunnen algoritmen worden in- en uitgeschakeld.
– Deze functie biedt de flexibiliteit om instellingen exclusief voor SSH of globaal voor alle protocollen te beheren, zoals het uitschakelen van SHA-1 voor alle protocollen.
– Het dient als centraal punt voor het beheer van al je cryptografische beleidsregels.
– De beleidsregels zijn onderverdeeld in meerdere bestanden, waardoor ze eenvoudig en flexibel kunnen worden ingezet.
– Opmerking: Op bepaalde platformen kan het beleid mogelijk niet de interne OpenSSH-sleutels beheren; in dergelijke gevallen is vertrouwen op de sshd-configuratie noodzakelijk.
Het is mogelijk om beide opties te integreren, zoals het uitschakelen van alle zwakke algoritmen in de beleidsregels en het whitelisten van toegestane algoritmen in de sshd-configuratie.
Gebruik tot slot het volgende commando om de impact van je wijzigingen te verifiëren: `ssh -vv 127.0.0.1`. Het resultaat van alle geaccepteerde algoritmen wordt weergegeven op de regels “debug2: ciphers stoc:” & “debug2: MACs stoc:”.
Wil je op de hoogte blijven van de nieuwste bedreigingen? Schrijf je dan in voor onze SOC-nieuwsbrief.
Bekijk onze website.
