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)

[Zoijar]

Ik snap het niet helemaal. Wat voor nut biedt het encrypten van sessie-ids? Het idee is toch dat je een voldoende groot getal kiest dat je niet zo maar kan raden, en dat dan eventueel nog aan een IP koppelt? Als je een versleutelde sessie-key afvangt, dan kan je er toch nog steeds bij? (ik bedoel, als je key een plain tekst getal is van zeg 64 cijfers, dan wens ik je veel geluk er eentje te raden...)

[Reactie gewijzigd door Zoijar op 27 juli 2024 03:29]

[Blorgg]

De fout die hier gemaakt is heeft niets met de encryptie van sessie-id's of de lengte van een string te maken

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.

[Givanisovic]

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

Het lijkt dus zo te zijn dat het ID dat in de URL staat om een iDeal-betaling te doen lek was.

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.

[Keneo]

Ja, maar aangezien dit ID toch niet opteld en random is maakt het niet uit welkf formaat dit heeft, je kan het nog altijd even makkelijk brute forcen?

[gimbal]

volgens mij zit het hem in dit geval in het feit dat de sessieID client side ergens opgeslagen en meegestuurd wordt (richting iDeal). Als je die gegevens kunt onderscheppen dan heb je blijkbaar direct toegang tot alles zonder enige verdere moeite.

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.

[Keneo]

Inderdaad, beetje onduidelijk. in het artikel staat namelijk:

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

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.

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...

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.

@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?

[Reactie gewijzigd door Keneo op 27 juli 2024 03:29]

[marcel-xl]

@Zoijar - ik snapte het ook niet, totdat ik het originele artikel las. Daarin staat helemaal niet dat het om SESSION id's gaat, maar om zgn. "SLEUTEL" id's.

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).

[enzyme]

Misbruik werkt mogelijk zo: Je luistert iemands browser requests af, vangt de url op waar de base64 parameter in meegegeven wordt, decodeert deze, haalt de sessie id eruit, maakt een eigen sessie die je bewerkt en de gestolen sessie id instopt en weer codeert als parameter en daarmee ben je opeens ingelogd als de andere persoon.

[maniak]

47295736589578364589547437549658347632654386943873247548956843765498693247549854932754954832765498569043732954965

Heb gewonnen?

[InsanelyHack]

volgens mij is het simpel.

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

[poster2011]

Maar als ze een GUID gebruiken op de plaats van het cijfer, dan is er toch niks aan de hand, waarom zou je een GUID versleutelen?

[Rutix]

Mag hopen van niet. Al zouden ze nu de session-id encrypten dan nog kun je er makkelijk 1 jatten en daarmee inloggen. Het probleem zit hem hier gewoon in dat een andere client dezelfde session-id kan gebruiken wat natuurlijk niet de bedoeling is.

[Soldaatje]

Het waterbedrijf is zo lek als een mandje.
Water naar zee dragen...
Sorry, hoor maar welke programmeur verzint zoiets? Base64 is geen beveiliging!

[Reactie gewijzigd door Soldaatje op 27 juli 2024 03:29]

[spil]

Hier past een recente InfoSec Reactions blogpost prima bij!
http://securityreactions..../we-use-base64-encryption

[maniak]

Niet alle programmeurs zijn even goed en slim..

[Verwijderd]

Alle goede programmeurs zitten hele dagen op het Tweakers forum te roepen hoe slecht andere programmeurs wel niet zijn....

[SiC123]

niet iedere goede programmeur krijgt voldoende budget/ruimte om alles te beveiligen.

[madmaxnl]

Oh ja, geef het budget maar de schuld. Die bankiers hadden zeker ook niet genoeg budget om de financiële crisis te voorkomen.

[macnerd]

Ik zou juist zeggen dat de bankiers teveel budget hadden waardoor ze de financiële crisis veroorzaakt hebben.

[Verwijderd]

gebrek aan budget is vaak de grootste reden om iets niet te doen

[Ook al Bezet]

Sessie-id's op laag water zoeken :ja:

[eborn]

Ik maak uit het artikel nou niet echt op wat er technisch aan de hand was. Het sessie ID van een gebruiker werd doorgegeven via een onbeveiligde verbinding denk ik?

[Verwijderd]

Voor zij die niet zo thuis zijn in de materie:

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.

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

Deze codering is dus strikte noodzaak om een systeem te laten functioneren.

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.

[Sorcerer8472]

Hoe lang is zo'n sessie-ID dan geldig bij dit bedrijf? En is er geen brute-forcebeveiliging?

[_Thanatos_]

cookiewet gone mad?

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 27 juli 2024 03:29]

[Xavier]

Joost van Luijk Luijt van Oasen.