image

Git-repositories gegijzeld door onveilig wachtwoordgedrag

maandag 6 mei 2019, 12:37 door Redactie, 8 reacties

Criminelen hebben de afgelopen dagen verschillende Git-repositories gegijzeld voor losgeld. Iets wat mogelijk was door onveilig wachtwoord gedrag, zo heeft GitLab laten weten. Git is een versiebeheersysteem dat ontwikkelaars gebruiken voor het beheren van broncode.

Bij verschillende ontwikkelaars was er ingebroken op het Git-account en aanwezige code verwijderd. De criminelen hadden een bericht achtergelaten dat er een back-up was gemaakt en er moest worden betaald voor het terugkrijgen van de verwijderde code. Onder andere gebruikers van GitLab, een bekende Git-respository, werden slachtoffer. Volgens het platform heeft de aanvaller tenminste 131 gebruikersaccounts en 163 repositories benaderd. Uit voorzorg zijn alle getroffen accounts tijdelijk uitgeschakeld en de eigenaren geïnformeerd.

GitLab stelt in een reactie dat de aanvaller kennis had van het wachtwoord van zijn slachtoffers. Uit onderzoek blijkt dat de gecompromitteerde accounts wachtwoorden in plaintext hadden opgeslagen op een uitrol of gerelateerde repository. "We moedigen het gebruik van wachtwoordmanagers aan om wachtwoorden op een veiligere manier op te slaan, en het inschakelen van tweefactorauthenticatie waar mogelijk. Beide hadden dit probleem kunnen voorkomen", aldus Kathy Wang van GitLab.

Reacties (8)
06-05-2019, 13:07 door Briolet
en er moest worden betaald voor het terugkrijgen van de verwijderde code.

Is de essentie van Git niet dat elke cliënt een copie van de gehele server bevat? Dus waarom zou je betalen voor iets wat je al hebt. Je kunt er wel files op zetten die niet synchroniseren, maar dat zullen vast niet de belangrijkste zijn.
06-05-2019, 14:17 door Anoniem
Door Briolet:
en er moest worden betaald voor het terugkrijgen van de verwijderde code.

Is de essentie van Git niet dat elke cliënt een copie van de gehele server bevat? Dus waarom zou je betalen voor iets wat je al hebt. Je kunt er wel files op zetten die niet synchroniseren, maar dat zullen vast niet de belangrijkste zijn.

Precies,.. volgens mij hebben de criminelen hier niet helemaal lekker over nagedacht.

Je mist wellicht wel je logs en versiebeheer,. maar alle files heb je nog.
06-05-2019, 18:28 door Anoniem
Door Anoniem:
Door Briolet:
en er moest worden betaald voor het terugkrijgen van de verwijderde code.

Is de essentie van Git niet dat elke cliënt een copie van de gehele server bevat? Dus waarom zou je betalen voor iets wat je al hebt. Je kunt er wel files op zetten die niet synchroniseren, maar dat zullen vast niet de belangrijkste zijn.

Precies,.. volgens mij hebben de criminelen hier niet helemaal lekker over nagedacht.

Je mist wellicht wel je logs en versiebeheer,. maar alle files heb je nog.

Dit klopt niet. Je kan de geschiedenis van een Git repository herschrijven door "git push - - force" uit te voeren. Hierdoor is alle history wel degelijk weg.
06-05-2019, 19:11 door Anoniem


Je mist wellicht wel je logs en versiebeheer,. maar alle files heb je nog.

Versiebeheer zit in je lokale .git directory en daarmee elke versie van elk bestand die ooit in de repository ge-commit is. Als je dus niet rechtstreeks op de git server je boeltje aanpast maar pull-edit-stage-commit-push doet (zoals het hoort) heb je inderdaad alles lokaal staan.
06-05-2019, 19:41 door Briolet
Door Anoniem: Dit klopt niet. Je kan de geschiedenis van een Git repository herschrijven door "git push - - force" uit te voeren. Hierdoor is alle history wel degelijk weg.

Zou inderdaad kunnen. Git geeft een 'achterdeurtje' om files compleet uit de repository te verwijderen. Handig als er per ongeluk een file met persoonlijk data in terecht komt. Maar volgens mij moet je dan nog steeds een pull doen om dit ook op de cliënts te wissen.
06-05-2019, 21:22 door Anoniem
Als je een "git clone" uitvoert heb je de hele "repository" inclusief commit history. Als daarna iemand je git account overneemt is er voor jou niets aan de hand zolang je niet probeert je lokale repo bij te werken.

En github is voor zeg een kleine groep ook niet zo belangrijk: Maak een account op een andere git-hoster aan, zet daar je repo neer, en vertel iedereen daartegenaan verder te werken.

Maar voor veel open source projecten is github het enige distributiepunt. Dat kwijtraken betekent dan ook gelijk jezelf moeten forken. En oh ja, je raakt ook nog de tickets kwijt die github ook nog voor je host. Maargoed, die zijn mischien minder belangrijk. De reputatieschade en de gebruikers die jou niet meer kunnen vinden zijn wellicht vervelender.

Ik zou niet zo snel betalen. In plaats daarvan zou ik van github wegverhuizen. Maar persoonlijk zou ik sowieso dit soort dingen niet in handen van een derde partij willen leggen: Gewoon releases bouwen en die zelf ergens hosten, en/of de git repo zelf ergens hosten. Bijvoorbeeld toen allerlei aan freebsd gerelateerd geknutsel steeds meer op github ging zitten en zelfs ging vereisen dat je een github account moest hebben om bugs te kunnen rapporteren was het voor mij wel gedaan met mijn vriendschap met dat project. Dat de projectleiding niet snapt dat die houding problematisch is, was voor mij reden om de boel definitief af te schrijven.

Op vergelijkbare wijze zal deze afpersaanval vooral mensen treffen die wel lief aan het knutselen zijn maar niet echt een duidelijk idee hebben waar ze nou helemaal mee bezig zijn. Dat zijn dan vaak weer ideale mensen om op te lichten.
07-05-2019, 06:40 door Anoniem
Door Briolet:
Door Anoniem: Dit klopt niet. Je kan de geschiedenis van een Git repository herschrijven door "git push - - force" uit te voeren. Hierdoor is alle history wel degelijk weg.

Zou inderdaad kunnen. Git geeft een 'achterdeurtje' om files compleet uit de repository te verwijderen. Handig als er per ongeluk een file met persoonlijk data in terecht komt. Maar volgens mij moet je dan nog steeds een pull doen om dit ook op de cliënts te wissen.

Ja, dat is waar. Hopen dat iemand de repository nog gecloned had op zijn/haar computer.
09-05-2019, 05:12 door Anoniem
Lekker wanneer je de "Back-up" van deze lieden terug krijgt. Dat wordt dan wel een weekje code nalopen om te kijken of er niet ergens een onveilige construct in terecht is gekomen.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.