'Meer dan elf miljoen https-websites in gevaar door Drown-aanval'

Beveiligingsonderzoekers hebben een kwetsbaarheid ontdekt die het mogelijk maakt via het verouderde sslv2 binnen enkele uren verbindingen te ontsleutelen die zijn beveiligd met tls. Hierdoor zijn onder andere websites en mailservers getroffen.

De Drown-aanval met nummer cve-2016-0800, die staat voor Decrypting RSA using Obsolete and Weakened eNcryption, werkt door herhaaldelijk verbindingen naar een server op te bouwen met gebruik van sslv2. Daarmee kunnen steeds kleine stukjes informatie over de encryptiesleutel worden achterhaald en kan uiteindelijk een onderschepte tls-verbinding ontsleuteld worden. Een server is kwetsbaar voor de aanval als deze zowel tls en sslv2 ondersteunt of als dezelfde privésleutel aanwezig is op een sslv2-server en een tls-server. Een van deze configuraties komt volgens de onderzoekers bij 33 procent van alle https-servers op het internet voor.

Normaal gesproken is sslv2 uitgeschakeld, omdat het een oude implementatie van het ssl-protocol is. Veel servers blijken deze echter nog steeds te ondersteunen, bijvoorbeeld door een verkeerde configuratie. Zo is het in OpenSSL standaard zo dat ondersteuning voor sslv2 is uitgeschakeld, maar zijn er toch beheerders die deze instellingen overschrijven, meldt Ars Technica. Daarnaast zijn er twee kwetsbaarheden in OpenSSL, cve-2015-3197 en cve-2016-0703, die de aanval aanzienlijk eenvoudiger en sneller maken. Het wordt dan ook aangeraden de updates uit te voeren die dinsdag zijn uitgebracht. Er zouden volgens de onderzoekers geen aanwijzingen zijn dat de kwetsbaarheid actief wordt gebruikt.

De aanval is volgens Ars Technica niet eenvoudig uit te voeren, omdat deze ervan uitgaat dat de aanvaller het verkeer tussen een slachtoffer en de server in de gaten kan houden. Als de nodige informatie eenmaal in handen van de aanvaller is, kan deze echter met weinig moeite de verbinding ontsleutelen. De onderzoekers maakten daarvoor een paar uur gebruik van de Amazon EC2-dienst voor 440 dollar, omgerekend ongeveer 405 euro.

De onderzoekers hebben een online tool ter beschikking gesteld waarmee gecontroleerd kan worden of een server daadwerkelijk vatbaar is voor de aanval. Het is niet de eerste keer dat de beveiliging van ssl in het geding komt, in mei 2015 werd de zogenaamde Logjam-aanval bekend.

drown Schematische weergave van een Drown-aanval

IT-banen

Reacties (47)

bartvb

1 maart 2016 17:11

Makkelijke tool om te checken hoe het staat met de toegestane ciphers/protocols op jouw SMTP server:
https://ssl-tools.net/mailservers/

SSLv2 is echt al behoorlijk antiek, bizar dat er nog zoveel servers kwetsbaar zijn.

edit: Ik weet eigenlijk niet zeker of de ssl-tools.net tool goed checkt of je SSLv2 aan hebt staan, SSLv3 wordt in ieder geval wel gedetecteerd. Als je daar ziet dat je server wel SSLv3 doet dan is het ook tijd om eens naar je configuratie te kijken, ook SSLv3 heeft best een aantal problemen. Verder is de kans vrij groot dat SSLv2 uit staat als in het lijstje met protocollen alleen TLSv[123] wordt genoemd.

Andere site om te checken:
https://test.drownattack.com/

[Reactie gewijzigd door bartvb op 22 juli 2024 15:16]

World Citizen @bartvb • 1 maart 2016 17:27

Is er een heel klein kansje dat je ons uitlegt waar na te kijken $_/-\o_$

Ik krijg namelijk een "weak cipher" melding maar heb geen idee of dit terug slaat op deze "hack". (Ben een hobbyist )

Weak ciphers
supported
RSA_WITH_RC4_128_SHA

-253 days remaining 2048 bit sha1WithRSAEncryption
Expired

[Reactie gewijzigd door World Citizen op 22 juli 2024 15:16]

Erulezz @World Citizen • 1 maart 2016 17:40

Weak ciphers kun je op lossen door onder andere deze configurator te gebruiken;

https://mozilla.github.io...tls/ssl-config-generator/

Hydranet @Erulezz • 1 maart 2016 21:51

Deze site bevat ook wel wat handige info mbt TLS en cipher suites, waar ook weer een link staad naar die handig configurator

azerty

@World Citizen • 1 maart 2016 17:37

Weak Ciphers krijg je omdat je dus nog toestaat dat RC4 als cipher gebruikt wordt (http://www.imperva.com/do...ng_ssl_when_using_rc4.pdf, https://blog.qualys.com/s...in-tls-is-broken-now-what).

Je certificaat is zo te zien al bijna 3/4 jaar vervallen...

[Reactie gewijzigd door azerty op 22 juli 2024 15:16]

Verwijderd @azerty • 1 maart 2016 21:59

Eh, als ik tweakers.net invoer krijg ik ook de melding: Weak ciphers
supported
RSA_WITH_RC4_128_SHA

azerty

@Verwijderd • 1 maart 2016 22:11

Wel ja, dat is ook redelijk logisch... Hoe meer oude clients je wilt ondersteunen, hoe meer verouderde ciphers je moet toestaan... Een site als tweakers wilt natuurlijk zo veel mogelijk publiek trekken, en heeft dus deze "zwakke" ciphers nog ingeschakeld.

Voor de meesten gaat het niet uitmaken, omdat modernere clients moderne ciphers gebruiken, maar theoretisch is het een probleem.

Ge Someone @Verwijderd • 2 maart 2016 18:02

Maar aangezien op Tweakers https niet verplicht/automtisch is (tenzij je HTTPS everywhere gebruikt) vindt men het misschien geen probleem.

Robo @World Citizen • 1 maart 2016 23:25

RC4 is weak.

Voor de best practices kun je naar deze RFC van IETF kijken: https://tools.ietf.org/html/rfc7525

aadje93 @World Citizen • 2 maart 2016 01:14

het probleem is dat ciphers "gedowngrade" kunnen worden doordat een kwaadwillende zich voor gaat doen als oude browser (IE 4.0 ofzo?) en zo oude encryptie gebruikt. Daarom is het verstandig deze gewoon uit te zetten, die enkele % gebruikers die dat nog gebruiken en geen hedendaagse encryptie in de browser hebben is niet echt relevant vind ik persoonlijk.

musiman

@bartvb • 2 maart 2016 16:03

Een betere check kun je hier uitvoeren: https://www.ssllabs.com/ssltest

bartvb

@musiman • 2 maart 2016 16:24

Maar let dan wel hierop:
https://drownattack.com/#faq-ssllabs

ssllabs.com checkt alleen webservers terwijl het met DROWN vaak mis gaat met b.v. mailservers.

Overigens heeft Debian een jaar of 5 terug OpenSSL gepatcht zodat SSLv2 en alle 'export' ciphers uit zijn geschakeld. De meeste servers met Debian/Ubuntu zijn veilig dus.

Klippy

1 maart 2016 17:27

Het nieuws is dan ook niet zozeer dat SSLv2 verouderd is, maar dat alleen door het ondersteunen van SSLv2 ook de andere verbindingen kwetsbaar zijn.

Dit stukje uit de FAQ maakt dat het meest duidelijk:

SSLv2 has been known to be insecure for 20 years. What’s the big deal?

Indeed, SSLv2 has long known to be weak when clients and servers use it to communicate, and so nearly every modern client uses a more recent protocol. DROWN shows that merely allowing SSLv2, even if no legitimate clients ever use it, is a threat to modern servers and clients. It allows an attacker to decrypt modern TLS connections between up-to-date clients and servers by sending probes to any server that supports SSLv2 using the same private key.

Dus waar je er eerst vanuit kon gaan dat je voor legacy clients misschien nog wel SSLv2 aan kon laten staan en dat dan alleen het deel van je traffic dat SSLv2 gebruikte niet veilig was, blijkt nu dat dan in dat geval meteen ALLE traffic onderschept kan worden.
En je hebt je clients niet altijd onder controle, dus ik kan me situaties bedenken waar voor een klein aantal clients SSLv2 nog toegelaten werd terwijl 99% van het verkeer TLS gebruikt, maar ook dat is dus nu niet meer mogelijk.

Verwijderd @Klippy • 1 maart 2016 17:42

Op voorwaarde dat dezelfde private key voor beide protocollen gebruikt wordt, wat kennelijk dus op heel veel servers het geval is.

Ik ben het eens met de mensen die aangeven dat sslv2 support eigenlijk niet meer thuis hoort in openssl. Ik heb geen verstand van hoe openssl is opgezet maar wat ideaal zou zijn is dat je een modulaire opzet en dat per default de legacy modules niet worden meegeleverd.

Deze modules zou je b.v. alleen in 'insecure' repositories willen aanbieden zodat de moeite die gedaan moet worden om ze te installeren echt vrij groot is. Alleen mensen die heel bewust dat risico nemen zijn dan kwetsbaar.

Backwards misschien is waarschijnlijk te lang heilig geweest?

Ventieldopje @Verwijderd • 1 maart 2016 18:03

Standaard loop je niet eens risico, het probleem zijn de admins die te laks zijn en zonder blikken of blozen hun configuratie die ze al 20 jaar gebruiken er overheen knallen of geen idee hebben wat ze doen.

Wel zal een modulair ontwerp net zoals bijv. bij Apache een stuk makkelijker ontwikkelen en configureren zijn. Ook zal de overhead van legacy code een stuk minder zijn en dus sneller. Maar goed, zie dat maar eens bij zo'n project aan te pakken en daarna te auditen.

CAPSLOCK2000

Ssl
Netwerk en systeembeheer

@Verwijderd • 1 maart 2016 18:10

Op voorwaarde dat dezelfde private key voor beide protocollen gebruikt wordt, wat kennelijk dus op heel veel servers het geval is.

De meeste organisaties moeten flink betalen voor certificaten, die nemen er dus het liefst zo min mogelijk en zeker niet meerdere per server.

Ik heb geen verstand van hoe openssl is opgezet maar wat ideaal zou zijn is dat je een modulaire opzet en dat per default de legacy modules niet worden meegeleverd.
(...)
Alleen mensen die heel bewust dat risico nemen zijn dan kwetsbaar.

Het is in ieder geval heel configureerbaar. Standaard staat SSLv2 uit. Het is in principe al zo dat alleen mensen die er zelf moeite voor hebben gedaan nog SSLv2 hebben. Daarnaast is er nog een hoop oude troep uit de tijd dat we niet beter wisten.

Backwards misschien is waarschijnlijk te lang heilig geweest?

Techneuten snappen het wel maar veel bedrijven willen geen enkele klant weigeren, doet er niet toe wat voor risico's ze daarbij nemen met andere klanten. De risico's overzien ze meestal niet eens echt. Ze weten alleen dat klant X niet kan bestellen.

Devster 2 maart 2016 12:02

Wij zijn alleen nog maar false positives tegengekomen. Dit wordt ook bevestigd uit andere bronnen:

Digging a little deeper into the GitHub repo for the DROWN attack’s check utility (https://github.com/nimia/public_drown_scanner), we found a little disclaimer: “Likewise, it may also have false positives, i.e. it may indicate a server is vulnerable when it is in fact not.”. This explains the false positives.

Bron: http://www.softwaresecured.com/2016/03/01/how-to-confirm-whether-you-are-vulnerable-to-the-drown-attack

Ed Vertijsment 1 maart 2016 17:19

Wat ik me vooral afvraag is waarom dit soort issues steeds terugkomen, ik kan me voorstellen dat openssl een leuk target is maar er is al genoeg verschenen over de "matige" kwaliteit waar de code in zou verkeren.

Zouden distro's er niet goed aan doen om by default over te stappen naar libressl (welke probeert de codebase te auditten/refactoren naar een beter geheel)?

Armin

Ssl
Netwerk en systeembeheer

@Ed Vertijsment • 1 maart 2016 18:53

Meeste grote bedrijven zijn dan ook al overgestapt. Google's BoringSSL, Apple's SSL en inderdaad LibraSSL zijn allemaal forken van de OpenSSL. En de grote content-cachers zoals Akamai en CloudFlare hebben ook eigen varianten.

Maar het gaat hier voroal om websites waar HTTPS niet zo heel belangrijk is. Er wordt vaak wel stoer geroepen X van de top 5000 websites, maar die websites izjn meestal HTTP-only en hebben een HTTPS-server erbij die vaak zo goed als niets doet. Zelden gaat het om banken of andere serieuze bedrijven.

Dit zijn vaak bedrijven die oude software draaien, en die laten draaien zolang het "werkt". Wellicht wel patchen, maar de configuratie wordt niet aangeraakt.

WhatsappHack

Netwerk en systeembeheer

@Armin • 1 maart 2016 20:29

Meeste grote bedrijven zijn dan ook al overgestapt. Google's BoringSSL, Apple's SSL en inderdaad LibraSSL zijn allemaal forken van de OpenSSL. En de grote content-cachers zoals Akamai en CloudFlare hebben ook eigen varianten.

De vraag is wel in hoeverre het wenselijk is dat ze allemaal hun eigen spulletjes in elkaar gaan zetten. Niet hun eigen crypto in elkaar draaien, maar wel de libraries onafhankelijk van elkaar ontwikkelen. Dan krijg je alleen maar meer verdeeldheid.

Aan de ene kant is dat prettig omdat dan niet bij elke fout die er in OpenSSL te vinden is, meteen het hele web de l*l is; maar aan de andere kant is het minder prettig als ze allemaal voornamelijk hun eigen straatje schoonvegen en enkel voor hunzelf ontwikkelen; aldanniet zonder peer review.

Of het er veiliger op wordt vraag ik mezelf dan ook af.
Het is een lastige situatie.

Armin

Ssl
Netwerk en systeembeheer

@WhatsappHack • 1 maart 2016 21:13

De vraag is wel in hoeverre het wenselijk is dat ze allemaal hun eigen spulletjes in elkaar gaan zetten

Op zich eens, maar dat was al de gangbare manier van werken. Google sprak bijvoorbeeld wel van "contributing" naar de community, maar dat was vooral patches over de muur gooien en heel hard de andere kant op rennen. Akamai en CloudFlare niet anders. Dat is mede ook waarom OpenSSL zo'n zooi was.

Aan de andere kant, was het OpenSSL team ook niet erg actief. Deels vanwege gebrek aan mensen, maar deels ook gewoon omdat dat er zo ingeslopen was. BoringSSL, Apple's OpenSSL variant, etc worden wel actief ontwikkeld.

In feite dus nu meer een system waar je een aantal grote bedrijven hebt die mensen hebben en ook inzetten die verstand van zaken hebben en een paar bibliotheken ontwikkelen. Ik denk dat dat een stap vooruit is qua veiligheid.

Ideaal was wellicht om allemaal dezelfde te gebruiken, maar dat past niet echt in de mentaliteit van werken vabn Google en Apple. Die willen immers allemaal in control zijn. Bij open source kun je alle zaken wijzigen, en dus gebeurt het

Jan-E @Armin • 2 maart 2016 01:01

Aan de andere kant, was het OpenSSL team ook niet erg actief. Deels vanwege gebrek aan mensen, maar deels ook gewoon omdat dat er zo ingeslopen was. BoringSSL, Apple's OpenSSL variant, etc worden wel actief ontwikkeld.

Het OpenSSL team is tegenwoordig weer veel actiever. Er wordt nu driftig ontwikkeld aan OpenSSL 1.1.0.
Ook moet niet vergeten worden dat OpenSSL veel platformen ondersteunt. De ChaCha20/Poly1305 ciphers worden bijvoorbeeld actief gepromoot door Google/Chromium (als onderdeel van BoringSSL), maar ze compileren gewoon niet onder Windows x64. Wel onder Windows x86, gek genoeg.
Apple's OpenSSL variant heeft het ook makkelijker: slechts 2 platformen moeten ondersteund worden: OSX en iOS.

Edit: typo

[Reactie gewijzigd door Jan-E op 22 juli 2024 15:16]

JT @Ed Vertijsment • 1 maart 2016 17:23

Leest het volledige artikel

Zo is het in OpenSSL standaard zo dat ondersteuning voor sslv2 is uitgeschakeld, maar zijn er toch beheerders die deze instellingen overschrijven, meldt Ars Technica.

Wederom de mens als zwakste schakel en niet de programmatuur.

Ed Vertijsment @JT • 1 maart 2016 17:28

Waar ik meer op doelde is dat libressl afaik ssl2 er gewoon uitgemikt heeft. Dit zet dan ook meer druk op sysadmins om het niet te ondersteunen als het in de standaard distro zo meegeleverd wordt.

In openssl wordt dit gewoon in stand gehouden.

CAPSLOCK2000

Ssl
Netwerk en systeembeheer

@Ed Vertijsment • 1 maart 2016 18:14

Waar ik meer op doelde is dat libressl afaik ssl2 er gewoon uitgemikt heeft. Dit zet dan ook meer druk op sysadmins om het niet te ondersteunen als het in de standaard distro zo meegeleverd wordt.

In openssl wordt dit gewoon in stand gehouden.

Dat is niet realistisch. Systemen die nu SSLv2 draaien die doen dat omdat ze a) oud en niet onderhouden zijn of b) omdat een systeembeheerder de moeite heeft gedaan om SSlv2 aan te zetten.
De meeste systeembeheerders zullen dat niet doen omdat ze het zelf een goed idee vinden maar omdat ze software of hardware hebben die niet aangepast of vervangen kan worden. Die zullen nooit openssl vervangen door iets beters als dat betekent dat hun applicatie of apparaat stuk gaat, dan blijven ze liever met een antieke versie werken.

Jester-NL @Ed Vertijsment • 1 maart 2016 18:47

Even los van open vs. libressl...
Ik kom zat windows machines tegen met dezelfde combo.

[Reactie gewijzigd door Jester-NL op 22 juli 2024 15:16]

Jerie

@Ed Vertijsment • 1 maart 2016 18:00

Rabobank en Xs4all (website en smtp server) hebben er last van. Kwalijke zaak!

Vergelijking track record OpenSSL vs LibreSSL is hier te vinden:
https://en.wikipedia.org/...urity_and_vulnerabilities

Voor uitleg CVE-2016-0799 en lijst met meer software die kwestbaar is:
https://guidovranken.word...orruption-via-bio_printf/

WhatsappHack

Netwerk en systeembeheer

@Jerie • 1 maart 2016 20:31

Not sure if fair comparison, OpenSSL gaat natuurlijk al heel wat jaren langer mee dan LibreSSL en heeft nog altijd veel meer gebruikers waardoor het ook een wat interessantere oplossing is om te kraken; en wat ook meer kans heeft dat gebruikers/admins lekken tegen komen.

Niet dat ik LibreSSL slecht noem of ontken dat het minder veilig is, enkel dat de tijd het nog ff moet uitwijzen als je ze enkel gaat vergelijken op absolute aantallen kritieke lekken.

Jerie

@WhatsappHack • 1 maart 2016 22:10

Not sure if fair comparison, OpenSSL gaat natuurlijk al heel wat jaren langer mee dan LibreSSL en heeft nog altijd veel meer gebruikers waardoor het ook een wat interessantere oplossing is om te kraken; en wat ook meer kans heeft dat gebruikers/admins lekken tegen komen.

Heb je het wel gelezen? De vergelijking wordt gemaakt vanaf de tijd dat er geforked is. Dat heeft niets met track record te maken. Ten tweede het gaat er om of de CVE van toepassing is (ie. per gevonden bug in een van beide versies) en zo ja op welk project en zo ja op welke versies. Het is dus een fair comparison.

CAPSLOCK2000

Ssl
Netwerk en systeembeheer

@Ed Vertijsment • 1 maart 2016 18:05

Zouden distro's er niet goed aan doen om by default over te stappen naar libressl (welke probeert de codebase te auditten/refactoren naar een beter geheel)?

Mogelijk doen ze dat in de toekomst ook maar het is gigantisch veel werk. De applicatieprogrammeurs zullen het meeste werk moeten doen. Tot dat gebeurd is (of er in ieder geval grote stappen zijn genomen) zullen de distro's niet over gaan.

omoerbeek @CAPSLOCK2000 • 1 maart 2016 19:34

Hoveelheid werk valt erg mee. LibreSSL is binary compatible met OpenSSL. Eén van de uitgangspunten was: we maken een drop-in replacement.

R4gnax @Ed Vertijsment • 1 maart 2016 21:11

Wat ik me vooral afvraag is waarom dit soort issues steeds terugkomen

Vaak omdat business stakeholders technische beslissingsbevoegdheid hebben en indien ze deze niet hebben, een manier vinden om hun voet dwars te zetten en deze te nemen.

Qua beveiliging alles up-to-date houden is vaak te duur en het loopt toch niet zo'n vaart, of er zijn nog 0.01% van de klanten die van deze oude technologie afhankelijk zijn en als je daarvoor de veiligheid van de andere 99.99% een beetje moet compromiteren; ach wie gaat dat nou toch echt merken, heh?

freaky @Ed Vertijsment • 2 maart 2016 09:42

Tja, je zou er ook beter aan doen om op al je IIS installaties de SSL/TLS instellingen aan te passen. In IIS 7 staat het ook standaard aan en de meeste mensen weten niet echt hoe ze het aan moeten passen daar.

M.a.w. goed beheer is essentieel en dat is niet echt product afhankelijk.

Heb ook klanten die het gewoon nog serieus nodig hebben (gelukkig wel intern). Dus het er default uitstrippen zou ik persoonlijk niet vrolijk van worden. Het staat standaard uit in de config (al heel lang overigens op de meeste distros).

Meekoh 1 maart 2016 17:40

Tsja, opzich niet gek eigenlijk. Op Windows Server is SSLv2 standaard nog enabled.

Armin

Ssl
Netwerk en systeembeheer

@Meekoh • 1 maart 2016 19:22

Op Windows Server is SSLv2 standaard nog enabled.

Al veel jaren niet meer hoor. Volgens mij was 2008 (non R2) de laatste. En daarna zijn er flink wat updates/patches en bulletins gekomen van Microsoft om dat te veranderen.

Je moet vanaf 2008 R2 een registry plaatsen om het aan te zetten. Niet iets wat je per ongeluk doet.

Meekoh @Armin • 1 maart 2016 21:02

Nope de sslv2 client is al jaren standaard disabled. Sslv2 en 3 server is standaard nog steeds enabled. Ook op server 2012 r2!

Kalief 1 maart 2016 20:13

De info.php van mijn hostingprovider vermeldt:
Registered Stream Socket Transports: tcp, udp, unix, udg, ssl, sslv3, sslv2, tls.
Dit betekent dat genoemde kwetsbaarheid zich ook op mijn sites bevind?

WhatsappHack

Netwerk en systeembeheer

@Kalief • 1 maart 2016 20:26

Niet perse, dat PHP een socket ondersteuning geregistreerd heeft staan, wil niet zeggen dat Apache/nginx/watjeookgebruikt deze ondersteuning aan de voorkant aan heeft staan; en dat is wel vereist voordat de spreekwoordelijke pleuris uit kan breken...

Gebruik dus gewoon de gelinkte tool, dat is een stuk makkelijker.

Ook de Qualys scanner op ssllabs.com kent de aanval, en zal je dus kunnen vertellen hoe en wat; maar vertelt daarnaast wat er nog meer mis is. (Tot op zekere hoogte, die scanner weet ook niet alles en er ontbreken wat dingetjes.)

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 15:16]

Bjornmeijer935 1 maart 2016 21:46

Ik snap niet dat admins sslv2 en sslv3 niet gewoon standaard uitzetten, mail en web diensten zou wat mij betreft alleen maar tls 1.1/1.2 moeten accepteren en alles behalve sterke ciphers mag gewoon disabled blijven, en voor die paar clients die het dan niet doen tja daar moeten de mensen die ze gebruiken toch eens bij zichzelf gaan afvragen of ze die niet eens moeten upgraden.

Foamy @Bjornmeijer935 • 1 maart 2016 23:14

Het staat standaard al uit

Als het aanstaat dan is dat juist het werk van de admin

Soldaatje 1 maart 2016 17:16

Elf miljoen mensen doen hun deur niet op slot als ze boodschappen gaan doen, en hangen een briefje op "haal mijn huis leeg".
Dat is dus gewoon dom.
Sslv2 is al jaren standaard niet meer aanwezig in openssl, v3 is standaard uitgeschakeld.