Waterbedrijf Oasen versleutelde sessie-id's niet
Het Zuid-Hollandse waterbedrijf Oasen kampte met een beveiligingsprobleem op zijn website, waardoor klanten gegevens van anderen konden inzien. De sessie-id in de url bleek alleen te zijn gecodeerd via base64, dat geen encryptie biedt.
Volgens Oasen is de beveiliging inmiddels 'verscherpt', nadat vier weken geleden een hacker via het Nationaal Cyber Security Centrum een melding maakte van het beveiligingsprobleem. Het waterbedrijf, dat rond de 750.000 klanten heeft, noemt de kwetsbaarheid moeilijk te misbruiken. Security.nl schrijft dat het probleem in de iDeal-betalingspagina bij Oasen zat.
De sessie-id van acht tekens op de betalingspagina was niet versleuteld, maar gecodeerd met base64. Die codering wordt onder meer gebruikt om bijlagen te versturen via e-mail, door binaire objecten te converteren naar ascii-code. Base64 biedt echter geen enkele vorm van encryptie en dus kon de beveiligingsonderzoeker die het probleem ontdekte, de sessie-id decoderen en manipuleren, waardoor betalingsverzoeken van andere gebruikers konden worden opgevraagd.
Daarbij waren de adresgegevens zichtbaar, en door de iDeal-betaling te starten en direct weer af te breken kon ook het accountnummer van de klant worden bemachtigd, meldt Security.nl. Die gegevens waren genoeg om de 'wachtwoord vergeten'-functionaliteit van Oasen te misbruiken en daardoor in te loggen als een andere klant. Daarbij waren ook e-mailadres en telefoonnummer zichtbaar, en konden meterstanden en verhuizingen worden doorgegeven. Meterstanden doorgeven kan overigens enkel als de desbetreffende klant een oproep heeft gehad.
Volgens woordvoerder Joost van Luijk van Oasen is er in de praktijk geen misbruik gemaakt van het beveiligingsprobleem. "Het is echt heel erg lastig om er wat uit te krijgen", aldus Van Luijk. Volgens hem was de sessie-id niet oplopend, zodat een brute force-aanval noodzakelijk was om de gegevens te pakken te krijgen. Inmiddels wordt 256bits-encryptie gebruikt voor de beveiliging van de sleutel-id's.
Reacties (26)
Water naar zee dragen...
Sorry, hoor maar welke programmeur verzint zoiets? Base64 is geen beveiliging!
[Reactie gewijzigd door Soldaatje op dinsdag 25 september 2012 13:03]
http://securityreactions..../we-use-base64-encryption
Coderen is "in code overzetten". Je zet hierbij bepaalde gegevens om naar andere gegevens volgens een vooraf bepaalde afspraak. Zo zou je het alfabet kunnen coderen met nummers. Je krijgt dan A - 1, B - 2, C - 3, D - 4, E - 5, etc. etc.
Door gebruik te maken van codering kun je bepaalde afspraken maken over het uniform uitlezen van gegevens.Stel dat je een programma hebt dat uitsluitend cijfers kan lezen. Door te coderen kun je vervolgens álle soorten karakters (zoals gebruikt in ons eigen alfabet maar ook Arabisch, Cyrillisch, Sino-Tibetaanse talen, etc. etc.) omzetten naar cijfers zonder dat daarbij de oorspronkelijke inhoud verloren gaat.
In het geval van Base64 ligt de noodzaak in het ontwerp van diverse protocollen.
Deze codering is dus strikte noodzaak om een systeem te laten functioneren.De conversie naar ASCII is noodzakelijk omdat veel protocollen op internet gebouwd zijn op het gebruik van (7-bits) ASCII-tekens en niet van binaire code van 8 bits. @ Wikipedia
In het geval van de genoemde Base64-codering wordt binaire code (011011010011) omgezet naar ASCII. ASCII is een tekenset die bestaat uit 95 karakters die overeenkomsten hebben met vrijwel alle mogelijke toetsen op een toetsenbord.
Een wachtwoord wordt Base64 omgezet naar ASCII. Stel dat je als wachtwoord "kanarie" gebruikt. Wanneer je dit omzet naar middels kom je uit op "a2FuYXJpZQ==".
Dit lijkt op het eerste gezicht een versleuteld wachtwoord omdat "a2FuYXJpZQ==" in de verste verte niet lijkt op kanarie". Het probleem is echter dat de omzetting is gebeurd met een vooraf bepaalde internationaal bekende afspraak. Op internet zijn tal van tools te vinden om Base64 om te zetten naar hun oorspronkelijke formaat (neem bijvoorbeeld http://www.motobit.com/util/base64-decoder-encoder.asp). En dat is wat je met een wachtwoord nu net niet wilt hebben.
Encryptie daarentegen is het proces waarbij gegevens daadwerkelijk versleuteld worden waarbij je de sleutel nodig hebt om de gegevens weer in te zien. Zonder deze sleutel is het (in principe) onmogelijk om de oorspronkelijke gegevens te achterhalen.
[Reactie gewijzigd door Zoijar op dinsdag 25 september 2012 13:18]
Heb gewonnen?
Moet je wel eerst de gegevens onderscheppen natuurlijk. Als je dat al kunt dan is het probleem veel groter en ergens anders op te lossen, lekker belangrijk dat er gegevens niet encrypted zijn.
Als het nu plain text is, base64 encoded (wat ok is voor binaire data die in text formaat moet worden verstuurd) of encrypted met een 256bits key, het maakt niet uit... Je kan nog altijd brute forcen.Volgens ... Oasen is er in de praktijk geen misbruik gemaakt van het beveiligingsprobleem. "Het is echt heel erg lastig om er wat uit te krijgen", aldus Van Luijk. Volgens hem was de sessie-id niet oplopend, zodat een brute force-aanval noodzakelijk was om de gegevens te pakken te krijgen
Enige verschil zal zijn dat een encryptiemethode in de praktijk padding zal toevoegen waardoor de sessie id altijd minstens een vaste lengte heeft.
Echter een random integer van 256bit, base64 encoded is even moeilijk te brute forcen.
Ook is de reactie van Oasen zeer proper en open, de vinder bedanken om het lek te melden, ipv hem aan te klagen zoals sommige andere grote bedrijven wel durven doen...
@gimbal: als ik het goed begrijp: wanneer je de session ID kan onderscheppen kan je toch de sessie hijacken? Behalve als de session ID eigenlijk een string is die encrypted is met een key die enkel beide partijen weten, en er telkens een nounce meegestuurd wordt in deze string?Oasen is de anonieme hacker dankbaar voor het melden van de zwakte in de beveiliging. We testen uitgebreid onze beveiligingsmaatregelen maar staan altijd open voor dit soort meldingen. Als blijkt dat we de beveiliging ermee kunnen verbeteren zullen we deze adviezen gebruiken om maatregelen te nemen.
[Reactie gewijzigd door Keneo op dinsdag 25 september 2012 14:01]
Wat hier mis gaat is dat een string van client A door client B kan worden gebruikt om zich te authenticeren. Vervolgens wordt de fout gemaakt dat input van client A geaccepteerd wordt als zijnde input van client B zonder dat er tussen client en server een mechanisme gebruikt wordt om correct vast te kunnen stellen welke input van welke client afkomstig is.
Dit zijn toch twee behoorlijk eenvoudige dingen om goed te programmeren. Elke beetje fatsoenlijke web ontwikkelaar zou dit moeten kunnen dromen. En anders heeft zo iemand niets te zoeken bij systemen waar het gaat om privacy gevoelige gegevens.
Het lijkt dus zo te zijn dat het ID dat in de URL staat om een iDeal-betaling te doen lek was.Een beveiligingsonderzoeker genaamd 'häcker' wist via een link van de iDeal-betaling de ID's in de URL aan te passen.
Bron: http://www.security.nl/ar...s_via_iDeal-betaling.html
Voorbeeld: http://www.domain.tld/betaalnu?ID=1234 Het 1234 gedeelte was dan gecodeerd met Base64, dus dan krijg je http://www.domain.tld/betaalnu?ID=MTIzNA==
Dit komt overeen met wat victoire22 zegt: URL manupilation.
Weet niet precies wat ze daarmee bedoelen en kan het nu niet meer op de website van het waterbedrijf nagaan, maar vermoed dat het ging om klantid's oid, welke niet gecryped in de URL stonden. En dan is het vrij makkelijk raden inderdaad.
Naar mijn weten is het gebruik van SESSION id's niet slecht (En zoals iemand hieronder zegt, GUIDs crypten heeft weinig zin)
De titel van het artikel op tweakers is dus niet goed (en misleidend).
als je je meterstand invult b.v. via https://meterstanden.oasen.nl/session12345.aspx
dan kan je in een andere sessie met een browser gewoon een andere sessie proberen te benaderen zoals https://meterstanden.oasen.nl/session54321.aspx
Noemen ze URL manupilation
http://www.cgisecurity.com/owasp/html/ch11s04.html
Je kunt de sessie ook gewoon op de server bewaren, daarvoor heb je niets nodig in de url. Is gewoon een standaard web-iets. Zo goed als iedere website met login gebruikt het, dus je mag er best vanuit gaan dat dat aanstaat bij je bezoekers.
En de cookiewet? Die laat dit gewoon toe. Het is immers nodig om de site te laten functioneren. Of om het om te draaien: er is geen realistisch cookieloos 100%-alternatief.
[Reactie gewijzigd door _Thanatos_ op dinsdag 25 september 2012 21:39]
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Games Microsoft 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
