'Omroep Llink laat ledenbestand uitlekken'

De inmiddels opgeheven omroep Llink heeft persoonsgegevens van zijn ex-leden laten uitlekken. Onder andere wachtwoorden, naw-gegevens en gedoneerde bedragen zijn zichtbaar. Hackers konden de gegevens via sql-injection krijgen.

Het is onduidelijk wie de gegevens van de oud-Llink-leden heeft weten te ontfutselen, maar weblog GeenStijl berichtte als eerste over het beveiligingsprobleem. Door sql-injectie toe te passen, waarbij een database dankzij het slecht filteren van user-input om de tuin kan worden geleid, konden de gegevens van Llink-leden worden verkregen.

Onder andere naw-gegevens, bankrekeningnummers, wachtwoorden, ip-adressen en e-mailadressen waren zichtbaar. Om hoeveel leden het gaat, is onduidelijk; het bericht van GeenStijl impliceert dat de gegevens van alle leden zijn uitgelekt, maar dat wordt niet met zoveel woorden aangegeven. Inmiddels is de website van Llink offline.

Het is onduidelijk waarom de database met ledengegevens nog toegankelijk was; omroep Llink is in augustus vorig jaar opgeheven. Het in de lucht houden van de database was daarmee niet alleen onnodig, maar mogelijk ook onwettig, zoals GeenStijl aangeeft. Volgens de Wet bescherming persoonsgegevens mogen persoonsgegevens niet langer worden bewaard dan noodzakelijk.

Reacties (92)

[donny007]

Deze hackers pakken het wel een stuk netter aan dan 'LulzSec' of die skiddie van de Duinrell website. Deze hackers kaarten het probleem aan, zonder de database ongecensureerd op internet te gooien of een website te defacen.

Het is natuurlijk jammer dat SQL injectie weer mogelijk is, het is een van de meest bekende manieren om een database te dumpen.... input valideren (en vreemde tekens escapen) is een vereiste, geen bonus!

[Reactie gewijzigd door donny007 op 25 juli 2024 03:04]

[Verwijderd]

Inderdaad, zie lek Llink weldegelijk gemeldt

[Verwijderd]

Dat gaat lekker met de hackers. Ik vond het niet erg toen de hackers tegen Sony terug vochten voor hun rechten, maar dit gaat bij mij wel te ver. Waarschijnlijk vinden de hackers het leuk om gegevens van grote en kleine bedrijven te achterhalen. Schandalig, dit kan gewoon niet. Ik hoop dat die hacker achter de tralie zal gaan staan. Sql injection is toch bijna niet meer mogelijk toch? Hoe kunnen hackers nog steeds Sql injection gebruiken? Hebben de programmeurs alleen maar aan de neus gepeuterd dan?

[Reactie gewijzigd door Verwijderd op 25 juli 2024 03:04]

[RagingR2]

Dat gaat lekker met de hackers. Ik vond het niet erg toen de hackers tegen Sony terug vochten voor hun rechten, maar dit gaat bij mij wel te ver.

Jij vond dat niet erg?? Ik vind het als Playstation gebruiker wel erg.

Dat gezeur maar steeds over "terug moeten vechten tegen het grote boze Sony". Dat dat bij het hacken van Sony de reden was (en niet gewoon ordinaire criminelen op zoek naar geld) is volgens mij pure speculatie, daar is toch helemaal geen bewijs voor?

Maar afgezien daarvan is er nog wel een verschil tussen een Tweaker en een hacker (en ook binnen hackers is nog verschil).

Voor het Tweaken kan ik begrip opbrengen (wat doe ik hier anders??); ik vind ook principieel dat je met een apparaat wat je gekocht hebt moet mogen doen wat jij zelf wil. En als dat geblockt wordt, dan mag je van mij met vreedzaam protest terugvechten. Het is niet alsof Sony een wet overtreedt ofzo; je kan het niet eens zijn met hun beleid en dat mag je dan ook (luidkeels) laten weten, maar meer ook niet. Maar niet door de privacygevoelige gegevens van 70 miljoen mensen te jatten, waardoor al die onschuldige mensen de dupe zijn. Dat is heel iets anders dan Tweaken, dat is hacken.

En ook binnen "hacken" is er nog verschil. Een "goede" hacker, hackt een bedrijf om een lek aan te tonen, en doet dat zonder zinloze schade aan te richten en meldt dit daarna ter info bij het bedrijf zo van "Kijk, ik kon jou hacken, misschien moet je je beveiliging verbeteren?" Dat is heel iets anders dan hacken om je ongenoegen met een beleid te laten weten, of erger nog, hacken om privacygevoelige gegevens te bemachtigen zoals namen/adressen/credit cardnummers (credit cardnummers schijnt niet gelukt te zijn, maar dat terzijde). Dat is geen hacken meer zoals ik hierboven bedoel, dat is gewoon criminaliteit; grootschalige diefstal.

Laten we ons als Tweakers er in godsnaam niet voor lenen om voor dat soort mensen sympathie te gaan tonen...

[Reactie gewijzigd door RagingR2 op 25 juli 2024 03:04]

[kimborntobewild]

Het is niet alsof Sony een wet overtreedt ofzo

Ahem, jawel. OtherOS kunnen draaien was een verkoopargument. Om dat dan vervolgens na verkoop via firmwareupdates weer uit te schakelen op afstand, is onwettig. MAAR... In de praktijk gaat het zo: de wetten (naderhand) worden d.m.v. lobbyin van het bedrijfsleven gewoon in hun voordeel omgebogen ten nadele van de consument. Vervolgens is er na een paar jaar geen haan die er meer naar kraait: men laat het gelaten over zich heen komen.

[Reactie gewijzigd door kimborntobewild op 25 juli 2024 03:04]

[Verwijderd]

http://www.bredavandaag.n...ns-leden-bij-omroep-llink

Deze person heeft dus duidelijk het lek gemeldt, en NIET de privé-gegevens openbaar gemaakt voor iedereen.

Ik zeg KLOKKENLUIDER!

[Stoffel]

Misschien heeft het wel tot gevolg dat bedrijven eens wat meer aandacht gaan besteden aan de beveiliging van hun gegevens. SQL injection voorkomen is nu ook weer niet zo enorm lastig, ik vind dat iedereen die professioneel webapplicaties ontwikkelt die kennis behoort te hebben.

[xp7amrkr]

Ik ben zelf niet zo op de hoogte van internetbeveiliging, dus weet niet in hoeverre het technisch makkelijk of mogelijk is om dit soort bestanden 'veilig' af te schermen. Maar het lijkt wel alsof het gros van de websites qua beveiliging zeer ondermaats is. De laatste tijd zijn er een hoop gegevens achterhaald bij websites waar je toch van mag aannemen dat deze niet op een zolderkamer gemaakt en gehost wordt.

Ik denk toch dat dit te danken is aan een groot scala aan 'amateur' programmeurs die voor bedrijven als deze ingehuurd worden. Iedereen kan leren programmeren in het huidige tijdperk, en de goedkoopste zal vaak een website of database in elkaar mogen draaien. Misschien wordt het tijd om toch echt strenger naar de beveiliging te kijken, certificaten uit te delen of zelfs de programmeur te 'certificeren' op zijn kunnen.

[Mentalist]

Ik ben zelf niet zo op de hoogte van internetbeveiliging, dus weet niet in hoeverre het technisch makkelijk of mogelijk is om dit soort bestanden 'veilig' af te schermen.

Da's vrij eenvoudig uit te leggen. Dit is onveilig:

$usertroep = $_GET["tralala"];
mysql_query("INSERT INTO LedenbestandFBI (Voornaam, Achternaam, Usertroep)
VALUES ('Jopie', 'de Hackert', '$usertroep')");

Zo kan je gewoon je eigen query achter de URL zetten als:

www.zooi.com/formulier.php?tralala=dit is usertroep. Hier komt mijn eigen query: ' OR 1=1; DROP DATABASE LedenbestandFBI ('

Dan krijg je dit:

mysql_query("INSERT INTO LedenbestandFBI (Voornaam, Achternaam, Usertroep)
VALUES ('Jopie', 'de Hackert', 'dit is usertroep. Hier komt mijn eigen query: ' OR 1=1; DROP DATABASE LedenbestandFBI ('')");

Dit voorbeeld zal wel niet werken wegens wat verkeerd geplaatste tekens maar dit is wel het principe. Drop database is over het algemeen wel ongewenst.

En één extra woordje had deze hele hack kunnen voorkomen:

$usertroep = addslashes($_GET["tralala"]);
mysql_query("INSERT INTO LedenbestandFBI (Voornaam, Achternaam, Usertroep)
VALUES ('Jopie', 'de Hackert', '$usertroep')");

Let op de addslashes. Hierdoor zullen bijvoorbeeld CD's veranderen in CD\'s.

Natuurlijk zijn er meer dingen waar je op moet letten bij user input, b.v. lengte (om te voorkomen dat iemand 80MB bagger als voornaam neemt) en htmlspecialchars (als de content op een webpagina zichtbaar gemaakt zal worden). Maar het vergeten van addslashes is de reden dat er sql-injection bestaat.

Helaas zijn veel webbouwers te lui, slordig en/of onkundig om consequent die functie te gebruiken voor zooi die in een query gebruikt moet worden.

[Reactie gewijzigd door Mentalist op 25 juli 2024 03:04]

[poepkop]

Goed voorbeeld, maar in de screenshots zie ik een soort database programma waardoor het lijkt alsof hij zelfs de inloggegevens van de database heeft gekregen...

Webbouwers zou ik trouwens niet zo maar lui willen noemen, zolang er bedrijven zijn die in een pitch een redelijk flinke website durven aan te bieden voor 1500 euro, kan je je afvragen of dat zozeer aan de webbouwers ligt dat zij niet toe komen aan een simpele check op de beveiliging.
En met het dramatische niveau van de scholing op dit gebied komt het zelfs voor dat ik mensen zie die nog nooit van addslashes() of mysql_real_escape_string() gehoord hebben

[Mellow Jack]

Mjah persoonlijk vind ik dat dit door de directeuren en account managers van de ontwikkelaars komt. Ik ben bij een aantal van dat type vergaderingen geweest en het is vaak niets meer dan de ene directeur die de andere overtuigd terwijl het technische aspect achterwege blijft. Dit resulteert vaak in een product waar je de veiligheid ed niet kan garanderen.

Als dit soort zaken geregeld worden door een echte IT manager heb je dat probleem niet want die managers weten tenminste waar ze op technisch gebied rekening mee moeten houden

[fommes]

Het lijkt me toch ook wel fijn dat de programmeurs rekening houden met een basis behoefte aan beveiliging? Of moet het volgens jou iedere keer voorgekauwd worden dat :

- passwords niet plaintext opgeslagen moeten worden
- er een bepaalde mate van filtering moet zijn op (alle) userinput

[Mellow Jack]

Ik probeerde de rol van de directie te benadrukken maar blijkbaar heb ik dat niet voldoende gedaan. Wat kan een programmeur doen aan de beveiliging als zijn directeur zijn planning vol stopt met opdrachten? Ik heb redelijk wat programmeurs gesproken en een groot deel van die personen klagen elke keer weer over het feit dat de directie beloften doen die niet gemakkelijk te behalen zijn waardoor ze meer tijd bezig zijn met onbenullige opdrachtjes om de directie te "pleasen" dan dat ze tijd kunnen besteden aan het goed maken van het product. Natuurlijk weet de programmeur van het probleem en hij meldt dit vaak ook aan zijn leidinggevende maar dat heeft geen nut wanneer de directie een slechte kijk heeft op de zaak.

Daarom benadruk ik ook dat dit soort zaken door echte IT managers geregeld moet worden omdat zei weten wat de haken en ogen zijn aan het platform/systeem.

Als voorbeeld heb ik een keer een site op maat laten bouwen (koppeling met ERP systemen ed) en bij de initiele afspraak heb ik gevraagd wat zei doen om de beveiliging te waarborgen... Toen kreeg ik een hele lap aan termen naar mijn hoofd gegooid waardoor ik het gevoel kreeg dat ze echt hun best hebben gedaan. Toen wij een voorbeeld hebben gekregen (wij gingen pas betalen na de eerste opzet) en ik een simpele tool erop los liet had ik binnen no-time de gebruikersnamen en wachtwoorden. Ik ben geen hacker en heb wel kennis over SQL ed maar niet genoeg om hier misbruik van te maken. Ik heb deze opdracht dus ook niet getekend en ben zaken gaan doen met een bedrijf waar het management wel genoeg IT kennis heeft en zei mij exact konden laten zien wat zei qua beveiliging doen

[tERRiON]

Degradeer je hiermee "de programmeur" tot een veredelde typegeit?

Vooral zoiets elementairs als versleutelde wachtwoorden of preventie tegen SQL-injectie is in een paar regels code gerealiseerd. Waar is dan dat stukje verantwoordelijkheidsgevoel van de programmeur in jouw verhaal? Ik kan me niet voorstellen dat een zichzelf respecterend programmeur dit maar niet implementert omdat de directeur anders zijn deadline niet haalt.

Dit riekt eerder naar onkunde. Dit zijn nou typisch van die dingen die je vanaf de eerste regel code wilt implementeren want achteraf alsnog inbouwen levert altijd problemen op. Als het geen technische problemen zijn (kunnen mensen 100% zeker inloggen als het wachtwoord van plain text naar een versleuteld wachtwoord wordt geconverteerd?) dan zijn het wel financiele (wie draait op voor kosten van de aanpassing en het testen, klant of leverancier?)

Dit soort elementaire zaken zouden voor een programmeur zó standaard moeten zijn dat ie (bij wijze van spreken) niet eens weet dat de koppeling ook werkt zonder deze extra regels code.

Het is een beetje als een automonteur die als vanzelfsprekendheid een band oppompt nadat deze op de velg gemonteerd is: het is voor het laten rijden van een auto niet strikt noodzakelijk om de band op te pompen maar je krijgt onherroepelijk gezeik als je het niet doet.

[Reactie gewijzigd door tERRiON op 25 juli 2024 03:04]

[Sjnirk]

Dit is allemaal al lang mogelijk. Je kunt je website laten beoordelen, je kunt als programmeur makkelijk een cursus Ethical Hacker of Security Analist volgen, zoals EC-Council (stellen niet heel veel voor, weet ik uit ervaring)

Het punt zit hem er in dat men in business cases (als die al worden gebruikt) niet de verschillende risico's rondom veiligheid weet te kwantificeren (en niet alles op 1 hoop gooien), waardoor het voor een niet technisch iemand enorm lastig is om te beoordelen waar hij wel of niet voor wil betalen.

Bij dit soort clubs is het meer regel dan uitzondering namelijk dat een niet technisch iemand de knopen doorhakt op IT gebied.

[Reactie gewijzigd door Sjnirk op 25 juli 2024 03:04]

[gerbennn]

Los van het niveau van de beveiliging vindt ik het vooral heel kwalijk dat er zo makkelijk gedacht wordt over de WBP. Deze database had helemaal niet meer mogen bestaan volgens de wet.

[Verwijderd]

Je moet de eenzijdige uitleg van Geenstijl over wetgeving altijd met een korreltje zout nemen.
Organisaties als KPN mogen hun klant contacten ook tot een jaar na opzegging bewaren en zelfs opnieuw benaderen.
Mogelijk mag LLink dat ook als je bijvoorbeeld een doorstart overwegen of als ze hun idealistische activiteiten op een andere manier willen gaan voortzetten.

[Dikkedikkie]

met bovenstaande reactie van Xonar ben ik het zeker eens. Wel vindt ik het dan weer erg knullig dat de database nog steeds online stond. Ook heb ik het idee dat de beveiliging bij veel bedrijven toch echt tekort schiet en dat terwijl er zoveel gevoelige informatie in kan staan.

[poepkop]

Och, ik kan nog steeds in de ftp van een paar hosting accounts die ik 8 jaar terug bij space1 had... Ik kijk er niet van op dat zo'n database nog jaren kan rondslingeren. Die organisaties hebben helemaal geen weet van wat er nou eigenlijk allemaal op het internet staat opgeslagen, en aan deze rare nederlandstalig gestructureerde database zou het me niks verbazen als de programmeur ook slechts een zolderkamer piloot is.

[Reactie gewijzigd door poepkop op 25 juli 2024 03:04]

[stuffer]

Of je bedoelt het aantonen van een lekke site met DB? Zonder deze lui zouden er minder mensen op hun hoede zijn om op een juiste manier met de gegevens om te gaan zoals het bedoelt is.

[i-chat]

aan je hak-op-tak reactie heb ik het idee dat je vooral eerst bent gaan typen en toen bent gaan nadenken...

de eerste reactie is namelijk altijd - oh help die vieze vuile hackers...

gelukkig lijk je aan het einde van je betoog toch meer inzicht te krijgen, immers, wat voor een prutser moet er bezig zijn geweest als iets achterhaalds als sql-injection mogelijk is op een leden-database... - en waarom was die data nog online ... had het een doel????

nu kun je zeggen, dat sql-injecties een soort van hacken is, en dus eigenlijk niet mag...

maar nu vraag ik me af, wat heb jij liever, een hacker of iemand die willens en wetens slecht omgaat met de veiligheid van anderen (bijv een busschaufeur die altijd door rood rijd). - of top ambtenaar die een koffertje met jouw gegevens zomaar in het park laat staan...

je kunt moeilijk een nieusgierige voorbijganger kwaad aankijken omdat die wilde weten wat er in het koffertje zit (dat zou jij ook doen waarschijnlijk) - kijk liever de gast aan die zo slordig met jouw gegevens omgaat, en met de gasten die er willens en wetens misbruik van gaan maken. - de meeste an dit soort hackers (dus niet allemaal) zijn gewoon nieuwsgierige voorbijgangers -

[himlims_]

hackers? hihihi

dit is een gratis tool die jij en ik zonder problemen kunnen gebruik op willekeurige websites; http://itsecteam.com/

Kijk maar eens naar de screenshots, is dezelfde tool

[Reactie gewijzigd door himlims_ op 25 juli 2024 03:04]

[DarkKnight]

Himlims doelt daarmee bijv. op deze screenshot:
Klik voor screenshot op de pagina van Havij Advanced SQL Injection
Dus ben ik het wel met hem eens dat het nu niet echt professionele hackers geweest zullen zijn.

[mokkol]

Sorry voor een beetje offtopic maar wil iets vragen over sql injectie in het algemeen.

Waarschijnlijk een domme vraag maar hoe kan je gegevens stelen met sql injectie? Ik snap dat je gegevens kan wijzigen/verwijderen maar stelen snap ik nog niet. Als je een select query maakt dan toont hij toch niet automatisch de results?

Dit snap ik bijvoorbeeld:

' OR 1=1; DROP TABLE users;

Maar dit niet

' OR 1=1; SELECT email FROM users;

Hoe krijgen ze de results te zien?

[Reactie gewijzigd door mokkol op 25 juli 2024 03:04]

[Precision]

Hangt een beetje af van hoe het ontworpen is
als de originele query bijvoorbeeld

'select * from users where user_id =

dan zou je kunnen zeggen:

1' or user_id is not null

Zoals hierboven aangegeven kan je ook een union oid gebruiken en in feite gelijk welke gegevens selecteren zolang je ze maar een alias geeft die de website kent/verwacht. Als de databank onder te veel rechten werkt kan je ook:
use mysql; gebruiken, dus iets als:

USE mysql; UPDATE user SET Password = password('nieuw wachtwoord') WHERE User = 'root';

in plaats van een update kan je nu ook een insert doen. Daarom dat het dus een slecht idee is om een databank onder root te draaien.
Edit: of je hoeft het zelfs zo ver niet te gaan zoeken, je zou ook gewoon het wachtwoord van een admin kunnen veranderen en inloggen via hun admin panel.

[Reactie gewijzigd door Precision op 25 juli 2024 03:04]

[Smilezz]

Bij ' OR 1=1; SELECT email FROM users; komt er toch veel informatie uit de database. Als er ergens een textveld op de pagina is waar een tabel getoond wordt (zoals hier de pricewatch items) kan je de de veldnamen aanpassen zodat de velden overeen komen met de velden die op de pagina staan bijvoorbeeld:

' OR 1=1; SELECT email AS product, password AS prijs FROM users;

Zo wordt de email op de plek van het product gezet en het password op de plek van de prijs.

Je moet hiervoor wel veel gokken hoe deze veldnamen heten natuurlijk.

Misschien een beetje slechte uitleg maar hoop dat het iets duidelijker is nu. Meer info:

http://www.unixwiz.net/techtips/sql-injection.html

[Verwijderd]

select in een select zoals hierboven gaat niet werken eh, ge zult een union selectie moeten maken als je het op bovengenoemde manier zou willen tonen

[Reactie gewijzigd door Verwijderd op 25 juli 2024 03:04]

[Smilezz]

Het verschilt per database en scripttaal of het stacked queries afhandelt maar in sommige gevallen is het wel mogelijk. bij php-mysql niet.

bron: http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/

UNION of UNION ALL kan in dit geval niet omdat de naam van de columns wordt bepaald door het eerste SELECT statement.

[Reactie gewijzigd door Smilezz op 25 juli 2024 03:04]

[Verwijderd]

dat de naam wordt bepaald maakt niks uit, je kunt toch zelf gewoon vanuit een andere tabel selecteren.. en de query afbreken nadat jouw select klaar is. daar heeft de query van de eerste select niks mee van doen

[Smilezz]

Je hebt gelijk, stel dat ik bij de pricewatch hier een zoekopdracht invul dan zal de query bij tweakers er ongeveer zo uit zien:

SELECT productnaam, categorie, prijs FROM producten WHERE productnaam LIKE %'zoekopdracht'%;

Dit kan ik via mijn zoekopdracht veranderen in:

SELECT productnaam, categorie, prijs FROM producten WHERE productname LIKE '%x' OR 1=2 UNION ALL SELECT username, email, password FROM members WHERE 1=1 OR email LIKE 'x%';

nu komt op de pricewatch pagina alle usernames bij de productnaam te staan, het emailadres als categorie en de prijs bij het password (of een hash ervan).

[Verwijderd]

SELECT productnaam, categorie, prijs FROM producten WHERE productname LIKE '-1 UNION ALL SELECT username, email, password FROM members /*

or 1=2 is hier nergens voor nodig als je uitvoer krijgt.

[Smilezz]

met 1=2 zorg ik ervoor dat ik geen producten krijg maar alleen members. Het hoeft niet maar het is wel makkelijker.

[Verwijderd]

die krijg je hoe dan ook niet omdat hij je die like afkapt..

[Smilezz]

Ow ik zie t, het moet AND 1=2 zijn.

[Verwijderd]

dat is niet nodig

[Mellow Jack]

Uuuhm bij MsSQL kan je UNION gewoon gebruiken wanneer je de kolom namen gelijk houd. dus je zou gewoon SELECT naam AS anderenaam kunnen gebruiken in je UNION als ik het goed heb. Ik gebruik eigenlijk geen UNION in MySQL dus dat moet ik eens uitproberen

[Reactie gewijzigd door Mellow Jack op 25 juli 2024 03:04]

[Verwijderd]

dat kan in elke taal, dat is het hele nut achter de union implementatie binnen sql. dat je een verbond/vereniging kunt maken, ofwel een andere tabel selecteren

[Mellow Jack]

een inner query zal ook wel moeten lukken toch?

[Verwijderd]

ja dat ligt aan de plek waarin je kunt injecteren, kan mogelijk zijn ja

[Tazzios]

aan de screenshots te zien zou het een scriptkiddie kunnen zijn die gewoon een programma heeft gebruikt.

Dat was pas ook al het geval, zie alleen het linkje niet bij gerelateerde items.
edit:
gevonden hacker-maakt-mailadressen-80000-duinrell-klanten-buit

daar lijkt het screenshot ook een programma waarbij je kan de aanvalsmethode op kan geven.

[Reactie gewijzigd door Tazzios op 25 juli 2024 03:04]

[Precision]

Afgaand op de grote icons, lijkt het mij eerder iets als navicat te zijn, een gewone client dus.

[Reactie gewijzigd door Precision op 25 juli 2024 03:04]

[bassekeNL]

In geval van de meeste cms-en heb je een veldje in je profiel wat vrij invulbaar is (profielbeschrijving). Daarvoor is alleen een update nodig waarin je de gevraagde data erin gooit.

Ander voorbeeld: gebruik een bestaand jpg bestand. Gebruik dan select into file naar dat bestand. Laad het bestand in en je hebt de data (het is immers je eigen of in ieder geval een toegankelijk bestand). Dit kan beperkt worden in de rechten in mysql/rechten op de directories. De rechten settings laten echter vaak te wensen over.

Behalve een select kun je ook een create user doen in de database of het rootwachtwoord wijzigen (again, voor beide: rechten verkeerd ingesteld). Als je dan op de één of andere manier kunt connecten naar poort 3306 (mysql) heb je ook je data.

Legio manieren.

[Verwijderd]

als je select into/load_file kunt doen ofwel create user is er echt iets mis in hun koppe.
default staat dit ook niet aan, dan zou je zelf die setting aan moeten hebben gezet

[PiepPiep]

Je hoeft niet altijd gelijk results te zien.
where username = 'naam' and password = 'geheim'
maak van je password
geheim' or 'a' = 'a
en dan krijg je
where username = 'naam' and password = 'geheim' or 'a' = 'a'
Als je dan de naam van een admin invult en zo als admin kan inloggen kan je wellicht bij formulieren komen waar je gebruikers kan aanmaken/wijzigen etc.

[Verwijderd]

Hier is een forum gedeelte voor. Zie http://gathering.tweakers.net/

Ik vinmd het overigens ook schandalig, dit omdat Link deze gegevens niet meer hoort te hebben. Zolang de hacker niets met de gegevens doet vind ik het een geslaagde actie.

[Inny]

Een mogelijkheid kan zijn door de gegevens te dumpen naar een file en deze via de webserver weer op te halen.

[Verwijderd]

union select ....???

[BadRespawn]

misleidende titel: "laat uitlekken"

beter van toepassing zou zijn "is gehacked" (of "is gescriptkiddied")

[psyBSD]

Helemaal niet misleidend, die database zou ten tijden van de hack niet meer mogen bestaan. Als Llink zich aan de wet had gehouden was er nu niets geweest om te lekken.

Stel (hier volgt een hypothetisch voorbeeld):

De NL overheid neemt een besluit dat de amerikaanse nucleare-raketten voor het eind van het jaar van Nederlands grondgebied moeten verdwijnen, dat gebeurt niet maar er wordt tegelijkertijd niet meer geinvesteerd in de beveiliging van die depots. In 2013 wordt er een terroristische aanval gepleegd waardoor een van die bommen explodeert. Dan stellen we de overheid ook aansprakelijk, ondanks het feit dat zij de aanslag niet gepleegd hebben. Wanneer zij hun afspraken zouden zijn nagekomen (zoals ze gezegd hebben) was er niets geweest om op te blazen.

In beide gevallen (de tweede hypothetisch) is de betrokken partij op 2 gebieden nalatig geweest. 1) Er is een object aanwezig dat niet mag bestaan. 2) De beveiliging rond dat object wordt genegeerd.

In mijn ogen heeft Llink die database daadwerkelijk 'uit laten lekken'.

[Reactie gewijzigd door psyBSD op 25 juli 2024 03:04]

[Sundog]

Wel misleidend, omdat "laat uitlekken" verwijst naar een actieve rol van (een persoon/personen binnen) Llink door bijvoorbeeld een handeling of besluit. Daar is geen sprake van.
D.w.z. er is geen doelbewuste poging van Llink om deze gegevens beschikbaar te maken voor derden.
Wel kan je inderdaad spreken van grove nalatigheid, maar dat is een andere verhaal.

De titel boven dit artikel wekt daarom zeker de verkeerde indruk. Dat is vergelijkbaar met de titel "Overheid laat nucleair wapen ontploffen" als titel boven je voorbeeld.

Je kan als titel wel zeggen: "Omroep Llink verantwoordelijk voor lekken ledenbestand" .

[Magere Hein]

Dit zal PowNed nou nooit overkomen. Joris pakt dat veel professioneler aan

[Keypunchie]

Alles valt te hacken.

Voor gebruikers is hier ook een belangrijke les:

Waarom het van belang is om verschillende wachtwoorden bij verschillende registraties te hebben. Dat vraagt best wel een investering van een gebruiker en daarom denk ik dat het handig is om een password tool te gebruiken. Binnen Mac OS X wordt door de Keychain je al veel werk uit handen genomen.

Volgende stap is echter dat er eigenlijk ook een default "houdbaarheidsdatum" voor wachtwoorden zou moeten zijn. Standaard 1x per jaar je wachtwoorden moeten wijzigen is nog steeds een hoop gedoe, maar het geeft wel een flink stuk veiligheid. Natuurlijk zullen er mensen zijn die "wachtwoord1" in "wachtwoord2" veranderen, maar dan nog verhoogd het bewustzijn.

Het blijft extreem moeilijk: aan de ene kant gebruiksgemak en beschermen tegen onterecht toegangsverlies, aan de andere kant goeie identiteitscontrole en bescherming van privacy.

Eindconclusie blijft wel dat bij Llink de setup nogal knullig lijkt te zijn. Maar ook daar geldt weer: hacken is illegaal, dus ik hoop dat er wel serieus politie-onderzoek naar komt. Dat gebeurt naar mijn mening toch iets te weinig.

[Reactie gewijzigd door Keypunchie op 25 juli 2024 03:04]

[tweaker2010]

"De inmiddels opgeheven omroep Llink heeft persoonsgegevens van zijn ex-leden laten uitlekken." en dan lees ik verder "Hackers konden de gegevens via sql-injection krijgen."

Dus Llink heeft niets bewust laten uitlekken, ze zijn gewoon gehackt...

[BlackHawkDesign]

Waar, maar toch moet je je afvragen, waarom is die database nooit offline gegaan? Er was 0,0 reden om dat ding online te houden. Door laksheid is hij online gebleven en is dus nu slachtoffer geworden, vaak dat soort dingen gewoon een kwestie van tijd als er geen onderhoud meer gepleegd wordt.

Om nou te zeggen, ze hebben ze hebben het laten uitlekken dat is overdreven, maar het is ze natuurlijk wel kwalijk te nemen dat ze zo met de persoonsgegevens van hun ex-leden omgaan..

[NoMoreMusic]

Misschien moet je/tweakers/de rest van journalist spelend nederland dan eens stoppen alles maar "Hacker" te noemen terwijl we het over dieven, vandalen en andere gespuis hebben.

Daarbij komt nog dat er is niet wordt gezegd wat er mee is gebeurd. Als het alleen maar is om aan te tonen dat het nog steeds mogelijk was bij Llink dan is de term Hacker goed en verdient hij/zij een pluim.

Zo'n zin ook "omroep Llink heeft persoonsgegevens van zijn ex-leden laten uitlekken.". Dit insinueert dat ze het met opzet hebben gedaan, sterker nog dat ze (LLink) in het geniep mensen op de hoogte hebben gebracht en de lijst met leden in handen hebben gegeven aan derden.

[Reactie gewijzigd door NoMoreMusic op 25 juli 2024 03:04]

[mashell]

Een hacker is iemand die computervredebreuk pleegt. Dat is altijd al de betekenis van het woord hacker geweest. Het wordt hier dan ook correct gebruikt. Of de hacker nou nobele, kapitalistische of terroristische doelen heeft doet helemaal niet ter zake.

[NoMoreMusic]

Dat ben ik niet met je eens.

De betekenis die jij aangeeft is er van gemaakt door journalisten, bedrijven en politiek. Vooral omdat bedrijven liever de boel onder het vloerkleed vegen en geld verdienen aan nieuwe (overgenomenn) software dan dat ze de beveiliging up to date brengen en hun klanten van de lekken op de hoogte stellen van de al verkochte software.

Als een hacker dat dan na veel aangeven maar openbaar maakt om producenten op die manier te dwingen de zaken op orde te stellen is alleen maar juist. Wanneer er vervolgens nog steeds niets gebeurd en andere personen met die zelfde kennis wel zaken verichten die voor eigen verijking is dan ligt de schuld bij de makers en beheerders en niet bij een hacker.

Politiek praat de bedrijven na en journalisten vinden het maar lastig om dingen te scheiden en gebruiken gewoon de zelfde term voor alles.

En als dat maar vaak genoeg gebeurd denk jij dat het altijd al zo is geweest. Of misschien wordt ik te oud dat ik dat nog kan herinneren, dat kan natuurlijk ook.

[Reactie gewijzigd door NoMoreMusic op 25 juli 2024 03:04]

[RagingR2]

Een hacker is iemand die computervredebreuk pleegt. Dat is altijd al de betekenis van het woord hacker geweest. Het wordt hier dan ook correct gebruikt. Of de hacker nou nobele, kapitalistische of terroristische doelen heeft doet helemaal niet ter zake.

Ja maar ik sluit me bij Ign0r3Me aan, het kan geen kwaad om het te nuanceren. Je kan alles over één kam scheren maar er is echt wel verschil tussen:
1. Hacken om een lek aan te tonen, zonder verder grote schade aan te richten en dit daarna ter info melden bij het bedrijf zodat ze er wat mee kunnen doen.
2. Hacken om je ongenoegen met een beleid te uitten, en op een manier waardoor 70 miljoen mensen een maand niet meer de volledige functionaliteit van hun apparaat kunnen gebruiken, en er potentieel nog erger de dupe van zijn. (Overigens, dat dit bij het hacken van Sony de reden was is volgens mij pure speculatie, maar dat terzijde.)
of nog erger:
3. Hacken met het specifieke doel om namen en credit card nummers te stellen, of tewel gewoon proffesionele criminaliteit gericht op financieel gewin.

En het is een kleine moeite; nuanceren doe je namelijk door je woordkeuze, of door er een paar simpele dingen aan de formulering toe te voegen. Om met dat soort dingen zorgvuldig om te gaan is toch wel het minste wat je van journalisten / de media mag verwachten.

Je scheert toch ook niet alle geweldsmisdrijven over 1 kam?
Het maakt nogal wat uit of je uit zelfverdediging iemand in zijn gezicht slaat, of dat je met voorbedachte rade iemand vermoord, of dat je schuldig bent aan volkerenmoord.

Overigens vind ik niet persé dat dit nieuwbericht van Tweakers hier echt schuldig aan is hoor; er staat duidelijk genoeg waar het over gaat. Maar niet álle media weten waar ze het over hebben (of ze *willen* dat niet weten).

[Reactie gewijzigd door RagingR2 op 25 juli 2024 03:04]

[rommeke]

De kop suggereert dat Llink actief betrokken was bij het openbaar maken van de gegevens, maar daar komt niks van terug in het artikel. De gegevens zijn dus gewoon gestolen.

[Foamy]

De kop suggereert dat Llink actief betrokken was bij het openbaar maken van de gegevens, maar daar komt niks van terug in het artikel. De gegevens zijn dus gewoon gestolen.

Technisch gezien hebben zij een slecht beveiligde database, onnodig lang in de lucht gehouden. Dus de kop "Omroep Llink laat ledenbestand uitlekken" is imho zeker wel terecht.

[!null]

Er is misschien wel sprake van nalatigheid ja, maar zelfs dan is de titel niet terecht.

Als ik spullen uit m'n huis laat jatten, dan bedoel ik niet dat ik mijn huis slecht beveiligd heb, maar dan bedoel ik dat ik de deur open heb gezet en op vakantie ben gegaan

Het gaat erom of iets doelbewust gedaan is. En zo lijkt het net alsof Llink het doelbewust heeft gedaan en dat is natuurlijk niet zo. Uiteraard zijn er wel fouten gemaakt, dat moge duidelijk zijn.

[Mellow Jack]

ls ik spullen uit m'n huis laat jatten, dan bedoel ik niet dat ik mijn huis slecht beveiligd heb, maar dan bedoel ik dat ik de deur open heb gezet en op vakantie ben gegaan

Geen beveiliging is een slechte beveiliging

[kozue]

Ik lees nergens iets over een slecht beveiligde database. Voor zover ik weet kan de database best flink dichtgetimmerd zijn geweest. Bv door alleen connecties van localhost toe te staan en geen root access. Maar uiteindelijk moet de website er nog steeds bij kunnen, en die was niet op orde.
Je kunt het vergelijken met jouw huis op en top beveiligen, en vervolgens een sleutel geven aan je ouders, waarbij wordt ingebroken en een inbreker dus ook meteen een sleutel van jouw huis heeft. Aangezien je er zelf in moet kunnen met een sleutel, valt er dus niks tegen te doen (afgezien van het slot direct vervangen).

[fdh]

Eigenlijk gaat het bij sql injection niet over het slecht filteren van user-input, maar over een verkeerde programmeer techniek. Hierbij wordt de user input attached aan een sql statement (bv "select * from leden where id = " || <user_input>).
Bij de user input kan men dan een eigen clause zoals "or 0=0" toevoegen (of zelfs een volledig eigen statement) waardoor men veel meer resultaten terugkrijgt.

De oplossing hiervoor is dan niet om de user input te filteren, maar om te werken met prepared statements, waarbij dan een variabele gebruikt wordt.
Hierdoor kunnen er geen extra filter clauses of statements in het prepared statement geplaatst worden.

[!null]

Als je werkt met goede escaped strings is het al voldoende eigenlijk. Natuurlijk is prepared statements een betere opzet, maar wanneer je een input string gewoon goed escaped etc, dan kunnen er ook niet zo maar extra filter clauses of statements toegevoegd worden.

[hackerhater]

Kunnen wel toegevoegd worden, maar ze zullen dan niet werken

[Gadgetdude]

Ik vind het echt schandalig dat er nog steeds wachtwoorden niet versleuteld worden opgeslagen. Het is helemaal niet moeilijk om een hash van te maken. Ik schaam mij diep als medeprogrammeur.

[kimborntobewild]

Ik ben programmeur en ik kan programma's maken . Maar wat een hash is weet ik niet precies. Laat staan dat ik weet hoe zoiets te maken. (Zou ik eerst moeten uitzoeken.) Een databaseje opzetten kan ik best.
Het verschil is dat ik dit van mezelf weet en me er niet mee in zou laten zoiets te programmeren zonder de boel (veiligheidsaspecten) echt goed uit te pluizen. Dit in tegenstelling tot anderen programmeurs die gewoon maar een opdracht aannamen om geld te vangen.
Wat ik dus aan wil geven: er zijn zat programmeurs voor wie 't WEL moeilijk is om een hash te maken - simpelweg omdat ze niet eens weten wat 't is.