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 , , 61 reacties
Bron: Giorgio Maone

In plaats van toespraken van de hoogste baas van de Verenigde Naties waren er korte tijd boodschappen van een hacker tegen IsraŽl en de VS op de VN-website te zien. Hoewel de site is hersteld lijkt het gat nog open te staan.

'Hackers ahead'-bord SQL-ontwikkelaar en universitair docent Giorgio Maone vermoedde al dat er van SQL-injectie gebruik was gemaakt toen hij het verzoek "dont kill children", dus zonder apostrof, op de VN-site zag staan. Inderdaad blijkt de VN-server ten tijde van dit schrijven SQL-fouten te geven wanneer er een apostrof achter een documentaanvraag wordt geplakt, wat er op duidt dat de site vermoedelijk nog net zo kwetsbaar is als voorheen. Maone wijst erop dat SQL-injectie eenvoudig te vermijden is en vraagt zich af waarom een deftige site als die van de VN gevoelig voor is voor zo'n 'genant incident': het voorval haalde de wereldpers.

De kwetsbaarheid treedt op wanneer gebruikersinvoer zonder behoorlijke validatie in een SQL-uitdrukking wordt toegelaten. Door op specifieke plekken apostrofs in de invoer te gebruiken, en deze aan te vullen met andere stukken SQL, kan een aanvaller een heel andere instructie naar de database laten sturen dan wat de developer oorspronkelijk voor ogen had. De VN-sitedevelopers maken weliswaar gebruik van prepared SQL-statements - in het ergste geval propt de programmeur alles in een enkele regel - maar blijkbaar is toch niet goed gecontroleerd of de inputvariabelen aan de juiste eisen voldoen. Het lijkt er op dat het nog slechts een kwestie van tijd is voordat de programmeurs van de VN-website opnieuw aan de slag moeten, ditmaal wellicht om het gat voorgoed te dichten.

VN-site gedefaced
Moderatie-faq Wijzig weergave

Reacties (61)

Volgens het bronartikel:
If only prepared SQL statements were used properly, this embarrassing incident would have been easily prevented.
And yes, prepared statements are available even in the very obsolete ASP “Classic” + ADODB Microsoft setup they’re using.
Dat lees ik alsof er geen prepared SQL statements gebruikt zijn waar het wel had gemoeten, waardoor dit plaats heeft kunnen vinden, in tegenstelling tot wat er in het artikel hier staat.
Als je een prepaired statement maakt door string concatenation in plaats van een statische string met parameters ben je net zo ver van huis. (naast het feit dat je optimalisatie omzeep helpt omdat je dan onnodig en onzetten veel prepaired statements krijgt.)

het zit hem dus in "used properly" en properly is met parameters.

eg.

PreparedStatement findFoo = con.prepareStatement("select foo from foos where bar='"+ value + ""');
database.execute(findFoo);

vs

PreparedStatement findFoo = con.prepareStatement("select foo from foos where bar=:value ");
findFoo.setParameter("value",value);
database.execute(findFoo);
Ik vraag me af wie eigenlijk de ontwikkelaars van die website zijn. Echt professioneel ziet het er al jaren niet uit voor een gerenomeerde internationaal operende organisatie. Veel statische pagina's stammen nog uit 2001 zonder ooit bijgewerkt te zijn. Met de technische zijde van de site is het ook al niet beter gesteld. De zoekfunctie zit vol met fouten.
Het blijft toch wel erg hoe bedrijven met status, en dan nog wel met politieke invloed, vaak een onvolmakte beveiliging hebben. Ik vraag me af hoe het uberhaupt kan dat de programmers er nooit bij stilgestaan hebben op het ogenblik dat sql-injection bekend geraakte (enkele jaren terug ofzo?) dat het ook hun kon treffen...

Het vermijden is echt geen moeilijke job, gewoon even filteren wat men kan ingeven op je site en het is verholpen... Waarom blijven deze bedrijven dan toch altijd maar het slachtoffer(?) van deze aanvallen?
De meeste websites worden gelukkig wel 'veilig' opgeleverd. Alleen dan komt er een manager en die wil dat 'even' die en die functie wordt aangepast. Dat soort aanpassingen wordt vaak veel minder gedocumenteerd en uitgewerkt dan het oorspronkelijke ontwerp. Ook gaat zo'n wijzigen dan vaak over minder schrijven.

Vervolgens wordt de aanpassing getest, maar aan veiligheid wordt dan helaas niet meer gedacht.

Als je hebt hebt over veiligheid denken de meeste alleen maar aan SSL/TLS verbindingen. Omdat de VN site geen persoonlijke gegevens bevat wordt vaak het hoofdstuk security overgeslagen. Over de impact van een artikel wijziging wordt op dat moment niet stil gestaan.

Nu heeft deze hacker de homepage aangepast, maar wat als hij verschillende VN documenten maar kleinschalig had aangepast. Dan had vrijwel niemand de hack opgemerkt. Stel je voor dat de hacker alleen het aantal burger slachtoffers in Irak en Afganistan had aangepast. Heel veel nieuws media nemen berichten van de VN website 1-op-1 over.
Dit vindt ik nou gewoon zielig, dat ze zo'n site gaan hacken
Zielig, ja misschien, maar je kan het ook anders bekijken. Ik geloof dat de hacker in kwestie niet echt iets groots misdaan heeft op de site. Hij heeft het meer aangetoond dat het kon. Voor hetzelfde geld had hij er gewoon vanalle vieze plaatjes/spyware,... opgezet. Dan was het erger geweest...

De programmers hadden er gewoon voor moeten zorgen da dit niet kon. Ik vind het dus meer hun fout. Ik weet dat je niet door een open deur mag lopen, mar in de gevangenis zet men de deuren toch ook niet open...
Dat kon hij waarschijnlijk niet
SQL injection is redelijk simpel, ik zou 't niet eens hacking durven noemen. De < > tekens werden waarschijnlijk gefilterd om omgezet in de HTML entities.

voorbeeld SQL injectie:
Ik type in het zoekveld 'naam' op een site het volgende:
Jansen' OR 'a' = 'a

de SQL string wordt dan:
SELECT * FROM persoon WHERE achternaam = 'Jansen' OR 'a' = 'a'

Omdat "'a' = 'a'" altijd waar is, voldoet nu elk record aan de gestelde voorwaarde.

[Reactie gewijzigd door ? ? op 13 augustus 2007 11:05]

Even ter aanvulling.. Als het wel goed ge-escaped zou zijn worden de zoek string

SELECT * FROM persoon WHERE achternaam = 'Jansen\' OR \'a\' = \'a'

En die query zou normaal gesproken geen resultaten opleveren.. of er moet net iemand met die achternaam zijn :P
't is vooral zielig dat een site van zo een organisatie, met zo een budget, zo een banale fouten bevat...
Je staat er vreemd van te kijken bij hoeveel overheidswebsites dit mogelijk is. Persoonlijk vind ik dat naast dat de hacker ´fout bezig is´, zeker de admin(s) op zoek mogen naar nieuw werk. Dit is toch uitermate slordig om een site zo open te laten staan. Iedereen met een beetje sql kennis kan zoiets uitvoeren.
de admins?
een admin heeft niets met devven te maken, het zijn hier de ontwikkelaars die de fouten gemaakt hebben niet de admins.
Je staat er vreemd van te kijken bij hoeveel overheidswebsites dit mogelijk is.
Met insecure-by-default talen als PHP is daar toch niks vreemds aan?
Ik weet niet welke taal hier achter zit, maar met een beetje goede database functies is zoiets eenvoudig uit te sluiten.
[...]

Met insecure-by-default talen als PHP is daar toch niks vreemds aan?
Ik weet niet welke taal hier achter zit, maar met een beetje goede database functies is zoiets eenvoudig uit te sluiten.
http://www.un.org/apps/news/infocusRel.asp

ASP dus :)

-edit- Verkeerde quote

[Reactie gewijzigd door Kjoe_Ljan op 13 augustus 2007 10:41]

Iedere professionele programmeur had dit makkelijk kunnen voorkomen, zelfs in php...
Klopt, met htmlspecialchars(), intval() (in geval van cijfer), of addslashes() kan je vrijwel alle hacks voorkomen. Dit soort functies pas ik altijd toe en ik zie weinig andere scripters dit standaard invoegen.
intval() kan je idd gebruiken, de andere twee zijn echter alleen nodig om te voorkomen dat je html/javascript kan plaatsen zodat het voor de gebruiker onveilig wordt.

wil je sql injection voorkomen kijk dan even naar deze pagina
http://nl3.php.net/manual...ql-real-escape-string.php
Java kan anders ook onveilig zijn.
Java kan anders ook onveilig zijn.
Je hebt het misschien niet helemaal netjes onderbouwd, maar je kunt in een servlet of jsp inderdaad net zo goed met request.getParameter("var") een apostrofe binnentakelen en deze doorspelen naar je database. Bovendien heeft Java geen standaardfunctie om ellende eruit te halen, dit moet eigenlijk altijd met een reguliere expressie zoals var.replaceAll("[^a-zA-Z ]+","");
Dan is dat onveilige PHP zo gek nog niet met z'n (veilige) standaardfuncties.

[Reactie gewijzigd door tweakerbee op 14 augustus 2007 02:03]

PHP heeft een instelling waarmee je quotes kunt beveiligen met een backslash. Kijk maar eens in het php.ini bestand. Daar kan je dat instellen.

Dit in tegenstelling tot ASP waar je zelf alle input moet filteren.
Hmm ff de addslashes( ); statement vergeten in de code.
Ik sla als ik naar huis loop ook altijd onderweg alle ramen in. Dit doe ik om te kijken of de alarminstallaties overal wel werken. Het is toch banaal dat sommige het niet doen, of zelfs afwezig blijken te zijn. Ik doe zulk goed werk............ of wacht, dit is natuurlijk helemaal anders dan het probleem waar het nu over gaat. Toch?
En jij laat ook de deur openstaan van je auto en je eigen huis in de veronderstelling dat toch niemand even komt kijken? Je moet altijd op zijn minst verwachten dat er iets kan gebeuren met je website, sterker nog doe je dit niet kan dit het gevolg zijn of nog erger. De beveiliging mag minimaal zo hoog zijn dat een idioot niets kan uitrichten, en bij de VN is dit niet eens het geval.
Wat als ze ervan tussen gingen met de persoonlijke gegevens van het complete vn-archief. Of bv opdrachten intern geven zonder dat iemand dit beseft. Nee.. hacken is niet goed maar een site open laten staan is net zo slordig, en zou eigenlijk net zo goed bestraft moeten worden.
Nee.. hacken is niet goed maar een site open laten staan is net zo slordig, en zou eigenlijk net zo goed bestraft moeten worden.

Ik lees dit, en mijn mond zakt open van verbazing.

Een analogie. Een bedrijf koop een slot voor zijn voordeur. Wat blijkt, recentelijk is ontdekt dat dat slot heel makkelijk te kraken is. Nu wordt er ingebroken bij dit bedrijf. En nu zeg jij dat, ok wat de dieven deden is niet netjes maar het bedrijf moet worden bestraft? Ik moet (ook) worden bestraft omdat jij een misdaad begaat ?

Achteraf is het altijd makkelijk praten. Nalatig is het pas als ze wisten van het probleem en er niks aan hebben gedaan.
Als je onderweg naar huis alle ramen inslaat zullen dat in 99% van de gevallen huizen van 'Jan Modaal' zijn. Dat daar geen beveiliging is zelden een probleem.

Het levert ook geen problemen op als het weblog van Jan onbeveiligd is tegen SQL Injection.

Voor een grote organisatie als de VN is het echter wel beschamend.
Waar er regels zijn zullen er altijd mensen zijn die deze proberen te buigen. Deze hacker hackte waarschijnlijk met een doel, niet om de beveiliging van een applicatie te testen maar om een statement te maken en op deze manier heeft zijn actie veel 'exposure-impact'.

Dit soort hacks kan je uitvoeren een op simpele sql-site, verbaast mij dat dit op een site zoals die van de VN mogelijk was. Hier zal toch ergens een programmeur zich diep moeten schamen.
Er zijn genoeg 'hackers' die alleen hacken voor de 'lol'. Ze willen kijken hoe goed sites (in dit geval) beveiligd zijn zonder schade te willen aanbrengen. Deze site van de VN is dus zo slecht beveiligd dat dit zonder veel moeite kan. Grote kans dat deze alleen een melding op de site heeft gezet en verder niks. Nu kunnen ze deze vulnerability dichten, zodat het in de toekomst niet meer mogelijk is. Veel bedrijven dichten zo'n lekken pas na publiciteit, daarvoor heeft het geen prioriteit als je dit kenbaar maakt.
Ik vind het veel zieliger dat zo'n gigantische organisatie zo'n verschrikkelijk lekke site heeft. Dit mag en kan gewoon niet
Inderdaad een SQL inject is zoo 1996 komaan, je kan een volledige database gaan deleten met ťťn regel! Dat er nog programmeurs dit doen!?!
Ach ja, ASP is op zich niet moeilijk en iedere hobbyist kan wel een database aanspreken...
Bedrijven moeten mensen aannemen die de theorie achter web development snappen ipv handige Harry's
Je kan het zielig vinden, maar ik vind het een van de eerlijkste en edelste manieren van hacken. Een veel voorkomend alternatief is een hacker die een zombienetwerk exploiteert. Ook dan zou ik altijd kiezen voor de geengageerde hacker die een statement wil maken.
mwaoh... als je verder niet echt iets stuk maakt... vind ik het wel een legitieme manier van protesteren eigenlijk. Af toe moet je een beetje 'onconventioneel' ergens je mening op kunnen plakken. Dat houdt de boel wakker.
Ik snap niet waarom de databasegebruiker in kwestie schrijfrechten heeft. Ok, we weten niet langs waar de injectie gebeurd is, dus misschien zit ik er compleet naast, maar toch. Er is geen enkele reden om een databasegebruiker UPDATE/DELETE rechten te geven op zulk een pagina. Zo'n dingen reserveer je voor een admin gedeelte. Correcte rechten toekennen is nog veel belangrijker dan strings op te schonen. Maar ja .. oeps. Te laat.
en voor de mensen die willen weten hoe je in asp zoiets tegenhoud
replace(request("statID"),"'","''")
aka vervang ' door '' (dus 2 losse '-tjes
of
replace(request("statID"),"'","")
aka vervang ' door gewoon niks

[Reactie gewijzigd door 7GatesOfHell op 13 augustus 2007 14:04]

Ja, en dan ga je op je bek door null karakters of iemand die \' invoert (wat dus \'' wordt). Als je tips geeft doe het dan goed.

Overigens worden in het artikel volgens mij parametrized queries bedoelt ipv prepared statements, en zijn deze juist _niet_ gebruikt.
Dit is echt een schande voor de web developers van de VN-site.
Waarom noemt iedereen dit toch hacken ?
dit is toch niet meer dan : creatief gebruik maken van de geboden functionalteit ?

verder moet inderdaad de ontwikkelaar zich schamen.
Waarom is dit zielig?

Die hacker heeft wel gelijk(ja dit is een mening).
Dit is een prima plek geweest om zo'n protest te laten luiden.
Vooral omdat het nog de wereldpers gehaald heeft ok.

Kortom, goede actie van die gast.

(aivd, volg je me nu?)

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