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.

gentoo linux 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 29 juni 2018 10:35

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 @Chuk • 29 juni 2018 11:11

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 @Loggedinasroot • 29 juni 2018 12:01

Zonder "--no-preserve-root" ?

Myrdhin

@wica • 29 juni 2018 12:33

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 @Myrdhin • 29 juni 2018 13:01

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

Loggedinasroot @wica • 29 juni 2018 12:08

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 @Loggedinasroot • 29 juni 2018 12:35

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

Linux
Malware
Beveiliging en antivirus

@wica • 29 juni 2018 12:46

* zorgt ervoor dat je geen no preserve root nodig hebt

MrMonkE @Loggedinasroot • 30 juni 2018 15:37

Je linkt werk(niet) meer.

Loggedinasroot @MrMonkE • 30 juni 2018 15:41

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

MrMonkE @Loggedinasroot • 30 juni 2018 15:44

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 @MrMonkE • 30 juni 2018 15:48

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 @Loggedinasroot • 30 juni 2018 16:19

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 @Saven • 30 juni 2018 14:38

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

wica @Chuk • 29 juni 2018 10:43

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 @wica • 29 juni 2018 11:27

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 @analogue • 29 juni 2018 12:31

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 @aaahaaap • 29 juni 2018 17:31

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

aaahaaap @Verwijderd • 29 juni 2018 19:05

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 @aaahaaap • 29 juni 2018 18:20

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

Verwijderd @Chuk • 29 juni 2018 10:38

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

m3gA @Verwijderd • 29 juni 2018 10:40

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_ @m3gA • 29 juni 2018 12:46

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 @m3gA • 29 juni 2018 10:50

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 @HollowGamer • 29 juni 2018 10:58

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

MadEgg @Archcry • 29 juni 2018 11:08

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 @MadEgg • 29 juni 2018 11:27

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 @Archcry • 29 juni 2018 11:28

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 @Archcry • 29 juni 2018 18:23

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 @MadEgg • 29 juni 2018 13:06

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 @RoestVrijStaal • 29 juni 2018 14:28

OS + applicaties = distributie.

DJMaze @Chuk • 29 juni 2018 10:45

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 @Chuk • 29 juni 2018 11:03

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 @Chuk • 29 juni 2018 12:27

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 29 juni 2018 10:37

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

DennusB @NiLSPACE • 29 juni 2018 10:39

Die kans lijkt me vrij klein!

MiesvanderLippe @DennusB • 29 juni 2018 10:47

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 @MiesvanderLippe • 29 juni 2018 11:06

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 @NiLSPACE • 29 juni 2018 10:55

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 @sumac • 29 juni 2018 10:59

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

sumac @NiLSPACE • 29 juni 2018 14:04

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 Moderator Devschuur® @sumac • 29 juni 2018 12:39

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

sumac @.oisyn • 29 juni 2018 14:03

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

Bitmaster @sumac • 29 juni 2018 14:09

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 @NiLSPACE • 29 juni 2018 10:41

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 @NiLSPACE • 29 juni 2018 12:24

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 @NiLSPACE • 29 juni 2018 14:47

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 29 juni 2018 10:41

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 @Stoelpoot • 29 juni 2018 10:47

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 @Smuey • 29 juni 2018 10:51

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 @Stoelpoot • 29 juni 2018 11:12

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 @MadEgg • 29 juni 2018 11:19

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 @Stoelpoot • 29 juni 2018 10:50

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 @Stoelpoot • 29 juni 2018 10:56

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 @Stoelpoot • 29 juni 2018 10:56

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 @HollowGamer • 29 juni 2018 11:03

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 @Stoelpoot • 29 juni 2018 13:21

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

Stoelpoot @Robthebest • 29 juni 2018 13:25

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 @Stoelpoot • 29 juni 2018 13:28

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® @jimshatt • 30 juni 2018 15:31

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

MrMonkE @Mocro_Pimp® • 30 juni 2018 15:41

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® @MrMonkE • 30 juni 2018 15:46

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 @Mocro_Pimp® • 30 juni 2018 15:47

$_/-\o_$

Sandor_Clegane 29 juni 2018 10:43

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

MiesvanderLippe @Sandor_Clegane • 29 juni 2018 10:48

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 @MiesvanderLippe • 29 juni 2018 10:56

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

RagingRaven @Sandor_Clegane • 29 juni 2018 11:26

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 @Sandor_Clegane • 29 juni 2018 11:42

"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 29 juni 2018 11:00

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 @HollowGamer • 29 juni 2018 13:42

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

mrdemc @HollowGamer • 29 juni 2018 13:59

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 29 juni 2018 17:29

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]