Kwaadwillenden hebben Linux-distributie Gentoo op GitHub aangepast

De ontwikkelaars van Gentoo waarschuwen dat onbekenden het beheer over hun GitHub-account wisten over te nemen en de inhoud van repositories en pagina's hebben aangepast. Alle op GitHub gehoste code moet als onveilig worden beschouwd.

De inbraak op het account vond donderdag plaats. Niet bekend is hoe lang de onbekende aanvallers het beheer in handen hebben of hadden, maar volgens Alec Warner van de Linux-distributie Gentoo was het lang genoeg om repositories en pagina's aan te passen.

De aard van de aanpassing is niet bekend. "We werken er nog steeds aan om de reikwijdte te bepalen en het beheer van de organisatie en de repositories terug te krijgen", schrijft hij, waarbij hij belooft dat meer updates volgen.

Hij benadrukt dat de masterrepository van Gentoo niet getroffen is, omdat deze niet op GitHub, maar op een eigen infrastructuur wordt gehost. Wie rsync of webrsync met Gentoo.org gebruikt, zal volgens Warner geen risico lopen.

Reacties (79)

[Chuk]

Kunnen ze geen diff trekken tussen de laatst known 'legit build' om zo de kwaadardige aanpassingen te pinpointen?

Niet bekend is hoe lang de onbekende aanvallers het beheer in handen hebben of hadden

Maakt het natuurlijk wel moeilijker om die laatste legit-build te vinden.

[Loggedinasroot]

Het zijn vooral kinderen geweest. Bij veel bestanden zijn rm -rf /* etc dingen toegevoegd en het logo is aangepast naar "Linux for negroes".

Hier het archief link.

Nogal een erg kansloze actie.

[wica]

Zonder "--no-preserve-root" ?

[Myrdhin]

De --no-preserve-root werkt alleen als je expliciet alleen / opgeeft als parameter. Helaas helpt het niet als je met een shell-glob werkt zoals /* want die expandeert weer in b.v. /etc /boot /usr etc, etc.

[wica]

* had ik overheen gelezen. Ja dat wordt idd door de shell vertaald naar /boot /etc /usr ....

[Loggedinasroot]

Wat ik heb gelezen is dat portage dit sowieso niet toelaat. Dus rm rf is altijd kansloos. Maar blijkbaar voert Portage ook alleen code uit die gesigned is door een gentoo dev, welke deze nieuwe code dus niet is.
Dus als het goed is zou er niks aan de hand moeten zijn maar heb er te weinig verstand van.

Heb ook geen idee hoe zoiets zou werken binnen een repo.

[aaahaaap]

Alle packages worden standaard gebouwd in een sandbox en die heeft geen toegang tot het root filesystem voor het grootste deel van wat er gedurende de build gebeurd (er moet natuurlijk uiteindelijk wel iets geinstalleerd/gekopieerd worden), de changes die gedaan zijn hadden niks destructiefs kunnen doen.

Commits van developers zijn gesigned en de ebuilds (de packages van gentoo) ook afhankelijk van hoe je deze synct (via rsync staat dit tegenwoordig standaard aan, via git voor zover ik weet niet).

[Reactie gewijzigd door aaahaaap op 2 augustus 2024 06:27]

[Blokker_1999]

* zorgt ervoor dat je geen no preserve root nodig hebt

[MrMonkE]

Je linkt werk(niet) meer.

[Loggedinasroot]

Linkt werkt nog prima hier. Volgens mij gebruik je of Ziggo, of de cloudflare DNS server of niet?

[MrMonkE]

Ziggo als ISP en met Cloudfare DNS: 1.1.1.1

Misschien adblocker, ik zal even zonder adblocker en disconnect proberen.
Thanks.

edit: Nope.

archive.is’s server IP address could not be found.

Vreemd.

[Reactie gewijzigd door MrMonkE op 2 augustus 2024 06:27]

[Loggedinasroot]

Ja klopt dan kan je archive.is niet resolven.
Als je je DNS server op 8.8.8.8(of iets anders) zet dan werkt het wel.

[MrMonkE]

Ja, ik heb even gegoogled.
Bekende issue en schijnt voor meer dingen te gebeuren.
MIsschien toch maar even 8.8.8.8 als secundairy instellen.

[lezzmeister]

Ik kon er ook om lachen. Maar alles moet politiek correcter dus dat is niet meer okay en zo.

[wica]

Since the master Gentoo ebuild repository is hosted on our own infrastructure and since Github is only a mirror for it,

In dit geval kunnen ze het idd gemakkelijk vergelijken, elke change die op github gedaan is, welke niet op de master staat, is een ongeldige change.

Maar dit is wel even een auw moment.

[analogue]

Jep, met als kanttekening dat veel mensen hun tree syncen a.d.h.v. git i.p.v. met rsync, en dan kun je dus nog wat problemen binnentrekken in theorie.

[aaahaaap]

In principe gebruikt niemand deze repo als sync voor hun tree, er mist behoorlijk wat data om em daarvoor nuttig te maken + er is geen CI overheen gegaan.
Git syncs gaan via git.gentoo.org/repo/gentoo.git of https://github.com/gentoo-mirror/gentoo

De repo die compromised is wordt voornamelijk gebruikt voor development.

[Verwijderd]

Gaat het specifiek om dependencies wat ontbreekt of meer dan dat?

[aaahaaap]

Nee, niet om dependencies. Alle packages in de gentoo tree moeten installeerbaar zijn zonder externe repos. Alle dependencies zijn dus ook beschikbaar.

Het verschil zit voornamelijk in metadata. Als je details wilt weten, vergelijk alles wat hier staat https://github.com/gentoo-mirror/gentoo/tree/stable/metadata (een mirror, incl metadata) met wat hier staat https://gitweb.gentoo.org/repo/gentoo.git/tree/metadata (de originele git tree).

De metadata wordt automatisch gegenereerd vanuit de git tree. De tree + metadata is wat door de mirrors geserved wordt. De metadata wordt o.a. gebruikt voor niewsberichten en glsa checks (vulnerabilities).
Daarnaast worden de mirrors alleen geupdate als de QA checks slagen.
Voor meer details zie https://wiki.gentoo.org/w...:Repository_mirror_and_CI

[Reactie gewijzigd door aaahaaap op 2 augustus 2024 06:27]

[analogue]

Dat heb ik inderdaad nagelaten te vermelden in mijn post, voor een reguliere user die synced via git is dit geen issue.

[Verwijderd]

ik durf te vermoeden dat ontwikkelaars van een besturingssysteem wel zullen weten hoe ze de aanpassingen kunnen ontdekken...

[m3gA]

De code van een besturingsysteem zal wel aardig uitgebreid en complex zijn. Dus het zal aardig wat werk zijn om alles te controleren. Zeker als je niet weet wanneer het aangepast is.

[_Thanatos_]

Volgens mij niet. Zodra ze de controle over het github-account weer terug hebben, lijkt het me een kwestie van de legitieme repo force-pushen naar de github remote. Alle wijzigingen na de recentste legitieme commit zijn dan gewoon weg.

[HollowGamer]

Het is niet een OS maar een Linux-distro. Gentoo is vooral voor die-hards die zelf (zo veel mogelijk) willen compilen om zo de ultieme Linux-ervaring te krijgen.

Heb zelf nooit echt met Gentoo gespeeld, maar als ik het goed heb zie je wat er gewijzigd is aan een package elke keer als je deze ophaalt om gecompiled te worden.

[Archcry]

Gentoo is zeker wel een OS, OS staat voor Operating System, elke linux distributie is daarom een OS.

[MadEgg]

Gentoo is een OS, maar het gebruikt heel veel code van andere projecten. Daarom is Linux Distro een betere omschrijving. Het is een distributievorm van een besturingsysteem gebouwd op de Linux kernel, aangevuld met alle software die nodig is om tot een volwaardige gebruikerservaring te komen.

Ik weet niet precies wat er in de Gentoo repository (en die is momenteel offline gehaald) staat, maar het lijkt me sterk dat de daar de code van de kernel, X.Org etc mirrorren. Het zal voornamelijk gaan om Portage, het package management systeem van Gentoo en alle scripts en software die nodig zijn voor het bouwen van images en het installeren van het systeem. En de ebuilds, de tekstbestanden die omschrijven hoe de packages gebouwd moeten worden, gebruikmakend van de originele packages die de ontwikkelaars ervan. En andere software benodigd om de community in leven te houden.

[Reactie gewijzigd door MadEgg op 2 augustus 2024 06:27]

[Archcry]

Dat lijkt me inderdaad ook sterk. De filosofie achter Gentoo is volgens mij dat het middels portage vrijwel alles van source build. Waarschijnlijk pakt het daarom de kernel en software van de originele bronnen i.p.v. de eigen repositories van Gentoo.

[MadEgg]

Dat doet het inderdaad. Alhoewel, er zijn wel gewoon mirrors natuurlijk, je download niet rechstreeks van kernel.org.

Neemt niet weg dat ebuilds een zeer belangrijke rol spelen, als ebuilds gehackt worden staat niets die ebuilds in de weg om software van malafide bronnen te downloaden en te installeren. Aangezien portage doorgaans als root draait kan dat verstrekkende gevolgen hebben.

[analogue]

De kernel is wel (minimaal) gepatcht, je ook kan vanilla-sources mergen, maar ook die zal via gentoo's systemen binnenkomen denk ik eerlijk gezegd.

[RoestVrijStaal]

Het is maar de vraag of "Linux distributie" de volledige lading dekt.

Voor Gentoo kun je namelijk ook de kernel van diverse BSD's gebruiken.

Met dit gegeven lijkt het koepelwoord "OS" een betere duiding te geven over het project.

[ajolla]

OS + applicaties = distributie.

[DJMaze]

De master staat op een intern netwerk, je kan die dus prima diff'en met die op github.
Iedereen die daar de tijd en interesse voor heeft kan dat doen.

Zodra de ontwikkelaars weer het beheer hebben, zal de repo op github wel vervangen worden met de master.
Dat is het mooie van DCVS.

[RVervuurt]

Dan moeten ze eerst weer het account in hun beheer hebben en dat hebben ze blijkbaar nog niet:

"We werken er nog steeds aan om de reikwijdte te bepalen en het beheer van de organisatie en de repositories terug te krijgen"

[aaahaaap]

De state van deze mirror repo is al gereset, het is nog wachten op checks van de open pull requests en dan het weer publiek maken van de github org + leden weer toevoegen.
Zie https://infra-status.gentoo.org/notice/20180629-github

[NiLSPACE]

Is bekend of deze beheerder two factor authentication aan had staan?

[DennusB]

Die kans lijkt me vrij klein!

[MiesvanderLippe]

Nee hoor. Je kan het voor organisaties forceren en dat is vrij gebruikelijk. Dan moet eenieder lid van de organisatie 2-factor aan hebben anders kunnen ze geen lid zijn. Je kan het in ieder geval zien van de leden van je organisatie.

[wica]

2FA is ook niet heilig, het is enkel een extra drempel opwerpen. Welke voor de meeste "hackers" nog een drempel te veel is.

Maar je moet ook vast leggen hoe je met OTP 2FA omgaat.
- Hoe, je codes backup
- Op welke manier je het moet gebruiken. Welke apps je gebruikt.
- Hoe het device waar de code opstaat/binnen komt beveiligd dient te zijn.

Maak je als backup, een screenshot van de QR-code en hoe bewaar je deze?
Download je de recovery codes en hoe bewaar je deze?
Mag de gebruiker een script gebruiken om zijn OTP te genereren en in te vullen op de zelfde computer.
etc etc.

[sumac]

En wat als je Authy gebruikt, op je telefoon én op je laptop in Chrome, je computer is gehackt, en op die manier wordt de 2FA-code uitgelezen?

[NiLSPACE]

Dat zijn nog steeds meer handelingen die de hacker moet doen dan alleen je gebruikersnaam en wachtwoord weten.

[sumac]

Het is stukken complexer, want je moet een gerichte aanval uitvoeren, specifiek op die gebruiker. Ik geef alleen aan dat dit een mogelijkheid is.

[.oisyn]

Dus omdat het niet perfect is, is het niet goed genoeg?

[sumac]

Dat zeg ik niet. Ik geef alleen aan dat het op deze manier zou kunnen gebeuren.

[Bitmaster]

Als beheerder van de code van een complete Linux distributie ben je nu eenmaal vatbaar voor dit soort hacks. Dat weten ze wel, maar als het al 20 jaar goed gaat ga je slapen. Eigenlijk was deze hack -hoe kansloos ook- wel ff goed, nu is iedereen weer wakker en het is makkelijk te herstellen.

[oezie]

Indd, het lijkt mij toch dat als je met zo iets groots bezig bent als een OS, dat je dit toch beveiligd met 2FA?

[aaahaaap]

Sowieso leek een compromised account al de meest voor de hand liggende optie en dat is zonder 2FA een heel stuk makkelijker.
Lijkt idd zo te zijn gezien de impliciete bevestiging dat sommigen 2FA niet aan hadden staan hier https://infra-status.gentoo.org/notice/20180629-github

Ongoing & Remaining actions:
...
(Gentoo Infra) Re-add all members to gentoo GitHub organization. Some members may have to add 2FA to their GitHub accounts first.

[Reactie gewijzigd door aaahaaap op 2 augustus 2024 06:27]

[Verwijderd]

Niet relevant. Om push-access tot de repos te krijgen hoef je alleen maar toegang te krijgen op een account waarvan de ssh public key in het github-account staat. Als ze het niet per project hebben dichtgetimmerd, kun je gewoon naar elke repo pushen. De github pages aanpassen is zo ook een fluitje van een cent.

Dat gezegd hebben, je kan met git log/blame/bisect prima achterhalen wat ze hebben veranderd. En dan kun je gewoon reverten.

[Stoelpoot]

Kijk nou wat Microsoft doet met Github!!!1

Oke, serieus nu: Ik vraag me af hoe dat account was binnengedrongen. Github ondersteunt 2FA, ik ga er voor het gemak van uit dat dat ook is gebruikt. Dus dan vraag ik me af hoe dat is omzeild?

EDIT: Help me even, komen die minnetjes omdat ik een opmerking maak waarvan ik daarna toegeef dat deze niet serieus is?

[Reactie gewijzigd door Stoelpoot op 2 augustus 2024 06:27]

[Smuey]

Ondersteunt, maar dwingt niet af. Dat is dus waarschijnlijk het probleem en de oorzaak dat dit heeft kunnen gebeuren.

[Reactie gewijzigd door Smuey op 2 augustus 2024 06:27]

[Stoelpoot]

Of dat het probleem is, is niet duidelijk. Elders in de discussie geeft @MiesvanderLippe ook al aan dat dit voor een organisatie geforceerd kan worden. Er kunnen ook best lekken bestaan in 2FA. In het verleden is door gebrekkige identificatie bij telefonieproviders telefoonnummers van celebrities overgenomen om daardoor de 2FA-berichten te onderscheppen.

[MadEgg]

2FA is niet een garantie tegen misbruik, net zo goed als afwezigheid van 2FA een reden is om aan te nemen dat je account hackbaar is.

De mens blijft de zwakste schakel. Als je gewoon sterke wachtwoorden gebruikt en je zaakjes netjes op orde hebt (geen wachtwoorden hergebruiken, goed geheim houden etc) voegt 2FA niet veel toe.

[Stoelpoot]

Wat 2FA toevoegt, is wmb wel belangrijk. Het zorgt er voor dat als de beveiliging van een dienst onvoldoende is, dat nog niet ten gevolge heeft dat je account gehacked kan worden. Bovendien is het een fysieke beschermingslaag, bovenop de geheime sleutel. Het kan in principe niet worden gekopieerd.

[Cloud]

Github ondersteunt 2FA, ik ga er voor het gemak van uit dat dat ook is gebruikt.

Zou ik niet doen. Het meest waarschijnlijk is gewoon - hoe nalatig dat ook is - dat 2FA niet gebruikt werd.

[sumac]

Als je 2FA op je laptop hebt, bv met Authy, en je laptop is gehackt, is dat dan niet een manier om 2FA-codes uit te lezen?

[HollowGamer]

Van dat laatste zou ik niet uitgaan. In het verleden heeft een Gentoo developer ook al eens de Wiki per ongeluk weggegooid zonder backups.

Het lijkt me erop dat 2FA niet aanstond, anders kom je er echt niet in - tenzij je de recovery keys hebt.

[Stoelpoot]

Of als je de 2FA authentication device kan hacken. In een reactie elders in de comment chain heb ik een voorbeeldgegeven hoe dat mogelijk wat met SMS.

[Robthebest]

Ergens vanuit gaan is ZO slecht.. vertrouwen is goed, controleren is beter!

[Stoelpoot]

Controle kan vziw dus niet. Ik zeg ik niet dat ik erop vertrouw, ik ga er voor het gemak van uit omdat het normaal hoort te zijn, en een interessanter vraagstuk voorlegt. Als er geen gebruik is gemaakt van 2FA, dan is het gewoon een maintainer fuckup.

[jimshatt]

Okee, even conspiracy modus aan:
1. GitHub host Gentoo broncode
2. Gentoo is een Linux distro zonder systemd
3. Systemd wordt gemaakt door Lennart Poettering
4. Lennart Poettering werkt by Red Hat
5. Red Hat wordt gesponsord door Microsoft
6. Microsoft neemt GitHub over
7. ..
8. Profit!?

[Mocro_Pimp®]

Hoewel het vergezocht is, is het zeker op dit moment niet uit te sluiten.

[MrMonkE]

Dat je dingen niet kunt uitsluiten is een slechte manier van werken. Zelf denk ik dat het een renegade AI is van microsoft, die AI is racistisch en als ik de aanpassing van het logo met racistische text en beelden zie lijkt me dat we dit niet uit kunnen sluiten. 1 + 1 = 2

[Mocro_Pimp®]

Gezien de geschiedenis van een bekende MS chatbot, misschien wel een combi van bovenstaande. De AI moet data hebben, dus misschien zijn de 8 stappen door de AI prima gezien/uitgestippeld.

[MrMonkE]

[Sandor_Clegane]

Waarom blazen ze niet gewoon de masterrepo over de oude heen? Daarvoor heb je die toch?

[MiesvanderLippe]

Nouja nee, nu kunnen we er nog wat van leren en ervoor zorgen dat we in de toekomst ook weer kunnen vertrouwen op de Github mirror.

[Sandor_Clegane]

Trek je er eerst een kopietje van.........

[RagingRaven]

Omdat ze waarschijnlijk wel willen weten wat er aangepast is.
Dit omdat er misschien mensen zijn die de aangepaste versie in gebruik hebben of tijdelijk gebruikt hebben.
Dan is het wel zo netjes dat je de mensen kan informeren over welke kwaadaardige code er in gestopt is.

[NaliXL]

"We werken er nog steeds aan om de reikwijdte te bepalen en het beheer van de organisatie en de repositories terug te krijgen"

Daar heb je je antwoord: ze hebben dus het beheer over het repository nog niet (volledig) terug.
Bovendien wil je ook wel weten hoe iemand de controle heeft gekregen, al was het maar om te voorkomen dat het weer gebeurt.

[HollowGamer]

Misschien wel interessant om te benoemen dat Chrome OS gebaseerd is op Gentoo. Ik ga er gemakshalve vanuit dat zij niet de Github-repo gebruiken, maar ik weet er zo weinig van dat het mogelijk wel zou kunnen.

Het is jammer dat dit gebeurd, 2FA moet gewoon verplicht zijn, al weet ik uit eigen ervaring dat genoeg mensen dit niet aan hebben staan. Zelfs domein/hosting aanbieders ondersteunen dit anno 2018 nog niet!

[Szz]

Ik heb mijn domain bij gandi en heb wel degelijk 2FA.
M'n hosting op Azure is ook 2FA

[mrdemc]

GitHub ondersteund dit gelukkig wel en ik kan me niets voorstellen waarom ze dit niet geactiveerd zouden hebben. Dus een vreemde keuze wat mij betreft aan hun kant. Daarnaast klopt je laatste zin niet helemaal. Het woordje “veel” moet er nog bij er zijn er genoeg die het wel ondersteunen.

[Verwijderd]

Ik vraag me af of dat ze dit hebben gedaan omdat MS Github heeft gekocht, dat zette kwaad bloed in de OS gemeenschap. Angst zaaien bij mensen om Github te gebruiken...
Voor de duidelijkheid en voor wie voorbarig conclusies trekt: ik keur het af dat ze zoiets doen.

[Reactie gewijzigd door Verwijderd op 2 augustus 2024 06:27]

[Jerie]

Da's opmerkelijk. GitHub ondersteunt al tijden 2FA. Ze hadden zelfs een partnerschap met YubiCo (het bedrijf achter YubiKeys).

[WhatsappHack]

Oh crap, dan moeten ze meteen de hele codebase nalopen om te zien of er ergens nog 0.0000001% performance verloren is gegaan.