Alweer bijna 10 jaar terug hackte ik mijn vrienden. Daarmee kreeg ik informatie onder ogen, dat op dat moment nog niet voor mij bestemd was.
Eén van de voor mij meer opvallende berichten rond diezelfde periode (2009/2010), betrof het eten van pizza voor 1 cent per stuk. In het jaar voordat ik mijn vrienden hackte, vonden studenten van Nyenrode een kwetsbaarheid bij Just-Eat.
Gratis pizza via applicatie hack
Door de gevonden kwetsbaarheid met andere studenten(steden) te delen, wisten studenten ter waarde van EUR 30.000 aan pizza's te bestellen, maar dan bijna gratis. In die zin viel deze uitbuiting niet meer onder white-hat hacking;
Opvallende zaken aan deze hack:
- De kwetsbaarheid was al langere tijd bekend bij Just-Eat, maar is desondanks niet eerder tot actie overgegaan;
- Just-Eat heeft een zaak aangespannen om misgelopen inkomsten terug te halen;
- Alhoewel iDeal als betalingsmechanisme werd gebruikt, stond iDeal hier als payment provider los van;
- Dit voorval mocht nauwelijks hacken worden genoemd; studenten wisten verborgen formuliervelden aan te passen, wat niet dubbel gecontroleerd werd in de webshop c.q. het bestelproces.
Deze uitbuiting kon vooral ontstaan, doordat de definitieve betaal-gegevens (bedrag) in het bevestigingsscherm niet onder water werd onthouden om vervolgens te verifiëren. Hierdoor werd de waarde in het scherm als correct beschouwd, die door de studenten naar hartelust gewijzigd kon worden. In tegenstelling wat de directeur van Just-Eat toentertijd verkondigde onder het mom damage-control, hoefde je hiervoor niet het slimste jongetje van de klas te zijn.
Terwijl ik in het prille begin van mijn programmeer-carriere stond, heb ik dit toentertijd direct aangegrepen om websites en systemen van mijn hand onder de loep te nemen. De hack bij Just-Eat had voorkomen kunnen worden. Bijvoorbeeld door:
- gebruik te maken van CSRF tokens waarin de daadwerkelijke getallen konden worden meegestuurd naar een volgend scherm, of;
- de correcte data nog eens uit de database te lezen, in plaats van uit de POST omgeving.
Hoe het afliep met de gehackte vrienden
We zijn nog steeds bevriend. Sterker nog, de hack van mijn hand werd ook door hen beschouwd als een goede poets. Het toont echter goed het belang van security van applicaties, webshops of websites aan en deed me ook zelf stil staan bij mogelijke consequenties.
De impact van mijn hack was beduidend kleiner dan het pizza-scenario. Desondanks kon ik met mijn hack meekijken met mijn vrienden en informatie buit maken.
Hacken begon als grap
Wat resulteerde in het hacken van mijn vrienden, begon als een grap. Bij Lootjestrekken.nl kon je in de groep berichten schrijven c.q. met elkaar communiceren via de groeps-chat. Hierin probeerde ik met HTML de tekst op te maken en via CSS de kleuren aan te passen van de hele webpagina, een zogenaamde XSS kwetsbaarheid.
Toen bleek dat dat mogelijk was, begon ik met het invoegen van JavaScript. Voor de grap schreef ik een stukje code, waarmee het voor bepaalde gebruikers onmogelijk werd om aanvullende reacties achter te laten. Dit deed ik door in de code te controleren op de naam van de gebruiker die op dat moment was ingelogd.
Informatie achterhalen
Toen dit mogelijk bleek, en ik wist op welke plek van het scherm de naam van de andere persoon (van wie jij het lootje had) stond, kwam ik tot de volgende conclusie: De ingevoegde code valt in de categorie stored XSS, wat inhoudt dat de code bij iedere gebruiker die dezelfde webpagina oproept, wordt uitgevoerd.
Om conflicten in de code te voorkomen, heb ik dit toentertijd eerst in een testomgeving gedaan, middels een kopie van de webpagina van lootjestrekken.nl. Vervolgens heb ik de code online geplaatst. Het doel: van alle vrienden achterhalen wie ze getrokken hebben en opslaan op een eigen omgeving.
Hiervoor had ik een plekje op een eigen server geserveerd, die achterhaalde data zou opslaan. De achterhaalde namen van de getrokken personen wist ik via een AJAX request naar mijn server te versturen, tezamen met de persoon die was ingelogd. Op die manier wist ik de combinatie van persoon en bijbehorende getrokken persoon.
Hacking: social engineering
Het enige dat mij restte, was een stukje social engineering; Zorgen dat men zou inloggen, nog voor het moment dat we zouden samenkomen. Zo kon ik bewijzen dat ik al in een vroeg stadium exact wist wie welke persoon had getrokken.
Social engineering omvat het binnen dringen van een systeem of systeemlaag via de zwakste schakel, de mens. Daar waar social engineering soms de eerste schakel in het proces van een hacker kan zijn, was het voor mij de laatste schakel; mijn code moest immers nog door ieder individu nietsvermoedend uitgevoerd worden.
In mijn geval was het tevens de makkelijkste schakel. Ik speelde in op de nieuwsgierigheid van de mens en stuurde iedereen per SMS het verzoek om nou toch eens op mijn laatste bericht binnen lootjestrekken.nl te reageren. Daar stond natuurlijk een loos bericht, gepaard met een stukje kwaadaardige code van mijn hand. Hiermee stroomde per iedere vriend die ging inloggen, de laatste informatie binnen.
Kwaadaardig hacken
Alhoewel bovenstaande hack onschuldig lijkt, had het voor meer kwaardaardige doeleinden ingezet kunnen worden. Hierbij had ik willekeurige mensen uit kunnen nodigen. Zolang deze mensen nieuwsgierig genoeg werden gemaakt om eens een kijkje te nemen , had ik ze via JavaScript elk ander denkbaar scenario voor kunnen leggen.
Wat er is veranderd
Behalve dat lootjestrekken.nl mij heeft Gegoogled en het lek heeft gedicht, is er qua security in het algemeen niet significant veel veranderd. Dat is helaas breed van toepassing. Een meer recente lek van Albert Heijn past in dit rijtje van onverhoopte doch eenvoudig te voorkomen euvels. Pakken we het bericht van NOS omtrent afwezigheid van aandacht voor (cyber)security bij ICT vakken erbij, dan kan voorzichtig de conclusie getrokken worden dat er weliswaar meer awareness is voor cybersecurity, maar dat er op het gebied van software als ook scholing nog te weinig positieve verschuiving is.
Door ook als hacker te (kunnen) denken, ben je in staat je eigen software of software binnen de eigen organisatie qua cybersecurity onder de loep te leggen. Buiten automatische tests om, of juist in het verlengde ervan. Dit heeft mij als programmeur en security consultant geholpen.
Meer kwetsbaarheden en hacks
In een volgende security-blogpost geef ik een beknopte inleiding in de hackers-wereld en exploit-mogelijkheden waar bijvoorbeeld binnen een website, webshop of applicatie sprake van kan zijn. Dit zal ik aanvullen met links naar artikelen en overzichten die mij als hacker meer inzicht heeft gegeven in kwetsbaarheden en mogelijkheden tot misbruik ervan.