Onderzoekers ontwikkelen nieuwe aanval op sessiecookies https
Twee beveiligingsonderzoekers beweren dat ze een nieuwe aanval op het https-protocol hebben ontwikkeld. Met de hack zouden kwaadwillenden beveiligde internetsessies kunnen overnemen, zoals bij de sites van banken en webwinkels.
Beveiligingsonderzoekers Juliano Rizzo en Thai Duong beweren dat ze een nieuwe aanval op het https-protocol hebben ontwikkeld, waarbij de sessiecookies van de gebruiker kunnen worden ontsleuteld. Deze cookies worden gebruikt bij de authenticatie van gebruikers op beveiligde websites, zoals die van banken en webshops. Kwaadwillenden zouden zich met deze aanval toegang kunnen verschaffen tot sessies van andere gebruikers. De https-cookies zijn juist ontworpen om dit soort aanvallen tegen te gaan.
De methode gebruikt een zwakte in een specifieke functie van het tls- en het ssl-protocol, die onderdeel van het https-protocol zijn. Volgens de onderzoekers zijn alle versies van ssl en tls kwetsbaar, al wilden ze nog niet bekendmaken welk onderdeel precies zwak is. De onderzoekers hebben de nieuwe aanvalsmethode de naam crime gegeven en zullen de methode later deze maand demonstreren op de Ekoparty-beveiligingsconferentie in Buenos Aires.
Voor de aanval is het wel nodig dat de gebruiker de bewuste code uitvoert. De aanvaller kan de gebruiker hiertoe een besmette website voorschotelen of in het netwerk van de gebruiker inbreken. Volgens de onderzoekers is voor de aanval geen browser-plug-in vereist, al zou het gebruik van javascript de aanval wel versnellen. Wel moet de aanvaller toegang hebben tot het https-verkeer van het slachtoffer, iets wat mogelijk is op open wifi-verbindingen of door toegang tot het bedrade netwerk te hebben. Ook moeten zowel de server als de browser de kwetsbare functie van het tls- of ssl-protocol ondersteunen.
De onderzoekers hebben de aanval bij zowel Firefox als Chrome met succes getest. Ook andere internetbrowsers kunnen kwetsbaar zijn. Mozilla en Google zouden al beveiligingsupdates tegen de aanval hebben, maar de bedrijven hebben deze nog niet verspreid.
Vorig jaar toonden dezelfde onderzoekers al een andere aanval tegen het https-protocol, met de naam beast. Die aanval werkte op ssl-versie 3.0 en tls-versie 1.0. Updaten naar tls-versie 1.1 of 1.2 zou voldoende zijn om die aanval af te slaan. De nieuwe aanval zou echter ook op deze versies werken.
Reacties (32)
dat is dan tochw el zorgwekkend, natuurlijk alles kan gehackt worden, maar dit zijn toch wel kritieke dingen, goed dat er iig snel een update komt, maar alsnog kan dit gebruikt worden tegen mensen met oudere browser versies.
hoop dat niemand dit lek actief gaat misbruiken want dat zou wel eens erg vevelend kunnen worden
hoop dat niemand dit lek actief gaat misbruiken want dat zou wel eens erg vevelend kunnen worden
Wees blij met dit soort jongens, anders hadden we nog jaren met lekke verbindingen gecommuniceerd en we wisten het niet eens. Dit soort acties maken de beveiliging alleen maar beter.
Had er geen hack geweest dan had je ook geen oplossing nodig gehad.
Nu is er een hack zonder oplossing, moet ik blij zijn ?
Nu is er een hack zonder oplossing, moet ik blij zijn ?
Wat jij zegt is: ogen dicht en het is er niet.
Zonder hack wilt niet zeggen dat de bug/kwetsbaarheid er niet is.
Als zij het kunnen ontwikkelen kan iemand anders het ook en ook nog eens actief misbruiken. Doordat zij het op deze manier communiceren kan het opgelost worden voordat het actief misbruikt word.
Zonder hack wilt niet zeggen dat de bug/kwetsbaarheid er niet is.
Als zij het kunnen ontwikkelen kan iemand anders het ook en ook nog eens actief misbruiken. Doordat zij het op deze manier communiceren kan het opgelost worden voordat het actief misbruikt word.
Dit is echt zo niet relevant.Zonder hack wilt niet zeggen dat de bug/kwetsbaarheid er niet is.
Je hele os zit vol met gaten maar ze moeten eerst gevonden worden.
Actief opsporen van gaten is 1 ding, misbruik een 2e, een 2e die al heel snel in zicht komt.
Kijk, ik kan de wielen van je fiets/auto/scooter ook losschroeven en dan ga je mooi onderuit als je een stukje gaat tuffen, gelukkig gebeurd dit niet regelmatig omdat er geen geld mee te halen valt.
Internet is een schimmige omgeving zeker als het om dit soort zaken gaat. Liever hoor ik de oplossing tegen deze shit.
Liever hoor ik de oplossing tegen deze shit.
Hoe wil je iets oplossen voordat bekend is dat er een probleem is...!?
Tom V heeft gewoon volkomen gelijk: als een universitaire groep het probleem kan vinden dan kan een bovengemiddeld slimme cracker (of eentje met heel veel geluk) datzelfde probleem óók vinden (en die zal het echt niet openbaar maken, zodat het opgelost kan worden).
Edit:
@humbug:
Dit doet mij vermoeden dat ze:Mozilla en Google zouden al beveiligingsupdates tegen de aanval hebben, maar de bedrijven hebben deze nog niet verspreid.
- eerst de browserbouwers hebben ingelicht
- zodat die patches kunnen maken
- die daarna voor alle browsers in één keer worden uitgerold (omdat in de patch waarschijnlijk is te zien wat het probleem is)
- (vlak) daarna zullen ze wel hun presentatie geven
Ik geef toe, dit zijn aannames, maar waarom zouden Mozilla en Google anders een patch "achterhouden"; dit is de enige logische verklaring die ik kan bedenken.
[Reactie gewijzigd door robvanwijk op zaterdag 8 september 2012 23:58]
Maar moet je dan nu blij zijn? Blijkbaar is er nog geen patch uitgerold. Doordat het nu bekend is dat er een gat , is de kans alleen maar groter dat een hacker het gat vindt en misbruikt voordat men de patch uitrolt.
Dus hoewel het niet slecht is dat onderzoekers op universiteiten dit soort algoritmes tegen het licht houden, wordt ik pas blij als het gat gedicht is. Ik heb dan ook veel liever dat dit soort onderzoekers eerst zorgen dat het probleem opgelost is, voordat ze het openbaar maken. Dat is niet zo leuk voor de presentatie tijdens de conferentie maar wel zo goed voor de gebruikers van die software. De keuze om het op dit moment openbaar te maken is dus eigenlijk alleen maar in het eigen belang van de onderzoekers. Niet iets om echt blij van te worden.
Dus inderdaad, ik hoor veel liever dat er een gat was wat nu is opgelost dan dat er een gat is.
Dus hoewel het niet slecht is dat onderzoekers op universiteiten dit soort algoritmes tegen het licht houden, wordt ik pas blij als het gat gedicht is. Ik heb dan ook veel liever dat dit soort onderzoekers eerst zorgen dat het probleem opgelost is, voordat ze het openbaar maken. Dat is niet zo leuk voor de presentatie tijdens de conferentie maar wel zo goed voor de gebruikers van die software. De keuze om het op dit moment openbaar te maken is dus eigenlijk alleen maar in het eigen belang van de onderzoekers. Niet iets om echt blij van te worden.
Dus inderdaad, ik hoor veel liever dat er een gat was wat nu is opgelost dan dat er een gat is.
De oplossing staat eigenlijk toch al vermeld in het artikel?
Niet op onbekende netwerken je bankzaken doen totdat de patch er is. Oh en zet een wachtwoord op je wifi-netwerk.
Opgelost?
Niet op onbekende netwerken je bankzaken doen totdat de patch er is. Oh en zet een wachtwoord op je wifi-netwerk.
Opgelost?
In relatie tot de reactie waar Tom V op reageerde is het juist uitermate relevant.Dit is echt zo niet relevant.
Tom V reageerde op onderstaande:
Het is alles behalve slim om te denken dat als de betreffende onderzoekers deze lek niet hadden gevonden het lek er niet zou zijn en er geen oplossing nodig zou zijn.Had er geen hack geweest dan had je ook geen oplossing nodig gehad.
Nu is er een hack zonder oplossing, moet ik blij zijn ?
Dat criminele organisaties mogelijk al veel langer op de hoogte (kunnen) zijn en het mogelijk al langere tijd in de praktijk uitvoeren is blijkbaar niet relevant voor jou
Zolang het nog niet mogelijk is om per direct een oplossing te leveren hoor ik liever ASAP dat dit lek er is en onder welke condities het van toepassing kan zijn.Internet is een schimmige omgeving zeker als het om dit soort zaken gaat. Liever hoor ik de oplossing tegen deze shit.
Kop in zand steken oftewel ogen dicht houden zolang er geen oplossing is wil uiteraard niet zeggen dat de bug/kwetsbaarheid er niet is en er nog geen misbruik van wordt gemaakt.
-edit-
Ik was een beetje laat met verversen pagina en zie nu dat robvanwijk inmiddels min of meer zelfde reactie had geschreven.
[Reactie gewijzigd door Dlocks op vrijdag 7 september 2012 21:14]
"Mozilla en Google zouden al beveiligingsupdates tegen de aanval hebben, maar de bedrijven hebben deze nog niet verspreid."Nu is er een hack zonder oplossing, moet ik blij zijn ?
Aldus het artikel.
Ja, maar als ze nog niet verspreid zijn, is de eindgebruiker nog steeds kwetsbaar.
Je kan wel blij zijn dat ze de patches klaar hebben maar dat is een beetje nutteloos als je rekening ondertussen geplunderd wordt.
Je kan wel blij zijn dat ze de patches klaar hebben maar dat is een beetje nutteloos als je rekening ondertussen geplunderd wordt.
Elke patch moet ook een bepaalde quality test ondergaan, zeker als het gaat over security, je kan eenvoudig een nieuwe aanvalshoek creeeren.
Inderdaad, er zit iets in, als ik het goed inschat, in wat je zegt.
Terwijl de (lokale-) politiek van alles en nog wat onzin als 'geheim!' bestempelen, politici moeten zwijgen van BenW of den haag...
Gaan techneuten dit aan de grote klok hangen...
Had ik ook liever niet gehad. Liever een bericht met de kop, plots, : jarenlang httpS lek gedicht...
Terwijl de (lokale-) politiek van alles en nog wat onzin als 'geheim!' bestempelen, politici moeten zwijgen van BenW of den haag...
Gaan techneuten dit aan de grote klok hangen...
Had ik ook liever niet gehad. Liever een bericht met de kop, plots, : jarenlang httpS lek gedicht...
"Alles kan gehackt worden"? Dat vind ik wel erg naïef. Vooral tls en ssl zijn protocollen die beveiliging mogelijk maken die in theorie redelijk basaal zijn. Het zorgt namelijk voor versleuteld verkeer tussen twee partijen over een publieke lijn. Er zijn dan ook duidelijke theoretische modellen bekend die dit probleem oplossen en deze protocollen zijn formeel te bewijzen door middel van Zero-knowledge proofs. Het grootste probleem is vaak dat de stap van formeel model tot implementatie nog erg groot is en het simpelweg te complex is om implementaties formeel te bewijzen of valideren. Hierdoor kunnen implementaties van deze basale protocollen toch nog fouten bevatten. In de implementatie wordt er mogelijk een samenloop van de omstandigheden gecreëerd die te misbruiken valt. Dit verzwakt dan het protocol.
Bevestigen dat alles gehackt kan worden is juist het tegenovergestelde van naïef.
Alles KAN gehackt worden, alleen is het een moeilijker te kraken dan het andere.
De grootste zwakke plek blijft natuurlijk de gebruiker, zoals dit artikel weer opnieuw zegt: "Voor de aanval is het wel nodig dat de gebruiker de bewuste code uitvoert.". Zo is natuurlijk alles wel te 'hacken', als ik mag aannemen dat ik een tooltje op jouw PC kan uitvoeren alvorens jij iets gaat doen.
HTTPS is heel veilig omdat het gebruik maakt van het public key systeem, waarbij jij iets versleuteld met je public key, wat vervolgens niet kan worden gedecrypt met dezelfde key, hier is een private key voor nodig, die de server heeft ontvangen doordat jij die hebt toegestuurd na er de public key van de server er over te halen. Verder wordt de authenticiteit van de server met een certificaat bevestigd, die vrij moeilijk te faken zijn zonder een certificate authority te hacken (Hallo diginotar!) of aan de gebruiker toe te voegen. Dit maakt man-in-the-middle aanvallen vrijwel onmogelijk, maar als er aan de server of gebruiker kant iets mis is kan je dat natuurlijk altijd weer daar onderscheppen.
Zo valt te concluderen dat inderdaad alles te hacken valt, sterker nodig, encryptie is er ook niet om dat onmogelijk te maken, maar om het zodanig moeilijk te maken dat het niet waard is om te proberen (omdat het bijvoorbeeld een x aantal mensenlevens duurt om op gemiddelde hardware de key te bruteforcen). Uiteindelijk is het vooral van belang dus dat we het zo moeilijk mogelijk blijven maken voor blackhats om dit soort dingen mogelijk te maken.
Om te zeggen dat het NIET mogelijk is om iets te hacken, DAT is naïef.
Alles KAN gehackt worden, alleen is het een moeilijker te kraken dan het andere.
De grootste zwakke plek blijft natuurlijk de gebruiker, zoals dit artikel weer opnieuw zegt: "Voor de aanval is het wel nodig dat de gebruiker de bewuste code uitvoert.". Zo is natuurlijk alles wel te 'hacken', als ik mag aannemen dat ik een tooltje op jouw PC kan uitvoeren alvorens jij iets gaat doen.
HTTPS is heel veilig omdat het gebruik maakt van het public key systeem, waarbij jij iets versleuteld met je public key, wat vervolgens niet kan worden gedecrypt met dezelfde key, hier is een private key voor nodig, die de server heeft ontvangen doordat jij die hebt toegestuurd na er de public key van de server er over te halen. Verder wordt de authenticiteit van de server met een certificaat bevestigd, die vrij moeilijk te faken zijn zonder een certificate authority te hacken (Hallo diginotar!) of aan de gebruiker toe te voegen. Dit maakt man-in-the-middle aanvallen vrijwel onmogelijk, maar als er aan de server of gebruiker kant iets mis is kan je dat natuurlijk altijd weer daar onderscheppen.
Zo valt te concluderen dat inderdaad alles te hacken valt, sterker nodig, encryptie is er ook niet om dat onmogelijk te maken, maar om het zodanig moeilijk te maken dat het niet waard is om te proberen (omdat het bijvoorbeeld een x aantal mensenlevens duurt om op gemiddelde hardware de key te bruteforcen). Uiteindelijk is het vooral van belang dus dat we het zo moeilijk mogelijk blijven maken voor blackhats om dit soort dingen mogelijk te maken.
Om te zeggen dat het NIET mogelijk is om iets te hacken, DAT is naïef.
[Reactie gewijzigd door Alex_dragon op zaterdag 8 september 2012 21:40]
Het zal wel aan mij liggen, maar zolang er nog iets van de computer van de gebruiker moet komen vraag ik me af hoe zorgwekkend dit is. Natuurlijk is veiligheid belangrijk, maar de veiligheid is nu niet echt meer in het geding dan wanneer iemand anderszins een besmette PC hebt. Ik bedoel; als je de PC al hebt overgenomen, waarom is het dan nog interessant om ná de versleuteling het SSL-protocol aan te vallen
nieuwe aanval.... "MAAR" je moet wel effe een gebruiker een code laten uitvoeren of in het netwerk zitten....
Ja precies, als je de user code moet laten uitvoeren, kan je er net zo makkelijk pcAnywhere op zetten of een keylogger of weet ik veel allemaal... Heel handig dus.
Als je die code kunt verspreiden via een andere site die de gebruiker bezoekt... is het helemaal niet meer zo vergezocht.
Bijvoorbeeld nieuws: Telegraaf.nl serveert bezoekers malware - update
Bijvoorbeeld nieuws: Telegraaf.nl serveert bezoekers malware - update
[Reactie gewijzigd door Roland684 op vrijdag 7 september 2012 18:15]
Details ontbreken nog, maar alles wijst erop dat noch de server, noch de PC gecompromitteerd is bij deze aanval (zie http://www.ekoparty.org/2012/thai-duong.php). Naar verluidt volstaat volledige netwerktoegang voor een aanvaller (en dat is doodsimpel op publieke WiFi netwerken).
Het lijkt erop dat de aanvaller, bij bepaalde combinaties van webbrowsers en servers, op een SSL/TLS verbinding "kan inbreken" door javascript en/of html te injecteren. D.w.z. zonder dat dit tot een foutmelding in de betreffende browsers en/of een verbroken verbinding leidt.
Uit "bad news is some of them might contribute to global warming" zou je kunnen afleiden dat er op sommige plaatsen zwaardere encryptie (renegotiations?) nodig is om dergelijke injecties te voorkomen.
Uit https://threatpost.com/en...ack-https-sessions-090512, door Juliano Rizzo:
"By running JavaScript code in the browser of the victim and sniffing HTTPS traffic, we can decrypt session cookies. We don't need to use any browser plug-in and we use JavaScript to make the attack faster but in theory we could do it with static HTML," Rizzo said.
Het lijkt erop dat de aanvaller, bij bepaalde combinaties van webbrowsers en servers, op een SSL/TLS verbinding "kan inbreken" door javascript en/of html te injecteren. D.w.z. zonder dat dit tot een foutmelding in de betreffende browsers en/of een verbroken verbinding leidt.
Uit "bad news is some of them might contribute to global warming" zou je kunnen afleiden dat er op sommige plaatsen zwaardere encryptie (renegotiations?) nodig is om dergelijke injecties te voorkomen.
Uit https://threatpost.com/en...ack-https-sessions-090512, door Juliano Rizzo:
"By running JavaScript code in the browser of the victim and sniffing HTTPS traffic, we can decrypt session cookies. We don't need to use any browser plug-in and we use JavaScript to make the attack faster but in theory we could do it with static HTML," Rizzo said.
Als dit zo is dan klinkt het allemaal nogal relatief simpel en betekent het dus dat er best een groot risico is.
Ik ben benieuwd naar de details, maar als iets met simpele HTML sessiecookies gekraakt kunnen worden...
Dan vraag ik me af hoe veilig dat hele https eigenlijk is, niet zo veilig als ik dacht iig.
Of is het puur een browser aangelegenheid, misschien de reden waarom IE niet genoemd wordt en niet kwetsbaar is?
Ik ben benieuwd naar de details, maar als iets met simpele HTML sessiecookies gekraakt kunnen worden...
Dan vraag ik me af hoe veilig dat hele https eigenlijk is, niet zo veilig als ik dacht iig.
Of is het puur een browser aangelegenheid, misschien de reden waarom IE niet genoemd wordt en niet kwetsbaar is?
Dat is toch apart dat IE of niet kwetsbaar is of niet getest is of om een andere reden niet genoemd wordt.De onderzoekers hebben de aanval bij zowel Firefox als Chrome met succes getest. Ook andere internetbrowsers kunnen kwetsbaar zijn.
Als je al in staat bent om javascript te injecteren, waarom lees je dan niet gewoon met JavaScript de cookie en de sessionid uit? Of is dat weer een heel vreemde vraag?
Dat kan, echter bestaat daartegen al een maatregel, namelijk en HttpOnly sessie cookie. Dit betekent dat bij Http verkeer geactiveerd door het drukken op een Submit knop of op een hyperlink, dat dan alleen de cookie mee gaat. Niet dus als Javascript probeert een Ajax request te doen naar een andere website.
Met een HttpOnly sessie cookie is cross site scripting een heel stuk moeilijker geworden.
Met een HttpOnly sessie cookie is cross site scripting een heel stuk moeilijker geworden.
Ter verduidelijking, met "javascript injecteren" speculeer ik op basis van de schaarse informatie. Het is best mogelijk dat ik die verkeerd interpreteer.
Maar, ervan uitgaande dat dat het Rizzo en Duong gelukt is om inderdaad javascript in een versleutelde verbinding te injecteren, d.w.z. zonder dat de webbrowser dit signaleert, dan zit je nog wel met het "probleem" dat je het cookie uit die encrypted stream moet zien te exporteren - zonder de browser (en gebruiker) "wakker" te maken. Je kunt dat cookie niet zomaar even unencrypted naar een andere site sturen, allerlei protectiemechanismes in webbrowsers helpen dat (hopelijk) voorkomen.
Het zou me niet verbazen als Rizzo en Duong twee verschillende uitdagingen hebben moeten tackelen. Ik verwacht dan ook dat dit niet niet een appeltje-eitje aanval is die het SSL/TLS concept in één klap prullebakkeert, maar dat ook in dit geval implementatie-issues aan deze kwetsbaarheid (-heden) ten grondslag liggen.
In deze blog beschrijft Adam Langley (SSL/TLS specialist bij Google) ruwweg in welke volgorde je je zorgen moet maken om problemen rondom https.
Met stip op 1 zijn dat, aldus Langley, certificaatwaarschuwingen (die in verreweg de meeste gevallen door onjuist toegepaste of verlopen certificaten worden veroorzaakt, niet door aanvallers). Samen met onwetenheid van eindgebruiker leidt dit er kennelijk toe dat de meerderheid van die eindgebruikers, 61.6%, deze waarschuwingen gewoon wegklikt en verder surft (in deze follow-up post legt Langley uit hoe hij aan dat percentage komt).
Daarna volgen "mixed mode" probemen waarbij de webbrowser, naast https content, ook http content ophaalt. Dit is de reden waarom je, met gangbare webbrowser instellingen, bij https://tweakers.net/ en https://secure.security.nl/ geen "slotje" ziet.
Heb je dat voor elkaar dan verdienen toegestane "weak" (of zelfs "null") ciphers aan serverzijde, samen met te korte assymmetrische sleutels en/of zwakke cryptografische hashes (zoals MD5) in certificaten, de aandacht. Advies: check je https server na installatie bijv. bij https://www.ssllabs.com/ssltest/index.html.
Nb (mijn opmerking, niet letterlijk van Langley):
Encryptie is zinloos als je niet weet met wie je communiceert
(d.w.z. de bedoelde site of een MITM aanvaller).
Self signed certificaten zijn erger dan zinloos (vanwege eerdergenoemde certificaatwaarschuwingen die gebruikers normaal gaan vinden) - tenzij je dergelijke self signed certs vooraf via een veilige (dus alternatieve) route in de certificate stores van je bezoekers weet te importeren. PKI, hoewel allesbehalve feilloos, is bedoeld om die rompslomp te voorkomen.
Langley vervolgt zijn betoog met te melden dat BEAST attacks (de vorige door Rizzo en Duong gevonden https kwetsbaarheid) in vergelijking met de eerder genoemde risico's vooral theoretisch van aard zijn, temeer daar de meeste geactualiseerde webrowsers hier ondertussen bescherming tegen bieden.
Met de nu beschikbare informatie zie ik geen aanleiding om aan te nemen dat we in dit nieuwe "CRIME" geval wel met een https ramp te maken zouden hebben. Ik ga zo lekker slapen...
Maar, ervan uitgaande dat dat het Rizzo en Duong gelukt is om inderdaad javascript in een versleutelde verbinding te injecteren, d.w.z. zonder dat de webbrowser dit signaleert, dan zit je nog wel met het "probleem" dat je het cookie uit die encrypted stream moet zien te exporteren - zonder de browser (en gebruiker) "wakker" te maken. Je kunt dat cookie niet zomaar even unencrypted naar een andere site sturen, allerlei protectiemechanismes in webbrowsers helpen dat (hopelijk) voorkomen.
Het zou me niet verbazen als Rizzo en Duong twee verschillende uitdagingen hebben moeten tackelen. Ik verwacht dan ook dat dit niet niet een appeltje-eitje aanval is die het SSL/TLS concept in één klap prullebakkeert, maar dat ook in dit geval implementatie-issues aan deze kwetsbaarheid (-heden) ten grondslag liggen.
In deze blog beschrijft Adam Langley (SSL/TLS specialist bij Google) ruwweg in welke volgorde je je zorgen moet maken om problemen rondom https.
Met stip op 1 zijn dat, aldus Langley, certificaatwaarschuwingen (die in verreweg de meeste gevallen door onjuist toegepaste of verlopen certificaten worden veroorzaakt, niet door aanvallers). Samen met onwetenheid van eindgebruiker leidt dit er kennelijk toe dat de meerderheid van die eindgebruikers, 61.6%, deze waarschuwingen gewoon wegklikt en verder surft (in deze follow-up post legt Langley uit hoe hij aan dat percentage komt).
Daarna volgen "mixed mode" probemen waarbij de webbrowser, naast https content, ook http content ophaalt. Dit is de reden waarom je, met gangbare webbrowser instellingen, bij https://tweakers.net/ en https://secure.security.nl/ geen "slotje" ziet.
Heb je dat voor elkaar dan verdienen toegestane "weak" (of zelfs "null") ciphers aan serverzijde, samen met te korte assymmetrische sleutels en/of zwakke cryptografische hashes (zoals MD5) in certificaten, de aandacht. Advies: check je https server na installatie bijv. bij https://www.ssllabs.com/ssltest/index.html.
Nb (mijn opmerking, niet letterlijk van Langley):
Encryptie is zinloos als je niet weet met wie je communiceert
(d.w.z. de bedoelde site of een MITM aanvaller).
Self signed certificaten zijn erger dan zinloos (vanwege eerdergenoemde certificaatwaarschuwingen die gebruikers normaal gaan vinden) - tenzij je dergelijke self signed certs vooraf via een veilige (dus alternatieve) route in de certificate stores van je bezoekers weet te importeren. PKI, hoewel allesbehalve feilloos, is bedoeld om die rompslomp te voorkomen.
Langley vervolgt zijn betoog met te melden dat BEAST attacks (de vorige door Rizzo en Duong gevonden https kwetsbaarheid) in vergelijking met de eerder genoemde risico's vooral theoretisch van aard zijn, temeer daar de meeste geactualiseerde webrowsers hier ondertussen bescherming tegen bieden.
Met de nu beschikbare informatie zie ik geen aanleiding om aan te nemen dat we in dit nieuwe "CRIME" geval wel met een https ramp te maken zouden hebben. Ik ga zo lekker slapen...
[Reactie gewijzigd door Bitwiper_secu op vrijdag 7 september 2012 23:34]
"Maar, ervan uitgaande dat dat het Rizzo en Duong gelukt is om inderdaad javascript in een versleutelde verbinding te injecteren, d.w.z. zonder dat de webbrowser dit signaleert, dan zit je nog wel met het "probleem" dat je het cookie uit die encrypted stream moet zien te exporteren - zonder de browser (en gebruiker) "wakker" te maken."
Als je eenmaal javascript hebt geinjecteerd, kun je gewoon aan de DOM de sessie cookies opvragen en deze via Ajax ergens heen sturen.
Verder niets nodig.
Als je eenmaal javascript hebt geinjecteerd, kun je gewoon aan de DOM de sessie cookies opvragen en deze via Ajax ergens heen sturen.
Verder niets nodig.
Dus eigenlijk zeggen ze dat ze een "chosen plaintext attack" hebben geconstrueerd voor het SSL/TLS protocol? Verbazingwekkend...
Ik vraag me af hoelang andere hackers hier al misbruik van maken. Ik bedoel, niet iedereen komt er voor uit dat ze een exploit kunnen maken toch.
Het verhaal begon vrij spectaculair, maar hoe verder je leest hoe onwaarschijnlijker word dat de hack ook ingezet wordt. Toegang tot hetzelfde netwerk en computer van het slachtoffer is vereist. Er zijn veel ergere dingen die je kan doen als je deze 2 dingen hebt.
Zouden ze het niet geprobeerd hebben bij IE?De onderzoekers hebben de aanval bij zowel Firefox als Chrome met succes getest. Ook andere internetbrowsers kunnen kwetsbaar zijn.
Dat lijkt toch wat onwaarschijnlijk.
Als ik het artikel lees zie ik dat het nodig is om eerst iets uit te voeren op de pc van de persoon die ge-hacked wordt. Door middel van javascript. Dan kunnen ze een session cookie uitlezen.
Daarmee zou het mogelijk zijn om die session cookie te gebruiken, en dus de zelfde ssl sessie te kunnen gebruiken als de ge-hacked- te persoon.
Ik vat dan een ding niet, ze moeten eerst iets in de sessie (die dan nog niet ge-hacked is) injecteren en het resultaat uitlezen. Hoe doen ze dat dan?
Het enige wat ze los laten is dat zowel de server als de client een tls versie moeten draaien die gevoelig is voor de attack.
Zorgen dat mijn kant de 'laatse' versies draait.
Daarmee zou het mogelijk zijn om die session cookie te gebruiken, en dus de zelfde ssl sessie te kunnen gebruiken als de ge-hacked- te persoon.
Ik vat dan een ding niet, ze moeten eerst iets in de sessie (die dan nog niet ge-hacked is) injecteren en het resultaat uitlezen. Hoe doen ze dat dan?
Het enige wat ze los laten is dat zowel de server als de client een tls versie moeten draaien die gevoelig is voor de attack.
Zorgen dat mijn kant de 'laatse' versies draait.
The CRIME attack code, known as an agent, needs to be loaded inside the victim's browser. This can be done either by tricking the victim into visiting a rogue website or, if the attacker has control over the victim's network, by injecting the attack code into an existing HTTP connection.
Slachtoffer bezoekt een site via HTTP die vervuild wordt door middel van injectie om session-data te stelen:The attacker must also be able to sniff the victim's HTTPS traffic. This can be done on open wireless networks; on local area networks (LANs), by using techniques such as ARP spoofing; or by gaining control of the victim's home router through a vulnerability or default password.
Ik snap niet waarom SSL/TLS hier de boosdoener is:User -> HTTP -> HTTPS
^
Inject -------/
Als iederaan overal gelijk HTTPS gebruikt, dan is dit opgelost?For the attack to work, both the victim's client and the server hosting the targeted website need to support the vulnerable SSL/TLS feature, Rizzo said.
Belangwekkend is (nu 3rd party cookies plaatsen zonder toestemming verboden is geworden) trouwens dat veel eigenaren van websites er keer op keer op hameren dat cookies _nooit_ gevaarlijk zijn.
Maar het is dus wel gewoon een extra security risk, net zoals op zich vergeleken met andere technieken bijvoorbeeld: wireless, javascript, flash, hubs i.p.v. switches (maar gelukkig zie je nooit meer hubs), TLS1.0, ActiveX, etc.
Maar het is dus wel gewoon een extra security risk, net zoals op zich vergeleken met andere technieken bijvoorbeeld: wireless, javascript, flash, hubs i.p.v. switches (maar gelukkig zie je nooit meer hubs), TLS1.0, ActiveX, etc.
Op dit item kan niet meer gereageerd worden.
Populair: Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Politiek en recht Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
