Aanvaller vraagt losgeld voor gekaapte onbeveiligde MongoDB-databases

De Nederlandse beveiligingsonderzoeker Victor Gevers is een persoon op het spoor gekomen die onbeveiligde MongoDB-databases opzoekt en de inhoud daarvan vervangt. Vervolgens vraagt hij de eigenaren om losgeld in de vorm van 0,2 bitcoin, omgerekend momenteel ongeveer 212 euro.

Gevers voorzag de site BleepingComputer van uitleg over zijn ontdekking. In zijn eigen zoektocht naar onbeveiligde MongoDB-servers kwam hij onlangs een server tegen die was voorzien van een tabel met de titel 'waarschuwing'. Daarin werd uitgelegd dat de databases op de server alleen terug te krijgen zijn als het slachtoffer 0,2 bitcoin overmaakt naar een bepaald adres. Volgens Gevers was aan de logbestanden duidelijk te zien dat de aanvaller de aanwezige tabellen uit de database had geëxporteerd en had vervangen door zijn eigen tabel.

Dit kan handmatig of via een eenvoudig Python-script, legt de onderzoeker uit. In het geval van de ontdekte server was Gevers in staat om de eigenaren ervan te waarschuwen, zodat zij een recentelijk aangemaakte back-up konden terugzetten. Uit een Google-zoekopdracht met de naam van de aanvaller, Harak1r1, en het bitcoinadres, blijkt dat er meer mensen door dit soort acties zijn getroffen, schrijft BleepingComputer. Ook is aan het bitcoinadres te zien dat er recentelijk meerdere keren de genoemde bedragen zijn overgemaakt. Shodan-oprichter John Matherly laat aan de site weten dat hij in staat was om in totaal 1800 door Harak1r1 getroffen servers te vinden.

Gevers zegt dat hij vaak onbeveiligde servers vindt en deze meldt aan de respectievelijke eigenaren. Tot nu toe zou hij in de loop der jaren ongeveer 5200 meldingen hebben gemaakt. De meeste kwetsbare MongoDB-installaties komen voor op AWS-servers. Zij zijn vaak niet voorzien van een wachtwoord of maken gebruik van kwetsbare versies.

Reacties (92)

Hoe kan je in godsnaam een onbeveiligde server hebben
Zo dom is toch niemand zou je zeggen, zal toch wel iets over in de handleiding staan als je deze installeert.

Standaard staat MongoDB open op port 27017. Geen authenticatie, geen SSL. In de handleiding staat zeker hoe je Auth aan moet zetten en dat je je MongoDB niet aan het open internet moet hangen.

Maar MongoDB is binnen 5 minuten te installeren en te gebruiken. Met docker nog sneller. Configureren en goed dicht timmeren is lastiger en moet je begrijpen hoe het werkt. De lage drempel maakt het zo aantrekkelijk om eens met mongo te spelen.

Dat itt MySQL of MariaDB dat je ook binnen 5 min installeert? Ik zie nog niet echt een voordeel tegenover de concurrentie in je argumenten eerlijk gezegd (ken verder mongo helemaal niet).

Mijn argumenten? Waar vergelijk ik met andere databases?

"Maar MongoDB is binnen 5 minuten te installeren en te gebruiken"

Dit impliceert dat iets anders dat niet is. Tenminste mijn interpretatie, want waarom zal je het anders benoemen.

Ik bedoelde dat het heel snel te installeren is, maar om het dicht te zetten en je replicasets en backups in te richten je veel verder moet gaan dan die paar minuten.

Mongo is sqlloos afaik, tegenwoordig helemaal hip. Het feit dat je geen SQL queries hoeft te begrijpen/schrijven maakt het laagdrempelig.

Dat is nou niet helemaal het grote voordeel van non-relationele databases zoals Mongo

Maar dan zet je toch op zijn minst er een firewall tussen die de poorten blokkeert en/of een ip restrictie?

Standaard staat mongo inderdaad open op poort 27017, maar hij is alleen 'gebind' aan zijn lokale IP, dus niet van buitenaf te benaderen. Pas als je hem instelt op '0.0.0.0' kun je hem van buiten de machine benaderen.

Ja, je hebt gelijk

Ik ben niet thuis in MongoDB, maar dit klinkt toch als tegenstrijdig met 'secure defaults'. Ik mag hopen dat de rest van de security beter doordacht is.
Gelukkig bevat de handleiding een hardening guide, maar het lijkt erop dat de belangrijkste strategie afschermen is.

In het geval van mongodb was het een tijd lang zo dat je authenticatie moest uitzetten als je replicatie gebruikte. Dan krijg je dus handleidingen waar autoenticatie standaard uitgezet word als je een cluster maakt.

Maar dan moet je ze uiteraard niet aan het publieke internet hangen...

Dit, je isoleert de mongod instances op een VPN, al dan niet virtueel en zorgt ervoor dat het listen address op die van je VPN is, en niet 0.0.0.0.

Dan zijn er developers die verder komen dan de gebruikelijke MySQL en dan niet eens hun database kunnen afsluiten van de buitenwereld. Wat een onkunde eigenlijk...

1800 keer heeft hij ze zeker gevonden..., goed voor bijna 4 ton aan inkomsten als er word betaald, En dat zullen ze vast wel doen, voor een bedrijf is 212 euro iets wat gemakkelijke te betalen is dan oude backups terug zetten en je data base weer up to date krijgen, dat kost vele malen meer...
Slimme gast dus, en je weet nog niet hoe lang hij hier al mee bezig is...

Voor 212 Euro heb je geen garantie op de data integriteit. Een restore uit een goede backup....dan wel.

Een backup van een onbeveiligde database geeft net zo weinig garantie op integriteit.

Klopt, maar net zo integer als de data was voordat de hacker het weghaalde.

Plus dat je bij een backup data mist en dan iedereen moet gaan verwittigen wat er gebeurd is.
Wat sowieso netjes zou zijn, maar neem van mij aan dat de meeste bedrijven dergelijke voorvallen onder de pet houden, helaas al te vaak meegemaakt na het melden van kritieke lekken in systemen..

voor een bedrijf is 212 euro iets wat gemakkelijke te betalen is

Nou ja, dat valt te bezien. De hoogte van de waarde van de te betalen Bitcoins is het probleem inderdaad niet; het daadwerkelijk uitvoeren van de betaling, de verantwoording van deze betaling en het juist administreren zijn echter ook nog belangrijke hobbels die genomen moeten worden.
Bitcoin is nog steeds niet 'iets normaals'.

Dat niet alleen, wie garandeert de restore? vertrouw jij die hacker? ik niet.
plus als je als bedrijf betaald. hoe zet je dit dat in de boeken? dit gaat gewoon niet. dit is meer een persoon die de mensen op de vingers tikt en de mensen die geen backups hebben betalen de prijs. en ja daar moet je van leren.
Nette actie van Gevers.

Als beheerder van de db zal die dat wellicht uit eigen zak betalen en zijn baas in het ongewisse laten... anders kost het mischien wel zijn baan ...

Zo zit ik er ook in. Je kunt de integriteit niet meer vertrouwen/onderbouwen denk ik.
Mijn uitgangspunt is altijd A) nooit betalen en dan maar overuren draaien om de boel te herstellen.

Een oude backup terugzetten is goedkoper, de vraag is of mensen met een onbeveiligde databank, een backup hebben

Dat ligt maar net aan je backup/storage omgeving. Ik kan me best voor stellen dat wanneer je verschillende teams in moet schakelen om een database restored te krijgen, die 212 euro goedkoper is dan de kosten van de werknemers die elk wat werk moeten verzetten. Voor die 212 euro hoop ik dan dat deze persoon gewoon weer inlogt op je db, en de tabellen netjes terug zet. (daarna zou je natuurlijk je lek moeten dichten....)

edit: mod maar weg.. overbodige reactie

[Reactie gewijzigd door Roxsman op 5 januari 2017 08:41]

En jij denkt dat als je betaald, dan deze "hackende" (pardon my french) eikel dan ook lief is en je mongo collecties vriendelijk terug gaat zetten?

Nee hoor, als je betaald dan gebeurd er helemaal niks, behalve dan dat je kan fluiten naar je centjes.

Dat is een discussie die elke keer terug komt.Vaak krijg je je data wel terug, want als eenmaal bekend is dat je die toch niet terug krijgt, zullen toekomstige slachtoffers minder snel betalen. Wat dat betreft is dit net als elke andere service, als deze de reputatie "onbetrouwbaar" krijgt zullen minder mensen betalen.

Tuurlijk zal hij dat doen. Anders is zijn businessmodel naar de knoppen. Niet voor niets hebben de cryptolockers allemaal Nederlandstalige ondersteuning en sommige zelfs livechat. Hoe onethisch ook, maar ze willen de drempel tot betaling van het losgeld natuurlijk zo laagdrempelig mogelijk maken.

Ik verbaas me tegenwoordig ook nergens meer over.
Gemak, onkunde, verkeerde netwerk acl's of een combinatie van dit alles.
Volgens mij bind mongodb zich, out of the box, aan alle interfaces en dat zou maar zo een netwerk interface die aan het boze internet zit kunnen zijn.

Installeren van software is makkelijk, de ware uitdaging zit 'm in de configuratie van die software.

Voor zover ik weet klopt dat niet: hij bind alleen op 127.0.0.1 out of the box.

Tja, op AWS Amazon Webservice heb je dan niets, dus de kans is groot dat men dan kiest voor het IP van de virual machine.

Web gek dat mensen op AWS niet gewoon dynamoDB kiezen, op AWS moet je Mongo zelf beheren.
Kies dan als je persé MongoDB wil voor Microsoft Azure die MongoDB managed aanbiedt.

Ik zag laatst op pastebin in een random paste een complete mysql login staan Dat soort mensen denken gewoon niet na

Tuurlijk wel, ik kan je ook gewoon gebruikersnaam en wachtwoord van mijn mysql server geven, dat je er niet mee kan verbinden ligt niet aan de gegevens wel aan verder beleid.

Het is uiteraard wel knullig als je dan ook nog een (oude) versie PhpMyAdmin publiekelijk draait.

Gebruik van PhpMyAdmin mag wat mij betreft gelijk afgestraft worden. Dat is me een ranzig pakket zeg.

Dat is omdat je er vanuit een perspectief van techneut er naar kijkt.
De hoeveelheid bedrijven/managers/(mensen?) die denken dat "DE CLOUD" al hun problemen oplost is ongelovelijk.
Het is een keyword geworden om zelf geen vakkundig personeel meer aan te nemen. Tot de deksel op hun neus valt. (Dan is het meestal "iemand anders schuld" anyway)

Verder denkt ook elke techneut dat zoiets hem nooit zou overkomen.

Handleiding?

nieuws: Onderzoekers: veel MongoDB-databaseservers zijn publiek toegankelijk

In totaal wisten de studenten op 39.890 ip-adressen openstaande MongoDB-databases te lokaliseren. [...] Een van de kwetsbare databases zou in handen zijn van een Frans telecombedrijf. Klantgegevens als telefoonnummers en adressen van circa 8 miljoen Fransen waren vrij opvraagbaar.

Voor zo'n Telecombedrijf mag hij wel iets meer vragen dan 0.2 BTC.

Weet je hoeveel bedrijven illegaal windows gebruiken en het ook weten ?
Ik weet het wel en je schrikt je kapot, echt waar!
Deze onbeveiligde servers zijn geen uitsluitsel.

Lijkt mij dat dit eerder in bewerkersovereenkomst staat

De meeste kwetsbare MongoDB-installaties komen voor op AWS-servers. Zij zijn vaak niet voorzien van een wachtwoord of maken gebruik van kwetsbare versies.

AWS servers zijn van Amazon, hebben die hier geen verantwoordelijkheid in?

Microsoft doet een proactieve scan naar openstaande Mongo instanties. Onderstaand een stukje van hun email:

The Microsoft Azure Safeguards Team is notifying you that your account may be at risk of attackers extracting data from MongoDB databases that allow unauthenticated remote access. Please take the recommended next steps outlined below to secure your Azure deployment(s).

One or more of your MongoDB databases deployed in Azure could be at risk by allowing access to unauthenticated users. Please adjust your virtual machine configuration to make it more secure by taking the following actions as soon as possible:
1. Remove the external endpoints when not required.
2. Choose non-standard ports.
3. Apply access control lists to limit access to known IP addresses.
4. Regularly inspect logs to determine whether your critical data was exposed.

Here are resources you may find useful:
• MongoDB Security Checklist (Documentation)
• Enable Client Access Control (Tutorial)
• Securing MongoDB on Azure (Blog post)
• What is an endpoint Access Control List (ACLs)? (Technical article)

We also urge you to become familiar with the cloud shared responsibility model and understand the steps necessary to secure your assets. For more information, please read the Microsoft Incident Response and shared responsibility for cloud computing blog post. This exposure wasn’t created by the Azure infrastructure, but we wanted to make sure and notify you of your potential security risk.

If you have any further questions, please contact us.

Thank you,

Your Azure Team

Nee, je mag binnen hun voorwaarden hosten wat je wilt, of je dit nu met of zonder passwords of authenticatie doet of niet.

sterker nog alle security is de verantwoordelijkheid van de gebruiker.. AWS geeft je een VM en een stapel tools.. de gebruiker kan het zo secure mogelijk maken als hij wil..

Als je niet zelf je servers kunt beveiligen vind ik dat de schuld van de klant. Als je bij AWS wil hosten en je hebt een vergelijkbare service als MongoDB nodig dan kun je ook DynamoDB kiezen en regelen zij alles voor je zodat je hier niet over na hoeft te denken. Ze bieden overigens genoeg tools (VPC!) en veilige standaard instellingen om open servers te voorkomen.

Ze kunnen het beter NoAuth noemen ipv NoSQL.

Net als (bijna) alle Auth bugs in MySQL opgelost worden stapt iedereen over...

Er zijn meer smaken NoSQL dan MongoDB hoor Interessant leesvoer over MongoDB waarom het misschien beter is het te vermijden. Artikel is anderhalf jaar oud maar kan me niet voorstellen dat het in die relatief korte tijd allemaal opgelost is.

Veel van die problemen zijn wel opgelost omdat er sinds 3.0 een andere storage engine onder kan. Sinds 3.2 is deze de standaard. Dit is WiredTiger. De links in dat artikel verwijzen naar 2.4.

[Reactie gewijzigd door Anoniem: 84766 op 4 januari 2017 16:08]

Dank voor de aanvulling, toch zou ik zelf liever uitwijken naar een andere database omdat t voor mij een nare bijsmaak heeft dit allemaal te lezen.

Zou het niet gebruiken voor bedrijfskritische systemen zo te lezen, maar gezien de betalingen vrees ik het ergste.

... is not ACID-compliant

Als dit klopt, dan vraag ik mij af waarom zoiets nog een database genoemd wordt.

Omdat het geen file storage is, en ook geen block storage, en ook geen object storage. Database is een algemene benaming voor data-opslag met zoekfunctionaliteit.

Daarom is een goede back-up oplossing altijd belangrijk, maar als ze de beveiliging niet op orde hebben heb ik daar ook mijn vraagtekens bij...

Je ziet het wel veel vaker je kunt gewoon bijv. een hele winkel als Bol.com overnemen (gijzelen in feiten) het is gewoon modern overnemen van een winkel (bijv. ACTION)
"nu betalen jullie €200 of niemand kan meer bij de kassa afrekenen of producten vinden."
Eigenlijk best gek als je het zo verwoord, maar is toch echt realiteit ( en toekomst)

Ik kwam vandaag een site tegen die een soortgelijk verhaal op de landing page had staan:
http://www.festivalinfo.nl/
Wellicht interessant om eens na te vragen of ze bij festival info ook door die hacker zijn getroffen.

Gevers is wel echt een eindbaas dat hij in de loop der jaren ongeveer 5200 meldingen heeft gemaakt.: Respect! Het blijft natuurlijk triest dat 'beheerders' servers online blijven gooien zonder na te denken over security. Het is niet zo dat je de laatste jaren nieuws over IT security toevallig hebt gemist.

Ik host mijn mongodb databases bij mlab.com. Daar neem je een instantie af die goed beheerd en beveiligd wordt. Voor mijn eigen installs is het echt een eitje om mongo goed te beveiligen. Ik heb destijds ook de mongo university trainingen m101, 102 en 202 gedaan en daar zitten meerdere hoofdstukken over "production hardening" in.

Het is makkelijk om naar mongo te wijzen met slechte default instellingen, maar dat is ook moeilijk te voorkomen omdat mongo door gebruik van een hoop docker images, linux distro pakketten e.d. weinig invloed meer heeft in hoe mongo nou precies geinstalleerd wordt.

Los daarvan: het blijft een twijfelachtige keuze om een dbms te maken die überhaupt de optie heeft om zonder authenticatie te functioneren. Dat is eigenlijk nooit een goed idee.

[Reactie gewijzigd door TweakMDS op 4 januari 2017 19:44]

Ik had ook een keer via Shodan een onbeveiligde mongoDB server van een kleine Nieuw Zeelandse provider te pakken gekregen.
Zat aardig wat informatie in maar ben toch maar de witte kant op gegaan.

Is het een inbraak als de deur open staat?

Op zijn minst huisvredebreuk, en diefstal als je iets meeneemt.

/edit: Maar vooral heel dom

[Reactie gewijzigd door Ypho op 4 januari 2017 15:29]

Nee das insluiping

Computervredebruik. Kan je in Nederland zomaar een celstraf van een jaar opleveren

Puur goud dit soort ondernemingen.
1. Woon in een derde wereld land
2. Hack wat databases en vraag losgeld in de vorm van bitcoins
3. ?
4. Profit

Echt niet normaal wat een koekdozen er rondlopen in deze wereld...
Onbeveiligde database hangen aan het internet...

Voor ons is dat inderdaad idioot, maar voor Sjon Winkelman, die weinig IT-verstand heeft maar wel een leuk tentje, is het niet duidelijk dat je je database moet beveiligen. Waarschijnlijk heeft ie ook z'n administratie gewoon in zn kantoor liggen, binnen bereik van iedereen die binnenloopt.

Stel nou dat ik Sjon ben, ik heb geen bedrijf maar wel een Raspberry Pi thuis die apache2 i.c.m. php5 draait op Debian 8. Hoewel ik geen belangrijke info erop heb staan, heb ik naar mijn weten ook niks aan beveiliging gedaan (behalve SSH keys + TOTP en website via https). Wat kan ik doen om mijn 'server' te beveiligen?

Ik zou een webserver binnen een VM draaien die geen uitgaande internet toegang heeft. Gewoon in bijv. VirtualBox "Host only" communicatie aanzetten en dan poort 80 doorzetten naar de VM. De kans dat er wat binnenkomt via een rot PHP scriptje heb je namelijk al vrij snel en dan voorkom je in elk geval dat je in een spam botnet komt te hangen of dat er meer besmet wordt dan de webserver zelf. Voor software updates kan je dan op je host systeem een port forward maken naar een debian update server en het host IP instellen als server op de VM.

Uiteraard gaat dit op een Raspberry niet lukken ivm gebrek aan VM software maar op iets x86 based wel. Buiten regelmatig updaten en zoveel mogelijk brakke PHP scripts vermijden vind ik dit wel een fijne voorzorgsmaatregel die erger kan voorkomen als er wat misgaat.

Je kan het in Docker containers draaien. In ieder geval wat isolatie.

Stel nou dat jij Sjon bent... en dan ga je met zulke termen strooien.
Dan ben jij echt Sjon niet.

Ik neem aan dat je alleen port 80 en 443 doorzet naar je RPI, dat is al een goed begin. Verder ligt het er natuurlijk aan wat er draait op je web server en of dat wel veilig is.

Je kunt beginnen met de php.ini doorlopen, php header uitschakelen, modules uitzetten die je niet nodig hebt, alleen poorten naar buiten die nodig zijn (http(s)) en eventueel met een ip restrictie, geen root gebruiken maar sudo'en indien nodig en rootloginop ssh uitschakelen, iprestrictie op ssh, kijken welke diensten er draaien en uitschakelen of restricties toepassen, etc.

Ik denk niet dat Sjon Winkelman weet wat een database is. Dat laat ie over aan z'n neefje van 16, die zoiets wel even fixt.

Zolang er mensen zijn, zullen er koekdozen die hun voordeur open laten staan.
Mensen met een minder goed ontwikkeld geweten maken daar gewoon misbruik van.

En wat jij stelt, dat een onbeveiligde DB niet het probleem is, dat is het dus wel.
Iedereen hier van een respectabele leeftijd kan nog meepraten over Sub-7 om iemand zijn CD-laatje open te laten gaan op afstand.

Het wordt gewoon op die manier TE makkelijk gemaakt. Dieven doen echt te veel moeite hoor. Die pakken altijd de makkelijkste weg.