Variant op 19 jaar oude aanval maakt ontsleutelen TLS-verkeer mogelijk
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.
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.).
Die vertaling klopt niet helemaal. De tekst moet luiden:
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.
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.
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.
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.
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.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
