Datadiefstal bij Britse provider TalkTalk vond plaats via sql-injectie

De hack bij de Britse provider TalkTalk was mogelijk doordat de aanvallers een sql-injectie deden op een oude webpagina. Die oude webpagina hoorde bij de provider door een overname van de Britse tak van Tiscali in 2009.

De sql-injectie was onder meer mogelijk doordat de databasesoftware verouderd was en de leverancier ondersteunde die versie van de software niet eens meer, schrijft de Britse toezichthouder ICO. De sql-injectie was mogelijk op drie webpagina's die gelinkt waren aan de database die voorheen van Tiscali was. Er waren voor de hack in oktober vorig jaar al twee eerdere pogingen gedaan, maar de provider had die niet opgemerkt. Dat kwam doordat TalkTalk de pagina's niet monitorde.

De aanval was makkelijk te voorkomen geweest met de juiste beveiligingsmaatregelen, aldus ICO. Daarom oordeelt het dat TalkTalk zich niet aan de wettelijke verplichting voor het beveiligen van gebruikersdata heeft gehouden en heeft de provider veroordeeld tot het betalen van een boete van 400.000 Britse ponden, momenteel omgerekend ongeveer 455.000 euro. In Nederland is sinds dit jaar een dergelijke boete ook mogelijk vanwege het verwaarlozen van de beveiliging met de diefstal van klantdata tot gevolg.

Bij de hack waarvan TalkTalk slachtoffer werd in oktober vorig jaar zijn de gegevens van ongeveer 150.000 klanten gestolen. Daarbij gaat het mogelijk om gegevens zoals telefoonnummers, e-mailadressen en bankgegevens. De drie verdachten die de politie arresteerde, kunnen een gevangenisstraf krijgen. TalkTalk verloor na de hack tientallen miljoenen ponden aan kosten en 95.000 klanten.

Reacties (30)

Voor wie SQL injectie niet goed kent:

SQL= de database en Injectie = het 'misbruiken' van het zoekveld door er 'sql-zoek-code' in te typen. Code die enkel een database verstaat zodat je niet enkel zoekt naar een bepaald woord maar ook code mee kan sturen om de rest van de database te downloaden. Een onbeschermde database voert gewoon uit wat jij vaagt. Dus ook de resultaten van alle wachtwoorden en logins ;-)

Het is een vrij oude hack-techniek (15j+) die meestal nog enkel werkt op erg oude websites die geen updates gekregen. (Daarom dat er nu boetes op staan, het is als een bank die de brievenbus gebruikt als geldkluis) Via een zoekveld op een website (dat natuurlijk gekoppeld is aan een database) kan simpelweg een product ID opgezocht worden maar je kan ook bepaalde 'sql-zoek-code' injecteren in dat veld.(indien het niet beschermd is tegen injectie)

Stel dat er ook persoonsgegevens en logins in de database staan, dan kan je in dat zoekveld een code injecteren. Dat ziet er ruwweg zo uit: SELECT * FROM persoon WHERE achternaam = 'Janssens' OR 'a' = 'a' Dan stuurt de database je de gegevens door van 'jassensr'. Maar de hacker zet er doodleuk een ander statement bij dat altijd waar is: (A is dus altijd a) Met als gevolg dat je de hele lijst van achternamen toegestuurd krijgt. En natuurlijk probeert hij ook eens met 'logins' dan me 'password' enz. Tot hij alle informatie heeft ;-)

[Reactie gewijzigd door Coolstart op 6 oktober 2016 01:45]

Aanvulling: het hoeft niet per se om een zoekveld te gaan. Elke plek waar input van de gebruiker ingaat - of dat nu via de URL is, via een zoekveld of via een ander soort veld - is in principe kwetsbaar als die ongefilterd in een SQL-query wordt geplaatst.

Oftewel, zoals XKCD het uitlegt voor dummies: https://xkcd.com/327/
Als ik mij niet sterk vergis had hij die comic al geschreven voordat de hack plaatsvond.

Zoals we hier weleens zeggen: software schrijven is net als seks. Never trust user input.

Bij de hack waarvan TalkTalk slachtoffer werd in oktober vorig jaar zijn de gegevens van ongeveer 150.000 klanten gestolen. Daarbij gaat het mogelijk om gegevens zoals telefoonnummers, e-mailadressen en bankgegevens.

Waarom hebben ze überhaupt toegang tot bankgegevens?

Met bankgegevens wordt lijkt me bedoelt de rekeningnummers van klanten van talktalk waar talktalk het abonnementsgeld van afschrijft.

Best slecht dat er nog steeds veel sites zijn die sql injectie niet gefixed hebben terwijl dit heel makkelijk kan door bijvoorbeeld prepared statements te gebruiken voor je sql queries.

door bijvoorbeeld prepared statements te gebruiken voor je sql queries.

Gebruik je zelf altijd prepared statements?
Zo ja, heb je toevallig een linkje naar de code?

Op http://php.net/mysqli_query zie ik helemaal niks over prepared statements.. waarom is zelfs dat nog niet gefixed?

[Reactie gewijzigd door Olaf van der Spek op 5 oktober 2016 20:08]

Zie voor PHP/MySQL deze pagina over prepared statements.
Een andere handige pagina is ook nog deze link voor een aantal smaakjes SQL.

Belangrijkste les is: als je nog steeds SQL statements bouwt via string concatenatie (b.v. "SELECT * FROM users WHERE username = '" + userVar + "'") doe je het verkeerd!

De input van de gebruiker (of dit nu via een form of de URL is) moet je natuurlijk altijd valideren. Ook bij het gebruik van prepaired queries is dat gewoon "good practice".

Sowieso hoort dat eigenlijk zo te werken, maar ik merk een trend bij programmeurs.. (geen goede trend).. om back-end validatie maar een beetje te laten liggen.

Heel veel problemen 'lossen' ze op door een stukje javascript o.i.d.
Deze oplossingen worden wel doorgevoerd in een systeem, waar per definitie alles ge-prepare-t wordt.
Al staat er een cryptolocker in.. er gaat niks uitgevoerd worden.. never..
(met onervaren programmeurs zou het nog mogelijk zijn, maar die weten dan echt niet meer wat ze aan t doen zijn deze tijd)

Met al die frameworks verliezen veel programmeurs goed inzicht.. Wat je bijvoorbeeld ziet door het alom ontbreken van back-end validatie.
1 van de redenen waarom ik niet zo'n voorstander ben van het altijd maar inzetten van voorgekauwd werk. Het maakt mensen simpeler.

Eigenlijk zou een framework dit juist makkelijker moet maken, bijv. in Symfony kan je validatie regels instellen voor een bepaald model (XML of Annotaties) en die zelfde regels kan je dan weer gebruiken voor de client-side (automatisch via de juiste Bundle/plug-in).

Een framework de schuld geven van onkunde is wel erg zwak, ik deel wel je mening dat alles steeds meer client-side "moet" en dan beveiliging veelal slecht of helemaal niet word toegepast (wat kan er nu fout gaan? *kuch* XSS, CSFR).

Maar of je wel of geen framework gebruikt maakt niet uit, het framework zal het misschien makkelijker maken, dat je sneller geneigd bent om het op een bepaalde manier op te lossen. Maar als je een hamer gebruikt om een explosief onschadelijk te maken is het dan de schuld van de hamer of van de idioot die hamer gebruikt?

Ik zeg altijd maar zo: het instrument is beperkt tot de kunde van de gebruiker, met Photoshop kan je van alles maken (maar ik mag al blij zijn als maten kloppen ).

Nou.. ik zie hierbij hetzelfde probleem, zoals ik ze bij autonome auto's ga verwachten.
De aandacht van mensen neemt af. (zoals developers vrijwel nooit meer aan backend validatie denken)

Ik geef niet de frameworks de schuld, maar de mensen, die eigenlijk niks meer kunnen buiten zo'n framework.
Dingen als annotations en 10 verschillende plaatsen om dezelfde business logic te plaatsen vind ik aanzienlijk slecht qua structuur. (zeker met grote afwisselende teams en met -tig andere systemen/frameworks)
Alle voordelen van die systemen worden snel een nadeel.

Ik gruwel van al het werk van Fabien Laurencier (Symfony / Doctrine), omdat hij het K.I.S.S. principe gewoon niet kent of snapt. Het verschil is uiteraard dat deze man in principe wel snapt, wat hij doet. Het is alleen niet handig.
Nieuwe programmeurs leren in dit soort systemen eigenlijk alleen maar puur hoe je met dát systeem moet werken. Zeker met die specifieke -Im gonna do it mý way- Fabien code.
Ik wil nog eens de tijd nemen om verschillende systemen te benchmarken. Mijn aanname is namelijk dat alleen het stroomverbruik al bij bepaalde systemen zoveel meer is.. dat je beter gewoon native PHP kan gaan schrijven, of met losse libraries.

Ik werk regelmatig aan backends en vooral de sql scripts. Bij elk SQL script maak ik standaard een validatie routine voor de inputparameters. Ik gebruik daar nooit frameworks voor. Ik heb wel een paar vaste regels, maar ik maak er zoveel mogelijk maatwerk van. Liefst eerst een controle op wat wel mag en dan nog eens op wat beslist niet mag. Dit alles gaat netjes in een class waar je de parameters in kan stoppen en je één record terugkrijgt (of wegschrijft).
Of ik die class nu gebruik, of een collega, een sql-injectie komt er bij mij gegarandeerd niet door.

Dat is zoals het hoort.. Het nadeel van de frameworks is, dat niet iedereen meer een compleet overzicht heeft.
Dat ene kolommetje kan dan best ergens door de back-end heen glippen.

Als een totaal ander voorbeeld. Database triggers kunnen onwijs handig zijn.. Nog nooit écht gebruik van gemaakt, omdat ik weet dat de meeste mensen niet op de hoogte zijn hoe die dingen werken. (of überhaupt bestaan).
Die zien dan een heel stuk business logic niet.

http://www.phptherightway.com/#pdo_extension

Vergeet niet dat dit een oude pagina was van Tiscali in den tijd nog

en de eerste vraag die mij te binnen schiet: waarom was die in godesnaam nog online?

Omdat (kies uit de volgende)

• Deze pagina van een overname van een overname van een overname kwam?
• Partij X niet wil dat de klanten van overgenomen partij Y erachter komen dat ze over zijn genomen door partij X?
• In Telecom/Hosting-land overnames elkaar zo snel opvolgen dat het overnemen van een toko een haast-haast-haast klusje is waarbij nooit echt verder wordt gekeken dan "zorg maar dat de klanten morgen in onze database zitten".

Been there, done this a lot, got t-shirts. Dan kom je er na zo'n overname project achter dat er nog ergens een 'Billy's TelefooncentraleDotCom Klantenpaneel' van een paar overnames geleden te vinden is. Na even inloggen, zie je dat de klantgegevens-pagina een hoogst Web 1.0 frame is dat eigenlijk verwijst naar '/uwgegevens.asp?KlantID=1234' en dat je gewoon dat ID aan kan passen om de rest in te zien.

Het is vrij vaak voorgekomen, dat pagina's voor de eeuwigheid online blijven staan.. Zonder dat daar iemand vanaf weet.
De manager/chef weet het niet (meer), de developer/beheerder gaat niet uit eigen initiatief de boel controleren (zeker niet bij uurtje factuurtje bedrijven).

Normale gang van zaken.. Alleen een bedrijf met écht goede sturing, weet dit soort dingen te pareren.

Nu doe je de aanname dat 'zeer goede sturing' onafhankelijk is van de zwakkere schakels in de keten (vorige overnames).
En zelfs buiten uurtje-factuurtje bedrijven om spelen dit soort dingen, zelfs bij de grote jongens.
Want dan blijkt ineens dat Billy's Klantenpaneel een zelf in elkaar geprakt pakket is van een half miljoen regels classic ASP. En dan ga je naar de manager toe, want je wilt van die draak af. En dan hoor je dingen als:

• "Duurt te lang, gaan we niet aan beginnen."
• "Het werkt nu toch ook?"
• "Een compleet nieuw paneel zou teveel verandering zijn voor die paar klanten.
• "Ach, die paarduizend klanten, daar is toch geen hacker in geinteresseerd."
• "De klanten van die toko mogen eigenlijk niet weten dat ze al drie keer overgenomen zijn."

Ik heb inderdaad al die argumenten wel eens gehoord.
De slechtste blijven de argumenten m.b.t. white labeling en overnames. Dit is in mijn oren "bedrog".

Bedrog is een groot woord. Stel dat je bij overgenomen toko/label allemaal betalende klanten hebt die voor dienst X nog het voor die toko oude tarief van 100 eurie per jaar betalen, terwijl dienst X bij jou 50 cent kost.
Dan ga je niet dief van je eigen portemonnaie zijn door hen er op te wijzen dat ze 99,50 teveel betalen.

Nou.. het is dan wel zo netjes om ze erop te wijzen.
Iets wat Ziggo bijvoorbeeld niet doet. (ik betaalde 2,5x meer voor een ouder abbonement met minder)

Dus ja.. als Klant A 50 cent betaalt en klant B 100 euro voor precies hetzelfde.. niet heel errug netjes.

Het zou officieel geen bedrog zijn, maar wel een teken van een totaal onbetrouwbaar bedrijf (nogmaals: Ziggo dus als schoolvoorbeeld)

Goede kennis van mij werkt daar inmiddels als interim Head of security en gaf aan dat er toch wel aardig aan schort qua procedures en beveiliging dus verbaasd me niets.

Nu minder goede kennis van je, zal die niet waarderen dat je dit hier zo neerplempt met zijn functie en dit commentaar

Wat op zich niet zo erg is, want een head of security die zoiets vertelt aan een goede kennis hoort er misschien niet te werken. Hij helpt dus juist met het oplossen van het probleem!

mooi al die boetes maar waar gaat het geld heen?

mooi al die boetes maar waar gaat het geld heen?

Naar de (in dit geval, Britse) schatkist. Zoals alle boetes.

mooiste voorbeeld ever over SQL injectie. Iemand die geflitst was door de politie dacht zo uit de database te ontsnappen.

Ronduit belachelijk dat dat überhaupt niet meer gemonitord wordt. Ik vind de boete dan ook terecht. Als provider heb je veel verantwoordelijkheid, dus dat maakt het nog krankzinniger.

In 2016 nog onderuit gehaald worden door SQL injecties. Boete, kosten en verlies aan klanten totaal verdient. Het liefst nog erger.