Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

'Https bevat lek waardoor gegevens met javascript onderschept kunnen worden'

Volgens Belgische beveiligingsonderzoekers bevat https een lek dat het mogelijk maakt om met een javascript persoonlijke gegevens te achterhalen. Het script zou in een advertentie verwerkt kunnen worden. De onderzoekers presenteren hun bevindingen op Black Hat.

Voor de aanval is geen man-in-the-middle-positie nodig. Kwaadwillenden kunnen volgens onderzoekers Tom Van Goethem en Mathy Vanhoef van KU Leuven simpelweg een advertentie plaatsen met daarin een kwaadaardig javascript. De code kan vervolgens op de beveiligde pagina's exact meten hoe groot de versleutelde data is die wordt verstuurd.

Met de hulp van twee andere exploits, bekend als Breach en Crime, is het mogelijk om aan de hand van de grootte sommige data te ontsleutelen. Dat is mogelijk door kwetsbaarheden die zitten in de manier waarop websites data comprimeren om ze sneller te laten laden.

De onderzoekers geven de methode de naam Heist, wat staat voor HTTP Encrypted Information can be Stolen Through TCP-Windows. Op de Black Hat-beveiligingsconferentie zullen de onderzoekers hun bevindingen demonstreren aan de hand van een kwaadaardige advertentie op de New York Times-website.

Van Goethem stelt dat hij als hij er tijd in zou steken met de methode 'een hoop ellende' zou kunnen veroorzaken. Volgens de onderzoeker zou de combinatie van Heist en Breach het voor aanvallers mogelijk maken om csrf-tokens uit te lezen. Afhankelijk van de functionaliteit die de website aanbiedt, zou dat de aanvaller toegang kunnen geven tot het volledige account van het slachtoffer.

Het lijkt onwaarschijnlijk dat de kwetsbaarheid eenvoudig ingezet kan worden voor aanvallen op grote schaal. De code moet specifiek per website zijn geschreven en de methode vereist een groot aantal requests. Websites die dergelijke verzoeken in de gaten houden, zullen deze vermoedelijk tegenhouden.

De onderzoekers hebben Google en Microsoft vooraf ingelicht over hun bevindingen. Volgens Van Goethem is de exploit op dit moment enkel tegen te houden door third-party-cookies te blokkeren.

Update 15.23 uur: De onderzoekers hebben hun presentatie en het volledige onderzoek online gezet.

Door Julian Huijbregts

Nieuwsredacteur

04-08-2016 • 13:20

95 Linkedin Google+

Submitter: RAM1979

Reacties (95)

Wijzig sortering
Als ik het zo lees zit de grootste kwetsbaarheid dus in de manier van compilen van code door websites zodat die sneller laden en niet zozeer in https?
Nee. Het probleem zit in TLS compression (wat v.z.i.w. vanwege de eerdere CRIME exploit eigenljik in alle browsers uitgezet is als het Łberhaupt al ondersteund is geweest) en in HTTP compression m.b.v. bijv. gzip of deflate.

Kort door de bocht werken deze compressies werken door byte-sequences (ook dus gewoon stukjes tekst) die vaak voorkomen in een dictionary op te slaan en dan een kort replacer token in de plaats te zetten.

De eerdere CRIME en BREACH aanvallen werken door een intelligente gok (bij "@gmail.com") te doen op een pagina die gebruikersinvoer terug naar buiten stuurt en te kijken of de grootte v/d gecompresste response wijzigt. Zo ja; dan kwam die reeks characters niet al ergens anders voor. Zo nee; dan hebben ze goed gegokt. Door dit vaak genoeg te doen en een flinke hoeveelheid van de originele plaintext terug op te bouwen kun je een response uiteindelijk compleet gaan kraken.

CRIME en BREACH moeten dan echter wel de grootte v/d response meten. En dat vereistte tot aan nu altijd een Man-in-the-Middle positie om het TCP/IP verkeer te inspecteren.

HEIST is nu een toevoeging hier boven op die een aantal recent aan webbrowsers toegevoegde APIs misbruikt om uit afgeleidde data met redelijke zekerheid op te kunnen maken of een TCP/IP response van grootte is veranderd of niet. Hierdoor is de MitM vereiste komen te vervallen.

----

Het uitzetten van third-party cookies is een botte-bijl workaround. Door deze uit te zetten zal een browser bijv. login tokens die in cookies staan niet meer doorsturen wanneer een service of pagina als derde partij (bijv. in een voor de gebruiker verborgen iframe) benaderd wordt.

Probleem is natuurlijk dat third-party integraties zoals heel veel social media widgets, maar soms ook serieuzer spul zoals internetbetaaloplossingen, dan ook niet meer werken.

----

Een echte oplossing voor deze complete familie aan aanvallen is technisch gezien trouwens bespottelijk simpel: post-compressie, pre-encryptie random padding toevoegen aan requests en responses.

Het grote probleem is organiatorisch: dit vereist dat iedereen het moet ondersteunen want anders 'maken we het internet stuk'.

[Reactie gewijzigd door R4gnax op 4 augustus 2016 14:16]

Kunnen ze niet beter de API's uitfaseren waarmee je vanuit javascript de lengte van de header kunt achterhalen?

Uitfaseren is niet echt nodig. Deze specifieke toepassing van deze API is zo goed als zeker onbedoeld, en browsers zullen/kunnen deze manier van gebruiken wellicht/waarschijnlijk beperken. Browser fabrikanten hebben wel vaker bepaald gebruik van APIs aangepakt om soortgelijke redenen.

Maar het gevaar van deze aanval is niet echt groot. Zoals het artikel al aangeeft moet de aanval precies gericht zijn op een bepaalde site. En dan moet je al geluk hebben dat jouw add op die site, ťn op het juiste moment getoond wordt. Je moet immers het initiele echte pakketje van jouw onderscheppen.

En dan nog, zomaar 'onbeperkt' zelf dan probeersels naar een site sturen is niet zomaar mogelijk. Veel sites hebben rate limits. Daarnaast je kent de TLS plain-text niet, dus kunt ook niet zomaar de browser van het slachtoffer dwingen dezelfde plain-text te sturen plus jouw probeersel. Ik schrijf 'zomaar' vetgedrukt, want dat is een essentieel onderdeel van de BREACH aanval.

Je moet dan al een hogere API gebruiken, welke dan door de browser omgezet wordt in een GET met een cookie/token of zo. In feite is dat het enige wat echt mogelijk is: een cookie/token proberen te achterhalen. (Al is dat natuurlijk wel ernstig.)

Dus wat mogelijk is is heel erg site afhankelijk: dus niet alleen is de aanval moet site-afhankelijk opgezet worden, maar de maximale buit zelf is dat ook.

En tenslotte als jij de tab/browser te vroeg afsluit, is de aanval onderbroken.

Deze aanval is op zich goed gevonden, maar het effect wordt wel een beetje flink opgeklopt. Zomaar 'even' BREACH gebruiken is immers niet mogelijk.
Als je ooit een moderne webapplicatie gebouwd hebt zou je snappen waarom je niet alles met serverside rendering kan doen. Je krijgt er heel statische pagina's van en hebt voor iedere kleine verandering een page-reload nodig. Simpele ajax om een klein stukje opnieuw te renderen is zelfs al javascript. Niet zo gebruiksvriendelijk dus. Een beetje zoals het web in de jaren 90 was.

Komt nog bij dat het juist mogelijk was om binaire rotzooi als flash, silverlight en active-x uit te faseren door de beschikbaarheid van javascript. Ik ben echt geen fan van frameworks van megabytes groot die je binnen moet trekken over je gelimiteerde mobiele verbinding, maar het is het een of het ander, je kunt niet alles verwijderen en nog een functioneel web overhouden.

Maar als je het veilig wilt houden: iedere browser heeft een optie om javascript compleet uit te zetten. Have fun.
Nee, de basis is compressie.

Stel de webpagina die de Server naar mijn browser stuurt bevat "username = Hans". Deze is gecomprimeerd en ge-encrypted, dus kan niet gelezen worden.
Maar stel dat ik mijn "banner" samen met de webpagina word gecomprimeerd, en ik voeg "username = Pietje" toe, dan neemt de bestandsgrote toe van de webpagina toe.
Maar stel nu dat mijn "banner", "username = Hans" toevoegt dan zal de gecomprimeerde grote van het bestand nauwelijks toenemen, omdat deze "sequence" al voorkomt in het compressie woordenboek.

Oftewel dit type attack veranderd letter voor letter een bepaalde string tot dat deze matched met b.v. de cookie tekst...
Nee, een adblocker werkt meestal op basis van een lijst bekende adverteerders of trefwoorden in de website. Zodra je dus javascript van een onbekende host gaat laden dan vind de adblocker dat prima (die houd ook geen facebook knoppen tegen om maar iets te noemen).

Volledige zekerheid heb blijkbaar dus pas als je third party cookies blokkeert (en er is bijna geen goede reden om dat niet te doen).

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True