Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

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.

Door Bauke Schievink

Admin Mobile / Nieuwsposter

28-04-2019 • 09:15

42 Linkedin Google+

Submitter: zupahrstan

Reacties (42)

Wijzig sortering
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.
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.
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?)
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.
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.
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. :)
Precies, zo'n registry opzetten is peanuts :) Kijk bijvoorbeeld eens naar de officiële docker images voor de repository en naar Portus.
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 28 april 2019 09:27]

Als ik het goed begrijp dan vragen ze juist om de tokens in te trekken. Overigens, ik heb geen mail gehad.
Nou ja, de docker-builds zelf zijn wel aardig transparant dus voor malware of infectie is het risico klein.
Gebruiken ze zelf wel docker?😋
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.
Het is moeilijk om te controleren of een build overeenkomt met de gepubliceerde Dockerfile, maar je kan natuurlijk altijd zelf een build doen.
Precies. Het is toch weer een stap minder waar iets naar binnen kan sluipen. En je kan je images wat customisen.
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
Ik denk dat je serieus overschat hoeveel mensen uberhaupt kijken naar de images die ze installeren.
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.
Ben nog geen docker container tegengekomen waarbij ik hem kon runnen met next-next-finish. Tis geen Windows hoor
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.
Ik vroeg me echt serieus meteen ook af of ze zelf ook docker containers gebruiken.
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 28 april 2019 09:33]

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
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.
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.
'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 28 april 2019 11:16]

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.

Op dit item kan niet meer gereageerd worden.


OnePlus 7 Pro (8GB intern) Microsoft Xbox One S All-Digital Edition LG OLED C9 Google Pixel 3a XL FIFA 19 Samsung Galaxy S10 Sony PlayStation 5 Smartphones

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank, Intermediair en Independer de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2019 Hosting door True