image

Variant op 19 jaar oude aanval maakt ontsleutelen TLS-verkeer mogelijk

dinsdag 12 december 2017, 18:02 door Redactie, 6 reacties
Laatst bijgewerkt: 12-12-2017, 19:21

De manier waarop tal van websites een beveiligde verbinding naar bezoekers opzetten is kwetsbaar waardoor een aanvaller het versleutelde verkeer kan ontsleutelen, zo waarschuwen verschillende onderzoekers die hun aanval de naam ROBOT hebben gegeven.

ROBOT staat voor Return Of Bleichenbacher's Oracle Threat, vernoemd naar een aanval die de Zwitserse cryptograaf Daniel Bleichenbacher in 1998 ontdekte. Via TLS kan er een beveiligde verbinding tussen een webserver en browser van een bezoeker worden opgezet. Voor het beveiligen van de verbinding kan TLS van RSA-encryptie gebruikmaken. In een RFC-document is omgeschreven hoe dit moet worden geïmplementeerd, alsmede hoe de client en server sleutels voor de beveiligde verbinding kunnen uitwisselen.

In het geval implementaties de richtlijnen niet goed volgen kan een aanvaller aan de hand van foutmeldingen die de server geeft onderscheid maken tussen geldige en ongeldige berichten. Een aanvaller kan vervolgens discrepanties in TLS-foutmeldingen gebruiken om de pre-master geheime RSA-privésleutel (TLS-sessiesleutel) te bemachtigen die door TLS wordt gebruikt voor het ontsleutelen van versleutelde data. Het was Bleichenbacher die een dergelijke aanval in 1998 voor het eerst demonstreerde, vandaar dat dergelijke aanvallen Bleichenbacher-aanvallen worden genoemd.

Verschillende moderne cryptografische implementaties blijken kwetsbaar te zijn voor Bleichenbacher-achtige aanvallen op TLS, zo meldt het CERT/CC. Hierdoor kan een aanvaller in het ergste geval met RSA versleuteld verkeer ontsleutelen. Bij servers die alleen TLS RSA-encryptie ondersteunen kan een aanvaller het verkeer passief opslaan en het op een later moment ontsleutelen. In het geval van servers die van forward secrecy gebruikmaken, en een kwetsbare RSA-encryptie key exchange ondersteunen, hangt het risico af van hoe snel een aanvaller de aanval kan uitvoeren.

Tenminste zeven fabrikanten, waaronder F5, Citrix en Cisco, blijken kwetsbare implementaties te hebben. Hierdoor liepen ook grote websites risico, waaronder Facebook en PayPal. Bij 27 van de 100 populairste websites op internet werden subdomeinen aangetroffen die kwetsbaar waren. De onderzoekers hebben op Robotattack.org een test geplaatst waarmee websites en organisaties kunnen controleren of ze risico lopen. Beheerders van kwetsbare servers krijgen het advies om beschikbare updates te installeren of TLS RSA-encryptie waar mogelijk uit te schakelen.

Reacties (6)
12-12-2017, 23:02 door Anoniem
Prachtige actie van Google en anderen... dat https everywhere, maar nu zitten we voor websites met kwetsbaarheden op of slecht geconfigureerde servers wel met een heleboel sh*t en de gebakken peren (vergeef mijn Frans hier).

Even een voorbeeldje van de vele kwetsbare domeinen: zus.pl met een kwetsbare server voor de Bleichenbacher aanval
en nog een reeks kwetsbaarheden op een rij voor die server. Goed voor een plaatsje in de SSL Labs scan Hall of Shame met een F-graad status.

Er komt nog veel meer gatenkaas ellende uit het verleden ons achtervolgen! Alleen maar wachten tot het gevonden wordt.

Leuk die soms afgedwongen samenwerking van grote Amerikaanse tech-bedrijven en hun veiligheidsdiensten.
Je zou bijna gaan zeggen "onveiligheidsdiensten" met hun random generator encryptie kwetsbaarheden en jarenlang geheimgehouden handshake kwetsbaarheid. (Ironisch bedoeld overigens). De IT community is hen heel veel dank verschuldigd (iron.).
12-12-2017, 23:06 door Bitwiper
In het geval van servers die van forward secrecy gebruikmaken, en een kwetsbare RSA-encryptie key exchange ondersteunen, hangt het risico af van hoe snel een aanvaller de aanval kan uitvoeren.

Die vertaling klopt niet helemaal. De tekst moet luiden:
In het geval van servers die bij voorkeur van forward secrecy gebruikmaken, maar ook nog een kwetsbare RSA-encryptie key exchange ondersteunen, hangt het risico af van hoe snel een aanvaller de aanval kan uitvoeren.

Want het is, als ik mij niet vergis, als volgt (correct me if I'm wrong):

De MitM (Man in the Middle) aanvaller moet de client wijsmaken dat de server uitsluitend de kwetsbare RSA key exchange ondersteunt (en geen Diffie-Hellman cipher suites). Zodra de versleutelde verbinding tot stand gekomen is, zal de server nogmaals aan de client vertellen welke cipher suites hij ondersteunt; als dit afwijkt van wat de client (via de nog onversleutelde verbinding) van de MitM vernam, weet de client dat er sprake is van een "downgrade attack". Om te voorkomen dat de client het bedrog ontdekt, moet de MitM heel snel de versleuteling kraken en ervoor zorgen dat de client via de versleutelde verbinding dezelfde leugens van de MitM hoort als voordat de verbinding versleuteld was.
13-12-2017, 09:22 door Anoniem
Door Anoniem: Prachtige actie van Google en anderen... dat https everywhere, maar nu zitten we voor websites met kwetsbaarheden op of slecht geconfigureerde servers wel met een heleboel sh*t en de gebakken peren (vergeef mijn Frans hier).

Huh? Ben je nu aan het afgeven op het gebruik van https, omdat het in sommige gevallen lek is? Als het lek is, is het niet slechter dan http, en als het niet lek is, is het oneindig veel beter.
13-12-2017, 10:35 door Anoniem
Ik geef niet af op https, ik geef af op "holed" https encryptie. Https met encryptie altijd beter als https? Het hangt er maar vanaf voor wat voor website precies en wat voor connectie er beveiligd moet worden of niet. Https is niet overal perse nodig hoor.

Https met te doorbreken encryptie, altijd slecht! Waarom laatst dat theater overal van.... we hebben een algemene generieke encryptiesleutel nodig door Anglo-Amerikaanse politici, als de boel al zo lek is als een zeef.?

Wisten we toch al even, wat ze al in de achterzak hadden.

Je blaft wel tegen de verkeerde boom, vriend. De Zwitser, Daniel Reichenbacher heeft destijds aangegeven dat het vervangen moest worden. "Men" (wie dat ook was) koos destijds om dat niet te doen, maar het met een aantal ingewikkelde ingrepen te beveiligen, kennelijk met het gevolg dat het na 19 jaar, iets anders opgezet en uitgevoerd, nog zo lek is als de spreekwoordelijke zeef.

Toen begon dus het uitzichtloze pleistertje plakken al en men is nooit wat anders blijven doen. Net de veelgelaagde zeem uit de reclame.

Facebook ook (nog) kwetsbaar. Hoe lang hebben de mensen "in the know" hier al misbruik van kunnen en mogen maken op het volgens jou zo veel veiliger https?

Je moet zijn bij degenen die ook "jouw"" infrastructuur willens en wetens kwetsbaar hebben gehouden en gemaakt en nog verder naar de knoppen willen helpen ten behoeve van... en vul de rest maar in.

Waarom komt die kennis nu mondjesmaat in druppeltjes terecht bij de mensen, die degenen op de werkvloer zijn, die de boel veilig moeten houden en die men niet van de juiste info heeft voorzien? Zeg het maar.

Je moet wijzen naar degenen, die dat hebben gedaan en nog doen en die nog op gigantische gaten zijn blijven zitten, omdat ze die lekker kunnen misbruiken ten eigen faveure en ten behoeve van een klein clubje belanghebbenden.

Wie maakt het nu definief veiliger? Neen, allerlei figuren zitten te janken om algemene e2e encryptie ontsleuteling ten behoeve van surveillance en andere overheidscontrole sp**ks en de groot commercie belangen en we moeten verder gaan met de orde van de dag graag. Help je daar aan mee met kritiek snel afbranden?

We worden al ruim twintig jaar of langer op een geweldige schaal "genaaid" met de veiligheid op de infrastructuur?

Begin daar liever eens over. Naar Reichenbacher werd destijds niet geluisterd, Diffie en Hellman zijn bejaard. Naar wie luistert men inmiddels wel? Shamir, RSA? Neen, we vergaderen wel verder in een of ander emiraat.
13-12-2017, 12:18 door Anoniem
Zooitje.

Mijn cloud diensten maar overzetten naar een andere provider.
KPN.com is maximaal kwetsbaar, inclusief mn diensten daar.
T-mobile.nl niet.
Google.com ook niet gelukkig.

Benieuwd hoe de service providers die kwetsbaar zijn erover doen om dit te fixen.
13-12-2017, 13:05 door Anoniem
Software ontwerpers die kwestbaar zijn voor ROBOT,
waardoor informatie die door hen wordt versleuteld onveilig is, zijn o.m.:

F5 BIG-IP SSL vulnerability CVE-2017-6168
Citrix TLS Padding Oracle Vulnerability in Citrix NetScaler Application Delivery Controller (ADC) and NetScaler Gateway CVE-2017-17382
Radware Security Advisory: Adaptive chosen-ciphertext attack vulnerability CVE-2017-17427
Cisco ACE End-of-Sale and End-of-Life CVE-2017-17428
Bouncy Castle Fix in 1.59 beta 9, Patch / Commit CVE-2017-13098
Erlang OTP 18.3.4.7, OTP 19.3.6.4, OTP 20.1.7 CVE-2017-1000385
WolfSSL Github PR / patch CVE-2017-13099
MatrixSSL Changes in 3.8.3 CVE-2016-6883
Java / JSSE Oracle Critical Patch Update Advisory – October 2012 CVE-2012-5081

We moeten wachten tot ze beveiliging daarvoor uitrollen.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.