'Kwaadwillenden zetten gegevens Belgische werknemers online'

Informatie over de afwezigheid van duizenden Belgische werknemers op het werk is afgelopen week online verschenen, melden Belgische media maandag. De gegevens zouden zijn uitgelekt door een kwetsbaar formulier van controledienst Mensura Absenteïsme.

Door het kwetsbare formulier zouden 'enkele duizenden records' openbaar zijn geworden, zo liet de algemeen directeur van Mensura Absenteïsme weten aan persbureau Belga. Volgens hem gaat het om controle-aanvragen door bedrijven van zieke medewerkers. De directeur benadrukt echter wel dat er geen medische informatie zou zijn gelekt.

De kwetsbaarheid kwam aan het licht door een beveiligingsdeskundige, die daarover schreef op het blog Belsec. Volgens hem was het formulier vatbaar voor sql-injectie, en waren daardoor de gegevens van de medewerkers in een database op te vragen. Achter de aanval zou Rex Mundi zitten. Dat is een groepering die in het verleden ook al verantwoordelijk zou zijn voor diverse hacks.

Rex Mundi eiste naar verluidt geld van Mensura voor het niet online zetten van de gegevens, maar hier ging Mensura niet op in. "Dat werd ons ten zeerste afgeraden door de FCCU, onze advocaten en de raad van bestuur", zegt de directeur tegen de Belgische pers. Mensura heeft het formulier inmiddels offline gehaald en een klacht ingediend bij de Federal Computer Crime Unit.

Reacties (42)

De kwetsbaarheid kwam aan het licht door een beveiligingsdeskundige, die daarover schreef op het blog Belsec. Volgens hem was het formulier vatbaar voor sql-injectie, en waren daardoor de gegevens van de medewerkers in een database op te vragen. Achter de aanval zou Rex Mundi zitten.

Het is toch net 'n beetje anders.
De "hack" en diefstal werd door Rex Mundi vorige week via Twitter bekend gemaakt. Rex Mundi doet dit altijd zo, kijk je eigen berichtgeving er maar op na. Belsec blogde daarover zaterdag en volgt het sindsdien verder op.
Overigens veel erger dan die mogelijkheid tot sql-injectie is dat op die forms je rijksregisternummer wordt gevraagd. Geen idee hoe het in NL zit, maar je RRN kan je niet wijzigen. Ligt dat op straat, wellicht gelinkt aan naw gegevens, dan heb je een groot probleem.
Belsec klaagt terecht aan dat nog veel te veel sites (heel veel overheden, meestal lokale) het RRN vragen (en soms als verplicht veld). Dit zou verboden moeten zijn.

Overigens veel erger dan die mogelijkheid tot sql-injectie is dat op die forms je rijksregisternummer wordt gevraagd. Geen idee hoe het in NL zit, maar je RRN kan je niet wijzigen. Ligt dat op straat, wellicht gelinkt aan naw gegevens, dan heb je een groot probleem.

Beetje hetzelfde als hier in Nederland je BSN (burger service nummer). Maar die is nog leuker; die staat doodleuk op al je belastingaanslagen die per onbeveiligde briefpost in herkenbare blauwe envelopen verstuurd worden.

Hebben ze gelijk de helft van je NAW gegevens erbij. (Belastingdienst; leuker kunnen we het niet maken, wel makkelijker...)

[Reactie gewijzigd door R4gnax op 18 november 2014 00:52]

en die enveloppen gaan nu juist verdwijnen. Maar gelijk heb je, ouderwetse post is tegenwoordig een hoog risico.

Waar ergens kan je nagaan of je in die database zit? (en publiek gemaakt bent)
Vermoedelijk zit rijksregisternummer daar ook in... bij ons in het ziekenhuis is dat het enige wat je nodig hebt om uw wachtwoord te laten resetten... en een nieuw rijksregisternummer aanvragen is niet mogelijk...

Die pastebins zijn al lang offline gehaald.
Van Belsec blog: https://dpaste.de/VXuB

[Reactie gewijzigd door ColdRain op 18 november 2014 10:08]

Werknemer is thuis wegens overlijden van papegaai.

Staat er dus echt

Als je een papegaai al 30 jaar hebt is die gewoon lid van de familie. Goed te begrijpen dus

"Medewerkster heeft aangegeven last van depressie te hebben. Vertrouwelijk voor arts: Moeilijkheden" -> oeps, tot zover vertrouwelijk
"Werknemer is gisteren gezien in Turnhout door de productieverantwoordelijke" -> oeps, betapt
"Vincent heeft nog niet laten weten hoelang hij ziek zal zijn, hij kan dus langer afwezig zijn" -> Vincent weet volgens mij ook al dat hij in mei 2015 naar een begrafenis moet

Blijf er van versteld staan hoeveel grappige records er tussen staan:

"Werkt voor en na met een ijskar. We hebben hem in het weekend zien rondrijden."
"wn is blijkbaar op reis naar Marokko"

Sql injectie mag je tegenwoordig geen hack meer noemen. Dat is gewoon je database open zetten voor jan en alleman.

Natuurlijk ziet jan met de korte achternaam dit niet, maar hacken kan je het echt niet noemen.

Dat is inderdaad geen hack, de volle verantwoordelijkheid ligt bij de maangement die de applicatie absoluut wou uitbesteden naar indie voor het goedkoper te maken, ze trekken zich niets aan van veiligheid.

Voor hacking kan je die mensen alvast niet aanklagen, maar voor die blackmailing....enfin ik vind dat mensura wel had moeten betalen voor de veiligheid van die gegevens te garanderen.
Want dus hadden ze nu eigenlijk een tweede kans om die gegevens toch te beveiligen...

Enfin ze zouden beter een CISSP expert aannemen voor alle lekken te detecteren, want er zullen nog veel meer andere problemen in die software zitten.

Probleem is ook dat de ontwikkeling van software steeds sneller en goedkoper moet en dat komt de kwaliteit niet ten goede

Volgens hem was het formulier vatbaar voor sql-injectie

Waarom! Waarom is dit heden ten dage überhaupt nog mogelijk! En dan zeker bij software die gevoelige persoonsgegevens verwerkt, waar o.a. ook medische gegevens aansluiting bij vinden.

Hopelijk gaat hier blijken dat procedures en certificeringen niet op orde waren. Ik hoop van harte dat in dat geval de personen die op de beveilinging, audits of kwalitieit van de software beknibbeld hebben, gigantisch voor de bijl gaan.

Waarom is een goede vraag...het antwoord zal waarschijnlijk liggen in het feit dat dit soort software jaren geleden al ontwikkeld is en er toen niet genoeg naar beveiliging is gekeken en getest.
Om zulke software (gedeeltelijk) opnieuw te ontwikkelen kost klauwen met geld én tijd. Dat is er vaak niet of wordt niet toegewezen.
"Zolang het goed gaat, is er niets aan de hand..." zal de duurbetaalde en onwetende manager wel gemompeld hebben...

Nou ik heb de leiding over een dev team, maar helaas kom ik dit soort grappen ook (nog steeds!) tegen bij nieuwkomers.. Bij veel developers ontbreekt gewoon het besef dat dit uberhaupt mogelijk is Overigens hoeven die niet meer terug te komen als ik dat zie. Hoe treurig ook, want opleidingen bieden er niet allemaal genoeg aandacht aan

Overigens hoeven die niet meer terug te komen als ik dat zie. Hoe treurig ook, want opleidingen bieden er niet allemaal genoeg aandacht aan.

Gezien het gegeven dat een merendeel organisaties korte termijn winsten stelt boven scholing degelijke product-ontwikkeling denk ik dat je veel van die jongens te kort doet.
Je weet niet wat je niet weet is een belangrijk aspect. Ik verbaas mij er altijd over hoe er altijd mensen zijn die op het hardst roepen dat zij het allemaal beter kunnen.

Input-validatie is moeilijk, en zelfs als hij weet wat hij doet en de input volledig gespecificeerd krijgt kan zelfs een ervaren programmeur nog fouten maken. Als je dan in een team werkt (waarbij meerdere mensen onderdelen van de software maken), of onder druk van een deadline, dan kan een foutje gemakkelijk er tussendoor glippen.

In mijn ogen zijn de eerste verantwoordelijken bij dit soort problemen de managers, wegens onvoldoende scholing, te krappe deadlines en geen geld om goed te testen.

Fouten maken heb ik geen problemen mee hoor zolang je er van leert. Maar als je nu nog met mysql_query werkt in php dan snap je het volgens mij niet helemaal, dan ontbreekt er gewoon wat in de basiskennis.

In ons geval is er genoeg ruimte om te testen, daar gaat het dan ook niet om.. Het gaat erom dat ik bij veel nieuwe mensen zie dat zij geen basiskennis hebben van beveiliging. Daar schieten de scholen echt wat te kort. Het grappig is dan inderdaad dat mensen die het zichzelf vroeger hebben aangeleerd (en dus geen informatica opleiding oid hebben gedaan) een stuk meer en betere kennis hebben

Ach, wij hebben nog steeds developers die MD5 gebruiken, of soms gewoon wachtwoorden in plain text in de DB zetten.
Van Parameterized Queries heeft men nog nooit gehoord, en XSS wordt wel afgevangen door IIS.
We vertrouwen blind op de firewall, ook al is dat al eens mis gegaan.
En als er een keer stored procedures gebruikt worden, dan worden die zo erg misbruikt dat er weer gigantische performance problemen zijn.

Maar toegegeven, bij ons op school werd er bij PHP ook geen aandacht besteed aan SQL Injectie of XSS.
Evenals Object Oriented Programming vonden ze niet nodig.

Imho, de beste programmeurs zijn nog steeds degene die al vanaf jongs af aan ermee bezig zijn en nachten erin zijn doorgewerkt .
Niet degene die het maar uit een boekje hebben gehaald omdat "Het wel leuk leek"

Als je steeds tegen dat soort problemen aanloopt ga je toch naar oplossing zoeken in plaats van door te blijven amateuren?

Als je zelf beveiliging (of wat dan ook) programmeert maak je fouten, hoe senior je ook bent. Dan kan je je developers de schuld geven, maar het is beter om deze problemen te voorkomen.

Bijvoorbeeld door een webframework te gebruiken als Django, RoR of Symfony. Deze frameworks bieden bewezen, gestandaardiseerde, gedocumenteerde en geteste oplossingen voor alle beveiligingsproblemen die je noemt.

Bovendien kunnen nieuwe developers makkelijker aan de slag omdat een deel van de code bekend terrein is.

Wel, bij ons op school was dat iets anders.
Als er ook maar de mogelijkheid in zat om SQL injections of XSS toe te kunnen passen, of als de wachtwoorden niet voldoende geëncrypteerd waren, krijg je voor de volledige opgave een 0 (de opgaves/examens mochten nog op dat ene puntje na de beste van allemaal zijn).

Denk dat er velen zijn die daardoor geen zin meer hadden om te programmeren.

Ikzelf val onder de categorie die je aanhaalt in je laatste alinea: programmeer al vanaf mijn 6 jaar, en heb er ondertussen mijn beroep van gemaakt...

Blijkbaar schenken "jullie" hier ook niet genoeg aandacht aan bij de solicitatiegesprekken.

Waarom? Omdat Indiers onder druk moeten werken om zeer snel werk afgeleverd te krijgen , met andere woorden , er is geen geld voor kwaliteit of veiligheid!
Zulke kritische applicaties zouden niet mogen uitbesteed worden! Verboden moet het worden!

Volgens mij verwachten veel jonge developers nu het gebruik van moderne frameworks die SQL injectie (en andere) voor u oplossen.
Ze hebben zelf waarschijnlijk kleine projectjes uitgewerkt die dat niet nodig hebben (frameworks).
Dit is een vrij normaal probleem voor nieuwe developers die in een oud project worden geduwd.

Het zou natuurlijk wel opgelost moeten geraken met deftige code reviews.

De mensura applicatie is niet in europa gebouwd, het was uitbesteed voor het goedkoper te maken..., aan de europese hogescholen word zeer veel aandacht besteed aan data veiligheid, maar in Indie niet....bovendien zouden die indiers er zelf de tijd niet voor krijgen om de applicatie op veiligheid te controleren, die applicatie is veel lekker dan wat er nu in de media getoont is, bovendien zit het vol met performantie problemen...

Nou ik zie anders te vaak mysql_query() voorbij komen en dan dus nog niet eens mysqli. Geen pdo ofzo dus

[Reactie gewijzigd door Saven op 18 november 2014 11:26]

Maar met moderne frameworks als Laravel kan dat best nog wel meevallen. Het is natuurlijk nog steeds veel werk (als het om meer dan enkel een formulier gaat), maar het is niet alsof *alles* from scratch geschreven moet worden. Ik denk dat ze zelf toch ook wel door moeten hebben hoe zwaar het verouderd is indien dit het geval is?

Maar ja... "Het werkt"... Al iets te vaak gehoord.

[Reactie gewijzigd door RobinJ1995 op 18 november 2014 14:55]

Tjah er zijn ook gewoon nog veel programmeurs die niet weten wat sql-injectie is.
Vaak van die "senior developers" met veel ervaring...

Tjah er zijn ook gewoon nog veel programmeurs die niet weten wat sql-injectie is.
Vaak van die "senior developers" met veel ervaring...

Helaas zal daar waarschijnlijk een flinke kern van waarheid in zitten, ja.

Maar dan nog; als je persoonsgegevens verwerkt op die schaal, dan zijn er dacht ik toch echt allerlei procedures die je moet volgen om gecertificeerd bezig te zijn. Gewoon weer een gevalletje "niets mee gedaan", zoals Bux666 al aangeeft? Niet onwaarschijnlijk...

Op de een of andere manier leeft dat besef niet. Er heerst nogal het gevoel van "ach, deze gegevens zijn toch voor niemand interessant". In andere gevallen wordt er van uit gegaan dat het softwarebedrijf wel zal weten waar het mee bezig is. Zo vaak als ik al niet gehoord heb "iedereen in onze sector gebruikt dit programma, dan zal het wel in orde zijn".
Het vervelende is dat het voor buitenstaanders ook vrijwel onmogelijk is om te controleren of iets veilig is.

Ook al kent de programmeur het niet, met wat beschermdende maatregelen op server nivo zijn sql injecties ook tegen te gaan.

Het kan maar dan moet je pakweg de laatste 16 jaar zon beetje onder een steen geleefd hebben.

Ik ben een junior developer,zit in mijn laatste jaar, en mag mezelf dan ook beginnend beroeps oefenaar noemen

maar ik weet anders al een lange tijd wat bijvoorbeeld een SQL injectie is en hoe dat te voorkomen is.

De opleiding is inderdaad slecht, maar het heefte maken met jezelf.
als voorbeeld: als ik iets tegen kom wat ik niet ken, zoek ik het meteen op en zal ik me er in verdiepen.

daarom ben ik dan ook op de hoogte van dit soort dingen.
maar mijn klasgenoten is het helaas minder van te doen.
die vinden het leuker om te gamen, dan met het vak bezig te zijn waar ze later als professional in gaan werken.

"De opleiding is inderdaad slecht, maar het heefte maken met jezelf.
als voorbeeld: als ik iets tegen kom wat ik niet ken, zoek ik het meteen op en zal ik me er in verdiepen."

Ik was altijd in de veronderstelling dat je naar een school ging/studie doet om dingen te leren. Ik heb jaren geleden voor mijn HBO, MBO-ICT gedaan. Daar kreeg ik "websites programmeren". Wat we daar kregen was websites opmaken met html tabellen in 1 blok en in blok 2 basis PHP waarbij je een connectie met een database moest opzetten en gegevens kon invoeren/veranderen/verwijderen/uitlezen. Dat was letterlijk alles. Vervolgens op een stage moest ik met Ajax aan de slag.... divjes? parsen? wat? Ik was bekend met HTML, PHP en Javascript wat ik mijzelf had aangeleerd... Ja scholing faalt dus zeer. Je kan de student daar niet de schuld van geven ipv de scholen. Degenen die niks van webdev weten denken dat met de lage drempel ze Webmaster zijn of het is zo basaal dat het geen trigger geeft voor ze om er meer mee te doen en degenen die al vantevoren kennis hadden door interesse zullen zich vervelen.

Als je het bestaan van iets niet weet dan ga je ook niet ermee bezig, zoals je zelf zegt, als je iets tegenkomt wat je niet kent ga je ermee aan de slag. SQL injecties waren voor mij ook een onbekend iets totdat ik er wat over hoorde van een webdev die ik ooit eens sprak en toen eindelijk begreep waarom bij sommige formulieren meuk stond. Gelukkig had ik op mijn formulieren al de functie zitten dat rare tekens weghaalde of waren formulieren van websites zonder database. Overigens is tegenwoordig autobotspam een groter probleem met formulieren.

Tjah er zijn ook gewoon nog veel programmeurs die niet weten wat sql-injectie is.

Veel van dit soort front-end hacks zijn geen programeur-faal, maar administrator-faal. Namelijk niet geupdate systemen.

Geen enkele programeur schijft feilloze code. Het is daarom zaak je front-end systemen goed up-to-date te houden zodat elke gevonden bug zo snel mogelijk gefixt wortdt.

Aangezien er geen details gegeven zijn over de hack kunnen we enkel gokken. Was er een SQL-injectie gedaan? Of was er een bug in het formulier systeem en werd de data gewoon al afgevangen alvorens het naar de database ging? In dat geval is enkele en selecte periode van invoer vatbaar. Of is men echt het systeem binnengedrongen en kon ook bestaande databases leegroven?

Zij weten dan wel weer hoe je die mooie Facebook button op je website krijgt

En wat houd voor de bijl gaan in volgens jou?
Wil ik wel eens weten, als je weet dat NL en ict ook een warboel is.
Een pot nat.
Hoe vaak heeft Tweakers al bericht over de wanboel in NL?
Den Haag is aan de dope denk je dan.

Lijkt me sterk dat NL een geval apart is op wereldschaal.

Voorbeeldje UK op http://www.theguardian.co...isasters-universal-credit. Dit artikel over BE. Maar er is nog veel meer te vinden.

Bedrijven kunnen er ook wat van: http://www.computerworld....-can-learn-from-them.html

Dus ofwel alle overheden en bedrijven zijn aan dope, of IT is gewoon verdomde lastig...

[Reactie gewijzigd door menke op 18 november 2014 00:06]

Ik geef eerder de schuld aan de programmeertalen zelf. Het is prima mogelijk om native een querytaal in de programmeeromgeving aan te bieden, die niet gebaseerd is op het opbouwen van een samengestelde string met alle foutgevoeligheid door gebrek aan escaping en dergelijke vergissingen.

Maar op de een of andere manier worden deze onhandige en zeer voor fouten gevoelige string-based querytalen nog steeds gebruikt.

[Reactie gewijzigd door Grauw op 18 november 2014 09:13]

Duidelijk géén idee wat beveiliging is. Vechten tegen zero day exploits, hackergroepen met 100x meer vrije tijd dan de beveiliger werkuren, ...

Uw commentaar is hetzelfde als zeggen dat de zee leegpompen om een vermist vliegtuig te vinden, toch niet moeilijk kan zijn?

Noob!

We hebben het hier over SQL injection. En daar is al tientallen jaren heel eenvoudig iets aan te doen. Namelijk; niet als een domme sukkel queries opbouwen door strings aan elkaar te plakken, maar netjes prepared statements te gebruiken.

Misschien in het vervolg eerst even die grijze cellen laten werken, die je hopelijk nog in je kop hebt zitten, ok?

hackergroepen met 100x meer vrije tijd

Veel van die hackers zijn juist beroepshackers met grote beschikbare uren en budgetten. Dat is juist het probleem van veel van dit soort hacks.

Die mensen zijn beroepsmatig de hele dag op zoek naar kwetsbare systemen en kunnen gewoon van 8.00-18.00 betaald aan de slag.