Website Hi.nl bleek inloggegevens als plain text te verzenden

De website van Hi.nl blijkt inlognamen en wachtwoorden onversleuteld te hebben verzonden. De inlogmodule en een Flash-banner wisselden deze gegevens als plain text uit met de server. KPN heeft de auto-inlogfunctie inmiddels uitgeschakeld.

Beveiligingsonderzoeker ObAt heeft onderzoek gedaan naar de veiligheid van de website van Hi.nl en concludeert dat deze vatbaar is voor zogenoemde man-in-the-middle-aanvallen. Hieruit blijkt dat de gebruikersnaam en het wachtwoord van een gebruiker met relatief weinig moeite achterhaald konden worden.

De auto-inlogfunctionaliteit van de website van Hi blijkt geruime tijd de inlognaam en het wachtwoord als plain text te hebben verzonden. "Bij het inloggen worden de gebruikersnaam en het wachtwoord dus onversleuteld verstuurd naar de servers van Hi, de gebruiker wordt hierna doorgelinkt naar het beveiligde deel van de site", aldus ObAt tegenover Tweakers.net.

Hoewel een dergelijke beveiligingsfout niet direct grote gevolgen heeft, kan het lek wel door kwaadwillenden worden misbruikt als zij in staat zijn om het netwerkverkeer te bekijken, zoals bijvoorbeeld bij openbare wifi-netwerken het geval is. Met de inloggegevens kunnen klanten op een persoonlijke omgeving hun Hi-account beheren, hun telefoonrekeningen inzien en hun bundel aanpassen.

Ook ontdekte ObAt op de indexpagina van Hi.nl een Flash-uiting die dusdanig was ontworpen dat deze meermaals het wachtwoord en de gebruikersnaam van de gebruiker onversleuteld opvroeg. "Dit is onnodig, aangezien de banner ook te bekijken is voor niet ingelogde gebruikers", aldus de beveiligingsonderzoeker.

KPN heeft na een tip van Tweakers.net de auto-inlogfunctie uitgeschakeld. "Klanten kunnen nu dus nog wel inloggen, maar niet meer automatisch", aldus een zegsman van de telco. "In dit geval geldt dat veiligheid boven gemak gaat." KPN heeft inmiddels ook de Flash-uiting aangepast.

Reacties (79)

Ik hoop dat de tekst in het artikel niet rechstreeks van Beveiligingsonderzoeker ObAt afkomstig is. Want dan weet hij niet wat het verschil is tussen simpel afluisteren, en een "man-in-the-middle"-attack is.

Als er plain-text passwords worden verzonden, dan is het genoeg om gewoon af te luisteren. Je logt gewoon later in met de account/password informatie die je hebt afgeluisterd.

Man-in-the-middle attacks zijn iets meer gecompliceerd. De slechterik zit inderdaad tussen de twee partijen in. Maar hij luistert niet alleen af. Hij verandert ook de boodschappen. Of laat boodschappen weg, of voegt nieuwe boodschappen toe. Hiermee kun je veel meer doen dan je kunt doen met gewoon afluisteren.
http://en.wikipedia.org/wiki/Man-in-the-middle_attack

Waarschijnlijk bekt het wel lekker, "man in the middle". En daarom gebruiken mensen die uitdrukking. Maar hier wordt het wel foutief gebruikt.

Dan heb je je toch vergist! De aanval die is uitgevoerd heet zeker wel een Man-in-The-Middle attack! Om preciezer te zijn is het een MitM aanval geweest d.m.v. ARP Poisoning. Lees het volgende voorbeeld maar is om het simpeler te maken.

Stel je voor de zogenaamde pakketjes die worden gebruikt om in te loggen op de Hi.nl via TNT post worden verstuurd. Simpel gezegd heb ik de bezorger van TNT Post in elkaar geslagen en zijn kleren aangedaan. Daarna ben ik het pakketje opgehaald en heb ik het stiekem open gemaakt. Nadat ik alles heb gezien plak ik het pakketje weer dicht en breng ik het pakketje naar Hi

Ik heb geen pakketjes aangepast of ze überhaupt bewerkt!

Volgens mij klopt het verhaal van gryz wel. Met een MiTM attack kun je veel meer maar deze is ook een stukje moeilijker. Daarmee is tweakers.net ook een 'eenvoudig' doelwit. Je kunt dan bijvoorbeeld de beveiliging die tweakers erin heeft gebouwd (clientside het wachtwoord encrypten) gewoon weer weghalen.

In dit geval is het genoeg om de pakketten die toch al onversleuteld rondvliegen gewoon op te vangen, Hier zit je niet in het midden (Man in the middle) maar ben je gewoon een van de vele ontvangers.

Waarschijnlijk bekt het wel lekker, "man in the middle". En daarom gebruiken mensen die uitdrukking. Maar hier wordt het wel foutief gebruikt.

Klik jou Wikipedia. zie het plaatsje rechts.
Alice is je browser, BoB zou de banner en de login module moeten zijn.
Maar de banner kan worden verplaatst naar Mallory en daar uitgelezen worden.

Je krijgt je eigen wachtwoord ook gewoon via wachtwoord vergeten binnen op je mobiel. Dit is al zo lang als ik het me kan herinneren dus petje af voor de 'beveiligingsonderzoeker' dat ze er zolang over gedaan hebben

meen je dat serieus? .... Dus het was al bekend dat de passwords niet encrypt waren opgeslagen.... Of heb ik het mis? Ze denken zeker. het gaat via mobiel dus het is veilig... Wat een kneuzen zeg. Valt me nog mee dat ze het niet via mail versturen.

Zo zie je maar weer waarom het ow zo belangrijk is dat je overal een ander wachtwoord hebt....

Er zullen hier vast wel meer Hi! klanten zijn die dit kunnen bevestigen Je kunt gewoon je wachtwoord opvragen en dan krijg je je eigen wachtwoord terug, dus niet een die gegenereerd is.

Dat is inderdaad correct! Eigenlijk moet Hi een nieuw wachtwoord generen en deze te SMS (of beter, via een telefoongesprek) sturen.

Het aparte is, is dat ik niet snap waarom een nutteloos flash bestand de inloggegevens nodig heeft aangezien de aanbiedingen nog niet is persoonsgebonden zijn. Trouwens zat het lek niet alleen in het flashbestand maar ook in de inlogmodule op de homepage van Hi.nl. De homepage is niet beveiligd en stuurt de gegevens ook in plain text naar de servers van Hi.

Conclusie: Haastige spoed is zelden goed! Vooral als je website duizenden mensen vertegenwoordigd

Edit:
"De website van Hi.nl blijkt inlognamen en wachtwoorden onversleuteld te hebben verzonden."

Dat wil niet zeggen dat de gegevens onversleuteld in de database staan! Zover heb ik niet kunnen kijken op de servers (en maar goed ook!). Het enige wat ik weet is dat de gegevens onversleuteld worden verzonden naar de servers, iets wat minstens zo erg is.

[Reactie gewijzigd door ObAt op 19 mei 2011 18:00]

Je kunt gewoon je wachtwoord opvragen en dan krijg je je eigen wachtwoord terug, dus niet een die gegenereerd is.

Idem bij T-Mobile. Als je daar je wachtwoord opvraagd wordt die ook netjes in plain text gesmst.
Edit: toch nog even getest, maar ze hebben het aangepast, joehoe! Je krijgt nu een gegenereerd wachtwoord.

[Reactie gewijzigd door Rick2910 op 20 mei 2011 08:24]

Ik schrik altijd van websites waar je je wachtwoord in plaintext terugkrijgt, het liefst zie ik een random wachtwoord of een link met een eenmalig token om het wachtwoord te wijzigen. Constructies als "Wat is de naam van je huisdier" zijn zo lek als een mandje, met een beetje social-engineering kom je er zo achter (bijv. op de Hyves pagina van de gebruiker staat: Huisdier: 2 Katten, lolcat, lola) of je stuurt een mailtje als dierenfan en vraagt of de gebruiker een enquête over huisdiernamen in wil vullen...

De rapen zijn behoorlijk gaar als iemand die database ooit te pakken krijgt. Is nog net een stapje erger dan unsalted md5-hashes...

Zijn de programmeurs nou gewoon lui of naïef?
Of vergeten ze het gewoon?

Naja, telkens blijken er weer sites te zijn met zwakke beveiliging

[Reactie gewijzigd door calvinturbo op 19 mei 2011 17:19]

Om het geheel wellicht wat te nuanceren:

Hieruit blijkt dat de gebruikersnaam en het wachtwoord van een gebruiker met relatief weinig moeite achterhaald konden worden.

Met "relatief weinig moeite" bedoelen ze: indien je een publiek WiFi netwerk hebt en iemand maakt daar gebruik van om in te loggen op de Hi website en je zit al zijn verkeer af te luisteren en die persoon maakt niet toevallig gebruik van een dienst als Tor, dan kun je wellicht in die brei data een username en wachtwoord vinden.

Natuurlijk, een programma als wireshark geeft voldoende mogelijkheden om verkeer te filteren zodat je alleen de wat relevantere pakketjes onderschept, maar zelfs dan moet je al redelijk gericht gaan zoeken en hopen dat in de tijd die jij aan het luisteren bent toevallig een nuttig stuk informatie voorbij komt. Ja, het is relatief eenvoudig in zoverre dat het een stuk makkelijker is dan een wachtwoord te bruteforcen, maar nog vele malen simpeler is om domweg een telecomwebsite te maken, gebruikers daarvoor gratis te laten registreren en vervolgens te gaan checken hoeveel username/password combo's ook werken op de Hi website. Denk dat je er een stuk meer onderschept

[Reactie gewijzigd door FragFrog op 19 mei 2011 18:04]

Desondanks wordt het "onveilig" versturen van data wel degelijk een steeds groter probleem. Ik denk dat je bang wordt van de hoeveelheid data die je kan opvissen als je een laptopje 24 uur op een onbeveiligd netwerk laat sniffen ergens in de stad of bij een druk café / restaurant.

Ik heb zelf onlangs op een conferentie m'n MacBook ongeveer een uur laten meeluisteren met FireSheep. De vangst was overweldigend; geen Facebook en Twitter logingegevens, maar wel een stuk of 50 sessies waarmee ik zonder problemen de betreffende gebruikers kon imiteren. Het mag duidelijk zijn dat ik daar geen misbruik van heb gemaakt, maar dat het eenvoudig is wordt wel geïllustreerd.

Op Tweakers.net wordt het wachtwoord bij inloggen wel versleuteld, maar eenmaal ingelogd vliegt de sessie ook plain-text door de lucht en heeft vergrendelen aan een IP geen zin omdat het gelijk zal zijn.

Het is met tools als Wireshark "kinderspel" om een scriptje te schrijven wat de meest voorkomende termen (username / nickname / password / pwd / session / etc.) uit de requestdata vist en ergens op te slaan.

Ik kan je niet 123 getallen overleggen, maar het merendeel van de sites verstuurt inloggegevens plain-text in plaats van HTTPS. Als 2% het via HTTPS zou doen verbaast me dat al. Dat de andere 98% geen high profile sites zijn maakt natuurlijk weinig uit. Als je eenmaal een wachtwoord of login combinatie hebt en vervolgens een encrypted hit op een high profile site langs ziet komen heb je bij de gemiddelde gebruiker een bijzonder grote kans dat het wachtwoord gelijk is.

Kortom, los naast het feit dat websites de verantwoordelijkheid moeten gaan nemen om verkeer "gewoon" over HTTPS te gaan sturen (inloggegevens, maar het liefst ook alle data zoals Facebook, Twitter, Foursquare inmiddels aanbieden), moet de consument ook bewust worden van de beveiligingsrisico's die het makkelijk beschikbare internet met zich mee brengen. Dat laatste is bij de gemiddelde gebruiker helaas een utopie, dus blijft de verantwoordelijkheid mijns inziens liggen bij de ontwikkelaars.

[Reactie gewijzigd door Zoefff op 19 mei 2011 18:43]

Wat mij betreft zit de fout hem al in het gebruiken van een unsecure wireless netwerk. Ookal zit je op een website die de authenticatie via HTTPS doet, iedereen kan letterlijk met al je verkeer meekijken, en dus ook zijn eigen TCP/IP packets ertussen stoppen. Zolang deze maar eerder aankomen dan de packets van de echte server kan je dus gewoon wat extra scriptjes op de pagina injecteren die ingevoerde inloggegevens doorsturen naar een server die van jou is. Dus dan helpt die HTTPS verbinding niet.

HTTPS (SSL) beveiligt de verbinding tussen jouw browser (of andere applicatie) en de server, zogenaamde end-to-end encryptie dus. De pakketjes zijn al versleuteld voordat ze je computer verlaten. Of je op een beveiligd of onbeveiligd wireless netwerk zit maakt dan ook niks uit, want als de SSL encryptie van voldoende hoog niveau is kan men aftappen wat men wil, maar de pakketjes zijn onleesbaar. Ook het 'injecteren van wat extra scriptjes' zal dan niet mogelijk zijn.

Het enige dat een beveiligd WiFi netwerk je aan extra bescherming oplevert is dat niet iedere aanvaller je verkeer kan afluisteren. Maar dat beschermt je niet per definitie tegen een man-in-the-middle aanval. Andere gebruikers die verbonden zijn met hetzelfde WiFi netwerk kunnen nog steeds toegang krijgen tot jouw netwerkverkeer. Je bent dus alleen beschermd tegen aanvallers van buiten het netwerk. Helaas komt, met name in het bedrijfsleven, een groot deel van de aanvallen van binnenuit. Gebruik dus ook SSL op je LAN en WiFi.

Dit soort aanvallen komen regelmatig voor op beveiligde WiFi netwerken in hotels of luchthavens. Ondanks de met WPA beveiligde verbinding zitten alle gebruikers op hetzelfde netwerk, en kan men verschillende soorten man-in-the-middle aanvallen op poten zetten. Het is daarom altijd verstandig op zoveel mogelijk sites SSL te gebruiken, en indien mogelijk een VPN op te zetten naar een vertrouwd netwerk voordat je niet-versleuteld verkeer over een niet-vertrouwd netwerk stuurt. Voor dat doel heb ik bijvoorbeeld een simpele PPTP VPN ingericht op mijn privé servertje.

Andere gebruikers die verbonden zijn met hetzelfde WiFi netwerk kunnen nog steeds toegang krijgen tot jouw netwerkverkeer

Dat gaat niet op met WPA2(-PSK). Ieder apparaat heeft daar een andere session key. Met wat trucs is het wel mogelijk om de juiste keys te achterhalen, maar een kwestie van alleen maar sniffen is het zeker niet. Combineer je WPA2 met een RADIUS server, dan wordt het helemaal onmogelijk omdat de benodigde sleutels dan over een door SSL gecodeerd kanaal naar de client verstuurd worden.

Dus dan helpt die HTTPS verbinding niet.

Ik zou je toch wat meer gaan verdiepen in de werking van SSL/TLS. Dan zal je leren dat het daadwerkelijk wel helpt tegen eavesdropping en packet injection.

Wat ik probeer te zeggen is dat hier wordt gesuggereerd dat het wel veilig zou zijn als je op een onbeveiligd wireless netwerk zit en wanneer de authenticatie via SSL gaat, wat dus niet perse hoeft te zijn. Stel b.v. dat je binnenkomt op de homepage die niet via HTTPS gaat (of zelfs via google). Op dat moment kunnen er dus wel packets geinject worden, en kan je dus bijvoorbeeld uitgaande links op de pagina aanpassen. Dan zijn er dus een legio mogelijkheden, waarvan een bijvoorbeeld zorgen dat de authenticatie niet via HTTPS verloopt (als dat mogelijk is).

Desondanks wordt het "onveilig" versturen van data wel degelijk een steeds groter probleem. Ik denk dat je bang wordt van de hoeveelheid data die je kan opvissen als je een laptopje 24 uur op een onbeveiligd netwerk laat sniffen ergens in de stad of bij een druk café / restaurant.

Dit stuk verbaast mij helemaal niets en het leuke is, mensen trappen er ook heel makkelijk in, zie ook deze pagina van de Consumentenbond.

Meestal is het snel snel afronden, waarom extra functionaliteit inbouwen als de klant er toch niet van merkt?

Bij Eneco gaat het één en een ander ook mis, laatst was ik mijn wachtwoord vergeten, en kreeg ik mijn ingevulde wachtwoord per e-mail toegestuurd, op zn minst had ik verwacht dat ik een nieuwe gegenereerde wachtwoord zou ontvangen, helaas kreeg ik zelfde wachtwoord die ik tijdens registratie had opgegeven. Ze worden dus niet met een hash opgeslagen.

Je kan het wachtwoord toch versleuteld opslaan en weer ontsleutelen op het moment dat het nodig is?

Je kan het wachtwoord toch versleuteld opslaan en weer ontsleutelen op het moment dat het nodig is?

Dat kan, maar dat betekent dat iemand die toegang heeft tot de server het wachtwoord kan ontsleutelen. Die heeft dan immers zowel het versleutelde wachtwoord als de code om het te ontcijferen. Dat maakt het versleutelen nogal zinloos...

De gangbare oplossing is het opslaan van een zogenaamde hash. Dat is de uitkomst van een berekining waarbij data verloren gaat. Omdat er data verloren gaat kun je van een hashwaarde nooit meer terugrekenen naar de invoer. Je kunt echter wel controleren of iemand het wachtwoord kent: je voert de hashbereking uit met de gebruikersinvoer en controleert of de berekende hash overeenkomt met die in je database.

Maar goed het probleem bij hi.nl betreft niet zozeer het opslaan, maar het versturen van het wachtwoord. Als dat onversleuteld gebeurt dan maakt het weinig uit hoe de wachtwoorden zijn opgeslagen. Je kunt dan "gewoon" de inloggegevens afluisteren. Om dat te vookomen gebruik je ofwel SSL (versleuteling van je hele http-verbinding) ofwel een challenge-response systeem (of beide).

hash is niet hetzelfde als versleutelen he, bovendien waarom zou je een wachtwoord encrypten en dan weer decrypten, het hele idee is dat niemand achter je wachtwoord komt.

ja, maar de gebruikelijke manier is hashen. one way, niet terug te draaien.

Je moest eens weten hoe vaak er niet gebruik gemaakt wordt van hashen...

Als ik kijk hoe slecht de Hi site werkt zou ik ze eerder incompetent noemen.
Geen beveiligde erbinding is l fout, maar dan ook nog plain text i.p.v. digest.

Sommige programmeurs vertikken het gewoon om de minste moeite te doen voor beveiliging. Ik maak gebruik van een website die bij iedere request twee cookies stuurt met daarin het e-mailadres en het wachtwoord. Toen ik de de developper (die ik persoonlijk ken) erop attent maakte dat dit bepaalde risico's met zich meebracht, was zijn reactie dat het wel mee zou vallen. Wie zou zo'n man-in-the-middle-attack in vredesnaam willen uitvoeren?

Zolang er nog mensen rondlopen die niet bereid zijn om de minste moeite te steken in veiligheid blijven dit soort problemen spelen.

Ik denk dat heel veel programmeurs naïef zijn op dit gebied. Misschien hebben ze ooit op school iets over beveiliging geleerd maar dat zijn ze voor het grootste deel alweer vergeten. Dus er wordt niet (voldoende) over nagedacht wat voor beveiliging er in de applicatie moet worden toegepast.

Het is ook iets wat snel "vergeten" kan worden. Tijdens het ontwikkelen van een stuk software wordt het dan eerst op de simpele manier gedaan, zonder beveiliging, want dan is het makkelijker te testen, en dan wordt vervolgens vergeten om als het product bijna klaar is de encryptie nog toe te voegen.

Ik denk dat heel veel programmeurs naïef zijn op dit gebied.

De manier van opslaan is aan de programmeur, hier wordt echter niet gesproken over de manier van opslaan, maar over de manier van versturen. Dat stuk ligt toch echt bij de systeembeheerder. Jammer dat velen daar anders over denken.

Het is een combinatie van druk van de baas (project moet snel af) en prioriteitstelling, beveiliging staat meestal als laatst op de agenda "als er nog tijd over is". Alles wat op de achter grond gebeurt "waar de gebruiker niks van ziet" is voor de baas verloren tijd.

Als een hacker je netwerk is binnengedrongen dan zal versleuteld verzenden weinig uitmaken: het type mens dat zijn netwerk slecht beveiligd zal ook niet in de gaten houden of hij/zij via https werkt. Dan is het alleen nog een kwestie van Ettercap en SSLStrip.

Zeker telefoons zijn nog wel eens "te gast" op netwerken van derden, die meer of minder beveiligd kunnen zijn.

Ja het is ook makkelijk om wachtwoorden uit Flash bestanden uit te lezen.
Heb hier laatst nog een document over geschreven:
Wachtwoorden uitlezen van SWF bestanden.

Als je een wachtwoord opslaat in Flash ben je knettergek. Daarnaast slaat je zoekopdracht nergens op, 95% van de zoekresultaten zal inlog formulieren bevatten waar helemaal geen wachtwoord in is opgeslagen. Een Flash formulier is kwa beveiliging niet anders dan een HTML formulier. Daarnaast is het in Flash is het juist heel makkelijk om encryptie over een onbeveiligde HTTP verbinding te realiseren (kan met Javascript net zo goed maar dat is meer werk).

beetje mager dat artikel

KPN heeft na een tip van Tweakers.net de auto-inlogfunctie uitgeschakeld. "Klanten kunnen nu dus nog wel inloggen, maar niet meer automatisch".

Volgens mij deed de website dat al nooit.
Ik krijg gewoon een user id en password scherm wat vooringevuld is met een vinkje om je te onthouden, ja nu nog steeds, en ik hoef alleen maar op een knop te drukken om in te loggen, dat was zo en dat is nog steeds zo.
Hier is dus niets aan veranderd.

Dat is een functie van je browser die zelf de passwords opslaat en voor je invult, uitbreiding op het bekende autocomplete forms. Dit gaat over het opslaan in een cookie etc.

Precies, en bovendien mag je de value van een password veld niet met script aanpassen, toch?

De reden om http te onderscheiden van https was volgens mij serverbelasting.
Maar is dat anno 2011 nog steeds een geldig criterium?
Is er een goede reden om http te handhaven en niet in zijn geheel te vervangen voor https?

Redenen:
-dure certificaten... een kleine bandsite voor 100 euro wordt dan toch al weer 50 euro duurder.
-oude clients
-langzaam

Afgezien van het versleutelen met TLS/SSL ben ik me aan het bedenken hoe je dan een wachtwoord clientside moet encrypten zoals in de reacties hierboven wordt aangegeven... JavaScript? AES-256, waarvan de key dus in de JavaScript staat? Of een digest... Dus je gaat je salt in JavaScript zetten...

Misschien omdat ik net wakker ben (lees: slaapdronken) maar klinkt me niet echt logisch.

Edit @ hieronder: inderdaad! Was ook net pas wakker

[Reactie gewijzigd door Nexz op 20 mei 2011 09:33]

Encrypten met een door de server meegestuurde token. Het geencrypte password kun je vervolgens op de server weer decrypten en voor authenticatie gebruiken en hashen+salten wanneer het opgeslagen moet worden.

Ik vind wel eens tijd voor een Europese wet die websites met een bepaald aantal leden verplicht moeten worden om de gegevens in non-plain tekst te versturen. Als dat niet gebeurt dan moet de website een boete betalen.

De politiek moet zich buiten het internet houden. Punt.

Oneens. Het feit dat soort dingen telkens kunnen gebeuren is juist een gevolg van de wetteloosheid op het internet. Ik pleit niet voor een internetpolitie maar onzorgvuldig omgaan met privacy data op het internet moet wel bestraft (kunnen) worden.

Dan word elke amateuristische site gelijk aangeklaagd. Dat heeft geen zin, er moet gewoon in de privacy statement komen te staan hoe de gegevens worden opgeslagen, dan ligt de keuze bij jou.

Ik vind wel eens tijd voor een Europese wet die websites met een bepaald aantal leden verplicht moeten worden om de gegevens in non-plain tekst te versturen. Als dat niet gebeurt dan moet de website een boete betalen.

Je bent niet verplicht te registreren voor een website.

EDIT: Er zijn geloof ik weer downmodders aan de gang, zeker op jacht naar boostpunten?

[Reactie gewijzigd door CH4OS op 20 mei 2011 12:54]

Wat een bizarre basisfout! Kan niet anders zeggen dan dat iemand hier blijkbaar heeft lopen slapen. Natuurlijk kan er altijd een bepaald aspect onopgemerkt blijven, maar dit is een enorm gapend gat.