Docker meldt dat gegevens van 190.000 Hub-gebruikers mogelijk zijn gestolen

Docker heeft te kennen gegeven dat hackers mogelijk een database hebben binnengedrongen, waarbij zij toegang hebben gekregen tot gebruikersgegevens. Daarbij denkt het bedrijf dat er ongeveer 190.000 klanten zijn getroffen.

Volgens de loggegevens van Docker is er op 25 april ongeoorloofde toegang geweest tot een database van Hub, waarbij het bedrijf naar eigen zeggen 'niet-financiële' data heeft opgeslagen. Kort na ontdekking zegt Docker de server te hebben veiliggesteld waarbij tevens aanvullende beveiligingsmaatregelen zijn genomen. Die informatie staat in een e-mail die kort na de hack naar klanten is gestuurd. Daarbij moet worden aangemerkt dat het onderzoek naar de hack nog niet is afgesloten.

In de tussentijd zouden de hackers echter wel toegang hebben gekregen tot de persoonlijke gegevens van zo'n 190.000 Hub-gebruikers. Daarbij zijn mogelijk gebruikersnamen en versleutelde wachtwoorden in handen gevallen van de inbrekers. Ook tokens voor Github en Bitbucket zijn mogelijk gestolen. Docker vraagt gebruikers om die tokens in te trekken, maar ook om het wachtwoord van Hub-accounts te veranderen.

Docker is een bedrijf dat diensten biedt voor het bouwen en uitrollen van applicaties. Het heeft een reeks aan verschillende producten, waaronder voor individuele ontwikkelaars, maar ook voor bedrijven.

Reacties (42)

[Douweegbertje]

Mooi dat dit gebeurd. Tijd voor verandering.

Waarom ik dit aangeef heeft te maken met:

1: https://github.com/docker/docker.github.io/issues/6910
Ze hadden een tijd terug een change gemaakt waarin ze in feite forceerde dat iedereen een account moest maken. Vroegah was het helemaal niet benodigd. Zie het zo dat je nu een account moet hebben om docker te draaien. (side-note; het kan potentieel anders maar... you get the point).

2: https://github.com/docker/hub-feedback/issues/358
Al sinds 2015 (!!!!) staat er een request open voor 2factor auth.
Er wordt hier niets mee gedaan.

Het gevaar wat er nu is gebeurd is dat sommige mensen ook tokens/keys van bijv. AWS of andere cloudproviders in docker hub hebben staan voor deployments of builds. Obviously private images. De impact kan dus potentieel veel groter zijn dan een malafide 'push' op een bekende image.

[Ventieldopje]

Wel erg kort door de bocht dit hoor dus even tijd voor wat nuance (of klik op de links): de Docker GUI (all-in-one) applicaties kunnen niet gedownload worden zonder account. Zijn daarna prima te draaien zonder account voor zover ik weet. Ook om images te downloaden van de officiële hub heb je geen account nodig. Daarbij zijn alle losse (niet-GUI) applicaties altijd te downloaden zonder account en daarbij nog eens veel geavanceerder (en op OSX nog sneller ook).

Verder kom je niet onder tokens/keys uit als je 2FA gebruikt. Niks mis mee maar je moet wel alert zijn op je CI instellingen. Het is wel erg slordig om die tokens zo ergens in je repo te gooien.

[Verwijderd]

Hoezo op OSX sneller? Zo ver ik kan zien draait docker op OSX, net als onder Windows, gevirtualizeerd.
Voor sneller moet je onder Linux zijn, waar docker native draait.

On-topic; Is er hier geen gevaar dat toegang tot images mogelijk is geweest? (of mogelijk zelfs builds getriggered via de gegevens om zo images te maken waarin backdoors zitten?)

[Ventieldopje]

Docker via docker-machine is vele malen sneller dan "docker for mac" (GUI). Bekend probleem wat te maken heeft met filesystem virtualisatie. Met docker-machine kun je een engine als xhyve gebruiken (native hypervisor) met NFS als fs koppeling.

[Douweegbertje]

Het gaat mij om het principe. Hoewel wat je zegt klopt m.b.t. het account is dat natuurlijk wel in eerste instantie het geen waar ze zelf voor pushen. Lees: het zoveel mogelijk verkrijgen van account gegevens.
Zorg dan ook dat je je shit op orde hebt?

Inherent daaraan het stukje 2f auth. Als je dan zo pushed als bedrijf voor het verkrijgen van user-data, fix je bescherming.

Best-practises daar gelaten, het is gewoon niet goed geregeld daar IMO.

Ikzelf gebruik mijn eigen private registeries e.d. Het is voor mij meer een principe kwestie.

[Insehh]

Misschien dat teams ook eens na kunnen denken over wáár de images gebuild en opgeslagen worden. Als je jouw eigen images bouwt en vervolgens pushed naar Docker Hub vraag je er om, terwijl er genoeg oplossingen zijn om een eigen registry te draaien. Bijvoorbeeld.

[Ventieldopje]

Precies, zo'n registry opzetten is peanuts Kijk bijvoorbeeld eens naar de officiële docker images voor de repository en naar Portus.

[FireDrunk]

Uit de mail:

Data includes usernames and hashed passwords for a small percentage of these users, as well as Github and Bitbucket tokens for Docker autobuilds.

En:

We are asking users to change their password on Docker Hub and any other accounts that shared this password.
For users with autobuilds that may have been impacted, we have revoked GitHub tokens and access keys, and ask that you reconnect to your repositories and check security logs to see if any unexpected actions have taken place.

[Reactie gewijzigd door FireDrunk op 23 juli 2024 05:25]

[servicedb]

Als ik het goed begrijp dan vragen ze juist om de tokens in te trekken. Overigens, ik heb geen mail gehad.

[FireDrunk]

Ik verwoordde het verkeerd. Post gewijzigd.

[Soldaatje]

Nou ja, de docker-builds zelf zijn wel aardig transparant dus voor malware of infectie is het risico klein.
Gebruiken ze zelf wel docker?😋

[steven166.sh]

Docker builds worden altijd in een docker container uitgevoerd:
- start de base image
- voert een regel uit de dockerfile uit in de container
- stopt container en maakt er een snapshot van die de base image is voor de volgende regel uit de dockerfile.

Ondanks dat de docker builds in containers worden uitgevoerd, verwacht ik dat ze ook hypervisors gebruiken. Docker builds draaien standaard namelijk met root privilegdes. Opzich niet erg, maar het exposed wel potentiele kernel bugs die container escapes mogelijk maken.

[BlaDeKke]

Je hebt me geinspireerd iets meer opzoekwerk rond Docker te doen.
Van een hypervisor maken ze geen gebruik.

[steven166.sh]

Docker containers zelf maken inderdaad geen gebruik van hypervisors, maar van functionaliteiten uit de linux kernel die container technieken mogelijk maken door processen te isoleren.

Docker containers zijn veilig om processen van elkaar te scheiden, maar ik zou ze niet direct op fysieke server installeren (voor productie toepassingen). De linux kernel heeft namelijk meer functionaliteiten dan een hypervisor en daardoor ook een grotere attacksurface. Dan kans is daarom groter dat een potentiele bug in zit de linux kernel/docker die container escapes mogelijk maken dan in een hypervisor. Dus virtual machines met daarop docker containers (die draaien als non-root user) is qua security de best practise. https://kubernetes.io/blo...1-ways-not-to-get-hacked/.

Use the best of both worlds.

PS. In mijn vorig comment refereerde ik met ‘ze’ naar Docker hub/cloud. Die Docker builds as a service aanbieden. Excuses voor de onduidelijkheid.

[Blaise]

Het is moeilijk om te controleren of een build overeenkomt met de gepubliceerde Dockerfile, maar je kan natuurlijk altijd zelf een build doen.

[Verwijderd]

Precies. Het is toch weer een stap minder waar iets naar binnen kan sluipen. En je kan je images wat customisen.

[Ventieldopje]

Sterker nog, dit zou vrij snel moeten gaan. Zorgen dat je de image pulled die bij jouw versie van de Dockerfile hoort en vervolgens een build doet. Als ze identiek zijn zal alles uit de cache komen en dus snel klaar zijn, ook zullen de hashes gelijk zijn van je gepullde image en je gebouwde image.

Zie ook: https://semaphoreci.com/d...docker-layer-caching.html

[Blaise]

Als een Dockerfile een een package of code runt die van het internet wordt getrokken, zoals een RUN <package manager> install package of een RUN wget https://example.org/package.zip dan kan een evil hacker met een mitm attack die resource kunnen aanpassen, maar dan zal in je rebuild die layer toch gecached zijn omdat de context voor die stap niet gewijzigd is.

Docker heeft wel signed layers zodat je kan zien of een layer is gemaakt door een publisher die je vertrouwt: https://docs.docker.com/engine/security/trust/content_trust/

[Ventieldopje]

Dat wel maar dan is de volgende laag wel anders Afgezien van dat een MITM op dat niveau best lastig is, zal je bij zo'n MITM waar een ander bestand geserveerd wordt ook een andere hash krijgen voor de volgende laag, ongeacht of dit bestand nou opgeslagen wordt of uitgevoerd wordt en wijzigingen doorvoert.

[svenslootweg]

Ik denk dat je serieus overschat hoeveel mensen uberhaupt kijken naar de images die ze installeren.

[Verwijderd]

Ik maak er een gewoonte van alle images zelf te bouwen, dus eigen Dockerfiles.
Alleen het beginpunt is tricky; alpine met s6, maar daar stricte checks op de hashes en signatures.

Ik vertrouw de HUB voor geen meter, en hierbij wordt dit ook nog eens bevestigd. Ja het is makkelijk, ja je bent snel up-and-running, maar gezien tussen gebruikersgemak en security een spanningsveld is, moet het haast wel dat dit gemak ten koste gaat van de security.

[Ventieldopje]

En de package manager die je gebruikt (apk) vertrouw je wel? Just saying..

[MrMonkE]

next-next-finish

[idef1x]

Ben nog geen docker container tegengekomen waarbij ik hem kon runnen met next-next-finish. Tis geen Windows hoor

[TweakMDS]

Nee? ik draai er met vrij grote regelmaat een paar op mijn lab server met simpelweg een "docker run ...". Uiteraard is dat een verschrikkelijk slecht idee als je het daadwerkelijk in productie gaat neerzetten, maar een redis of sql servertje is wel zo makkelijk opgezet. Ik kan me zomaar voorstellen dat de stap van een interne test omgeving naar iets live zetten toch nog wel eens op deze manier gebeurd.

Hoe dan ook, security is een apart vak, en het wel of niet gebruiken van containers heeft hier niet automatisch positieve of negatieve effecten op. Wel biedt docker met diverse andere tooling er omheen de gebruiker (of devopser) meer dan voldoende informatie over de diverse best practices om het goed te doen.

[JustFogMaxi]

Wat daar anders aan dan een installer van bv SqlServer te gebruiken tov de officiële docker image?

[MrMonkE]

Gaat om het begrip en niet de feitelijke handelingen next-next-finish te klikken door de gebruiker.

[ro8in]

Ik vroeg me echt serieus meteen ook af of ze zelf ook docker containers gebruiken.

[Q]

Dat dit soort high-target cloud bedrijven wordt gehackt, dat is gewoon een risico. Google, Amazon en Microsoft hebben de cracks (wrote the book) aan boord, de kans dat die gehackt worden is niet zo groot.

Maar de kleinere spelers hebben misschien niet het risico-besef en niet de focus op security die de grotere (genoemde) bedrijven wel hebben. Voor kleinere spelers is het risico veel groter. Docker is een relatief kleine speler, 400-500 mensen in 2015, ik weet niet hoe groot ze nu zijn, maar dat valt in het niet bij de grote spelers. Ik zeg niet dat security specifiek te maken heeft met de grootte van een bedrijf, maar meer dat kleinere bedrijven niet de unlimited resources hebben die de grote bedrijven wel hebben, het leven is een stuk makkelijker als je weinig tot geen concessies hoeft te doen. Het moeilijkste is het vinden van talent.

Of het dan verstandig is om images voor je container cluster real-time bij dat soort toko's als docker op te halen?

Ik ben ouderwets OPS wat dat betreft en zou afhankelijk van de situatie een eigen repo bijhouden en die met een delay syncen om dit soort ongein te voorkomen. Dat zou ik ook doen met een OS-mirror bijvoorbeeld.

Ik zeg niet dat je dit altijd moet doen, maar het is wel een overweging. Wees bewust van de risico's.

[Reactie gewijzigd door Q op 23 juli 2024 05:25]

[Skit3000]

Ze hebben de databasetoegang gedetecteerd, dus de focus op security lijkt er in ieder geval te zijn. Real time images ophalen hoeft geen probleem te zijn als je de hash daarbij ook controleert, behalve dan dat je risico op downtime hebt als deze hash niet klopt en je op zoek moet naar de originele image

[Kabouterplop01]

Ben ik niet met je eens; als ze toegang hebben gehad tot de database dan hebben ze geen frontend gebruikt met prepared statements. Ik ga er dan niet eens van uit dat de database zo, kaal aan het internet heeft gehangen.

[GertMenkel]

Dat is een behoorlijke aanname om te maken vind ik. Ze zouden ook malware op een ontwikkelaarsmachine met netwerktoegang kunnen plaatsen, een 0-day op de website/SQL engine kunnen vinden, een medewerker hebben gechanteerd/omgekocht/bedreigd, noem maar op.

De conclusie dat ze dus wel geen prepared statements hebben gebruikt is een overhaaste, er zijn tig manieren om je als aanvaller toegang te verschaffen tot de database waarvan het gebrek aan prepared statements slechts de meestvoorkomende is.

[Kabouterplop01]

yep you are right, ik dacht meteen aan injection. Omdat het over database toegang ging.

[Reactie gewijzigd door Kabouterplop01 op 23 juli 2024 05:25]

[kakanox]

Microsoft leunt behoorlijk stevig op Docker, ik denk dat Docker qua security ook weer vrij stevig op MS leunt. Geen zekerheden, maar puur een inschatting.

Ga nu ook niet op zoek naar bronnen, want ik moet even een wachtwoordje wijzigen... :-)

[iMick]

In welk opzicht leunt Microsoft behoorlijk stevig op Docker? Qua techniek met Windows of qua container registry? https://azure.microsoft.c...docker-hub-data-exposure/

[kakanox]

Docker wordt voor de gehele ERP-stack van Microsoft sterk gepropageerd als ontwikkelplatform voor partners. O.a. door deze meneer:

https://blogs.msdn.microsoft.com/freddyk/

Freddy Kristiansen zegt je misschien niet direct iets, maar hij is een oude rot (sinds 2002) bij Microsoft voor ERP. Tegenwoordig is hij technical evangelist/software architect voor het NAV/Business Central platform.

Iemand die best wel een stevige vinger in de pap heeft over welke richting MS op gaat met NAV, en ook veel te zeggen heeft over hoe partners hun werk doen.

[Reactie gewijzigd door kakanox op 23 juli 2024 05:25]

[iMick]

Ik ben zeker bekend met Freddy Kristiansen en het ERP landschap . De link uit mijn vorige post is hier nog steeds van toepassing, gezien in de best practices voor partners van Microsoft gebruik gemaakt wordt van een eigen container repository (mcr.microsoft.com).

Tevens om je gerust te stellen: Microsoft has confirmed that the official Microsoft images hosted in Docker Hub have not been compromised.

[kakanox]

'Zojuist dus m'n wachtwoord gewijzigd.
Wat wel gek was: Ik logde in met m'n ID en wachtwoord (geen autologin, wel uit een passwordmanager). Ging naar Account Settings, vulde m'n wachtwoord in en 2x het nieuwe wachtwoord.
Krijg vervolgens de melding dat m'n huidige wachtwoord niet klopt? Ook na nog 2x opnieuw invullen.
Heel vreemd, ik weet namelijk zeker dat die klopt. Had 'm net gebruikt om in te loggen :-)

Heb het uiteindelijk gewijzigd d.m.v. vergeten wachtwoord.

[Reactie gewijzigd door kakanox op 23 juli 2024 05:25]

[s.stok]

Ik heb nog helemaal geen email gehad is toevallig bekend of alleen getroffen gebruikers zijn gemaild of dat iedereen een email behoord te krijgen?

Ik heb nu uit voorzorg mijn wachtwoord gewijzigd, maar anders dan wat andere melden werd mijn huidige wachtwoord wel geaccepteerd.

[Orion64]

Helemaal niet netjes!

Edit: Leek me ontopic

[Reactie gewijzigd door Orion64 op 23 juli 2024 05:25]

[turbojet80s]

Degene die je down mod heeft het reglement denk ik niet goed gelezen. Als men het nodig vindt om je te beoordelen dan hadden ze je een plus 1 moeten geven want het is inderdaad on topic. Over de toegevoegde waarde valt natuurlijk te twisten

https://tweakers.net/info/faq/karma/#tab:1-2

[cappie]

Zo blij dat ik al jarenlang een password manager gebruik en overal >12 karakter grote wachtwoorden gebruik....