Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 58 reacties

Een oude website van de VARA bevatte een sql-injectionlek waardoor toegang tot de database kon worden verkregen. Daardoor konden onder andere 19.000 e-mail- en ip-adressen worden uitgelezen. De website is inmiddels uit de lucht.

VARADe website van Mooi Weer de Leeuw, een VARA-programma dat in 2009 van de buis verdween, bevatte een beveiligingslek. Op de website konden tot vrijdagmiddag door manipulatie van een variabele sql-query's worden uitgevoerd, zo vertelde de ontdekker, een hacker die zichzelf Xcrypt0 noemt, aan Tweakers.net.

In het geval van de VARA-website kon met sql-injection de gehele database van de website worden uitgelezen. Daardoor konden onder andere 19.000 e-mail- en ip-adressen uit de database worden gelezen, die in een tabel van een gastenboek waren opgeslagen. Erik Leenders, webmaster bij de VARA, bevestigt dat de website kwetsbaar was en bestempelt het feit dat persoonsgegevens konden worden uitgelezen als 'kwalijk'. "Deze site had een vrij oud content management systeem", zegt Leenders. Het cms zou niet voor andere VARA-sites worden toegepast; daarvoor wordt nu TYPO3 gebruikt.

Volgens Xcrypt0 was het ook mogelijk om database-records aan te passen, al zegt hij dat zelf niet te hebben gedaan. Volgens hem heeft de VARA niet gereageerd op zijn e-mails, waarin hij waarschuwde voor het lek. Daarop mailde hij Tweakers.net over het lek. Nadat Tweakers.net contact met de VARA had opgenomen, werd de website binnen drie kwartier offline gehaald. De website komt ook niet meer online, aldus Leenders.

Moderatie-faq Wijzig weergave

Reacties (58)

Al zo vaak de beheerderes van de websites van de publieke omroep erop gewezen dat hun beveiliging rammelt,....naast layout/probleemloos werken van pagina's,linkjes etc gemaild,maar zoals zovaak ofwel geen antwoord of een totaal onbevredigend tot uitgekafferd wordend antwoord.Dus daar maar mee gestopt.

Vorig jaar bijvoorbeeld kon ik zo zowat alle aflevering van KRO detectives van de server downloaden,ten minste als het scriptje om de nieuwe aflevering te uploaden geen schrijffout had.Ook dit ff oplossen was te veel gevraagd.
ook weken nadien waren de aflevering te downloaden,terwijl ze maar 2 dagen online waren,
En dan zoek ik dus nieteens bewust naar lekken of fouten.
D'r zullen vast wel meer tweakers zijn die hierdoor dingen kunnen doen,wa niet de bedoeling is.

Krijg meer en meer de indruk,dat het enige wat goed gaat ,het factureren is voor het (wan)beheer en ontwerp.

Geld wel voor meer websites vandaag de dag,waar invoegen van allerhande fratsen, moderne functies, boven een correct werkende site gaat,met soms als resultaat een onwerkbare en/of trage site,menus die niet te selecteren zijn etc etc etc.
Twitter/facebook plugins,die ongevraagd omhoog komen schieten als je wat selecteert.

[Reactie gewijzigd door Akino op 15 juli 2011 18:41]

Hoe simpel is het tegenwoordig om een website (!!!zelfs dmv van IPS op een firewall!!!) te beveiligen tegen SQL injection.
Kom op zeg, wat een achterhaalde beveiliging houdt de vara er dan op na.
Het is inderdaad niet lastig om "basis" injecties tegen te gaan, maar hoeveel sites draaien er tegenwoordig nog op verouderde code waar dit nog niet is toegepast?

Het bedrijf waar ik werk is tegenwoordig erg strikt wat betreft dit soort beveiligingen, maar dat is niet altijd zo geweest. Vandaar dat er nog steeds oude sites draaien waar het heel gemakkelijk is om in de database te komen. Er draaien zelfs nog sites met PHP3 scripts :s

En hoewel het correct configureren van een firewall veel zal helpen, heeft een PHP Developer hier meestal geen kaas van gegeten.

Het grootste probleem is gewoon dat er geen tijd is om oudere sites bij te houden (wanneer je er 100+ in beheer hebt) met de laatste technieken, en zo dus ook bij de VARA.


Het feit dat de technici van de VARA geen gehoor geven aan een melding is wel kwalijk, al vraag ik me af hoe Xcrypt0 dit heeft gedaan (gezien het Duinrel gebeuren).
Als grote organisatie kun je je natuurlijk wel jezelf een goede firewall veroorloven die een hope van dit soort aanvallen kan tegengaan.

De vraag is, waarom wordt dat niet gedaan? Te duur, te ingewikkelde, te laks?
je kunt natuurlijk wel 100 websites in je beheer hebben, maar dat is dus wel een goede reden voor een goede firewall, en dat mag natuurlijk wel wat kosten.
Sql injectie hou je volgens mijn niet tegen met firewall, poort moet immers open zijn voor internet verkeer.
Een goede firewall doet wel wat meer dan poortje open/dicht :)
Een mailtje dat per ongeluk bij de verkeerde mensen terechtkomt of dat het even duurt voordat het terechtkomt bij de goede mensen die begrijpen van "hee, foute boel dat!" is op zich niet ongebruikelijk - ik neem aan dat tweakers gewoon gebeld heeft ipv gemaild en dat zij een ingang hebben via bijv de persvoorlichter oid.
ik neem aan dat hij het naar iets als webmaster@<varasite>.nl oid gestuurd heeft. Een beetje bedrijf redirect dat natuurlijk naar de juiste personen...
@ hierboven inderdaad!

Nu heb ik wel reeds contact met de webmaster. En dat gaat ook heel erg beleefd. Het is trouwens niet mijn intentie om schade aan te richten. Anders had ik toch gewoon die database op internet gezet?

Ik ben hier volledig ethisch verantwoord tewerk gegaan, toch vind ik het wat jammer dat mensen hier me dan meteen massaal de grond inboren. Niemand heeft hier schade geleden!
@ hierboven inderdaad!

Nu heb ik wel reeds contact met de webmaster. En dat gaat ook heel erg beleefd. Het is trouwens niet mijn intentie om schade aan te richten. Anders had ik toch gewoon die database op internet gezet?

Ik ben hier volledig ethisch verantwoord tewerk gegaan, toch vind ik het wat jammer dat mensen hier me dan meteen massaal de grond inboren. Niemand heeft hier schade geleden!
Respect.

Zou je ons eens willen vertellen hoe je dit lek kon vinden? Ben je op zoek naar dit soort dingen?
Daar hebben we o.a. google voor zoek maar eens op; Warning: mysql_result(): en check of de url ?=IETS bevat...

Bv als ze PDO gebruiken dan gooit PDO je username/wachtwoord combi op straat indien je dit niet goed afvangt.

Kijk eens hier;
http://webcache.googleuse...l=nl&source=www.google.nl

of hier;

http://webcache.googleuse...l=nl&source=www.google.nl

en zo kan ik eindeloos doorgaan....
Wat ik mij als Oracle ontwikkelaar al tijden afvraag is waarom toch niet simpelweg een 'read only' user wordt gebruikt voor toegang via de website.

Ik bedoel zoiets als dit:
grant select on table xyz to readonly_user;

De readonly user kan dan nooit en te nimmer data muteren of andere tabellen raadplegen. Een andere optie is om slim met views te werken.
Een andere opties is om je gewoon je mysql data te filteren, voordat het in een query beland. Dat is toch een doodnormale gewoonte als programmeur?
"where a="+a+" and b="+b leest toch makkelijker dan "where a=% and b=%", a, b ? :)
En SQL queries zijn toch gewoon tekst-regels. Database structuren werd ook op school als apart vak gegeven. Programmeren was iets totaal anders. Dat zal tegenwoordig wel wat meer gecombineerd zijn.
Ik kreeg vorig jaar op school een vak "SQL" en dit jaar gebruikten we databases in .NET en Java. Het verwonderde mij dat we databases leerden gebruiken op een volledig onveilige en foute manier. Ik heb de docent daar dan ook op gewezen, heb hem zelfs aangetoond dat ik zijn tabellen kon aanpassen via SQL injections. Toch hebben we geen enkele keer met parameter binding gewerkt.
Ik kreeg SQL netjes als een los vak, maar zelfs daar werd er gehamerd op "veilig programmeren", onafhankelijk van de taal waarmee je werkte.

Maar aan de andere kant; koop een gemiddeld boek over PHP en je zult erachter komen dat het beveiligen van de database ver te zoeken is.
Wat helpt je readonly gebruiker als je op een pagina een subset van data ophaalt maar je vergeet data te escapen/parametrized queries te gebruiken/etc waardoor je gebruiker ' OR 1=1' in je where statement weet te prutsen?
Niets, maar daar is dan weer parameter binding voor bedacht.
Jammer dat er eerst publiciteit moet worden gezocht voordat er actie wordt ondernomen...
Ja, dat vind ik nou ook. Op mails word niet gereageerd. Hoe slecht is dat...?
Ja, dat vind ik nou ook. Op mails word niet gereageerd. Hoe slecht is dat...?
Ach zal wel over waaien... Zo denken ze..
Het lek is natuurlijk niet gedicht, als de website offline is gehaald. Maar het probleem is daarmee wel opgelost.

Ik moet zeggen, dat het erop lijkt, dat deze hacker redelijk ethisch heeft gehandeld, ervan uitgaande, dat hij de gegevens niet gaat publiceren.
of je webapp nou veilig in elkaar zit of niet,
in principe kan je dit afvangen met iets als apache mod_security.

dit moet uiteraard geen vrijbrief zijn om onveilig te gaan coden maar dit extra security laagje had deze hack waarschijnlijk wel voorkomen.
Post hierboven? Wat een onzin...


Ik heb na mijn duinrell foutje inderdaad ingezien dat ik een meer ethische werkwijze moest gaan hanteren...

Deze heb ik dan ook hier toegepast.
Vara heeft niet geantwoord op mijn mails.

Doch heb ik niets laten lekken etc, ik heb iemand van de tweakers redactie gecontacteerd die vara wel zover heeft gekregen het lek te dichten.

Hier is niets onethisch aan? Er is niets naar buiten gegaan van info, ik heb ook geen schade gedaan. En heb vara zelf gecontacteerd alvorens tweakers te contacteren.

Groetjes
Het feit dat je ergens probeert binnen te komen en dat durft te combineren met 'meer ethisch'.. ironisch.
Het is ethisch dat mensen als Xcrypt0 een probleem vinden en mensen op de hoogte stellen. Er is niets ironisch aan!
"Wees verschillig"
Waarvoor dank, bel je ons nog voor het tshirt?
Zelf vind het top van Xcrypt0 dat hij de problemen meld

voor dit soort hackers, niks anders dan respect.
Natuurlijk iemand kan een beveiligingslek over het hoofd zien
(al zijn SQL injecties natuurlijk wel een groot iets om over het hoofd te zien)

Als je daar dan op gewezen word hoor je die persoon daar tenminste voor te bedanken
Zelf een tijd terug veel met TOPdesk gewerkt, hoeveel organisaties wel niet de
admin account vergeten aan te passen.

5 organisaties getest, 4 binnen gekomen, alle 4 een mail gestuurd
2x een antwoord gehad van de Directeur dat het probleem ondertussen
verholpen was. en daarbij vriendelijk bedankt voor het melden

Top voor het melden Xcrypt0 en pim en natuurlijk de rest die het ook meld:D
Hee!

Bekend van: http://tweakers.net/nieuw...uinrell-klanten-buit.html
Vraag me af of er hier eerst ook content is aangepast, voor het publiceren van het lek.

[Reactie gewijzigd door Vokx op 15 juli 2011 16:28]

Inderdaad. Was hij ook niet diegenen die allemaal kloontjes op deze site had geregistreerd om zichzelf de hemel in te prijzen in de comments?
Xcrypt0 aka AMN3SYS aka 0fftime?
Hij/ze zullen straks wel opduiken, I presume.
Klopt, die hadden hele conversaties met elkaar zichzelf.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True