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 compilenpressie van code door websites zodat die sneller laden en niet zozeer in https?

[Reactie gewijzigd door Michielgb op 4 augustus 2016 14:00]

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]

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.

Kunnen ze niet beter de API's uitfaseren waarmee je vanuit javascript de lengte van de header kunt achterhalen?
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.
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.

Kunnen ze niet beter de API's uitfaseren waarmee je vanuit javascript de lengte van de header kunt achterhalen?
HEIST misbruikt volgens het originele artikel secundaire karakteristieken en kennis van hoe het TCP protocol in frames/windows opgebouwd is om redelijk accuraat te voorspellen of een response van grootte is veranderd mbv informatie uit o.a. de Resource Timing en Fetch APIs.

Die APIs uitfaseren is het foute antwoord. Dat is gewoon wachten tot er weer een nieuwe manier is om die informatie boven te krijgen. Los het bij de bron op door de request lengte te randomizen en zo het compressie orakel onbruikbaar te maken.

[Reactie gewijzigd door R4gnax op 4 augustus 2016 15:03]

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.
LOL js heeft nog een hoop meer functies dan alleen een uitklap menu 8)7

Denk bijvoorbeeld aan online games, die schrijf je in HTML5 ÉN JavaScript, de een is de markup taal en de ander is de dynamische taal die daadwerkelijk de site functioneel maakt.

Zonder JavaScript zijn alleen nog maar webpaginas zoals wikipedia en nu.nl mogelijk....

Het idee om javascript uit te zetten is dan ook bizar. JavaScript kan je daarnaast nogeens niet te vergelijken met Adobe Flash, de een vereiste een hele eigen runtime en was een programma opzich ge-embed in de site en JavaScript is daadwerkelijk onderdeel van de browser en heeft daadwerkelijke interactie met de html en de gehele website.
Hoe kan het dat dezelfde stukjes tekst dan steeds terugkomen in de TLS stream? Je zou verwachten dat door block-chaining dit niet zou voorkomen.
Hoe kan het dat dezelfde stukjes tekst dan steeds terugkomen in de TLS stream? Je zou verwachten dat door block-chaining dit niet zou voorkomen.
Het feit dat dezelfde stukjes tekst niet steeds terugkomen (en de grootte v/d response niet wijzigt) geeft juist aan dat je goed gegokt hebt...
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...
de aanval bouwt verder op bestaande aanvallen die gericht zijn op HTTPS in combinatie met het GZIPen van request/responses. Dit heeft verder niets met compileren of code te maken.

En wat betreft CSRF-tokens stelen. Een fatsoenlijke JSON REST API heeft gelukkig geen CSRF-tokens nodig en rate-limiting om het aantal verzoeken, dus echt wakker lig ik er niet van.
Je bedoelt compressie denk ik. http(s) wordt met gzip ingepakt. En omdat gzip een vrij eenvoudige compressie is kun je (door informatie toe te voegen) meten wat voor effect dat heeft op de content lengte.
Volgens Van Goethem is de exploit op dit moment enkel tegen te houden door third-party-cookies te blokkeren.

Denk dat een ad-blocker ook prima werkt.
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).
Mijn gedachte ook. Ik blokkeer javascript al jaren.
Echt? Je kan JavaScript gewoon uitvinken in de browser en dan wordt er geen JavaScript meer uitgevoerd. Maar ik ken me moeilijk inbeelden dat jij het blokkeert. Veel sites werken simpelweg niet meer zonder JavaScript. Vroeger hielden webbouwers wel eens rekening dat hun site ook compatible is met browsers waar JavaScript is uitgeschakeld, maar ik denk dat de meesten hier geen rekening meer houden.
Zonder javascript kan je niet reageren op Tweakers, dus het lijkt me sterk dat hij het blokkeert :+
Dat maakt het toch glashelder? Dat hij Javascript blokkeert in plaats van gewoon uitzet betekent dus dat hij Javascript in beginsel blokkeert, totdat hij het op een bepaalde pagina goedkeurt of misschien een bepaalde website whitelist.
Mijn dank, ik had het niet beter kunnen uitleggen. :) Whitelisting is the way to go. Het zal je verbazen hoeveel nutteloze javascripts er draaien die absoluut niet nodig zijn voor de functionaliteit van een website. Tweakers heb ik gewoon in mn whitelist staan.
  • Websites laden sneller.
  • Het geeft je inzicht in welke sites betrouwbaar zijn.
  • Je bent een stuk veiliger
  • Alleen de scripts draaien die jij toestaat

[Reactie gewijzigd door PizZa_CalZone op 4 augustus 2016 14:22]

Wat is hier een goede voor in chrome. Ik zie veel extenties die het doen maar die hebben allemaal erg weinig votes < 400.

Zelf dacht ik Ghostery misschien, daar heb ik hier wel dingen over gehoord in het verleden. NotScripts bestaat niet meer in de store :(
Deden we dit niet in 2001 en zijn we er inmiddels mee gestopt ?
Waarom zouden we stoppen? Het is alleen maar erger geworden. De meeste sites hebben alleen javascripts nodig op het primaire domain en een content delivery network. De tientallen google scripts, advertentiescripts, vage tracking sites etc. vertragen de boel, zijn soms zo lek als een mandje of doen aan data-hebberigheid.

Ja, het maakt je browserervaring soms wat minder. Je moet per site uitzoeken wat nodig is voor de functionaliteit. En niet handig voor de huis-tuin en keuken internetter. Als je weet wat je doet heb je echter on the long run veel meer plezier ervan.

[Reactie gewijzigd door PizZa_CalZone op 4 augustus 2016 14:52]

Helemaal blokkeren is inderdaad niet mogelijk, maar met plugins als uMatrix, noscript en/of request policy is het goed te doen voor technische gebruikers.

In de meeste gevallen kom je een heel eind door "first-party" javascript (van de site zelf) wel toe te laten en alle externe scriptjes te blokkeren met een paar uitzonderingen voor sites als wordpress en jquery die grote delen van internet aansturen.

Niks voor je moeder, die wordt gillend gek, maar een techneut met inzicht in hoe websites werken kan de controle zelf in handen nemen.
Waarom is het moeilijk in te beelden?
Niet iedereen heeft behoefte aan sites die vol animaties en dergelijke zitten, zelf whitelist ik voor javascript een enkel paar sites of bepaalde pagia's als het nodig is, want je ontkomt er soms niet aan, maar zoveel mogelijk niet, zelfde geldt voor 3rd party cookies, plugins standaard uitgeschakeld.
Want dat soort dingen heb je toch niet nodig als je bij 99% van de onbekende sites even wat bepaalde informatie wilt weten wat vaak vooral alleen stukjes tekst is.
Verder boeit het me erg weinig als daardoor het uiterlijk in de war geschopt wordt, gebruik ook regelmatig zat Google cache.
En het gros daarvan wordt ook gewoon in incognito gedaan, geen meuk hoeven opslaan wat niet nodig is.

Terug naar de jaren 90 graag, sites met knoppen zonder poespas :).
Kun je dan nog gewoon browsen? Half internet is javascript
Hij kijkt alleen de Tweakers frontpage :+

Maar volgens mij kun je hier toch ook niet reageren zonder Javascript?
Lijkt me sterk eerlijk gezegt, er zijn aardig wat websites die compleet afhankelijk zijn van JavaScipt.
Dit gaat om Javascript, heeft niets met Java te maken.
Javascript is geen onderdeel van Java, ook al doet de naam iets anders vermoeden. Javascript zit in de browser zelf gebakken.
nee, Java is niet JavaScript...compleet iets anders
Java is iets anders dan JavaScript. Het gaat over JavaScript en dat is altijd ingebakken in de browser. Je kan het uitzetten, maar dan werken veel sites niet meer.
Het gaat om JavaScript niet om Java. Als je JavaScript uit zet heb je er geen last van, maar dan functioneren veel sites weer slecht.
Behalve de naamgeving is er geen enkele relatie tussen Java en Javascript...... Ze hebben helemaal niets met elkaar te maken.

Om antwoord op je vraag te geven dus: Ja, dit werkt ook als je geen Java geďnstalleerd hebt aangezien Java hier geen enkele invloed op heeft.
Java en Javascript hebben helemaal niets met elkaar te maken :)
Java != Java (Browser) Applet.
Er is werkelijk niets mis met Java zelf. Veel servers gebruiken java onder de kap om dynamische websites te serveren (inclusief Tweakers).
Daarnaast zijn er ook tal van desktop programma die Java nodig hebben. Je moet Java zien als tegenhanger van .net
Tevens worden native apps voor android ook in Java geschreven.

[Reactie gewijzigd door sir_huxley op 4 augustus 2016 13:47]

Nee de syntax en andere zaken waren helemaal niet op Java geďnspireerd, maar vooral op Scheme. Het zou eerst Mocha of LiveScript gaan heten.
De enige reden om Java in de naam te gebruiken was omdat dat moest van de marketing peeps van Netscape.
Zonder me te laten hinderen door kennis op het gebied van hedendaagse advertentiediensten, is een advertentie embedden op een website niet per definitie onveilig? Ik bedoel, als ik een pagina bezoek waar medische gegevens op staan, of wat voor gegevens dan ook, en iemand heeft daar een statistiekenscript of advertentiescript op draaien, dan kunnen deze scripts toch bij belangrijke data?

[Reactie gewijzigd door yade op 4 augustus 2016 15:39]

In de basis niet (encrypted data), maar afhankelijk van de website zelf, is potentieel alles mogelijk.

Was dat trouwens niet bij 1 van die zorgverzekeraars (iedergeval CZ), waar gewoon trackingcookies in je declaratieomgeving zitten?
Third-party cookies zouden gewoon standaard geblokkeerd moeten worden. Als bezoeker van een website heb je er eigenlijk nooit voordeel van, maar wel vaak nadeel.
Eigenlijk kun je dus gewoon geen client-side scripting toestaan op je machine. Zelfs met high-level talen kun je door gebruik te maken van timing en eigenschappen van het OS (zero pages, coalescing, compressie, etc) en de omgeving altijd wel data oogsten waar je niet bij zou moeten kunnen. Ook virtual machines zouden op zo'n manier data uit hun host kunnen oogsten, dus ook dat levert geen oplossing op de lange termijn.
Waarom zijn Google en Microsoft wel ingelicht en Mozilla niet? Is Firefox hier niet vatbaar voor?

Op dit item kan niet meer gereageerd worden.


Call of Duty: Black Ops 4 HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S9 Dual Sim Google Pixel 3

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