Onderzoekers vinden een open MongoDB-database met 809 miljoen persoonsgegevens

De beveiligingsonderzoekers Bob Diachenko and Vinny Troia hebben een onbeveiligde, voor het publiek toegankelijke MongoDB-database ontdekt waar in totaal bijna 809 miljoen e-mailadressen en andere gegevens in plain text te vinden zijn.

Onderzoeker Bob Diachenko schrijft dat hij op 25 februari een MongoDB-database vond met 150GB aan gegevens, die niet door een wachtwoord werd beveiligd. Hij noemt dit 'misschien wel de grootste en meest uitgebreide e-maildatabase' waar hij ooit over bericht heeft.

Het gaat niet alleen om e-mailadressen, maar ook om namen, telefoonnummers en fysieke adressen. Maar dat is niet het enige; ook geslachten, ip-adressen, geboortedata, hypotheekinformatie, rentehoogtes staan in de database. Daarnaast staat er ook zakelijke informatie in, zoals data over de werknemers en omzetcijfers van allerlei bedrijven.

De bewuste onbeveiligde database is het eigendom van e-mailmarketingbedrijf Verifications.io en werd door het bedrijf direct offline gehaald nadat Diachenko er melding van maakte. Dit bedrijf stuurt zelf geen e-mails, maar onderzoekt databases van klanten om te verzekeren dat de e-mailadressen geldig zijn. Dit doet het bedrijf simpelweg door de mensen een e-mail te sturen; als deze goed aankomt, wordt het e-mailadres in de database gevalideerd.

Wired schrijft dat beveiligingsonderzoeker Troy Hunt de data van het bedrijf Verifications.io aan zijn website Have I Been Pwned heeft toegevoegd. Volgens hem is 35 procent van de e-mailadressen uit de onbeveiligde database nieuw voor de HaveIBeenPwned-database. Deze dienst kan gebruikt worden om te controleren op uitgelekte inloggegevens.

Reacties (61)

[jabwd]

MongoDB is waarschijnlijk de grootste data lekker die er is. Zelfs de documentatie re-inforced dit gedrag. Dit is echt een fout van MongoDB zelf, je hoort te weten dat je gebruikers dit niet snappen of doen. Update die documentatie is een keer en haal de mogelijkheid om het zonder een ww te gebruiken nou es weg.

[Reactie gewijzigd door jabwd op 23 juli 2024 02:11]

[mmjjb]

echt een fout van MongoDB zelf, je hoort te weten dat je gebruikers dit niet snappen of doen

Dat ben ik niet met u eens!
Blijkbaar heeft de IT'er niet eens de moeite genomen om de poorten te sluiten op de server...

Als je zo laks bent, dat een goede configuratie maken en poorten sluiten te veel moeite is.. dan mag je ook de consequenties ervaren en op de blaren zitten!

In dit geval mogen we gewoon spreken van grove nalatigheid!
Naar mijn mening mogen de verantwoordelijken hier privé voor aansprakelijk gesteld worden.

[Reactie gewijzigd door mmjjb op 23 juli 2024 02:11]

[Verwijderd]

Hoeveel sysadmins denk je dat je kan inhuren als ze een dergelijk risico lopen? Recentelijk heeft een rechtbank in Texas de waarde van een email adres (zonder inlog) gesteld op $0.50. Dan zou deze sysadmin dus een schade van meer dan $400.000.000 moeten vergoeden. Nu weet ik niet wat jij jouw IT'ers betaald maar ik kan je verzekeren dat als ik ze dit onder ogen schuif ze me glazig aankijken en een andere baan zoeken.

Fouten zullen altijd gemaakt worden. Ook fouten die enorme gevolgen hebben. Van explorerende kerncentrales tot aan dit soort data lekken. Het dwangmatige zoeken naar iemand die de schuld moet hebben, iets wat de laatste vijf jaar gangbaar is) heeft simpelweg nog nooit tot verbetering geleid. Worden er in de VS minder fouten gemaakt terwijl de cultuur van 'blaming and shaming' daar veel groter is? Welnee! Worden er in Korea meen fouten gemaakt terwijl elke werknemer weet dat hij veilig is voor dat soort dingen? Wel nee.

Het roepen om de schuldige aan de schandpaal te nagelen is populair maar onzinnig. Je kan alleen proberen een bedrijfscultuur te verbeteren. Maar ik ben uitermate sceptisch over elk idee waarin een overheid via wetten veiligheid probeert af te dwingen. Ik ken werkelijk geen enkel voorbeeld waar dat gewerkt heeft. Jij wel?

[mphilipp]

Leuk, maar daar schieten we ook niets mee op. Als jij zoveel adressen in je systeem hebt zitten, ben je geen prutser meer. Dan ben je een grote speler. En hoe dan ook, ook al ben je die bakker op de hoek, anno 2019 wordt je verondersteld te weten dat datalekken actief worden opgespoord en moet je ervoor zorgen (lees: geld uittrekken) dat de security geregeld wordt.
Dus niet de sysadmin persoonlijk aansprakelijk stellen. Daar koopt niemand wat voor. Maar zijn opdrachtgever/baas hoort gewoon te weten dat eea veilig moet zijn. Dat is een bedrijf verplicht. Pas als blijkt dat ie wel opdracht heeft gekregen om het GOED te doen, zou je zo iemand persoonlijk aansprakelijk kunnen stellen. Hoewel je natuurlijk altijd als professional je eigen verantwoordelijkheid hebt. En je eigen beroepseer.
Dus de baas is de grootste prutser, want die moet zich ervan vergewissen dat het systeem goed is. Elk zichzelf respecterend bedrijf die met persoonsgegevens, zeker als dat via internet ontsloten wordt, laat een externe partij checken of het allemaal ok is. Doe je dat niet, en blijkt het systeem zo lek als een mandje, mag je bloeden voor je fouten. Dan ben je meteen een voorbeeld voor de anderen. Mits het maar goed in de media komt.

[mmjjb]

Ik ben het gedeeltelijk met u eens.

Echter spreken we in dit geval van nalatigheid, slechte beveiliging komt voor, maar niet eens de moeite nemen om beveiliging te implementeren is het andere uiterste.

Zoals u ook aangeeft, fouten zullen altijd gemaakt worden. Echter is dat niet het zelfde als het niet configureren van een wachtwoord en het niet inregelen van de firewall.

Ieder mens weet dat persoonlijke gegevens beveiliging vereisen. Als een bedrijf vervolgens alle gegevens zo open en bloot op straat legt. Dan ben ik van mening dat het volledige nalatigheid is.

Overigens ben ik het met u eens dat een boete wel in verhouding moet zijn, iemand de rest van zijn leven in de schulden brengen is niemand gebaat bij.

Gerelateerd:
Duits bedrijf krijgt boete wegens opslaan wachtwoorden in platte tekst

[Reactie gewijzigd door mmjjb op 23 juli 2024 02:11]

[sympa]

Als een bedrijf iets ter waarde van 400 miljoen moet bewaren ligt de verantwoordelijkheid niet bij een enkele medewerker.
Er wordt een structuur bedacht zodat het veilig is, ook bij fouten.
En er wordt dan ook op gestuurd om minder risico te lopen. Als je fietsenverhuurder bent wil je niet dat mensen een contante borg achterlaten. Je legt een reservering op hun creditcard, dan heb jij niks, en het kan dus ook niet gestolen worden.
Edit: dit bedrijf had na controle van een mailadres alleen een hash hoeven bewaren van het adres. De opdrachtgever/klant kan, als ze zelf een adres hebben, de geldigheid verifiëren door de hash te vergelijken.
Dit soort bedrijven verdient het om failliet te gaan.

[Reactie gewijzigd door sympa op 23 juli 2024 02:11]

[Zyphlan]

In een rechtzaak in Nederland kan je als bedrijf niet de admin verantwoordelijk maken of de kosten erop verhalen. Ik kan me nog goed herrineren van me recht lessen op de Uni.

Vliegtuigbouwer laat een kraanmachinist een vleugel optillen voor bevestiging maar door een fout verliest de kraanmachinist de controle en uiteindelijk gigantisch kostenplaatje het bedrijf wil het op de kraanmachinist verhalen.

Rechter kijkt ernaar en dan komt de mooie term : Redelijkheid en billikheid ter sprake.

https://nl.wikipedia.org/wiki/Redelijkheid_en_billijkheid

Als je iemand een salaris betaald van zullen we zeggen 1000 euro om de vleugel op te tillen en de schade loopt in de miljoenen en dat ga je verhalen op de persoon die 1000 euro krijgt dan zal de rechter beslissen dat de kosten en opbrengsten volledig uit verhouding zijn. Zou je echter de kraanmachinist een ton betalen dan is het een ander verhaal.

Misschien iets te simpel uitgelegd maar zit zelf niet in de rechten en kan me deze nog herrineren.

Dus in geval van een admin die over 400miljoen waarde moet houden moet er toch echt wel een salaris met 6 nullen tegenover staan en kun je moeilijk verwachten dat iemand die 2-3k euro verdient die verantwoordelijkheid gaat dragen.

[smiba]

Blijkbaar heeft de IT'er niet eens de moeite genomen om de poorten te sluiten op de server...

Je verwacht toch ook niet dat een database software bij default op alle IPs zich bind en dan unauthenticated requests accepteert ???

Ik heb een keer mongoDB gebruikt voor een tool en schok me te pletter toen ik zag dat dit zich automatisch naar buiten liet zonder dat ik dit expliciet opgaf in de database. Kan echt niet!

[Reactie gewijzigd door smiba op 23 juli 2024 02:11]

[curkey]

precies, wat is er mis met safety by design?

[fonsoy]

Vind je het normaal dan om een systeem zonder firewall online te zetten? Ik niet - dit is basis beveiliging!

[The Third Man]

"Als je zo laks bent, dat een goede configuratie maken en poorten sluiten te veel moeite is.. dan mag je ook de consequenties ervaren en op de blaren zitten!"

Daar hebben we weinig aan, dat die ene persoon dan op de blaren zit maakt het lekken van al die e-mails niet goed. Je moet juist naar een default-deny systeem waardoor je handmatig dingen open moet gaan zetten om zaken te exposen. Dat voorkomt dan tenminste nog de achteloze/nalatige sysadmins e.d.

[sfranken]

Ook de sysadmin die het heeft ingericht is niet helemaal lekker, als je het mij vraagt. Je hangt een DB niet zo aan het WWW. Die configureer je zo dattie alleen connecties accepteert vanuit je eigen LAN / intranet / vertrouwde IP('s)...

[jabwd]

Ja, precies. Het moet by default goed staan want anders krijg je dus dit. Niet iedereen is een professional en niet iedereen weet wat ie doet. Dat is dus de taak van => MongoDB. Niet luisteren op 0.0.0.0 maar gewoon op de loopback.....

[Reactie gewijzigd door jabwd op 23 juli 2024 02:11]

[Murk]

Inderdaad. En dat is ook alweer een tijdje de default.

Volgende probleem is dan natuurlijk dat als bedrijven onkundig genoeg zijn om databases aan het internet te ontsluiten, ze al helemaal geen systematische updates van hun stack zullen doen...

[RoestVrijStaal]

Inderdaad. En dat is ook alweer een tijdje de default.

Locatie aldaar: Fix Version/s: 3.5.7

We gaan eens kijken of die versie of hoger in de repo's van welbekende server distro's zit

Au, in ieder geval niet in Debian (unstable) Sid, Stretch of -niet erg verrassend- in Jessie zit.

Voor CentOS is men gewezen op de RPMs van MongoDB zelf. Met iets pijnlijks: er kan niet voor een "stable" of "current" versie gekozen worden. Voor elke nieuwe stable major release moet de .repo file handmatig aangepast worden om ernaar toe te gaan. Raad eens hoeveel mensen daar aan gaan denken?

Voor Ubuntu is er vanaf Bionic (18.04) die versie van mongodb of recenter, maar de LTS versies van Ubuntu Xenial 16.04 en Trusty 14.04 vallen dus buiten de boot.

Het gaat dus nog niet op rolletjes allemaal

[Reactie gewijzigd door RoestVrijStaal op 23 juli 2024 02:11]

[zenlord]

Debian heeft in haar packages al veel langer de defaults dichtgedraaid. Mogelijk ook andere distributies.

[floorcula]

Ubuntu afaik ook al jaren

[sfranken]

Hoezo "moet" het by default op manier X of Y staan? Weet jij waarom de packers/developers van MongoDB besloten hebben de default configuratie te maken zoals hij was? Ik niet in ieder geval, maar ik ga ervan uit dat dat met gegronde redenen is gedaan.

En bovendien, elke sysadmin die zichzelf serieus neemt kijkt configs altijd even door en past aan indien nodig. Als je het op de "Windows manier" doet (volgende, volgende, volgende, klaar) heb je het in mijn ogen ook wel aan jezelf te danken als er iets fout gaat met je setup dan.

[jabwd]

En bovendien, elke sysadmin die zichzelf serieus neemt kijkt configs altijd even door en past aan indien nodig.

En toch hebben we problemen. Waar komt die door? Yep, precies, de default configuration. Hoe fixen we dat? Door de default configuration goed te zetten.

[Reactie gewijzigd door jabwd op 23 juli 2024 02:11]

[sfranken]

Waar dat door komt? Door luie beheerders die zoiets hebben van "een ander fixt mijn netwerk + software wel".

Hier gaan we het niet over eens worden merk ik. Ik zelf loop élke config na die ik gebruik, ook al weet ik zeker dat de "defaults" goed dicht staan. Je weet maar nooit.

[Basszje]

Dan nog. Des vroegers had volgens mij MySQL en de netwerkdingetjes (netBios, folder sharing) in Windows ook dergelijke default configuraties. Alles open, alles naar web, geen wachtwoord nodig. Die hebben dat allemaal terecht aangepakt. Probleem is dat lieden die 'maar wat doen' op deze manier veel schade veroorzaken aan derden, wat makkelijk voorkomen kan worden.

[fastedje]

Een database zet je inderdaad normaal niet op een systeem dat aan het internet hangt. Aan het internet hang je een reverse proxy die requests door een klein gaatje in je firewall van je dmz naar kan doorstuurt.

[Verwijderd]

Je reinste onzin. Mongodb is niet degene die je server openzet voor het internet. En als je geen verstand hebt van databases, moet je er geen opzetten.

[curkey]

Dus als je een nieuwe wifi router kopt, moeten alle hosts default in de DMZ staan en remote management moet enabled zijn?

[Verwijderd]

Vaak staat upnp standaard aan, en is het wachtwoord admin oid, soms is het netwerk ook een standaard wachtwoord, of zelfs compleet open, dus feitelijk is je router ook niet goed beveiligd out of the box.

[hakog2]

Een WiFi router is een consumenten product. Mongodb is een product bedoeld om gebruikt te worden door professionals.

[jabwd]

"Lets remove all warning labels so the idiots kill themselves" is een slechte mentaliteit voor security.

[frickY]

Onzin.

MongoDB heeft heel duidelijk gedocumenteerd dat beveiliging niet hun expertise is en je daar een ander product voor moet gebruiken. Sowieso is er geen enkele use-case om je MongoDB direct via internet bereikbaar te maken.
Het is een fout van domme beheerders.

Andere dbmsen hebben hetzelfde probleem ondanks dat ze wél beveiliging hebben, omdat diezelfde domme beheerders het standaard wachtwoord niet wijzigen.

Tot slot heb je nog enkele systemen die bij installatie een random wachtwoord gebruiken. Daarvan staat het internet vol dat de domme beheerders hun eigen database niet meer inkomen.

[jabwd]

Andere dbmsen hebben hetzelfde probleem ondanks dat ze wél beveiliging hebben, omdat diezelfde domme beheerders het standaard wachtwoord niet wijzigen.

Je vergeet hier denk ik dat het standaard wachtwoord vaak je user account credentials zijn. Er is een reden dat het elke week "mongodb heeft weer wat gelekt is" en niet "mssql heeft data gelekt". Die reden is dat mongoDB by default niet veilig is. Dat kan wel, en moet wel, is het niet. Gelukkig luisteren ze niet meer op 0.0.0.0 zo te zien maar het is nog steeds gestoord dat dat uberhaupt ooit het geval was.

[frickY]

Daarin is mssql de uitzondering, niet de regel.

[Devion]

Vind het van ubiquiti uniFI anders wel handig als ik vergeten ben wat het admin email is...

Dus ja.. zeker mee eens. Onbeveiligde databases in welke vorm dan ook moeten beveiligd zijn danwel authenticatie of encryptie..

[jabwd]

Yep, het probleem zou zich ook nooit voordoen als er gewoon fatsoenlijke hardening op z'n box zat... maar net zoals met iets simpels als password expiration dates is het enige wat de eind gebruiker doet een kleine aanpassing doen. 'P@ssword' wordt dan 'P@ssword1'. Security moet makkelijker en toegankelijker gemaakt worden want we spelen nou eenmaal met het menselijke element. Libsodium is denk ik van een programmeurs perspectief hier een groot voorbeeld van.

[unglaublich]

MongoDB is een database applicatie. Dit is net zoiets als beweren dat TCP/IP één van de grootste lekkers van gevoelige informatie is.

Dat iemand weet hoe je die moet configureren om het veilig te maken is NIET het probleem van MongoDB. Je bent niet wegwijs met eenvoudige netwerk en computer theorie als je je database laat lekken zo open en bloot op het internet weet te krijgen.

[jabwd]

Net zoals met alle andere reacties; by default een onveilige configuration hebben is een probleem. Je ziet elke keer "mongodb dit dat" bijna nooit "postgresql dit", waarom? omdat postgresql by default beveiligd is.
Dat je de blame wilt schuiven, snap ik echt, maar we weten ondertussen echt wel dat security makkelijk moet zijn, anders doen mensen het niet. Professionaliteit is dus ook nooit wat ik heb opgenoemd in mijn eerste reactie.

[Reactie gewijzigd door jabwd op 23 juli 2024 02:11]

[hakog2]

Mongodb heeft ook een hele andere use case dan mySql. MySql databases worden veel meer gebruikt voor WordPress achtig oplossingen. Voor zo'n dergelijke oplossing verwacht ik ook security out of the box. Heeft te maken met de doelgroep die je product gebruikt.

Mongodb wordt veel meer toegepast in maatwerk oplossingen veelal icm big data. Dergelijke toepassingen worden vaak vanaf de grond af opgebouwd. Inclusief de bescherming van de database. Het is dan gewoon fijn dat de database leverancier duidelijk maakt dat security geen onderdeel is van de database. Dat is een prima uitgangspunt in een enterprise omgeving!

[burne]

Het gaat nog een paar stappen verder. Wat doet de database-server op het internet? Dat opdelen met firewalls en frontend networks, DMZ's en backend networks mag dan heel ouderwets zijn, er is een goede reden voor om het zo te doen. Je klantgegevens zitten dan drie lagen diep met twee verschillende firewalls verwijderd van het grote boze internet. Kun je nog eens een keer iets vergeten zonder dat je gelijk data van 809000000 mensen lekt.

[R4gnax]

MongoDB is waarschijnlijk de grootste data lekker die er is. Zelfs de documentatie re-inforced dit gedrag. Dit is echt een fout van MongoDB zelf, je hoort te weten dat je gebruikers dit niet snappen of doen. Update die documentatie is een keer en haal de mogelijkheid om het zonder een ww te gebruiken nou es weg.

Recente versies binden in elk geval standaard alleen aan localhost en zijn voor andere IP addressen niet bereikbaar zonder verdere aanpassing aan de configuratie.

[Verwijderd]

Uit andere berichtgeving die ik lees zou het gaan het om een Elasticsearch database.

"The server, which was running an Elasticsearch database, contained more than a decade’s worth of data - from loan and mortgage agreements to repayment schedules and other financial and tax documents."
https://www.zerohedge.com/news/2019-01-23/millions-bank-and-loan-documents-leak-online

Daarnaast is dit ook een mogelijke verklaring voor de vele persoonsgegevens die ineens toegankelijk werden.
https://blog.hackenproof.com/industry-news/childrens-charity-kars4kids-leaks-info-on-thousands-of-donors/

De vraag is wie nog meer de data van deze database heeft kunnen uitlezen in de tijd dat deze toegankelijk was voor de buitenwereld.

[hakog2]

Voor Mongodb installaties geldt dat je de machine waarop de database draait afschermt en niet het database process zelf. Voor de usecases waarvoor mongodb wordt ingezet is dat een prima uitgangspunt.

[darknessblade]

mogelijk kan dit de verhoging van spam mail verklaren op mijn email {is namelijk een nieuwe breach voor gevonden}.

zijn allemaal zielige scam pogingen die al jaren bekend zijn

[dasiro]

als je ingeschreven bent op haveibeenpwned, dan krijg je een mailtje als jouw adres opduikt in een nieuw lek. Als je er geen hebt gekregen, dan is de oorzaak elders te zoeken

[darknessblade]

denk het ook, krijg ze niet vaak maar het begon een week geleden weer,

ze zijn wel slimmer geworden door de email als BCC toe te voegen aan hun spamlijst, hierdoor kan ik helaas niet controleren of het via een ghostmail service is of niet.

[foaly]

In de e-mail header zal altijd je e-mailadres moeten staan, en kan je dus altijd zien naar wie de mail gestuurd is, ook als je in de BCC staat. Of bedoel je dat niet?

[darknessblade]

in de email header staat GEEN email adress ook is er geen BCC header/ adress zichtbaar
-----------
dit is wat ik bedoel: {ik heb niets aangepast zo laat GMAIL het zien}
https://i.imgur.com/olget2v.png
-----------
andere spam mails laten wel de email adress zien

[GeroldM]

Dat is de gesaneerde header en bijna nutteloos als je moet onderzoeken waar mail werkelijk vandaan komt.

Wat tweaker foalybedoelt is de ruwe header. Mail client software zoals Thunderbird laat dit vrij gemakkelijk zien. Outlook is al een stuk minder (en met iedere nieuwe versie stoppen ze dit soort opties steeds verder weg in onduidelijke menu structuren).

Deze link (Engelstalig) geeft aan hoe een ruwe mail header eruitziet en hoe je deze het beste kunt lezen of interpreteren.

Anyway, de ruwe header geeft je heel veel meer inzicht in wie wat heeft verstuurt zonder toegepaste trucjes om mail valide te laten lijken in mail client software en web-mail.

[frickY]

Rechts boven in de opties even klikken op "show original" om alle headers te zien. Inclusief jouw adres en via welke servers de mail is afgeleverd.

[Hakker]

Wat mij stuit is wat moet een email verificatie bedrijf met zoveel gegevens?

[haakjesluiten]

Luie marketeers uit vermoedelijk niet Europese landen (want gdpr verbied juist dit soort praktijken) even een dump hebben gedeeld.

[SinergyX]

Waarom kan je werkelijk zulke data nooit inzien? Ik kreeg dus ook mailtje dat ik er in stond (mijn mail), maar verder 0,0 informatie. Geef mij gewoon mijn data, heb ik in 5 minuten precies gevonden waar deze zooi vandaan komt.

[R4gnax]

Waarom kan je werkelijk zulke data nooit inzien? Ik kreeg dus ook mailtje dat ik er in stond (mijn mail), maar verder 0,0 informatie. Geef mij gewoon mijn data, heb ik in 5 minuten precies gevonden waar deze zooi vandaan komt.

Risico-minimalisering. Als jij er in staat, dan kan het zijn dat een kwaadwillende jouw e-mail al overgenomen heeft. Laatste wat je dan wilt, is dat je die kwaadwillende nog meer gegevens gratis en voor niets toe gaat spelen.

[SinergyX]

Absoluut met je eens, snap ook dat email zelf natuurlijk niet veilig is (als ze daar in zijn gekomen), maar zou mij (en aardig wat andere mensen) behoorlijk wat schelen om direct te bron te weten. Is het een simpele site waar je blauwe maandag account voor moest hebben.. so be it, maar als het opeens je Steam account of erger is, kan je 10x meer actie ondernemen dan op de gok maar alles gaan veranderen (daar waar 2FA of dergelijke niet aan staat)

[R4gnax]

Absoluut met je eens, snap ook dat email zelf natuurlijk niet veilig is (als ze daar in zijn gekomen), maar zou mij (en aardig wat andere mensen) behoorlijk wat schelen om direct te bron te weten. Is het een simpele site waar je blauwe maandag account voor moest hebben.. so be it, maar als het opeens je Steam account of erger is, kan je 10x meer actie ondernemen dan op de gok maar alles gaan veranderen (daar waar 2FA of dergelijke niet aan staat)

Ah zo. Je wilt de origine van het lek, dwz de hack zelf, weten.
Ja; dat zou eigenlijk gewoon prijs te geven moeten zijn...

[murkienl]

Dit bedrijf stuurt zelf geen e-mails, maar onderzoekt databases van klanten om te verzekeren dat de e-mailadressen geldig zijn. Dit doet het bedrijf simpelweg door de mensen een e-mail te sturen

Say what..?

[Verwijderd]

Whehe, 't viel me niet eens op. Maar dat is idd erg magisch

[Rembert]

Dit klinkt stom. Maar in de bron wordt dit wel uitgelegd:

Here is the scenario:

“Mr. Threat Actor” has a list of 1000 companies that he wants to hack into. He has a bunch of potential users and passwords, but has no idea which ones are real. He could try to log in to a service or system using ALL of those accounts, but that type of brute force attack is very noisy and would likely be identified. Instead, he uploads all of his potential email addresses to a service like verifications.io. The email verification service then sends tens of thousands of emails to validate these users (some real, some not). Each one of the users on the list gets their own spam message saying “hi”. Then the threat actor gets a cleaned, verified, and valid list of users at these companies. Now he knows who works there and who does not, and he can start a more focused phishing or brute forcing campaign.

Ik snap ineens die rare "hello" spam berichten die af en toe binnenkomen.

[grote_oever]

[edit] verkeerd gelezen.

Blijft toch grappig. Ik ben er tussen uitgevallen. Is er naast haveibeenpwned nog een mogelijk om meer te zien wat er gelekt is van mij? De site haveibeenpwned geeft nu 8 lekken en ben wel benieuwd wat er precies gelekt is. Misschien is het namelijk allemaal oude informatie en heb ik allang wachtwoorden gewijzigd.

[Reactie gewijzigd door grote_oever op 23 juli 2024 02:11]

[SgtElPotato]

Mijn e-mailadres komt inmiddels voor in 12(!!!) bestanden. Er staan grote partijen tussen, maar ook onbekende partijen waarvan ik niet weet hoe ze aan mijn adres komen.

Meeste breaches zijn met wachtwoorden van voor de tijd dat ik 1Password en Authy gebruikte dus er is niet echt iets aan de hand.

Wat ik dus wel sinds kort gebruik, om in de gaten te houden wie mijn mailadres doorspeelt, is om bij het aanmaken van een account op een website +websitenaam toe te voegen aan het e-mailadres.
[e-mail]. Mocht het dan zo zijn dan ik ooit onbekende spam zie kan ik zien wie mogelijk mijn informatie gelekt heeft naar andere partijen.

[fastbikkel]

Wij zeiden op de zaak altijd "verrekte mongo".
Maar even serieus, ik heb geen idee hoe mongodb exact werkt.
Wel een spijtige situatie in het artikel.