'Oude aanval op tls werkt nog steeds bij Facebook en andere grote sites'

Beveiligingsonderzoekers hebben vastgesteld dat een aanval uit 1998 nog steeds werkt op sites die tls met rsa gebruiken. Een derde van Alexa's top100-sites was hierdoor getroffen, waaronder Facebook en PayPal. De onderzoekers vonden de sites met een zelfontwikkelde scantool.

De onderzoekers presenteren hun bevindingen via een speciale site en een paper. Ze hebben de aanval Robot genoemd, omdat het een licht aangepaste versie is van de aanval die in de jaren negentig is ontdekt door Daniel Bleichenbacher. Die kwam erachter dat het ssl-protocol, preciezer de PCKS #1 v1.5-standaard, kwetsbaar was voor een methode waarbij de aanvaller een versleutelde tekst steeds opnieuw aanpast en op die manier uiteindelijk tot decryptie over kan gaan zonder over de encryptiesleutel te beschikken. Het woord 'oracle' in de aanval slaat op het feit dat een kwetsbare server steeds met true of false antwoordde, wat de aanval mogelijk maakte. De onderzoekers waren in staat om deze aanval licht aan te passen en te gebruiken op tls in combinatie met rsa-versleuteling.

Tls is de opvolger van ssl en wordt gebruikt om een https-verbinding te beveiligen. Volgens de onderzoekers laat hun methode een aanvaller internetverkeer tussen bijvoorbeeld een gebruiker en een kwetsbare server ontsleutelen, vooropgesteld dat hij het verkeer heeft onderschept en dat de server alleen rsa-sleuteluitwisseling ondersteunt. Ze achten het mogelijk dat een aanvaller zich voordoet als de server of een man-in-the-middle-aanval uitvoert, maar dat zou een grotere uitdaging zijn dan het ontsleutelen van internetverkeer.

Verschillende fabrikanten van netwerkapparatuur zijn kwetsbaar, waaronder F5, Citrix en Radware. De onderzoekers hebben een volledige lijst op hun site gepubliceerd, met daarop ook enkele opensourceprojecten. Met behulp van een zelfontwikkelde scantool, die publiek beschikbaar is, stelden ze bovendien vast dat subdomeinen van 27 sites uit de top 100 populairste sites van Alexa eveneens kwetsbaar waren. Toen ze naar de 1 miljoen populairste sites keken, kwamen ze uit op een lager percentage van rond de 2,5. Grote getroffen sites waren PayPal en Facebook. De onderzoekers waren in staat om een bericht te ondertekenen met de privésleutel van Facebook.

In de paper gaan de auteurs in op de reden dat een zo oude aanval nu nog mogelijk is. Ze schrijven dat er na de ontdekking van Bleichenbacher voor gekozen is om bepaalde tegenmaatregelen op te nemen in tls, maar om de kwetsbare encryptiemethodes te behouden. Dat resulteerde in een complex hoofdstuk over tegenmaatregelen in de tls-specificatie. De onderzoekers noemen het dan ook 'niet verwonderlijk dat de work-arounds niet op de juiste manier zijn geïmplementeerd'.

Bovenaan de Robot-site is een tool te vinden waarmee kwetsbare sites geïdentificeerd kunnen worden. De onderzoekers waarschuwen dat toekomstige variaties van de aanval meer kwetsbare hosts kunnen blootleggen. Ze raden aan om rsa-encryptie voor tls volledig uit te schakelen en doelen daarmee op codering waarvan de naam begint met TLS_RSA. Het updaten van de browser of het intrekken van certificaten is niet aan de orde. Rsa heeft in tls 1.3 de status deprecated gekregen.

Reacties (37)

[Kefke]

Hoe kan een hacker dat misbruiken op een site zoals PayPal? Daarvan zou ik toch graag willen dat die veilig is, want die gebruik ik meestal als ik online shop.

[Belgar]

Overigens hebben de onderzoekers Facebook en paypal uiteraard de tijd gegeven om het probleem op te lossen, van facebook wordt expliciet vermeld dat het probleem nagenoeg onmiddellijk is opgepakt en dat de onderzoekers een bounty hebben ontvangen voor het melden van het probleem. Ik neem aan dat Paypal hier ook werk van heeft gemaakt.

[Stoelpoot]

Het ontsleutelen van HTTPS-communicatie, zoals in het artikel vermeld staat. Simpel gezegd heb je dus geen zekerheid van HTTPS meer.

[blinchik]

Net even enkele van mijn sites gechecked en deze lijken niet vulnerable te zijn, ik gebruik een redelijk standaard Apache2 2.4.18 met Let's Encrypt...

[totaalgeenhard]

Lees whitepaper eens.

Ze kunnen het niet garanderen omdat er varianten mogelijk zijn.

Lang verhaal kort TLS ontwikkelaars hebben begin van deze eeuw een workaround gebouwd ipv heel probleem te verwijderen ivm backwards compatibility redenen.

[Verwijderd]

Dat soort stomme dingen zie je vaak, idd. Daarom is het beter om helemaal af te stappen van backwards compatibility en gewoon één of twee protocollen te maken met bijvoorbeeld AES en Salsa20 als ciphers en SHA-3-256 als hash functie en ECDH of RSA voor key exchange.

[Verwijderd]

Ja en daarmee een triljoen aan websites half tot niet meer functioneert.

[Verwijderd]

Je zal toch een keer de pijn moeten nemen. Men kan beginnen met sneller uitfaseren van legacy protocollen en daarna het de cipher suite zoals hierboven beschreven kenbaar maken die over 5 jaar door iedereen geïmplementeerd zal moeten zijn. Hoe minder cipher suites en hoe eenvoudiger deze in elkaar zitten hoe groter de veiligheid.

[totaalgeenhard]

Als je ziet hoe Apple, Firefox, Google en Microsoft grote stappen hebben genomen inzake flash en HTML5 is de pijn best te overzien.

Het is alleen dat oude software die niet geupdate kan/zal worden niet meer kan werken. En daar raak je wel de meerderheid op deze aarde mee.

[supersnathan94]

Software die niet geupdate kan worden is software die niet moet willen gebruiken.

Software die willens en wetens niet meer geupdate wordt moet je volledig mijden.

HTTPS is fundamenteel voor het bestaan van het internet. Als TLS niet meer veilig is, is internetbankieren dat dus ook niet meer. Derhalve kunnen de meest basale dingen al voor heel chaos zorgen.

[totaalgeenhard]

Dus alle oude telefoons, tablets wereldwijd moet men maar weggooien?

Zoals ik al schreef de meeste mensen op aarde zijn de sigaar als ze downwardscompatibiliteit er uit zouden halen.


Ps: als ze in je tcp stream kunnen komen is dit het minste probleem die je hebt.

[Reactie gewijzigd door totaalgeenhard op 28 juli 2024 02:15]

[supersnathan94]

Of we zijn allemaal onveilig bezig of iedereen met wen oud device (echt oud!) kan niet meer fatsoenlijk op HTTPS sites terecht en de rest heeft alles wel secure.

Met security moet je geen consessies gaan doen aangezien we gewoon weten dat het misbruikt gaat worden.

Moeten we deze legacy meuk die stamt uit de bgintijd van het internet de komende 20 jaar nog meeblijven slepen of moeten we dan maar zeggen dat alles per definitie onveilig is?

Dan maar oude apparatuur die vatbaar is voor aanvallen weren.

[Ge Someone]

En veel andere smart apparatuur zoals televisies, domotica enz. Het niet meer ondersteunen van producten na 1,5 jaar is eigenlijk onverantwoordelijk vanuit security oogpunt.

[fastedje]

Je zou wel voor thuisgebruik een revers e https proxy kunnen gebruiken (kan met apache of HAproxy).

[ShellGhost]

Het heeft dan ook niks met Apache van doen, dus dat je sites veilig zijn kan kloppen.

[HKLM_]

Dus onderstaand kan ik n.a.v deze bevinding beter uit mijn chiper lijst halen welke we gebruiken voor OWA ?

TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

[totaalgeenhard]

None of the above.

The TLS handshake is initiated by a TLS client with a ClientHello mes-
sage. This message contains information about the TLS version and a list of
supported cipher suites. If the server shares cipher and protocol support with
the client, it responds with a ServerHello message indicating the selected ci-
pher suite and other connection parameters.

Mijn eerste gedachte was ook dat ze gewoon niet goed gehardend waren en oude methode tussen hadden staan.

Maar het is een probleem in TLS waar ze workarounds voorgemaakt hebben die het probleem niet verhelpt. Zie whitepaper.

[Belgar]

Het is echter wel een specifiek probleem in de TLS_RSA handshake (specifiek PKCS #1 v1.5) . Het protocol dat gebruikt wordt voor elliptic curve is niet bevattelijk voor oracle aanvallen. Een nieuwere versie van PKCS is ook ontwikkeld maar nooit in de standaarden geplakt. Deze nieuwere PKCS is in principe ook niet bevattelijk voor oracle aanvallen.

In zoverre de correcte aanname dat als je server geen TLS_RSA gebruikt, je ook niet bevattelijk bent voor oracle aanvallen.

Uit de conclusie van de paper:

"The countermeasures in the TLS standard to Bleichenbacher’s attack are
incredibly complicated and grew more complex over time. It should be clear
that this was not a viable strategy to avoid these vulnerabilities.
The designers of TLS 1.3 have already decided to deprecate the RSA en-
cryption key exchange. However, as long as compatibility with RSA encryption
cipher suites is kept on older TLS versions these attacks remain a problem. To
make sure Bleichenbacher attacks are finally resolved we recommend to fully
deprecate RSA encryption based key exchanges in TLS. For HTTPS we believe
this can be done today"

[Belgar]

3DES_CBC staat volgens mij sowieso al een tijdje in de lijst met "mogelijk toekomstig probleem".

Als je gebruikte TLS provider de responses op de juiste manier heeft geïmplementeerd zou je in principe vandaag veilig moeten zijn voor deze aanval. Wel zeggen de onderzoekers dat ze niet uit kunnen sluiten dat er uiteindelijk toch nog een side channel wordt gevonden voor sommige implementaties en dat het constante geplak van tegenmaatregelen beter kan ophouden door geen RSA meer te gebruiken.

[SKiLLa]

3DES heeft meerdere problemen; 64-bit blockmodus (SWEET 32) en in de meest gebruikte EDE modus maar 112-bit sleutelmateriaal, maar het grootste 'issue' is dat het op moderne hardware tot wel 30x (factor 30 dus) trager/zwaarder/duurder is dan AES-GCM. In het verleden daarom ook vaak de achilles-hiel van een VPN, waarbij de hw-appliance een te trage CPU had om meer dan b.v. 100 Mbps te doen...

[Armin]

en in de meest gebruikte EDE modus maar 112-bit sleutelmateriaal

Dat is niet helemaal correct. Het is mogelijk om ipv 168 bit brute force te kraken, een alternatieve method te gebruiken waarbij "maar" 112 bit brute force verslagen hoeft te worden. Echter je moet dan wel de resterende 56bit pre-cached hebben op een server park. (En ja, een server-park want de benodigde storage space per 3DES sleutel is zo groot ) Ook moet je software custom made zijn, om die gehele gecachde data met lage latency toegangelijk te maken zodat je niet alsnog een tijd-kost penalty krijgt die significant is.

Ofwel 3DES is zeker niet aan te raden, maar zelfs voor organisaties als de NSA is deze 112bit methode niet bruikbaar in de praktijk.

[freaky]

Doe jezelf een plezier, draai deze tool: https://www.nartac.com/Products/IISCrypto, klik best practice, apply, reboot.

[fastedje]

Lijkt me ook ja. Eerder al waren de TLS RSA CBC ciphers als onveilig/zwak aangemerkt. Nu blijken dus alle TLS RSA ciphers zwak/onveilig. Met deze https://ssllabs.com link kan je trouwens goed zien welke ciphers en protocol combis onveilig zijn en op wat voor soort clients/OSen dit invloed heeft.

[SKiLLa]

Niet waar; het Oracle verhaal is een implementatie-fout waar niet elke TLS-stack (met RSA) per definitie last van heeft. Dat de TLS handshake (klassiek gezien zo ongeveer RSA-only) t/m v1.2 een legacy-nachtmerrie is, staat daar los van, dat is een politieke nachtmerrie. Dezelfde lobbyisten proberen nu trouwens de (verplichte) FPS in TLS 1.3 te ondermijnen middels FUD (fake requirements, non-existing use cases, hearsay, etc). Zie o.a. de 'visibility' draft -discussie op de TLS mailinglist: https://www.ietf.org/mail...tls/current/maillist.html

Het is echter niet instant-karma met deze ROBOT aanval, een actieve MiTM positie + duizenden https requests voor de Oracle-bruteforcing zijn vereist (tegen een kwetsbare server) om de TLS Pre-Master-Secret (PMS) te achterhalen en zodanig vervalste berichten te kunnen sturen ...

[Royale de Luxe]

Grappig dat volgende wordt geclaimd : Verschillende fabrikanten van netwerkapparatuur zijn kwetsbaar, waaronder F5, Citrix en Radware.

Is het niet aan de beheerders om deze protocollen op deze toestellen uit te schakelen? Als het niet aanstaat kan je het toch niet misbruiken? Waarom ligt de fout dan bij de fabrikanten?

[eric.1]

Het gaat hier bij mijn weten om hun websites, niet hun netwerkapparatuur zelf.

En hun website hebben ze hoop ik wel zelf in beheer ^^.

I stand corrected

[Reactie gewijzigd door eric.1 op 28 juli 2024 02:15]

[totaalgeenhard]

Nee lees whitepaper.

F5 en Cisco maken loadbalancers waarop ssl sessies op getermineerd worden.

Ook ssl accelators van hun en anderen zullen waarschijnlijk kwetsbaar zijn.

[Reactie gewijzigd door totaalgeenhard op 28 juli 2024 02:15]

[Belgar]

Het gaat wel degelijk om de apparatuur en servers geleverd door de bedrijven. Het gaat om een foute implementatie van tegenmaatregelen voor de originele aanval.

RSA/TLS is niet direct kwetsbaar voor een aanval (het protocol an sich is niet direct kapot). Het probleem is dat de foutmeldingen niet goed geimplementeerd zijn en aan de hand van de foutmelding afgeleid kan worden of een "gok" naar (een deel van) de sleutel goed of fout is. Door genoeg (soms miljoenen) gokjes te wagen kun je uiteindelijk bepalen hoe de sleutel van de site eruit moet zien.

[SteamboatWilly]

Dit nieuws is ongeveer al 3 weken geleden onderkend. F5 en Citrix hebben overigens hun Firmware al aangepast. Of dit geimplementeerd wordt ligt natuurlijk aan de beheerders, maar het is natuurlijk kortzichtig om het niet te doen.
Voor degene die dit niet kan vanwege verlopen support of anders, kan je op de Netscaler ook PFS (Perfect Forward Secrecy) op de EDHC certificaten configureren. Dan ben je ook beschermd en is zelfs gesupport vanaf versie 10.5.

[Helium-3]

Hier kan je de testtool vinden. Het kan even duren, want de entries worden toegevoegd aan een een que.

[totaalgeenhard]

Testtool laat alleen zien indien je zeker een probleem hebt, maar sluit niets uit omdat probleem op dit moment inherent aan TLS is.

[Proxxima]

Zo'n 20 jaar pleisters plakken en het probleem zelf niet aanpakken... Hoe bizar is dat?

[Belgar]

Voornamelijk compatibiliteit. Het heeft nagenoeg eenzelfde tijd geduurd voordat SSL eindelijk verbannen werd (NB: onder andere door een zelfde side channel aanval als deze). Vaak een hele conservatieve instelling om maar klanten te kunnen blijven bedienen die op IE6 of lager zaten e.d. (zelfs jaren nadat IE6 al out of support was).

Het is ook deels te wijten aan de spec schrijvers. Het beschreven probleem is een "side channel" aanval die voornamelijk voortkomt uit de implementatie van het protocol, niet zozeer het protocol zelf. De schrijvers van het protocol hadden initieel dan ook de instelling dat het niet HUN probleem was, maar van alle anderen die hun implementatie maar moesten verbeteren.

[lololig]

Gebeurt toch heel vaak zodat niet gelijk alles wat er op gebaseerd is onderuit gaat?

[--Andre--]

Dat lijkt me eerder regel dan uitzondering. Je wil mensen niet vertellen dat hun software/hardware niet meer werkt. En bovendien lijkt me dit ook van toepassing op andere gebieden van de ICT. Backwards compatibility, of, we hebben het altijd zo gedaan, dus gaan we ermee door.

[spank_mojoo]

waarom denk je dat ze het een "Patch" noemen?

[Barryke]

Weet je niet waar je op moet letten of weet je niet wat goede instellingen zijn kijk eens naar deze sites.