Mogelijk was de dader boos dat zijn persoonsgegevens gelekt zijn uit zo'n onbeveiligde database en heeft ie wraak genomen.
Waarschijnlijker is dat de dader van elke database een kopie heeft gemaakt en die straks tegen een flinke betaling gaat aanbieden aan de betrokken eigenaren (die de beveiliging dus niet op orde hadden).

Zo'n database is toch makkelijk via een firewall te beveiligen?

Of niet, en haalt hij of zij er genoegen uit om schade aan te richten. Maar wellicht is er ook nog een politieke drijfveer te vinden, je weet tenslotte nooit waar die doorgedraaide activisten op aanslaan. Daarnaast is het gewoon niet slim om een database direct aan het internet te hangen, dat is vragen om problemen. Anno 2020 zou je verwachten dat bedrijven het enigszins begrepen zouden hebben dat beveiliging toch wel een meer prominentere rol zou moeten hebben dan alleen als sluitstuk.
Helaas bewijzen dit soort aanvallen dat er nog een lange weg te gaan is.

Absoluut, het is erg simpel om deze aanval te voorkomen. Het stomme is dat het nog makkelijker is dan dat. In veel gevallen worden services als deze alleen door bepaalde systemen gebruikt. Veel van dit soort services zijn standaard alleen benaderbaar door de machine waarop deze is geïnstalleerd (alleen localhost).

Hier is het extra stom om het op een uitgaande netwerkinterface te laten luisten. Dit betekent dat ieder systeem/host die de machine kan bereiken bij deze services kan en data kan lezen, aanpassen, verwijderen, enz.

MongoDB heeft vanaf het begin al veel hiaten in haar software gehad. Jammer genoeg.
Het leek ook vanaf de buitenkant gestart als een interessant samenraapsel van allerlei software paketten die los van elkaar hun nut hadden aangetoond maar daarmee nog niet goed tot 1 geheel te smeden viel.
Nou weet ik niet welke belangen op de achtergrond kunnen meespelen maar neo4j leek als NoSQL database software pakket in MB's vanaf het begin groter en volgens mij niet zonder reden.
MongoDB kon niet alles dat Neo4j wel aan functionaliteit in zich had.
Toch omschreef het haar software als buitengewoon veelzijdig EN snel.
Echter waren de meeste NoSQL pakketten van meet af aan ofwel functioneler, ofwel sneller.
Dat laatste ook met minder uitgebreide focus / opoffering voor security.
Waarbij MongoDB standaard al met pitch zich meer richtte op o.a. CMS was mij onduidelijk wat ze nou met hun nadrukkelijke NoSQL en custonizeble uithangborden voor meerwaarde meenden te bieden ten opzichte van bestaande zogenaamd heel modulaire CMS's en python gebasseerde wiki systemen.
MongoDB en meerdere affiliaties & gebruikers werd op een gegeven moment ook vaker voor crypto base servers ingezet waarvan er ook gehackt werden.
Een systeem als Mongo-DB heeft mijn inziens een langdurig track record van kwetsbaar voor hacks.
Elasticsearch duikt in bepaalde media wat minder vaak op maar is ook om de zoveel tijd aan de beurt.

Naast de inherent grotere kwetsbaarheid van bepaalde database systemen lijken beheerders en ontwikkelaars zich gewoon ook niet afvragen wat en of de essentiële technische verschillen (of dat die er in gevallen vooral in marketing-praat worden gepromoot maar technisch / functioneel er niet zijn) zijn tussen diverse data-opvraag systemen?

En er ging vroeger al veel fout met inlees rechten van databases.
Nu is de hoeveelheid gegevens in databases echter wel omvangrijker.
Databases die gecorrupeerd raakten, kennelijk is alles dat vast hangt aan lees en schrijf-rechten beheer bij databases nog zeker niet op gelijke voet als database structuur, omvang en ontsluiting.
Gegevens kunnen wissen als gevolg van geen aanwezig wachtwoord lijkt mij hetzelfde als je huis 's-ochtend uitgaan zonder de deur op slot te draaien en later terugkomen en ontdekken dat een en ander in je huis is verplaatst en verwijderd.
Lees en schrijf-rechten beheer lijkt muj zeker ook nodig wanneer je je database eventueel in een virtuele omgeving draait of er met tijdelijke credentials op inlogt.

Hmm is UFO corp weer aan het datalekken?

Is wel sneu. Dan weten afnemers van de databrokers precies wie er zich achter verschuilen, als in klanten. Even een crossref tegen andere databases en je weet gelijk welke personen interessant zijn om wat nauwkeuriger te traceren.

Zo kwam ik een paar bekenden tegen in de Stratfor database. Weet je gelijk welke "backpackers" interessante nevenhobbies hebben. Ik sta er zelf ook in heur... ik ben op elke black en whitelist geabonneerd. Missschien de kennis maar eens gaan verzilveren ergens.

Neem dan Vipr of Cyber als VPN. Die gaven niets eens info aan Rusland toen een diplomaat van hun naar de hemel was gestuurd op "natuurlijke wijze".

Zo... nu maar een maandje wachten. Met de huidige financiele voorspoed kun je vooral veel blabla verwachten en weinig kwaliteitsVPN. Ach ik heb toch niets te verbergen


. Ik niet..

Dat probleem is er wel met meer services (geweest), maar die hebben veelal als reactie daarop een default configuratie
gemaakt die alleen op localhost luistert en die je zelf met een tool ofzo verder moet open zetten als je dat wilt.
Dus die ontwikkeling moet men misschien ook nog even doormaken bij deze services.

Welkom in de wondere wereld van de cloud, waarin de blob storage locaties of wat dan ook probleemloos aan het internet hangen. Meestal redelijk beveiligd, helaas niet altijd. In een "on-premise" datacenter kom je vaak weg met slecht geconfigureerde databases. In de cloud zijn vanwege het gewijzigde risicoprofiel grotere waakzaamheid, grotere kennis en specifiekere mitigerende maatregelen geboden. Eén foutje en je data ligt op staat. Of is weg. Nou ja, misschien was het wel goedkoop. Dat is ook wat waard.

Ik weet veel te weinig van dit soort software om te kunnen beoordelen of je overal gelijk in hebt, maar ik weet wel dat de mensheid bijzonder gevoelig is voor marketing en dat de kwaliteit van de marketing maar al te vaak meer gewicht in de schaal legt dan de kwaliteit van het produkt zelf.

Als onbeschermde gegevens gewist worden voor ze misbruikt worden wordt dat misbruik voorkomen. Het is denkbaar dat iemand meent de wereld te verbeteren door zo veel mogelijk onbeschermde databases te wissen, en meent dat het risico op het geheel verloren gaan van gegevens een kleiner probleem is.

Ik moet hierbij denken aan de felle discussies die gevoerd werden over het bekend maken van beveiligingslekken voordat responsible disclosure door de softwarereuzen netjes was ingericht en algemeen was geaccepteerd. Ik herinner me online discussies tussen twee kampen die kennelijk lijnrecht tegenover elkaar stonden: mensen die vonden dat het uiterst schadelijk was om lekken te openbaren voor ze gerepareerd waren waardoor je publiceren van ongepatchte lekken dus simpelweg nooit kon maken, tegenover mensen die vonden dat het nodig was om de lekken op straat te gooien om die bedrijven te dwingen de meldingen van lekken serieus te nemen. Het argument van de laatste groep was dat bedrijven vaak uiterst laks waren in het repareren van lekken, en dat de druk die direct openbaren opleverde in hun ogen per saldo meer goed dan kwaad zou doen.

Natuurlijk hadden beide kampen een punt en negeerden ze tegelijk het nodige. De tegenwoordige praktijk van responsible disclosure is dan ook een middenweg tussen die uitersten, die zowel druk oplevert om lekken te repareren als tijd om het te doen. We waren vermoedelijk niet op deze middenweg uitgekomen als niet beide kampen actief waren geweest.

Wat dat met deze situatie gemeen kan hebben is dat de achterliggende gedachte is dat er niets verbetert als de nalatigheid geen pijn doet. Het legen van onbeschermde databases past bij die logica: het doet de verantwoordelijke direct pijn, directer dan wanneer de data worden gekopieerd zonder dat de eigenaar van de database dat merkt, en het voorkomt tegelijk dat data die nog niet gekopieerd zijn gekopieerd kunnen worden. En als de verantwoordelijke zelf de database niet meer gebruikt is het alleen maar goed als die opgeruimd wordt.

Voor de duidelijkheid: ik ben het daar niet mee eens, maar ik snap de gedachtengang. Ik weet niet of dit inderdaad is wat erachter zit, maar het lijkt mij een plausibele mogelijkheid.

MongoDB luistert sinds versie 3.5.7 (uit de eerste helft van 2017) standaard alleen op localhost: https://jira.mongodb.org/browse/SERVER-28229
dus degenen die de betreffende service opgezet hebben, hebben 't zelf voor de wereld beschikbaar gemaakt. Vermoedelijk is dit ook zo voor de Cassandra-, CouchDB-, Elasticsearch services.