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. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 34, views: 12.850 •

De Vereniging van Nederlandse Gemeenten gaat gemeenten voorlopig niet verplichten hun sites aan bepaalde beveiligingseisen te laten voldoen. Afgelopen weekeinde bleken door een beveiligingslek vijftig gemeentesites onveilig.

Volgens de VNG verzorgen naar schatting tientallen bedrijven de webhosting van Nederlandse gemeenten. Met de elektronische dienstverlening loopt dat aantal op tot 'enkele honderden'. De organisatie neemt op korte termijn geen maatregelen om de websites technisch te controleren.

"Onze prioriteit is het informeren van de gemeenten. Donderdag komt deze zaak aan bod in de Tweede Kamer", stelt woordvoerder Gjalt Rameijer tegenover Tweakers.net. Hij sluit echter niet uit dat de VNG later alsnog met richtlijnen komt. Eerder al publiceerde Govcert een checklist voor de beveiliging van webapplicaties, maar een controle hierop wordt niet afgedwongen.

De sites van circa vijftig gemeenten bleken afgelopen weekeinde zo slecht beveiligd, dat ze op last van de VNG offline moesten worden gehaald. Privégegevens van zowel burgers als ambtenaren zouden in het geding zijn geweest. Zo kon naar verluidt sessie-informatie van DigiD worden bekeken, waardoor kwaadwillenden zich als een andere burger konden voordoen. Bovendien konden back-ups van de complete omgeving worden gedownload. Overheidsdiensten Logius en Govcert hebben uit voorzorg een aantal lekke websites voorlopig de toegang tot DigiD-diensten ontzegd.

Een deel van de websites bleek ondergebracht bij Gemeenteweb. Deze organisatie was verantwoordelijk voor de e-dienstverlening voor een aantal getroffen gemeenten, waaronder Drimmelen en Nederlek. De gemeente Nederlek meldt op haar website dat ze 'recent is verhuisd naar een nieuwe leverancier en hostingprovider'.

Een woordvoerder laat tegenover Tweakers.net weten dat de gemeente is overgestapt naar SIMgroep. Dit bedrijf nam 37 gemeentewebsites van Gemeenteweb begin dit jaar over. De organisatie is verantwoordelijk voor het installeren en beheren van e-overheidsproducten. Een deel van de gemeenten was nog bezig met de migratie, toen het lek werd ontdekt. Het restant zou nu inmiddels ook bij SIMgroep zijn ondergebracht. Het voormalige Gemeenteweb staat momenteel bekend onder de naam GW Crossmedia, dat onder andere software voor gemeenten ontwikkelt en aanlevert.

Een bron bij SIMgroep laat weten dat de back-ups van de lekke gemeentewebsites niet bij SIMgroep stonden, maar bij een andere partij. De bron wilde niet vertellen om welke partij het wel gaat. Mogelijk waren de servers nog eigendom van GW Crossmedia, maar die organisatie weigert inhoudelijk te reageren. Wel is zeker dat de onveilige servers op Windows draaiden; SIMgroep zegt alleen te werken met opensource-software.

Reacties (34)

Wat misschien nog ontbreekt in het artikel is dat er geen enkel concreet lek in enigerlei software is benoemd in alle artikelen rondom dit onderwerp.

Mogelijk zit het lek in nog openstaande userlogins van remote beheerstools en heeft de bron van deze artikelen daar nog toegang op.
Of is er een oude niet geschoonde webserver in de verkeerde handen gevallen?

[Reactie gewijzigd door hAl op 10 oktober 2011 17:28]

Dat zou ik nou ook willen weten. In de oorspronkelijke publicatie van geenstijl wordt gesproken van een "verouderde Windows-versie", maar het versienummer dat ze noemen is van Windows Server 2003 met SP2, dat is het laatste service pack. Deze Windows-versie is nog gewoon onder support en dergelijke grote lekken zouden bij een normaal geconfigureerde server niet moeten voorkomen. Zelfs als de systeembeheerder niet regelmatig Windows updates heeft geinstalleerd, zou het nog niet zo simpel moeten zijn.

Wat me bij de screenshots van geenstijl opvalt is dat de afgeplakte url heel kort is, alsof een bewust geinstalleerde beheertool is gebruikt (cq. misbruikt). In echt oude Windows-versies waren dit soort exploits inderdaad schandalig simpel, maar dan kreeg je lange urls zoals deze:
http://www1.example.com/s...ystem32/cmd.exe?/c+copy+c:\winnt\system32\cmd.exe+c:\inetpub\scripts
(bron)
Wat je ziet op die sceenshot is vrijwel 100% zeker een PHP-shell, dit is ťťn rege code die CMD aanstuurt. ;)

De truuck is om ergens een bestand op de machine weg te schrijven met die PHP-code die je vervolgens aanroept. Dit kan zijn door bijv. een onveilige upload functie maar ook door bijv. een fout op de webpagina te generen door een URL+de code op te vragen, uiteraard bestaat deze pagina niet waardoor de webserver een fout door krijgt. Deze fout wordt samen met de gebruikt URL weg geschreven in de fout log. En dat is precies waar je het wilt hebben, want 9 van de 10 keer zijn die standaard bestanden op standaard plaatsen.
Als je dit bestand vervolgens via de webserver aanroept zal hij de aanwezig PHP code uitvoeren en krijg je (afhankelijk van de shell) het scherm te zien wat je in de screenshot ziet !

Enjoy!

[Reactie gewijzigd door herbalx op 10 oktober 2011 21:17]

In apache heb je de mogelijkheid om x-hackbit in te schakelen in combinatie met SSI, server side includes, waarna je een kopie van command.com in de cgi map kunt plaatsen en dan kun je via de domeinnaam + command.com dos opdrachten uitvoeren zonder al te veel trucage. Je moet in dit voorbeeld wel de " .COM " extensie opgeven als zijnde cgi uitvoerbaar bestand.

Het is al weer even geleden maar volgens mij werkte het zo.

Die instellingen kun je aanpassen in httpd.conf geloof ik.

Uiteraard kan deze implementatie ook voor nuttige legitieme doeleinden gebruikt worden maar via het internet toegang bieden tot systeem commando's is niet slim. cgi executables moeten bestand zijn tegen buffer overflow aanvallen, ben daar dus heel voorzichtig mee.
De argumenten die via een url meegegeven kunnen worden moeten goed gefilterd worden.

Misschien is deze methode wat omslachtig. Zoals je echter ziet komt deze achterdeur niet vanzelf open te staan en moet je flink rotzooien in apache voordat het mogelijk wordt.

Maar in dit artikel wordt waarschijnlijk een ISS server benaderd. Ook daar moet je waarschijnlijk een aantal beveiligingen uitschakelen voordat het risicovol wordt.

Let bij het gebruiken van systeem functies ook op de user / gebruiker waaronder het commando draait. Creeer een aparte zeer beperkte gebruiker voor dit soort acties. ISS doet dat automatisch al. Na het installeren van ISS service zijn er een paar nieuwe (weggestopte) gebruikers accounts op je systeem. Die worden zichtbaar met de dos opdracht: net users

[Reactie gewijzigd door E_E_F op 11 oktober 2011 00:00]

Tot er straks belangrijke informatie gaat lekken, en dan gaat men weer kamervragen stellen... ;(
Zonde.. Dit gaat mis, kan je nu wel vertellen.. Ikzelf heb bij een gemeente gewerkt waar het (naar mijn mening) wel goed verliep, maar het blijft gewoon vervelend als je gegevens gelekt worden.
Gemeente is overheid. Alle sites van de ministeries zijn/worden overgebracht naar 1 hoster (als ik heb goed begrepen heb). Waarom gebeurt dit niet met alle overheidssites? Dus ook de lagere?
Dan is het heel makkelijk om 1 huisstijl (is verplicht) te handhaven, aanschafkosten gaan omlaag, 1 CMS, en veel minder administratieve lasten. En de beveiliging is centraal te controleren en beheren.
Behalve dat daar minstens zo veel nadelen aan kleven als voordelen zijn gemeenten niet alleen autonoom (en dat is maar goed ook), maar is hun functie en werkwijze zodanig anders dat dit helemaal niet kosteneffectief en efficiŽnt te verenigen is.

Anders gezegd: je zou weer aan een heel groot, heel duur en volkomen kansloos IT project beginnen. Daar hebben we er al genoeg van.
Dat is de kansloze smoes die altijd gebruikt wordt. Maar je slaat de plank finaal mis. De IT van iedere gemeente kan precies gelijk zijn, want iedere gemeente vervult voor 99.999% dezelfde taken. De 0.001% die daar buiten valt, is wel op een andere manier op te lossen.

Al die gemeentes zitten te zeuren dat ze niet samen kunnen werken omdat ze zo uniek en bijzonder zijn, dat zijn ze helemaal niet, ze zijn allemaal 't zelfde. Die arrogantie is juist wat dit soort beveiligingsproblemen creŽert.
En dit is weer complete onzin wat jij verkoopt. Elke gemeente heeft zo zijn eigen structuur, demografie, problematiek, geloofsachtergrond, politieke achtergrond, geschiedenis enz. Zo kan ik nog wel even doorgaan. Om deze reden is domweg onmogelijk om alles gelijk te trekken. Dit heeft niks met arrogantie te maken. De IT kan gewoon domweg niet gelijk zijn.

Waar je verder nog mee zit zijn de wettelijke aanbestedingsregels en marktwerking. Alles bij ťťn onderbrengen zal nooit kunnen en geoorloofd worden.
demografie, problematiek, geloofsachtergrond, politieke achtergrond, geschiedenis

Hebben geen drol te maken met de basistaken die iedere gemeente dient te verrichten. Alle werkzaamheden van gemeenten zijn uitwisselbaar, omdat iedere gemeente het zelfde werk dient te verrichten. Dat ze met andere klanten te maken hebben, dat klopt, maar dat maakt het werk niet ineens compleet anders en maakt de software/hardware eisen al helemaal niet anders.

Jij bent ťťn van die wereldvreemde figuren die denkt dat politiek, geloof, geschiedenis, of wat dan ook ook maar 'iets met een informatiesysteem te maken heeft. Wat jij loopt te verkondigen, is juist het probleem.
Dat is correct, alle ministeries die opgegaan zijn in rijkoverheid.nl draaien bij 1 hoster.
De beveiliging is naar mijn mening goed (kan op een paar puntjes beter), zolang er geen bug in het CMS zit, zal de gemiddelde hacker er niet inkomen. security updaten worden regelmatig door gevoerd en bij een ernstige lek zelfs binnen enkele dagen.

Dit heeft voornamelijk te maken met de technische project leider, die meer dan genoeg kennis heeft van beveiliging.

Dit neemt niet weg, dat het als nog gehacked kan worden, maar ja, alles is te hacken als je wilt.
Net even 3 gemeenten in Brabant beken en daarvan is er slecht 1 off-line. De rest maakt melding van oude bestanden bij een vorige hoster.
Nog steeds slordig, maar niet persť de fout van de overheid.
Wel een beetje makkelijk scoren op deze manier.
Locaal beleid is toe te juichen, maar voor ICT en beheer van geld is centrale regie toch wel zo kosteneffectief en veilig. Ik noem beheer van geld vanwege de diverse overheden die geld beleggen bij IceSave of in Dexia. Geeft meer risico en verhoging staatsschuld.

Jammer genoeg leiden pogingen tot standaardisatie niet altijd tot succes. Er zijn gezamenlijke aanbestedingen maar als het puntje bij het paaltje komt gaat veel locale overheden toch weer hun eigen weg, en doen niet mee. Misschien moet het eerst goed misgaan?
Het hele gemeente en provinciesysteem is finaal achterhaald en eigenlijk te gek voor woorden. Dat creŽert een dosis overhead die niet te overzien is. Verwijder die volledige laag en dan pas kan er efficiŽnt gehandeld worden. Nu zijn er teveel zinloze mensen bij betrokken die iets teveel te vertellen willen hebben over iets teveel dingen waar ze iets te weinig vanaf weten.
De VNG kan toch ook niets verplichten? Dat is een vereniging, een vergaderclub, maar geen overheidorgaan of regelopsteller.
Dat dacht ik ook, maar is kennelijk onjuist.

Als VNG websites offline kan halen hebben ze dus wel bevoegdheden. Jammer dat het daarbij horende verantwoordelijkheid nemen voorlopig even wordt overgeslagen. Ze wachten zeker liever op een nieuwe rel. Gemiste kans.
VNG kan inderdaad niets verplichten.
Formeel gaat de VNG alleen over de arbeidsvoorwaarden van de gemeenteambtenaren. Voor de rest lullen ze alleen maar mee. De gemeenten zijn gewoon autonoom, tenzij de wet (Den Haag) iets anders voorschrijft.

Ergo: alleen het Rijk kan dit verplichtend aan de gemeenten opleggen. Helaas zal daar dan ook meteen een pot met geld mee moeten komen, vrees ik.
De VNG heeft geen verstand van computers en techniek en ze weten dus niet eens hoe ze veiligheid zouden moeten afdwingen. Eerlijk gezegd is er ook geen makkelijk antwoord. Je kan regels & best-practices opstellen zo veel je wil, zonder competent personeel om het uit te voeren komt het nooit goed. Er zijn nog te veel gemeentes waar ICT niet voldoende aandacht krijgt. Ofwel is er niet voldoende goed opgeleid technisch personeel, ofwel ze zijn ondergeschikt aan een andere afdeling (communicatie!) die vervolgens alle goede adviezen naast zich neer legt.

Een dwaas maakt meer gaten dan tien wijzen kunnen dichten.
Er zijn nog te veel gemeentes waar ICT niet voldoende aandacht krijgt. Ofwel is er niet voldoende goed opgeleid technisch personeel, ofwel ze zijn ondergeschikt aan een andere afdeling (communicatie!) die vervolgens alle goede adviezen naast zich neer legt.
Bij mijn vorige werkgever was dat net zo.
De website was van de afdeling PR. Systeembeheer mocht er niet eens naar kijken (bij wijze van spreken) 8)7
Dat hoeven ze ook niet te kunnen, ze hoeven alleen te zorgen dat het gebeurt. De govcert checklist verplicht stellen lijkt me wel het minste.

Je opmerking over interne ICT is vast waar, maar veel van die sites zijn door externe partijen ontwikkeld en gehost, dus daar zit het hem ook niet in.
Het probleem met extern gehoste diensten is dan weer dat je de kwaliteit maar moeilijk kan controleren. Er is een nijpend tekort aan manieren om IT te controleren. Je kan wel een checklist verplicht stellen maar het heeft pas echt zin als je ook kan controleren. Achteraf concluderen dat niet aan de checlist is voldaan helpt niemand.

Neem bijvoorbeeld de govcert-checklist WebApplicaties. 90% daarvan is niet te controleren zonder een goede programmeur in de broncode te laten duiken. Dat is in vrijwel alle gevallen onhaalbaar voor een klant. Je moet er maar op vertrouwen dat je leverancier het goed doet.
Als je wil weten of je loodgieter goed werk heeft geleverd dan kun je een andere loodgieter vragen om het te controleren. Bij software gaat dat bijna niet zonder de broncode, die je in veel gevallen niet krijgt.

Ik wil dat software-leveranciers verantwoordelijk worden voor de gaten in hun producten zodat ze zich moeten gaan verzekeren tegen schade veroorzaakt door hun product. Net als bij een brandverzekering zullen bedrijven maatregelen gaan nemen om de veiligheid te verbeteren en zo hun verzekering goedkoper te maken.
Als je proces niet controleerbaar veilig is dan betaal je meer voor je verzekering. Op deze manier wordt het (ook) financieel gezien slim om de veiligheid van je product vanaf het begin serieus te nemen, in plaats van pas in actie te komen als het eigenlijk al te laat is.
Er zijn legio bedrijven gespecialiseerd in IT audits, daar kan het niet aan liggen.

Software controleren op fouten heet testen en ook daar zijn honderen bedrijven heel goed in, zonder dat ze ooit de broncode hoeven te zien.

Punt is dat de noodzaak tot controle op beveiliging (zowel van websites als de IT infrastructuur) slechts zelden wordt onderschreven en bij het opstellen van de begroting vaak als eerste kind van de rekening is.

Een tweede punt is dat zwakke plekken ook in onderliggende systemen kunnen liggen en wie is dan verantwoordelijk? Microsoft en andere leveranciers hebben alles vaak in de licensing dichtgetimmerd en wie is er nou eigenlijk verantwoordelijk voor fouten in een protocol? Je moet als organisatie ook maar de middelen en tijd hebben om je CMS te migreren naar een veiliger versie. Om nog maar niet te spreken van de 6 weken of langer die een partij als Getronics of Atos nodig heeft om een patch voor te bereiden of een MSI-tje te bouwen.

Men stapt hier veel te snel over heel veel, heel pragmatische, maar ook politieke problemen waar je in de echte wereld doorheen moet ploeteren om iets ogenschijnlijk eenvoudigs als gedegen beheer te realiseren.
Daarom wil ik dat bedrijven zich moeten verzekeren. Als je iedere maand E10.000 (ik roep maar wat) aan verzekeringskosten moet betalen omdat jij je code niet laat controleren dan zullen de cententellers je snel op de vingers tikken. Een brandverzekering wordt ook onbetaalbaar als jij inspecties van de brandweer weigert.

Verzekeraars zijn ontzettend goed in een prijs koppelen aan een bepaald risico.

Software testen zonder broncode kan wel maar is in mijn ogen toch maar de helft van het verhaal. Ik kan in 1 oogopslag zien dat een bepaalde regel kwetsbaar is voor een SQL-injectie terwijl het met trial-en-error heel lang kan duren. Maar dat probleem is voor de vrije markt, die zoekt wel uit hoe je software veilig krijgt tegen een zo laag mogelijke prijs. Momenteel mag het eigenlijk niks kosten, en dan krijg je ook geen kwaliteit.

[Reactie gewijzigd door CAPSLOCK2000 op 12 oktober 2011 10:32]

Ik onderschat niet hoe lastig het is, maar het is goeddeels op te lossen. Standaarden kan je kopen en controleurs kan je huren, zolang je het zelf niet kunt. Er zijn allerlei tools die kunnen helpen, tot het doorspitten van sourcecode aan toe. Het is geen fundamenteel probleem, het is een probleem van financiŽle prioriteiten.
Bij de VNG werken genoeg mensen die verstand hebben van IT en beveiliging (maar dat zijn niet allemaal ook de beleidsmakers).

Voor de rest heb je helaas gelijk.
Ik had altijd al geroepen dat DigiD zo lek is als een mandje.
Gelukkig hebben ze wel wat verbeteringen aangebracht, maar ik heb nu al weer gaten gevonden in hun server hosting xD
Veiligheid van een gemeente website zou toch niet opgelegd moeten worden, dit zou standaard procedure moeten zijn (vind ik).

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBTablets

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013