image

Shadowserver: bijna 11 miljoen SSH-servers kwetsbaar voor Terrapin-aanval

woensdag 3 januari 2024, 16:39 door Redactie, 17 reacties

Bijna 11 miljoen SSH-servers wereldwijd zijn kwetsbaar voor de 'Terrapin-aanval' die eind december werd onthuld, waaronder bijna 367.000 in Nederland, zo laat de Shadowserver Foundation vandaag weten. Via de aanval kan een aanvaller de gebruikte authenticatie-algoritmes downgraden en bepaalde maatregelen tegen keystroke timing-aanvallen, die in OpenSSH 9.5 werden geïntroduceerd, uitschakelen.

Om de aanval uit voeren moet een aanvaller wel een man-in-the-middle-positie tussen de client en server hebben, waarbij het mogelijk is om verkeer op de TCP/IP-laag te onderscheppen en aan te passen. Daarnaast moet voor het opzetten van de verbinding gebruik worden gemaakt van ChaCha20-Poly1305 of de Cipher Block Chaining (CBC) encryptiemode met de optie 'Encrypt-then-MAC'.

Via SSH kunnen gebruikers op een beveiligde manier op bijvoorbeeld servers inloggen of op afstand machines beheren. De Terrapin-kwetsbaarheid, ook aangeduid als CVE-2023-48795, is volgens de onderzoekers vanwege de kwetsbare encryptiemodes lastig te patchen. Wel zijn inmiddels voor allerlei populaire programma's, waaronder OpenSSH, PuTTY en WinSCP, updates uitgekomen.

De Shadowserver Foundation is een in Nederland en de Verenigde Staten geregistreerde non-profitstichting die zich bezighoudt met de bestrijding van botnets en cybercrime. De organisatie scant regelmatig op kwetsbare systemen. Bij de laatste scan werd gecontroleerd op CVE-2023-48795. Dan blijkt dat bijna elf miljoen servers nog kwetsbaar zijn, aldus de onderzoekers, waarvan bijna 367.000 in Nederland.

Reacties (17)
03-01-2024, 17:57 door Anoniem
Het is zaak om zowel de server als de client te patchen:
Connecting a vulnerable client to a patched server, and vice versa, still results in a vulnerable connection.
(https://terrapin-attack.com/)
03-01-2024, 18:51 door Xavier Ohole
Om de aanval uit voeren moet een aanvaller wel een man-in-the-middle-positie tussen de client en server hebben, waarbij het mogelijk is om verkeer op de TCP/IP-laag te onderscheppen en aan te passen.

Pas dus op met o.a. hotel-wifi.
03-01-2024, 20:12 door Anoniem
en wat als je server side nu eens geen tja-tja-nogwat-poly en of cbc toe laat?
03-01-2024, 20:41 door Anoniem
CVE-2023-48795 werd in Linux Ubuntu al gerepareerd op 19 december van het vorig jaar.
Ook vandaag (3 januari) zijn updates uitgerold voor ssh.
03-01-2024, 20:54 door Anoniem
Door Xavier Ohole: Om de aanval uit voeren moet een aanvaller wel een man-in-the-middle-positie tussen de client en server hebben, waarbij het mogelijk is om verkeer op de TCP/IP-laag te onderscheppen en aan te passen.

Pas dus op met o.a. hotel-wifi.

Niet alleen op bij hotel-wifi moet je daar rekening mee houden. Je moet hier rekening mee bij alle verbindingen die via een onvertrouwd netwerk verlopen, waaronder alle verbindingen via het publieke Internet. De tijd dat je pakketjes aan een internetprovider kon geven en dat ze ongelezen/ongeschonden aankomen bij de ontvanger zijn we al een aantal decennia voorbij.
04-01-2024, 08:27 door Bitje-scheef
Inmiddels wordt de shadowserver-scan een dagelijks aankloppend dingetje. Ook weer een hoop nieuwe (proxy)servers voor de zwarte hoeden die langskomen.
04-01-2024, 08:46 door Anoniem
in Linux Ubuntu al gerepareerd op 19 december
Ook in 22.04 LTS ...?
Ik zie bij mij geen ssh tussen de upgradeables staan.

in Linux Ubuntu al gerepareerd op 19 december
In OS-X kun je beter `brew install openssh` doen, om af te komen van OS-X' gebundelde ssh client af te komen, welke doelbewust 'gesaboteerd' is om vooral geen hardware security keys te ondersteunen (zoals bijv. de Yubikey Bio en Kensington VeriMark Guard). Ze zullen wel een andere agenda hebben gok ik dan maar.

Door Anoniem: en wat als je server side nu eens geen tja-tja-nogwat-poly en of cbc toe laat?
Hetgeen het advies is van CheckPoint (dat stiekem ook gewoon FreeBSD met OpenSSH is, maar dan met een prijskaartje waarvan weinig geld naar de werkelijke makers gaat. Legitiem conform de license, maar niet heel chique).
Ondanks dat FreeBSD in de laatste patches telkens OpenSSH update'te, is deze nog niet aangepakt.
En CheckPoint zal daar denk ik -als in aanname!- niet op vooruitlopen.
Want een advies van hen luidt, in sshd_config:
Ciphers -chacha20-poly1305@openssh.com
04-01-2024, 09:48 door Anoniem
Beetje een storm in een glas water dit.
Ja tuurlijk dit is een probleem alleen moet je zoals hierboven beschreven wel een MITM kunnen doen en dus zou je netwerk al compromised moeten zijn.
Oftewel reguliere patchronde en niet echt reden tot paniek.
04-01-2024, 10:46 door Anoniem
Door www.terrapin-attack.com: Additionally, the connection must be secured by either ChaCha20-Poly1305 or CBC with Encrypt-then-MAC.
Ik ben benieuwd hoe AI met zo'n omschrijving om zou gaan.

Is dat: (ChaCha20-Poly1305 || CBC) && Encrypt-then-MAC

of toch: ChaCha20-Poly1305 || (CBC && Encrypt-then-MAC)
04-01-2024, 10:49 door Anoniem
Door Anoniem: en wat als je server side nu eens geen tja-tja-nogwat-poly en of cbc toe laat?
Volgens de website von Terrapin is er dan geen probleem:
If you feel uncomfortable waiting for your SSH implementation to provide a patch, you can workaround this vulnerability by temporarily disabling the affected chacha20-poly1305@openssh.com encryption and -etm@openssh.com MAC algorithms in the configuration of your SSH server (or client), and use unaffected algorithms like AES-GCM instead.
04-01-2024, 11:10 door Anoniem
Door Anoniem: Beetje een storm in een glas water dit.
Ja tuurlijk dit is een probleem alleen moet je zoals hierboven beschreven wel een MITM kunnen doen en dus zou je netwerk al compromised moeten zijn.
Oftewel reguliere patchronde en niet echt reden tot paniek.
Inderdaad bij Redhat is het niet eens important (laat staan critical) maar moderate. Dat zelfs een moderate issue aandacht krijgt zegt wel iets :)
04-01-2024, 13:31 door Anoniem
Door Anoniem:
in Linux Ubuntu al gerepareerd op 19 december
Ook in 22.04 LTS ...?
Ik zie bij mij geen ssh tussen de upgradeables staan.

Daar moet je ook niet kijken denk ik. Bij een LTS worden security fixes vaak ge-backport. Canonical publiceert wat je wilt weten op https://ubuntu.com/security/cves?q=CVE-2023-48795 . Zowel 20.04LTS als 22.04LTS zijn gepatched.
04-01-2024, 16:22 door Anoniem
Door Anoniem: Hetgeen het advies is van CheckPoint (dat stiekem ook gewoon FreeBSD met OpenSSH is, maar dan met een prijskaartje waarvan weinig geld naar de werkelijke makers gaat. Legitiem conform de license, maar niet heel chique).
Ondanks dat FreeBSD in de laatste patches telkens OpenSSH update'te, is deze nog niet aangepakt.
Kan zijn dat ik je niet begrijp en je het over CheckPoint heb, maar FreeBSD is al op 19 december geüpdatet.
https://www.freebsd.org/security/advisories/FreeBSD-SA-23:19.openssh.asc
04-01-2024, 18:39 door Anoniem
Door Anoniem:
Door www.terrapin-attack.com: Additionally, the connection must be secured by either ChaCha20-Poly1305 or CBC with Encrypt-then-MAC.
Ik ben benieuwd hoe AI met zo'n omschrijving om zou gaan.
Is dat: (ChaCha20-Poly1305 || CBC) && Encrypt-then-MAC
of toch: ChaCha20-Poly1305 || (CBC && Encrypt-then-MAC)
De echte experts weten dat ChaCha20-Polcy1305 een AEAD cipher is waarbij geen MAC nodig is. (AES-)CBC heeft wel een losse MAC functie nodig omdat dit een 'confidentialty only' block-mode is. De logische uitleg is dus dat het `ChaCha20-Poly1305 || (CBC && Encrypt-then-MAC)` moet zijn. Maar of een AI/taalmodel dat snapt, is maar de vraag.
05-01-2024, 08:43 door Anoniem
Door Anoniem:
Door Anoniem: Beetje een storm in een glas water dit.
Ja tuurlijk dit is een probleem alleen moet je zoals hierboven beschreven wel een MITM kunnen doen en dus zou je netwerk al compromised moeten zijn.
Oftewel reguliere patchronde en niet echt reden tot paniek.
Inderdaad bij Redhat is het niet eens important (laat staan critical) maar moderate. Dat zelfs een moderate issue aandacht krijgt zegt wel iets :)

We zien dat vaker. SSH is dermate robust gebleken over de jaren dat elke CVE hoger dan 2 groot nieuws is.
Het heeft denk ik ook te maken met het feit dat deze onderzoekers graag hun naam in het nieuws zien verschijnen.
1. Bedenk een spannende naam
2. Maak een website en een scanningtool.
3. Zorg voor zoveel mogelijk media aandacht.
4. Profit?

Ik zag ook zakelijk 't een ander aan mailverkeer rondgaan hieromtrent met een hoop paniek terwijl ik niet de indruk had dat zelfs de 'security officer' in kwestie daadwerkelijk gelezen had waar het om ging.
05-01-2024, 10:09 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: Beetje een storm in een glas water dit.
Ja tuurlijk dit is een probleem alleen moet je zoals hierboven beschreven wel een MITM kunnen doen en dus zou je netwerk al compromised moeten zijn.
Oftewel reguliere patchronde en niet echt reden tot paniek.
Inderdaad bij Redhat is het niet eens important (laat staan critical) maar moderate. Dat zelfs een moderate issue aandacht krijgt zegt wel iets :)

We zien dat vaker. SSH is dermate robust gebleken over de jaren dat elke CVE hoger dan 2 groot nieuws is.
Het heeft denk ik ook te maken met het feit dat deze onderzoekers graag hun naam in het nieuws zien verschijnen.
1. Bedenk een spannende naam
2. Maak een website en een scanningtool.
3. Zorg voor zoveel mogelijk media aandacht.
4. Profit?

Ik zag ook zakelijk 't een ander aan mailverkeer rondgaan hieromtrent met een hoop paniek terwijl ik niet de indruk had dat zelfs de 'security officer' in kwestie daadwerkelijk gelezen had waar het om ging.
Ach zo gaat het hier ook. Van Linux hebben ze geen kaas gegeten en willen ze er ook niks over weten. Log4j ook grote paniek terwijl wij dat niet eens gebruiken. Alle open source wordt op 1 hoop gegooid.
06-01-2024, 14:04 door Anoniem
Door Anoniem:
Door Anoniem:
Door www.terrapin-attack.com: Additionally, the connection must be secured by either ChaCha20-Poly1305 or CBC with Encrypt-then-MAC.
Ik ben benieuwd hoe AI met zo'n omschrijving om zou gaan.
Is dat: (ChaCha20-Poly1305 || CBC) && Encrypt-then-MAC
of toch: ChaCha20-Poly1305 || (CBC && Encrypt-then-MAC)
De echte experts weten dat ChaCha20-Polcy1305 een AEAD cipher is waarbij geen MAC nodig is. (AES-)CBC heeft wel een losse MAC functie nodig omdat dit een 'confidentialty only' block-mode is. De logische uitleg is dus dat het `ChaCha20-Poly1305 || (CBC && Encrypt-then-MAC)` moet zijn. Maar of een AI/taalmodel dat snapt, is maar de vraag.

Een nogal groot deel van de NI (natuurlijke intelligentie) bezitters zal ook moeite hebben met de correcte interpretatie.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.