Ontwikkelaar maakt sessie-steler voor Firefox

Een Amerikaanse ontwikkelaar heeft een Firefox-extensie gepubliceerd waarmee de login-informatie van wie zich op een onbeveiligd wifi-netwerk bij websites aanmeldt, kan worden opgevangen. Daarna kan met die gegevens worden ingelogd.

Ontwikkelaar Eric Butler heeft zijn extensie Firesheep gedoopt en biedt deze via zijn website ter download aan. Gebruikers die de extensie draaien, kunnen, terwijl ze op een onbeveiligd wifi-netwerk zitten, Firesheep al het in- en uitgaande netwerkverkeer laten scannen. Als andere gebruikers op dat netwerk op een website inloggen, herkent de extensie de verstuurde sessie-cookie en slaat deze vervolgens op. Met een enkele klik kan de cookie worden gebruikt om in te loggen en het account te kapen.

Firesheep werkt niet in alle situaties. Zo moet het wifi-netwerk vrij zijn van enige beveiliging als wep of wpa2. Het werkt ook niet als de website waarop wordt ingelogd gebruikmaakt van een versleutelde https-verbinding. Hoewel veel websites, zoals de sociale netwerken Facebook en Twitter, https-verbindingen accepteren, is dit niet de standaardoptie. Gebruikers moeten dit zelf forceren. Er zijn wel extensies voor Firefox beschikbaar die automatisch een https-login forceren, als de bezochte website die mogelijkheid biedt.

De voornaamste reden om de extensie te ontwikkelen was volgens Butler het falen van veel grote websites om secuur met de gegevens van hun gebruikers om te gaan. Hoewel volledige encryptie via https niet moeilijk te implementeren is, zijn er naar zijn mening nog veel te weinig sites die van die mogelijkheid gebruikmaken. Butler hoopt met de publicatie van Firesheep dergelijke sites te dwingen om hun beveiliging te herzien.

Reacties (123)

[Martinus]

neem aan dat dit lek asap gedicht word.

[jiriw]

Nou, nee .. ik ben bang dat dat nog wel even gaat duren. het is namelijk geen 'lek' maar een verkeerde ontwerpfilosofie. Veel websites hebben gewoon nooit https geimplementeerd of ze hebben het niet standaard voor gebruikers aan staan. Ja, financiele websites doen het wel (banken) en bijvoorbeeld webmail ook maar veel sociale sites dus niet. En ook tweakers.net werkt hier gewoon over een http verbindinkje, ondanks dat ik ben aangelogd. Zo'n sessie kan je dus stelen zonder encryptie te moeten kraken als je weet wat je doet. Als je vervolgens bij tweakers inlogt wordt het wachtwoord misschien wel versleutelt (als je die optie aangevinkt hebt) maar alle communicatie gebeurt verder zonder encryptie.

[i-chat]

een een van die redenen is dat webhosters standaard zelden https aanbieden, wil je bijv een standaar joomla site draaien dan heb je er al last van.

ik denk dat er HEEEL wat moet gaan veranderen in webhosting land om dit te fixen.

[YaPP]

ik denk dat er HEEEL wat moet gaan veranderen in webhosting land om dit te fixen.

Zeker. Als webhosting bureau kun je meerdere sites op 1 IP-adres draaien. Bij HTTPS is dat niet mogelijk. Per https-site moet je een extra IP adres reserveren, en aan de server koppelen. Dat is mede de reden waarom je niet zomaar HTTPS cadeau krijgt.

De SSL-handshake vind namelijk plaats voordat de server weet welke site/pagina je opvraagt. De webserver kan dan alleen nog op basis van een IP adres het SSL-certificaat opsturen, wat later moet matchen met de domeinnaam van de site.

Gezien de schaarste aan IP-adressen, kun je bij webhosts een IP-per-site pas realistisch verwachten als IPv6 ingevoerd is. Voor sites als tweakers/facebook is het geen probleem, omdat die servers geheel ingericht zijn voor het draaien van 1 site, dus ook weten welk SSL-certificaat ze moeten opsturen.

[Reactie gewijzigd door YaPP op 22 juli 2024 22:29]

[Roland684]

Sinds Apache 2.2.12 is dat issue opgelost en voor de grote sites waar dit nieuws aan refereert is dat natuurlijk nooit een issue geweest.
Vooral de extra belasting van de cpu is een probleem (= kost geld)

[mad_max234]

Snap je punt enigszins, alleen joomla core en mods kunnen gewoon met https overweg, wellicht software van een derde partij kan problemen geven daar kan joomla geen garantie voor geven daar moet de webmaster zelf de kennis voor hebben om dat te controleren of anders de gok wagen.

Ik heb verschillende sites bij goedkope resellers en die bieden allemaal https aan naast gewone http.

[Reactie gewijzigd door mad_max234 op 22 juli 2024 22:29]

[jvd-nl]

Dus jij gelooft dat de websites die hier ter discussie staan, gehost worden bij een 'hostingboer'?

Neen, we hebben het hier over schaalgrootte 'rack' tot 'park'. Het is inderdaad niet ingewikkeld om https te implementeren. Zeker niet als je de volledige site https laat draaien. Dit heeft echter wel een stijging van de (cpu-)load tot gevolg, dus kan toch gevolgen hebben voor de werking van de site.

[bramgozer]

Ik weet niet of je hier echt van een lek kan spreken... Dit is meer een structurele fout in de beveiliging van websites.

[Verwijderd]

Dit is meer een structurele fout in de beveiliging van websites.

Hoezo van websites ? Bovenstaande situatie geld voor al het unecrypted verkeer (FTP, DNS, SMTP, POP, IMAP, LDAP, etc) in dergelijke sitiuaties. Dat iemand toevallig socialnetworking websites die over HTTP gaan eruit pakt is gewoon omdat dat een lekker opvallend target is.

[Soldaatje]

Is geen lek, maar een optie van websites.

[xoniq]

Doet me een beetje denken aan de uitspraak:

'It isn't a bug, it's a feature'...

Het is eigelijk vrij logisch dat dit kan, zo werken sessies en cookies nou eenmaal...
Denk dat hier ook weinig tegen valt te doen. Alhoewel, websites kunnen hier wel tegen wapenen.

Zelf heb ik destijds een 'anti-session-hijack' login gebouwd voor een website. Deze heb ik met een aantal man geprobeerd te manipuleren (sessie hashes en values overnemen, cookies kopieren, sessies aanpassen, cookies aanpassen e.d., maar die was behoorlijk goed beveiligd tegen het zogenaamde 'hijacking' zoals het in dit geval van de bovengenoemde extensie is...
Zodra de sessie ook maar gewijzigd was, werkte deze niet meer, en werd deze bij het eerst volgende bezoek aan het login systeem vernietigd.

Zouden meer websites moeten doen. Ben teveel sites tegen gekomen waarbij je gewoon doodleuk de sessies en cookies kan alteren. Zelfs zo ver, dat je andere rechten krijgt. (Denk aan guest, user en manager e.d.)

Zag laatst ook al een artikel, over hoe slecht beveiliging is geregeld bij het grootste gedeelte websites.

[bartvb]

Zouden idd meer sites moeten doen maar:

"Hoewel volledige encryptie via https niet moeilijk te implementeren is"

Is niet helemaal waar. Grootste probleem is dat SSL niet blij wordt als je op je pagina een mix hebt van eigen en externe content. Denk aan Google AdSense, Doubleclick, Facebook, Flickr stream, Twitter, Google Maps, etc, etc. Ook CDNs kun je niet meer zomaar gebruiken. Die diensten ondersteunen lang niet altijd SSL.

Daarnaast worden dingen als loadbalancing ingewikkelder en heb je meer rekenkracht nodig maar daar is op zich wel overheen te komen. Die 3rd party content is vervelender.

[remcovn]

Denk ook aan de kosten die certificaten met zich meebrengen. Zo moet er voor iedere domeinnaam een apart certificaat aangeschaft worden. Wanneer je dus 'echte' certificaten wil gaan gebruiken (en geen self-signed gedoe) loopt dit al snel in de honderden euro's voor een enkele domeinnaam.

[Ravek]

Wat nogal weinig is voor een beetje bedrijf.

[eghie]

Maar in combinatie met een beperkte IPv4 IP ruimte en virtual hosting, wordt dat technisch + kosten toch een ander verhaal. IPv4 adressen zijn er niet meer in overvloed. En TLS SNI wordt nog niet overal ondersteund. En beheersmatig is het ook een gezeik van niks al die certificaten.

[Verwijderd]

En TLS SNI wordt nog niet overal ondersteund

SNI word niet ondersteund door Windows XP. En daar door per definitie door niks wat erop draait, IE, FireFox, Chrome, etc. Met andere woorden SNI gaat niet gebruikt worden voordat Windows XP dood en begraven is. Ik schat 10 jaar.

[Woy]

Een certificaat hoeft echt geen honderden euro's te kosten. Bij de reseller waar wij ze aanschaffen zijn de goedkoopste € 35,- maar ze zullen vast nog goedkoper te krijgen zijn.

[Arietje]

Je hebt al een Comodo of GeoTrust certificaat voor 12 euro.

[phoenix]

Maar nu gaat het puur om het kapen van sessies. Daar is geen third-party content voor nodig. Het authenticatieproces kan wel - en makkellijk - via https gedaan worden.

[sc00p]

Dit is geen lek, dit kon al tijden.

Het is alleen erg vervelend dat er nu iemand een tooltje maakt waarmee iedere n00b het kan.

[Franckey]

Maar als hierdoor alle sites https gaan gebruiken, dan maakt deze actie de wereld toch weer een klein beetje veiler.

[hackerhater]

mwah het is al goed als er beveiliging tegen session-hijacking op de site staat
leuk dat je de sessie kan jatten, maar als de site het niet accepteerd heb je er niks aan

[Mr_x007]

dat zal moeilijk gaan, aangezien het hier om een basaal probleem van onbeveiligde netwerken gaat, wat deze ontwikkelaar gemaakt heeft is alleen een manier om heel makkelijk gebruik te maken van dit probleem.
de enige manier om je hier tegen kan doen is op onbeveiligde netwerken alleen https gebruiken.

[Verwijderd]

Dit is net zoiets als de deur openlaten en dan op vakantie gaan.
Een verbinding kan je nou eenmaal aftappen als het onbeveiligd is.
Een sniffer kan nog veel meer!

[Reactie gewijzigd door Verwijderd op 22 juli 2024 22:29]

[Soldaatje]

Nee, is niet nieuw, komt ook niet zo vaak voor.
Meestal alleen bij hele vervelende reacties.

[Left]

Dit werkt toch ook niet als de website waar de sessie cookie bij hoort, telkens controleert of het juiste ip-adres hoort bij de cookie?
Dus: Bij uitgifte van het cookie bewaart de website het ip-adres aan wie het uitgegeven is, en accepteert daarna alleen nog connecties die -en het cookie hebben -en het juiste ip adres? Dat lijkt me vrij standaard.

[Sisko]

ip-spoofing?

[compufreak88]

Ik kan er naast zitten, maar volgens mij is dat vanwege de 3-way handshake bij TCP niet mogelijk.

[hackerhater]

Mogelijk wel, maar je hebt er weinig aan gezien je geen antwoord krijgt

[mr_obb]

Dat is anders behoorlijk irritant met mobiele apparaten, die het ene moment via een 3G-netwerk inloggen en het andere moment via Wifi. Als eindgebruiker moet je dan iedere keer weer opnieuw inloggen.

[Foamy]

Lijkt me inderdaad handig ; vervelende is alleen dat je hier gebruik maakt van hetzelfde netwerk als degene waarvan je de sessie kaapt .. Je hebt dus hetzelfde IP adres

[Verwijderd]

Ik denk dat de meeste openbare hotspots gewoon internet aanbieden via nat. Dan slaat de website het externe ip address van de router op. Omdat zowel de aanvaller als het slachtoffer op het draadloos netwerk zitten hebben ze dus hetzelfde ip address en kan de website het verschil niet zien tussen de aanvaller en het slachtoffer.

[Fuzzillogic]

Mooie waarschuwing voor alle geiten in de NS-treinen met WIFI die zonder verdere beveiliging what so ever toch op allerlei sites inloggen en rondsurfen. Webmail (zonder SSL), Facebook, Marktplaats, you name it, alles direct via het open wifi-netwerk. En dan betwijfel ik ook nog of al die cookie-based inlogsystemen het wachtwoord tenminste gehasht versturen.

Mensen zijn zo naïef

[Foamy]

En dan betwijfel ik ook nog of al die cookie-based inlogsystemen het wachtwoord tenminste gehasht versturen.

Zolang het un-encrypted gebeurt maakt het wel of niet hashen geen verschil

[Fuzzillogic]

Wel. Je hasht je wachtwoord lokaal met een key die je van de server hebt gekregen. Zo is tenminste je login veilig. Natuurlijk kan al het verkeer nog steeds afgeluisterd worden, en ondertussen kan iemand zijn eigen wachtwoord instellen.

[Arnoud Engelfriet]

Dat is dus waarom een wachtwoordwijzigingsapplicatie altijd moet vragen om het oude wachtwoord voordat hij de wijziging doorvoert.

[thegve]

Het heeft geen zin om client-side (javascript), je wachtwoord te gaan hashen, want dan kun je dit gewoon later gaan "naspelen" als hacker zijnde, en dan ben je ook binnen. En als het goed is stuur je de hash later ook niet terug.

LOGIN -> SERVER -> ( HASH(LOGIN) === <<opgeslagen hash>> ) -> OK!

De reden dat je wachtwoorden hashed, is dat deze mogelijk in handen kunnen komen van hackers als je server gehacked word, of als er ergens een lek in zit. In dat geval hebben de hackers alleen de hashes, waarmee ze dus op je inlogschermpje nog niets kunnen beginnen. Tenzij die encryptie lek is natuurlijk of je geen seeded hashes gebruikt en de wachtwoorden staan in een rainbow table.

[Fuzzillogic]

Wrong. Je vergeet de stap waarbij de server een key naar de client stuurt die meegehasht wordt met (een hash van) het wachtwoord. Door het verkeer af te luisteren kom je op deze manier niet aan het wachtwoord, noch aan de (opgeslagen) hash van het wachtwoord.

[thegve]

Die is slim inderdaad. Gewoon een eenmalige extra seed feitelijk.

[thegve]

Ik heb maar 1 keer in een NS-trein met Wifi ook daadwerkelijk verder kunnen komen dan de "welkom in de trein" pagina. Dus dat risico hebben ze al afgedekt.

[Fuzzillogic]

Het werkte zelfs op m'n 3 jaar oude mobiel. Ik gok dat je sample van 1 wat weinig is om een gedegen conclusie te trekken

[thegve]

Ik reis 3 dagen per week met de trein, en kom hier met enige regelmaat een (in theorie) wifi trein tegen. Nog maar 1 keer dat het ook werkte alleen. Zelfs bij vertrekpunt Utrecht CS al niet.

[Verwijderd]

Strakke actie! Alle inloginformatie moet altijd over https! Daar zijn standaard technieken voor, het is niet moeilijk.
<edit> @jiriw Je hebt gelijk. Alle informatie moet afgeschermd over de lijn.. </edit>

[Reactie gewijzigd door Verwijderd op 22 juli 2024 22:29]

[jiriw]

Niet alleen de inloginformatie. het gaat hier om sessie stelen, niet wachtwoord stelen. De gehele communicatie moet via https om sessie stelen tegen te kunnen gaan. Enige tijdelijke oplossing voor dit probleem om over een onbeveiligde wifi veilig te kunnen internetten: IP tunnel/vpn naar een computer op het internet die jij wel vertrouwt (die bijvoorbeeld dichter op de backbone zit zodat er minder partijen zijn die de communicatie kunnen afluisteren) en die de informatie onbeveiligd verder laten verzenden.

<edit> ow ... en natuurlijk wel je tunnel met SSL encrypten... anders heeft het nog geen zin</edit>

[Reactie gewijzigd door jiriw op 22 juli 2024 22:29]

[thegve]

Je zou als website ontwikkelaar wellicht zelf een secure iets kunnen gaan verzinnen denk ik. Ik heb het nog niet perfect in mijn hoofd zitten, maar je client hoeft je sessie data niet te kunnen decoden (wel de naam van de cookie, maar niet perse de inhoud). Dus als je van dit 'voordeel' gebruik maakt door iets unieks te verzinnen per client (desnoods IP), en je encrypt je data daarmee, dan ben je al een heel stuk verder.

[eghie]

achter NAT vallen heel veel van dat soort beveiligingen weg helaas. Alleen Javascript encryptie zou daar iets aan kunnen veranderen.

[hackerhater]

Valt wel mee als het IP niet de enigste unique key is in de sessie

Op mijn werk gebruiken we het ip + userid + nick + rechten
als een van die 4 niet klopt wordt de sessie vernietigd

En verder is er ook nog een check op de browser. Dit is alleen lastig bij browser-updates
Het is zelfs zo streng dat ik als admin niet met 2 browsers tegelijk ingelogd kan zijn. 1 van de 2 wordt er altijd uit gegooit

De sessie is dus niet over te nemen.

[mbb]

Waarom werkt dit alleen via Wifi en niet via gewone gedeelde routers?

[Verwijderd]

Je moet het verkeer van anderen natuurlijk wel kunnen zien.
Op een bedraad netwerk met een hub zal het ook wel gaan - maar dat kom je niet veel meer tegen.

[Ibidem]

Ben zelf niet heel erg thuis in de software cq beveiling wereld. Echter wordt onder "onbeveiligd WiFi" alleen de verbindingen zonder WEP/WPA(2) encryptie verstaan?

Draai thuis al jaren zonder encryptie maar met MAC authenticatie. Heb altijd de indruk gehad dat WEP of WPA(2) oude notebooks een stuk zwaarder belast waardoor het netwerk en dus ook internet trager werd,

Kan iemand mij uitleggen of dit ook van toepassing is mbt dit artikel?

[ReenL]

je pakketjes kunnen gewoon uit de lucht gevist worden, echter zal de "hacker" niet zomaar hetzelfde IP hebben. Dus als de site de sessie aan een IP koppelt (wat lang niet altijd het geval is) is dit geen probleem. Totdat iemand z'n MAC of IP spooft.

[Reactie gewijzigd door ReenL op 22 juli 2024 22:29]

[Fuzzillogic]

Met trunking kan het zomaar gebeuren dat je met meerdere IP-adressen aan het surfen bent. Een sessie koppelen aan één IP-adres kan dus zomaar mensen weer uitsluiten.

[ieperlingetje]

MAC authenticatie is vooral handig als je de mensen die langs je deur passeren niet direct toegang wil geven tot je netwerk. Tegen gerichte aanvallen is het dan weer niet geschikt, na een paar minuten spoofen ze je adres en zittenze op je netwerk. Bij mac adres filtering is de data nog steeds uit de lucht te halen, wat deze tool ook doet.

[!null]

Ik begrijp niet waarom het wireless netwerk vrij moet zijn van beveiliging? Je moet toch gewoon met het wireless netwerk kunnen verbinden? Of er nou superzware beveiliging op zit of niet, als jij in het wireless netwerk kan deelnemen dan kun je ook alle berichten ontvangen.
Daarna is het dus onversleutelde informatie waar de extensie pas nuttig is lijkt me.

[kaneter]

Als het draadloze netwerk beveiligd is (bijv. met WPA of WPA2), dan kun je pakketjes van anderen wel ontvangen, maar niet lezen. Bij een onbeveiligd netwerk worden de pakketjes onversleuteld verstuurd, waardoor je ook het verkeer van anderen kan lezen.

[!null]

Hoezo, je kunt de pakketten van andere toch op dezelfde wijze ontsleutelen als de pakketjes van hetzelfde wireless netwerk die voor jou zijn bedoelt?

[Verwijderd]

Neen, want de pakketjes voor een ander worden anders versleuteld.

[telefoontoestel]

Kwalijke zaak als dit via een simpele FF extensie gedaan kan worden. Ik weet uit ervaring dat je bijv. in Amerika dood gegooid wordt met vrij toegankelijke Wifi hotspots zonder enige vorm van beveiliging. Ik vraag me ook af hoeveel van de normale mensen die hier gebruik van maken dan ook bekend zijn met deze mogelijkheid.

[Eonfge]

Sweet, stel je voor hoe alle trendsetters hun oren er af rukken als hun Imeak niet zo veilig blijkt te zijn...

[/evil]

Het is inderdaad een gevaarlijke optie voor hotspots. Het is natuurlijk geen onbekende truc maar het feit dat het nu een grafische add-on is maakt het erg eenvoudig. Dit kan iedere boven-modale gebruiker, in plaats van de nerd. Ik weet nu al locaties waar dit werkt in mijn eigen omgeving.

[Jeroenneman]

Het netwerk moet vrij zijn van enige beveiliging...
Tja, als je een onbeveiligd netwerkk hebt, vraag je er gewoon om.

[henkie196]

Tja, dit slaat niet alleen op je thuis situatie, maar ook als je bijvoorbeeld op reis bent en in een hotel of iets dergelijks via een onbeveiligd netwerk kunt internetten. Het is bij hotels vrij populair om een onbeveiligd netwerk te hebben, en dan internet alleen toegankelijk te maken via een login-scherm.
In zo'n situatie heb je helaas niet veel keus, behalve natuurlijk helemaal niet te internetten (of encryptie te forceren, maar dat moet de site dan wel ondersteunen, natuurlijk).

[kid1988]

Is het zo niet ook mogelijk om een sessie van iemand te gebruiken op niet-gratis hotspots? Deze zijn meestal onbeveiligd, en dient er via een browser worden ingelogd om verder toegang tot internet te hebben (weet overgens niet of Tmobile of KPN dit encrypted doen of niet).

Op de PC hebben we wel extensions om dit te forceren (KB SSL Enforcer bijvoorbeeld). Op mobiele telefoons lijkt me dit een groter probleem (vooral met allerlei apps die inloggen op twitter, gmail, facebook, hyves, etc. en dit niet altijd via SSL doen.)

[Reactie gewijzigd door kid1988 op 22 juli 2024 22:29]

[FloRadix]

Bij gmail is sinds kort (enkele maanden geleden) verplicht om alle sessie via https te laten verlopen, vroeger was dit een optie nu niet meer. Dus bij Google zit je veilig ;-)

[Reactie gewijzigd door FloRadix op 22 juli 2024 22:29]

[Petervanakelyen]

Is het zo niet ook mogelijk om een sessie van iemand te gebruiken op niet-gratis hotspots? Deze zijn meestal onbeveiligd, en dient er via een browser worden ingelogd om verder toegang tot internet te hebben (weet overgens niet of Tmobile of KPN dit encrypted doen of niet).

Uit ervaring weet ik dat mac-adress spoofing op betalende hotspots wonderen doet
Je verkeer over DNS tunnelen gaat overigens ook vaak goed.

[Freekers]

Het werkt dus ook niet als je 'normaal' verbonden bent met een WEP/WPA(2) netwerk (dus de key weet) ?
Waar zit um dan precies het verschil in ? Als je de key toch hebt, wordt de data toch ook gedecrypt, of zie ik dat verkeerd ?

[Reactie gewijzigd door Freekers op 22 juli 2024 22:29]

[Verwijderd]

@Freekers: Je krijgt een andere key dan je buurman, ook al meld je je op dezelfde router aan.. Anders zou je inderdaad ook altijd alles van andere computers kunnen afluisteren, zodra je verbonden bent met het netwerk...

[Verwijderd]

Bij WEP is een man-in-the-middle-attack voldoende om al het http verkeer af te luisteren