Nederlandse huurmakelaar haalt site offline na ontdekking datalek

De Nederlandse huurmakelaar AltijdWonen heeft zijn site offline gehaald na door RTL Nieuws op een datalek te zijn gewezen. De namen, telefoonnummers en wachtwoorden van 49.000 klanten waren daardoor jarenlang in te zien.

De wachtwoorden waren gehasht met oude md5, waardoor die makkelijk te ontsleutelen zijn, schrijft RTL Nieuws. De site draaide op PHP 5.3.10 uit 2012 en had een inlogomgeving zonder https, waardoor gegevens onbeveiligd werden verstuurd. De database bevatte 49.000 entries met gegevens van klanten.

AltijdWonen heeft de database en site offline gehaald met de melding 'Onderhoud, binnen een paar uur zijn we weer live'. AltijdWonen heeft het datalek doorgegeven aan de Autoriteit Persoonsgegevens, zoals verplicht is. De eigenaar van het bedrijf gaat aangifte doen van de hacks in de database, zegt Daniël Verlaan van RTL Nieuws. De huurmakelaar zet een nieuwe site online. Bij de gegevens van de 49.000 klanten ging het om potentiële huurders en verhuurders.

Bron: Verlaan via Twitter

Reacties (74)

[Murfy]

Aan die screenshot te zien zou ik denken dat het een SQL injection betrof, ik herken die tool precies maar kan niet op de naam komen.. daar ging HTTPS natuurlijk niet veel aan veranderen. Niet dat het niet-gebruik ervan daarmee is goedgepraat.

[DanielG]

sqlmap® http://sqlmap.org/

[Murfy]

Jep, dat was hem.

Dusja; dat is gewoon brakke programmatie dan.

[xoniq]

En nog php 5.3, waarbij ik kan begrijpen dat legacy meuk nog eventueel op 5.6 draait, gaat dit 5.3 er bij mij niet in.

Plus gebrek aan SSL, geen SQL controle danwel prepared statements, pruts website dus.

[PatrickH89]

Kunnen deze potentiële huurders en verhuurders dan ook aangifte doen van grove nalatigheid?

[ShellGhost]

Ja. Aangifte kan je altijd doen. Of de politie er iets mee gaat doen is een andere vraag.

[Thijsmans]

Aangifte doen doe je van een strafbaar feit. Nalatig zijn is op zichzelf geen delict (maar is wel een bestandsdeel van andere delicten, bijvoorbeeld artikel 135 Sr). De politie zal dus geen aangifte opnemen en, als je achter de balie iemand treft met verstand van zaken, doorverwijzen naar de Autoriteit Persoonsgegevens. Daar doe je geen aangifte, maar maak je melding.

Mocht een getroffene overigens schade lijden door de "hack", kan die de verhuurder aansprakelijk stellen op grond van een onrechtmatige daad.

[gitaarwerk]

Er word hier wel vaak serieus naar gekeken omdat dit echt wen groter probleem is dan alleen deze site. En het is ook gemakkelijk aan te tonen.

[FireDrunk]

PHP 5.3 icm achterwege laten van HTTPS op inlogpagina's klinkt mij als 'opzettelijke nalatigheid' in de oren. Daar mag best hard tegen opgetreden worden.

[holoduke51]

Of gewoon gekocht jaren geleden en nooit meer upgedate. Die versie van PHP maakt opzich niet veel uit. Zelfs http betekent niet automatisch een datalek. Ik ben eerder benieuwd hoe een dump van de server is bemachtigd. Via SQL injectie misschien? Of was de server zelf slecht beveiligd?

[Verwijderd]

Hoezo, maakt niet uit? Het is een stuk software waarbij elke cve niet meer gepatcht gaat worden. Er stond overigens ook dat logingegevens over HTTP gingen, dus dat is wachten op een datalek.

Door die eerste twee uit te buiten, kan dat derde gewoon een gevolg zijn geweest.

[Wulfklaue]

> logingegevens over HTTP gingen, dus dat is wachten op een datalek.

Enkel bij "man in het middle" dank je wel... HTTPS is geen magie zoals veel mensen denken.

Het feit dat de server op HTTP draait, maakt geen piek uit voor de meeste van die aanvallen.

> Door die eerste twee uit te buiten, kan dat derde gewoon een gevolg zijn geweest.

Het feit dat men zonder HTTPS draait, telt niet als "de eerste twee".

Het is het feit dat men een enorme oude PHP draait, dat is een veel grotere probleem want:

* PHP 5.3 => X aantal potentiële gekkende lekken
* Als men nog op PHP 5.3 zit, zit men 9/10 kans op een oude Linux kernel
* Als men nog op PHP 5.3 zit, zit men 9/10 kans nog op met een verouderde MySQL versie te draaien.

Dit is ook de manier dat men inbreekt. Het stelen van inlog gegevens via man-in-the-middle is eigenlijk zoals verkiezingsfraude. Enorm overroepen terwijl de echte problemen op andere punten zitten.

En dan is bijna altijd:

* Basic software principe zoals externe input dat niet gevalideerd / gefiltered is ( aka SQL injection = meeste voorkomende ).
* Verouderde ( en niet geupdated ) software, os, database software of gemakkelijke paswoorden dat met met brute force ontdekt
* Of de meeste leuke van al: een databank backup dat gedumped word op de server voor x klant of ontwikkelaar te downloaden en daarna nooit verwijderd word! Hoe veel keren dat op die manier data gestolen word is ook massief!

Man in the middle is echt iets dat meer toebehoord aan staten en overheden dat de resources hebben om zo een aanvallen op te zetten. En die zitten niet stil want ze stelen pvd gewoon de certificaten.

[Verwijderd]

"Man in the middle is echt iets dat meer toebehoord aan staten en overheden dat de resources hebben om zo een aanvallen op te zetten. En die zitten niet stil want ze stelen pvd gewoon de certificaten."

Of iemand met een pineapple in een NS-trein. Of McDonalds. Alle devices die ooit aan een populair, open netwerk zijn verbonden, kun je flink mee aan de haal gaan, als deze via onversleutelde verbindingen troep versturen. Niks overheid-level aan. Zoals je zelf al mooi aangaf "___ is geen magie", dat telt ook voor een MitM.

Granted, het is een verre strekking om te zeggen dat een hele database zou uitlekken, maar aan de andere kant hoef je enkel het wachtwoord van een mod/admin/phpmyadmin o.i.d. te pakken te krijgen. Ik ga er maar vanuit dat zaken als firewalling, MFA e.d. ook niet op orde zijn in deze omgeving.

[Wulfklaue]

We spreken hier over een hack naar de databank. Als je als ontwikkelaar zit te werken van een Wifi or andere insecure verbinding op de McDonalds, dan vraag je er wel naar he...

> hoef je enkel het wachtwoord van een mod/admin/phpmyadmin

Het feit dat je als ontwikkelaar werkt met een publiek toegankelijke phpmyadmin, ... en dan zonder secure verbinding, dan verdien je om je data kwijt te raken.

HTTPS doet er niets eens toe. Als je geen VPN hebt staan naar je server met phpmyadmin, ...

M.a.w, als iemand er in slaagt via een wifi of andere verbinding kritieke toegangscodes te verkrijgen tot je server, omdat je zo lui bent om geen VPN te gebruiken, dan maakt het eigenlijk niet uit dat je site HTTPS draait.

Als iemand een man-in-the-middle doet via wifi, dat kan men even goed HTTPS spoofen. De enige beveiliging als je echt remote wilt werken rechtstreeks tot je servers, is ... zeg het allemaal na mij: VPN verbinding opzetten!

De beste beveiliging is servers in je eigen firma, niet op remote, ethernet verbindingen enkel voor toegang tot de servers, publiek netwerk en toegang tot je servers netwerk fysiek gescheiden, mysql op aparte firewalled servers, applicatie servers firewalled, VPN zones enz...

Nu ja, dat is te veel werk voor veel firma's en ja, dan smijten ze de boel maar op enkel servers bij een provider, als de boel draait zijn ze al gelukkig en de gevolgen zijn voor later nietwaar

> Ik ga er maar vanuit dat zaken als firewalling, MFA e.d. ook niet op orde zijn in deze omgeving.

Ik ga er van uit dat in deze data lek gebeuren er gewoon NIETS deftige opgezet is. Puur servertje dat jaren geleden opgezet is, waarbij men vlug apt-get install php/apache/mysql deed ... het werkt. En daar bleef het bij. Het feit dat men nog nog met PHP 5.3 draaide is gewoon crimineel.

En het zijn niet de enige... Weet op men hand best een paar firmas waar men nog met 5.x PHP versies draait. Maar ja ... dan moeten ze wordpress updaten en dat is te veel werk nietwaar. En dan klagen als er ingebroken is op hun wordpress websites.

En wie krijgt de schuld, juist, de IT staf dat hun herhaaldelijk waarschuwt dat ze als amateurs werken. Maar ja... verkopen aan messcherpe prijzen, ITs staf dat maar moet programmeren, programmeren, ... content, ... dat brengt geld op. Beveiligen, daar betalen de klanten niet voor he. Net zoals documentatie, dat weigeren de klanten want dat moeten ze niet hebben. Och man ...

Op een dag gaat er is iemand een programma schrijven dat een hoop exploits combineert en dat de helft van het internet gaat platleggen met alle servers te wissen. Ik zie dag nog is gebeuren.

[Verwijderd]

" Op een dag gaat er is iemand een programma schrijven dat een hoop exploits combineert en dat de helft van het internet gaat platleggen met alle servers te wissen. Ik zie dag nog is gebeuren."
Laat dit gebeuren, dan gaan mensen pas wat beseffen, het moet eerst grandioos fout gaan alvorens mensen anders gaan denken.

[svennd]

login gegevens over HTTP is niet wachten op een data lek; dat betekent dat het onversleuteld over het netwerk gaat; een data lek betekend dat ze "op de server" zijn geraakt. Een MITM aanval zal nooit "alle" gebruikers vangen, enkel de actieve.

[PageFault]

Ik zit me ook af te vragen hoe men een dergelijke query zo maar kan uitvoeren op de server. En waarom de wachtwoorden niet hashed opslaan ipv leesbaar?

[TheKingOfHoney]

Bekijk deze 2 videos, die leggen jouw vragen goed uit:
https://www.youtube.com/watch?v=ciNHn38EyRc (Running an SQL Injection Attack - Computerphile)
https://www.youtube.com/watch?v=8ZtInClXe1Q (How NOT to Store Passwords! - Computerphile)

[PhoenixT]

HTTP gebruiken op een loginpagina is per definitie een datalek; inloggegevens worden dan onversleuteld verstuurd. Bovendien kun je met een man-in-the-middle aanval een gebruiker na het "inloggen" mooi doorsluizen naar je eigen website, waar ze dan fijn nog meer persoonsgegevens kunnen achterlaten.

[Quilt]

Of gewoon gekocht jaren geleden en nooit meer upgedate.

En dat zou nog steeds doelbewuste nalatigheid zijn.

[kodak]

Gebrek aan onderhoud kan ook gebeuren doordat de eigenaar onvoldoende verstand van zaken heeft of er vanuit ging dat iemand anders het zou regelen en controleren. Maar dat is niet perse doelbewust. Dan had de eigenaar er weet van en daarop een keuze gemaakt.

[Annihlator]

Voor deze dienst moet je zelfs betalen om te registreren; als de eigenaar een dienst aanbiedt dient hij ook een zeker niveau van kwaliteit te hanteren en het valt gewoon niet te verdedigen dat hij zijn best lijkt te hebben gedaan in het zorg dragen van dat dat niveau ooit bereikt is geweest (kijk voor de lol anders ook naar de google user-reviews; nalatigheid lijkt daar de rode draad.)

[kodak]

Het onderwerp is dat het doelbewust zou zijn. Dat is net even wat anders dan nalatig zijn. Nalatig zijn kan ook door het niet doelbewust te handelen. Als de wet stelt dat iemand aan eisen moet voldoen en de eigenaar voldoet daar niet aan dan is dat nalatig. Als ook nog bewezen kan worden dat de eigenaar wist wat er gedaan moest worden om aan de wet te voldoen en dat dat met opzet niet heeft gedaan zou dat doelbewust kunnen worden genoemd. Effectief is de oorzaak een gelijk resultaat, maar voor een eventuele straf kan dat wel een verschil maken.

[Annihlator]

Dat is ook wel weer waar, ik vraag mij eigenlijk ook wel af of er op enige manier een website-eigenaar verplicht was dit soort dingen te controleren als we aannemen dat deze situatie in deze vorm 5 jaar geleden ontstaan is en sindsdien botweg nooit herzien was.

[mati1983]

Ik snap wat je bedoelt, maar -zonder specifieke kennis- vermoed ik dat dat woordje 'opzettelijk' juridisch niet noodzakelijk overeind zal blijven. Wanneer een ondernemer een platform koopt, bouwt of overneemt, ziet hij/zij dat als een tool. Een stuk gereedschap. Kan ook een gevalletje 'nalatig' zijn..

[Reactie gewijzigd door mati1983 op 23 juli 2024 02:59]

[Annihlator]

Als je gereedschap wat je voor je werk dagelijks/systematisch gebruikt niet laat keuren en er ontstaat vervolgens door dat stuk gereedschap een situatie/ongeval dan heeft de rechter daar normaal gesproken wel een mening over als vervolgens blijkt dat het al járen feitelijk ongekeurd is.

[mati1983]

Absoluut. Een rechter zal dat zoals ik reeds zei nalatig noemen (althans, verwacht ik). 'Opzettelijk' suggereert een 'bewust streven naar'.. Net zoals 'roekeloos' rijden in een auto vrij moeilijk is om te realiseren.

[bbob]

De eigenaar van het bedrijf gaat aangifte doen van de hacks in de database, zegt Daniël Verlaan van RTL Nieuws.

Aangifte tegen wie, RTL die ze er op gewezen hebben. Is er wel gehackt ?

Geen https met let's encrypt is dat toch vrij eenvoudig te implementeren zou je zeggen.

[ITsEZ]

Dat staat inderdaad niet erg duidelijk bij Tweakers, in het artikel staat dat RTL een "anonieme tip" kreeg. Ik kan me voorstellen dat ze aangifte doen tegen deze persoon. Natuurlijk kan je dan zeggen "die persoon helpt ze toch alleen maar?". Maar de persoon heeft er dus bewust voor gekozen om het naar RTL te sturen en niet naar de organisatie zelf.

Het gehele verhaal is vrij onsamenhangend "De volledige namen, e-mailadressen, telefoonnummers en wachtwoorden waren jarenlang voor anderen in te zien. Het is onduidelijk of andere, mogelijk criminele hackers de data hebben buitgemaakt. Volgens Altijd Wonen is daar momenteel geen aanwijzing voor."

Altijd Wonen heeft dus geen aanwijzingen dat de gegevens buit zijn gemaakt, maar schijnbaar heeft RTL ze wel opgestuurd gekregen, dat lijkt me wel een "aanwijzing" dat er toegang is geweest. De manier van versleuteling zorgt er niet bepaald voor dat ik vertrouwen krijg in de beveiliging van dit bedrijf, het lijkt me dan ook niet waarschijnlijk dat ze loggen wie de data heeft opgevraagd.

[Reactie gewijzigd door ITsEZ op 23 juli 2024 02:59]

[mati1983]

Hoezo kun je je dat voorstellen?
Wanneer ik tegen de ene buurman vertel dat de andere buurman zijn achterdeur niet op slot heeft, ben ik dan strafbaar?

[ITsEZ]

Ik kan me voorstellen in de vorm van, als ze aangifte tegen iemand doen zal het waarschijnlijk die persoon zijn.

[mati1983]

Maar, boerenverstand:

Wanneer iemand kwaadwillend is met de data, ga je het vervolgens toch niet aan de grote klok hangen?
Klinkt mij meer in de oren als een klokkenluider..?

[Verwijderd]

Als je het bedrijf schade berokkent zonder het de kans te geven de fout te verhelpen kan ik me best voorstellen dat een rechter daar sancties aan verbind.

[Annihlator]

Er wordt gesteld dat de data al jaren beschikbaar is; dit geeft aan dat degene die deze situatie opgevallen is dit aannemelijk al sinds enige tijd (danwel jaren) poogt te melden en dat het doorspelen naar Media stap 2 is (al is dit natuurlijk een aanname).

[Dartillus]

Maar het artikel vermeldt niet of de tipgever zelf eerder AltijdWonen heeft gewaarschuwd en daarna RTL. Zal niet de eerste keer zijn dat een organisatie pas reageert als media er bij te pas komt.

[gitaarwerk]

Meestal netjes om toch eerst contact op te nemen met het bedrijf. Ik heb ook regelmatig privacy gevoelige mogelijke issues gezien waar weinig mee gedaan word, helaas.

[MarnickS]

Bij het bedrijf zelf melden was ook niet slim geweest...

Het bedrijf gaat aangifte doen:
https://twitter.com/danielverlaan/status/1108720450740412416

[DemanNL]

Ik zag op linkedin iemand cool doen dat hij via SQLMap een database leeg had getrokken. Dus denk dat hij dat was. Kan de post nu niet meer vinden.
Maar het is vrij makkelijk ethical hackers juridisch onder druk te zetten. Had zelf een lek gevonden in makelaarssoftware dat bij 20 van hun klanten kwetsbaar was. We hadden het gemeld en als dank ontvingen we een juridische claim en of we ff boete willen betalen anders rechtzaak.
Rechtzaak is uiteraard duurder dan de boete dus wordt er betaald. Kan je niks aan doen, ondertussen zijn al die mensen nog steeds kwetsbaar en kan je alle facturen, openstaande vorderingen enz eruit halen van elk jaar.

[qless]

Graag even geen boetes dan betalen, maar gooi het maar op de media. Schandelige manier om omgegaan met een onschuldige melder!

[Verwijderd]

Had zelf een lek gevonden in makelaarssoftware dat bij 20 van hun klanten kwetsbaar was. We hadden het gemeld en als dank ontvingen we een juridische claim en of we ff boete willen betalen anders rechtzaak.

Van dat verhaal klopt niet veel. Zoals jij het verteld heb je helemaal niets strafbaar gedaan en er kan natuurlijk van een boete helemaal geen sprake zijn want die kan alleen door een rechter opgelegd worden. Daarnaast is er niet veel risico voor financiële schade want als je niets fout gedaan hebt vraag je de rechter de verliezende partij de kosten te betalen. Dat kan eventueel ook nog een een civiele zaak na de strafzaak.

Als jij een schikking hebt getroffen ligt het erg voor de hand dat je iets hebt gedaan dat strafbaar was.

[DemanNL]

Ik heb niks betaald. Werk heeft betaald. Puur omdat het meer moeite en geld kost om er tegen in te gaan, dan de schikking van de tegenpartij te betalen.

[Verwijderd]

zijn ze nu mee bezig

[HollowGamer]

Ik ken er nog een paar: die draaien allemaal een lage/onveilige PHP-versie, gevoelig voor SQL-injectie zijn en ontzettend verouderde code-base hebben. Je kunt simpelweg niet zomaar (alles) upgraden zonder testen en herschrijven van vaak oude code.

Het probleem is vaak dat afnemers geen geld willen steken in een rewrite, gewend zijn aan 'het systeem' en het niet snappen waarom vernieuwing om de zoveel jaar nodig is. Toegeven dat ontwikkelaars hun best moeten doen en het algemeen bekend moet zijn dat je gegevens moet 'schoonvegen' en valideren, maar ondanks dat alles veranderd de techniek. Mensen snappen de aankoop van een nieuwe (elektrische hightech-)auto, maar een nieuwe website (upgrade) is vreemd/geldklopperij/onnodig.

Van PHP 5.3.10 ben ik niet op de hoogte, al dacht ik dat CentOS bv. (veel gebruikte server distro) patches terugporten naar oudere versies, al moet je natuurlijk wel die updates installeren.

Ik heb er overigens geen moeite mee dat dit in het nieuws komt. Alleen is het jammer dat hierin maar één kant van het verhaal wordt verteld.

Waarom die server tokens standaard moeten aanstaat, begrijp ik overigens niet.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 02:59]

[418O2]

Als je zoiets tegenkomt, meldt het dan bij de autoriteit persoonsgegevens.

De andere kant van het verhaal is maar deels relevant, als je gegevens van mensen hebt moet je daar netjes mee omgaan.

[MarnickS]

foutje (reactie kan verwijderd worden)

[Reactie gewijzigd door MarnickS op 23 juli 2024 02:59]

[SinergyX]

Maar wat is nu de oorzaak? Goed, PHP5.3 zal wel ergens een exploit hebben, maar wat heeft https daar verder mee te maken? Dat wachtwoorden als MD5 staan opgeslagen, zonder lek heb je geen data, zonder login heb je geen database. Moet je wel bezig zijn geweest met een sql injectie, dan had het geen kloot uitgemaakt welke php versie je draaide, als de code 0,0 injectieproof is.

[PhoenixT]

De inlogpagina gebruikte HTTP, dat betekent dat inloggevens onversleuteld werden opgestuurd. Dat is per definitie een datalek. Los daarvan zal de site waarschijnlijk een SQL injectie hebben gehad, maar PHP 5.3 heeft ook een aantal bekende CVEs. Wachtwoorden met MD5 opslaan is enorm nalatig, je moet er namelijk altijd vanuit gaan dat je ooit een foutje maakt en iemand bij je data weet te komen; anders kun je volgens die logica je wachtwoorden ook in plain-text opslaan.

[Unipuma]

Misschien goed om even duidelijk te maken: MD5 is NIET te ontsleutelen. Het is een one-way hash.
Waarom MD5 een probleem is, is omdat je (relatief) eenvoudig een hash collision kunt veroorzaken, dus als je het gebruikt om aan te tonen dat een bericht of binary niet is aangepast, is het onveilig. (Je kunt de binary aanpassen en dan wat 'loze bytes' toevoegen zodat de MD5 hash weer op de oorspronkelijke waarde uit komt).

Het is echter een one-wat encryption dus je kunt NOOIT het oorspronkelijke wachtwoord achterhalen. Wat je wel kunt doen is een reeks van mogelijke wachtwoorden achterhalen die allemaal tot dezelfde MD5 hash kunnen leiden, dus een rainbow table. Dat geld echter ook voor modernere hash mechanismes, zoals SHA-1 en SHA-256. Daarom moet je een hash altijd salten, om te voorkomen dat je met een simpele rainbow table tot een waarschijnlijke waarde van een wachtwoord kunt komen.

[afraca]

Je hebt redelijk gelijk, maar niet helemaal vind ik.

Hash collissions maken md5 inderdaad erg ongeschikt voor verifiëren van content. Maar dit probleem is minder groot dan het probleem bij wachtwoorden, ik kom niet vaak meer enkel md5 hashes tegen, ze gaan altijd gepaard met sha1/sha256 hashes (sha1 heeft ook al collissions tegenwoordig), en niet veel mensen zullen handmatig hashes controleren.

Technisch gezien bestaat "one way encryption" niet, hashing is géén encryptie, maar in spreektaal maakt dat niet zo heel veel uit.

Je hebt het over gebruik maken van een "salt" als oplossing voor rainbow tables, maar voor md5 is dit tegenwoordig echt helemaal niet meer voldoende. md5 en sha1 zijn dingen die gewoon te snel gaan, daar zijn ze ook letterlijk voor ontworpen, en daarmee krijg je problemen met rainbow tables. Voor wachtwoorden hashen gebruik je langzame dingen als Argon2.

Het hangt erg af van je programmeertaal en framework hoe je het handigste hiermee om kan gaan. Gezien veel websites nog met php gemaakt worden:

• http://php.net/manual/en/function.password-hash.php
• https://laravel.com/docs/5.8/hashing

[Rannasha]

AltijdWonen heeft de database en site offline gehaald met de melding 'Onderhoud, binnen een paar uur zijn we weer live'.

Want de software van je hosting platform updaten, HTTPS inschakelen en je hele loginproces migreren naar een ander hashing-algoritme in een paar uurtjes er doorheen raggen is absoluut niet vragen om problemen...

[gitaarwerk]

Ach, je kan hiervoor mensen inhuren die wel wat duur zijn maar de boel fixen voor je asap. dan hoef je je website niet offline te halen.

Daarnaast, weet ik niet of het veel slechter kan worden. Dit had veel eerder moeten gebeuren, lijkt me.

[Rannasha]

Hoe goed / duur je inhuur-krachten ook zijn, je gaat nooit in een paar uur je volledige software stack updaten, een certificaat aanvragen/installeren en je database en authenticatie software migreren naar een nieuw hash-algoritme en ook nog tijd hebben om alles op een goede manier te testen.

Kun je al die wijzigingen in een paar uur doorvoeren? Waarschijnlijk wel. Kun je dat ook op zo'n manier doen dat je alles op een degelijke manier getest en gedocumenteerd hebt? Absoluut niet.

[gitaarwerk]

Nee, vast niet. Maar dat is eigenlijk meer onderdeel van risicobeperking. Er is wel wat van te zeggen als je op een hele oude stack zit. Er zijn al jaren goede alternatieven. Als je die niet hebt, dan heb je daarvoor naar verwachting gekozen. Dat is OK, maar die risicos moet je dan ook beseffen. Nu is helaas het besef dat het erg pijn doet. Niet lullig bedoelt, maar als je online wilt opereren, en ervoor kiest de risicos te nemen, zal je ze nu ook moeten dragen. En wat mij betreft terecht als ze hiervoor een boete krijgen.

Ik verwacht dat dit niet zo direct naar buiten komt. Men neemt is gewoon contact op om dit te melden, en als er niets gedaan mee word gaat men naar de pers. Ik zie het te vaak te worden genegeerd.

[Cergorach]

Kun je dat ook op zo'n manier doen dat je alles op een degelijke manier getest en gedocumenteerd hebt? Absoluut niet.

Documenteren kan je ook doen als het weer in de lucht is en testen hoef je met dergelijke storing/incidenten ook niet een hele OTAP procedure te volgen. Zonder details kan je sowieso weinig er over zeggen... Geld er tegenaan smijten betekend niet direct dat het snel en goed wordt opgelost, maar geen/weinig geld er tegenaan gooien weet je zeker dat het niet snel en goed wordt opgelost. Afhankelijk van wie je heb, kan die zo zeggen, dat zijn de issues, dat er uit, sus er uit, dat er in en VMetje vervangen, klaar.

Of... Wat mogelijk waarschijnlijker is dat de leverancier al lang geleden heeft laten zien wat er mis mee is, wat het ging kosten om te verhelpen en er nog steeds geen ja op is gekomen. Nu is die er wel, heeft de leverancier er nog eens een spoed 'fee' bovenop gegooid en kan de klant weer verder. Of nog waarschijnlijke, de website zonder database komt weer online.

[MrMonkE]

Missschien moet je na zo'n debacle juist niet even snel de boel fixen maar juist offline halen en goed fixen.
Daarnaast zou het me niet berbazen als ze onder andere naam op een nieuwe site verder gaan. Als ze al niet meerdere sites hebben.

[gitaarwerk]

Dat zou zeker een goede keuze zijn. Denk dat het wat meer vertrouwen geeft.

[Verwijderd]

Ho eens. Niks "eventjes". PHP 5.3 is al 5 jaar unsupported/deprecated en LetsEncrypt kwam uit in 2016? Ook een regulier certificaat is maar 2 tientjes per jaar. Dus het is niet "even", het is 5-6 jaar aan laks gedrag.

[Mar2zz]

Zo! Jij hebt helemaal gelijk! Hier is geen excuus voor. Als je zulke gegevens op slaat heb je je verantwoordelijkheid te nemen. Dit hetzelfde als een tas met alle gegevens van die mensen erin in een schuur te zetten waarvan alle planken rot zijn.

Dat de hacker nu een aangifte tegen zich krijgt maakt het klimaat heel naar om zoiets te melden. Ik hoop dat de Nederlandse media een veilige plek maken waar mensen dit neer kunnen gooien, anoniem of beschermd. Het zijn klokkenluiders. En ja ik vind ook dat ze daarbij aan moeten tonen dat ze daadwerkelijk bij die gegevens konden, anders ontstaat er een oerwoud aan nepclaims en moet alles uitgezocht worden. Dit gaat om bewustwording, bij bedrijven en instanties. Bedrijven die grote websites kunnen betalen willen maar een paar dingen waar het geld heen moet: prachtig responsieve designs, (automatische) koppelingen met de grote sociale netwerken, en zoveel mogelijk automatisering in het aanmaken van de content. Daar is het budget aan op. Toegankelijkheid en security? Wordt meestal niet naar gevraagd. Met als resultaat dat ze producten krijgen die op moment van oplevering prima in orde zijn qua veiligheid, maar al na een maand of twee bekende exploits hebben.

Ik vind het sowieso erg bijzonder dat bedrijven websites hosten op systemen waarop ook ander spul op staat waardoor een server update erg lastig wordt. Een dedicated servertje speciaal voor je site (of een goede externe host) zal toch niet al te veel op het budget moeten drukken. Dan is een upgrade van php5.3 naar php7.x ook zo gebeurt. Hele hoge boetes is hier het enige middel tot het achter de oren zit. En degenen die de knuppels hanteren vervolgen zit deze vooruitgang alleen maar in de weg.

[faim]

Nou, als ik dit al zie:

fetching entries of column(s) 'email, wachtwoord' for table 'gebruikernl'

...je database inrichten met Nederlandse benamingen, oogt nou niet echt professioneel. Waarschijnlijk gemaakt door een 'goedkoop' scriptkiddie ergens op een zolderkamertje.

[comecme]

Hoezo? Waarom staat het professioneler als je moet gaan proberen engelse namen te bedenken voor tabellen en velden? Als iedereen binnen het bedrijf het over een verzekerde heeft met een verzekerdenummer, dan moet de tabel insureds heten?

[faim]

Jouw classes, properties en methods geef je zeker ook Nederlandse benamingen?
Leuk als een buitenlands bedrijf de boel mogelijk een keer wilt overnemen en alles in geprogrammeerd in het Nederlands, worden ze vast heel gelukkig van.

[comecme]

Ik gebruik veel engelse werkwoorden in method namen. En een repository noem ik ook gewoon een repository. Maar dat kan wel gewoon een VerzekerdenRepository zijn.

Maar een Verzekerde class heeft gewoon een Achternaam, Voornaam en Geboortedatum.

Persoonlijk vind ik Engels ook prettiger, maar ik vind het niet onprofessioneel als tabelnamen en kolommen Nederlands zijn.

[nst6ldr]

Waardloos geregeld, maar wel netjes dat ze het melden én de boel per direct loskoppelen van het internet.

[CyberMania]

Dus tegen een hacker kan je wel aangifte doen, maar tegen de eigenaar die heel slordig met je gegevens om gaat niet? Want:

De site draaide op PHP 5.3.10 uit 2012 en had een inlogomgeving zonder https, waardoor gegevens onbeveiligd werden verstuurd

[Reactie gewijzigd door CyberMania op 23 juli 2024 02:59]

[PeterBezemer]

on-ge-lo-fe-lijk, dat dit nog steeds gebeurt...

[Wraldpyk]

Net als dat er nog altijd vele websites zijn de in plain-text wachtwoorden opslaan (of gewoon versluiteld opslaan wat weer te ontsleutelen is met dezelfde code).

En dat alleen is al de reden om nooit een wachtwoord te hergebruiken, er hoeft maar een rotte appel tussen te zitten en je moet overal inloggegevens veranderen.

Helaas is een sql-injection en ietwat verouderde software zoals in dit geval de situatie is niet eens zo heel erg nalatig vergeleken met zoveel andere sites.

[monstertje.xyz]

Dat betekent dat je overal dezelfde wachtwoorden gebruikt.

Met een fatsoenlijke password manager is dat natuurlijk zo opgelost.

[AmigaWolf]

Dat betekent dat je overal dezelfde wachtwoorden gebruikt.

Met een fatsoenlijke password manager is dat natuurlijk zo opgelost.

Precies, gewoon voor ALLE websites een andere wachtwoord gebruiken, en het liefs zonder namen er in.

[Wraldpyk]

precies mijn punt inderdaad

> En dat alleen is al de reden om nooit een wachtwoord te hergebruiken