Hackers verkrijgen toegang tot server van programmeertaal Haskell

Onbekende hackers hebben toegang verkregen tot een server waarop de Debian-packages voor de Haskell-programmeertaal stonden. De server zou al sinds 12 februari gehackt zijn. De mogelijke gevolgen van de hack zijn nog niet bekend.

Op de website van Haskell, een functionele programmeertaal, is te lezen dat onbekenden enige tijd toegang hadden tot de server deb.haskell.org. Deze server bevatte diverse pakketten voor de Linux-distributie Debian, waaronder de zogeheten Glasgow Haskell Compiler. Nadat het hostingbedrijf verdachte activiteiten op de server had gesignaleerd, besloten de beheerders om de server offline te halen.

De Haskell-site zou sinds 12 februari toegankelijk zijn geweest voor de aanvallers, maar er zou relatief weinig tijd zijn geweest om de aangeboden Haskell-packages te manipuleren. Een onderzoek naar de aanval loopt nog, onder andere naar de vraag of er mogelijk meerdere servers zijn aangevallen. Desondanks is er onder Debian-gebruikers die met Haskell programmeren enige onrust ontstaan over de vraag of er mogelijk sleutels voor het ondertekenen van de packages zijn bemachtigd en of de aanvaller mogelijk toch backdoors in de code heeft kunnen aanbrengen.

Reacties (32)

[CurlyMo]

Zover ik het lees kan ik de setup van Haskell redelijk vergelijken met de onze bij XBian en de mijne bij pilight.

In de lijst van hun server kan je zien dat ze de volgende belangrijke server hebben:
- Git server: daar staat de ruwe code van haskell.
- Debian builds: daar staat de deb pakketten voor het distribueren van Haskell op Debian verwante linux versies.

De debian build server cloned / pulled om de zoveel tijd de sourcecode van de Git server en compileerd deze geautomatiseerd. Vervolgens wordt er van deze gecompileerde code een deb pakket gemaakt.

Als dit klopt, dan is het probleem bij Haskell zelf eigenlijk maar heel beperkt. De originele code staat op de Git server en die is niet gehacked. De debian build server doet niks anders dan compileren en deb pakketten maken. Als ze een backup hebben van hun scripts, dan is het zo simpel als opnieuw die server installeren + beveiligen en hun scripts (verbeteren en) terugzetten.

Als je in die periode Haskell hebt geïnstalleerd, dan doe je gewoon even een downgrade via apt en hercompileer je je software: apt-get install haskell=x.x.x

Zodra de nieuwe veilige versie er weer is kan je simpelweg een apt upgrade doen en je installeert weer automatisch de laatste veilige versie.

Als mijn aannames kloppen en overeenkomen met onze build infrastructuur, dan is Haskell zelf niet gehacked, zitten er ook geen verborgen backdoors in de code, is ook de compiler niet gehacked enz. Het enige wat er is gebeurt is dat de deb pakketten zijn geïnfecteerd.

Dat betekent niet dat dat laatste geen grote gevolgen kan hebben voor de gebruiker. Mogelijke scenario's die ik zou toepassen als ik deze hacker zou zijn geweest:
- Een eigen deb pakket op hun server zetten. Vervolgens er een dependency naar toevoegen aan hun deb.
- Via een postinst script eigen code injecteren in systeembestanden.
- Als het zich als een virus gedraagd een simpele rm -rf /* in de postinst zetten.

Iedereen die in de tussentijd deze Haskell versie heeft geïnstalleerd doet er dus ook goed aan de broncode van deb pakket te controleren. Deze is voor elk pakket hier te vinden /var/lib/dpkg/info/[naam].*. Voorbeeld:

# ls -1 /var/lib/dpkg/info/apt*
/var/lib/dpkg/info/apt.conffiles
/var/lib/dpkg/info/apt.list
/var/lib/dpkg/info/apt.md5sums
/var/lib/dpkg/info/apt.postinst
/var/lib/dpkg/info/apt.postrm
/var/lib/dpkg/info/apt.preinst

Controleer daarna ook de *.list zorgvuldig en vergelijk deze met de *.list na een down- of upgrade. Kijk of er bestanden instaan die niet in de originele deb zitten.

Als dat allemaal schoon is, dan is een simpele hercompilatie van je Haskell code voldoende.

[Reactie gewijzigd door CurlyMo op 23 juli 2024 13:01]

[afraca]

DIt is een redelijk prima overzicht. Echter lijkt het eerste deel van je reactie te insinueren dat het best meevalt, en je met een tijdelijke downgrade gewoon veilig zit. Feit is dat, zoals je in het tweede deel beter naar voren brengt, de packages zelf gewoon enorm veel schade kunnen veroorzaken, of zich kunnen nestelen op vervelende plekken. Het is waar dat voor het distributieteam ze hun infrastructuur kunnen herstellen. Er moet echter wel werk gebeuren in onderzoeken wat er eventueel veranderd is in de builds.

edit: Zie mijn andere reactie. Het zou hier gaan om nightlies, dus is de impact iets minder dramatisch, in de context van het aantal mensen dat er last van heeft.

[Reactie gewijzigd door afraca op 23 juli 2024 13:01]

[CurlyMo]

Ik zeg niet dat het meevalt voor de eindgebruiker. Ik zeg dat de schade meevalt voor Haskell zelf. Hun code is zeer waarschijnlijk niet aangetast.

Als dit klopt, dan is het probleem bij Haskell zelf eigenlijk maar heel beperkt.

en

Dat betekent niet dat dat laatste geen grote gevolgen kan hebben voor de gebruiker.

[hardwareaddict]

Keep dreaming, niemand controleert van die historisch oude interpreters.

Je statement is dus echt compleet uit de lucht gegrepen. De simpelste manier om wat dan ook te hacken is door te zorgen dat je de compilers en met name de interpreters in je zak hebt zitten als organisatie.

[afraca]

Het gaat om niet algemeen verspreide builds, namelijk enkel een soort nightlies:

For the record, the hosted files were daily builds of HEAD. Despite the domain name, these packages did not have "official status" anywhere and were not distributed outside of that site to our knowledge.
In fact there are very few users that we know of -- to the point that when the site went down, there were no reports filed or complaints made.
That said, when the service gets up and running again, the key will indeed need to be replaced.

[Johan9711]

Hopelijk is er dan geen backdoor in de code gebouwd. Wanneer er backdoors in de programmeertaal zelf zijn ingebouwd, is dat lastig te controleren, je moet immers op een ander niveau gaan zoeken.

[kwikstaart]

Ze zullen toch wel Git of SVN gebruiken? Dan is een vergelijking van de code geen groot probleem. Er zullen elders vast wel backups van de geschiedenis beschikbaar zijn, zodat die ook vergeleken kunnen worden. Zo kun je relatief snel zien of er met de code geknoeid is.

[Oljoner]

Op je code hebben die paketten geen invloed (tenzij ze gehacked zijn om je code aan te passen en te comittten op svn, maar dat is vergezocht en valt enorm op).

Het probleem zou kunnen zijn dat:

• je gecompileerde binary malware bevat.
• tijdens het compileren of runnen van de binary, je systeem gecompromiteerd werd

[jozuf]

Als de GIT of SVN service dan maar niet lokaal draait
Anders kan je als aanvaller ook wel zorgen dat je veranderingen niet opvallen...

[Blubber]

Als de GIT of SVN service dan maar niet lokaal draait
Anders kan je als aanvaller ook wel zorgen dat je veranderingen niet opvallen...

Dat kan bij Git niet, dat is een van de voordelen van een gedistribueerd VCS. Iedere ontwikkelaar heeft zijn eigen repo, dus het manipuleren van de repo op een plek heeft geen zin.

[BillyTheClit]

Je kan nog altijd teruggrijpen naar de laatste goede back-up.

[Johan9711]

De server zou al sinds 12 februari gehackt zijn.

Dat is al zes dagen terug. Een developer zit geen 6 dagen stil...

[SuperDre]

Nee, dat klopt, maar je kunt dus wel gewoon de code die de afgelopen dagen is toegevoegd controleren, en dat zou sowieso moeten gebeuren...

[Verwijderd]

Ik vermoed dat @Johan9711 refereert aan alle code die allerlei mensen de afgelopen dagen geschreven hebben, gebruikmakend van een potentieel corrupt Haskell package.

[SuperDre]

tja, das niets meer dan een recompile met de laatste gecontroleerde versie.. Maar je hebt gelijk, als er in de afgelopen dagen op basis van deze mogelijk besmette compilers productie is gecompileerd, dan is het zeker noodzaak om het goed te controleren..

[Johan9711]

Ik heb niet veel verstand van Haskell, maar ik neem aan dat die server een compile server is?

[Verwijderd]

Ik denk dat er stiekem een installer van bonzibuddy erbij inbegrepen zit.

[svenslootweg]

Ik mag toch hopen dat de sleutels voor het ondertekenen van de pakketten zich niet op de server bevonden. Dat zou echt een behoorlijke security-blunder zijn.

[roy-t]

Hoe kan anders de server, die automatisch nieuwe packages maakt, de builds ondertekenen?

[svenslootweg]

Dat is dan dus ook precies wat je niet moet doen. Builds moeten sowieso op een aparte geisoleerde server gemaakt worden, en pas ná menselijke controle ondertekend worden.

Dat is nu juist het hele punt van package signing. Als jouw distributieserver ook de buildserver is en automatisch packages ondertekent, dan ga je in zijn geheel voorbij aan het security model.

[CurlyMo]

Feitelijk wordt er helemaal geen deb bestand ondertekend. Je ondertekend je apt repository bestanden. Deb bestanden hebben op zichzelf dus nagenoeg geen beveiliging. Het enige wat je kan doen is een lijst van md5 hashes van elk bestand toevoegen. Er veranderd geen enkele bit aan je deb zodra hij in een apt repository wordt opgenomen. Het compileren van je code op een andere server had in dit geval dus geen enkele zin gehad (mocht dat wel of niet al gebeuren). In ons geval bij XBian wordt wel alles gecompileerd op een eigen afgeschermde server los van de apt server.

Een apt repository biedt daarentegen wel meer beveiliging:
- Er wordt een Release bestand gemaakt waarin een MD5, SHA1 en SHA256 hash staat van je Package lijst. Bijv. http://apt.xbian.org/dists/stable/Release
- In de Package lijst staat vervolgens opnieuw een MD5, SHA1 en SHA256 hash van de deb pakket. Bijv. http://apt.xbian.org/dists/stable/main/binary-armhf/Packages.
- De verschillende Release bestanden bestaan ook in een ondertekende vorm, maar dan heten ze InRelease. Daar zit dan nog een GPG public key in die aangeeft dat het bestand met de key van de server is gegenereerd. Bijv. http://apt.xbian.org/dists/stable/InRelease. Die public key wordt ook aangeboden als Release.gpg. Bijv. http://apt.xbian.org/dists/stable/Release.gpg.

Als je een beetje begrijpt hoe de verschillende bestanden worden gegenereerd, dan kan je heel gemakkelijk met een shell script je eigen ondertekende apt repository opzetten. Dat is hoe ik dat zelf gedaan heb bij XBian en pilight.

Het doel van deze beveiliging is dus dat je niet zomaar de inhoud van een deb pakket kan veranderen zonder je repository opnieuw te genereren. Daarnaast beveiligd het tegen man-in-the-middle aanvallen. Als dus je fysieke server waarin de repository wordt gegenereerd wordt gecomprimeerd, dan is er niks wat je kan doen om malafide paketten te weren. Daar biedt apt gewoon geen beveiliging voor. Het enige wat je kan doen is je server zo beveiliging dat alleen de root gebruiker toegang heeft tot de daadwerkelijke GPG private key en de apt scripts.

Een deb zal dus maar in beperkte mate zijn eigen valide inhoud kunnen garanderen. Als je dus in staat bent om zelf een deb bestand op hun server te zetten en deze mee te nemen in de repository bij de volgende herbouw ervan, dan is niemand die het merkt, totdat iemand fysiek zijn repository gaat controleren.

[Reactie gewijzigd door CurlyMo op 23 juli 2024 13:01]

[svenslootweg]

Pardon? Je reactie slaat echt kant noch wal. Ik heb het hier over het compromitteren van de pakketten op de server, iets dat niet mogelijk is als je de signing key niet hebt.

[svenslootweg]

Wederom, je reactie slaat kant noch wal. Suggereer je hier dat een of andere intelligence agency RSA-keys gaat "breken", of heb je het ergens anders over?

[Infinitive]

Merk op dat - zover vermeldt - er alleen toegang bestond tot een specifieke distributie-server (Debian) . Een potentieel gevaar dus voor de huidige gebruikers ervan, en eventueel moeten er stappen ondernomen worden om toekomstige gebruikers te beschermen.

Overigens is het wat sterk verwoord om over Haskell als geheel te spreken, want de "echte" distributie is Haskell Platform i.c.m. Hackage, en die staan bovendien weer los van de sources van de package ontwikkelaars en de compiler (GHC).

[Reactie gewijzigd door Infinitive op 23 juli 2024 13:01]

[svenslootweg]

Debian is overigens erg verouderd als distro. Voor die single core firewalls, die zo lastig te kraken zijn, is het prima. Dual core lukt meestal ook nog wel, maar als je echt 2 sockets hebt en bende cores, dus Xeon machines, dan zitten er te veel race condities in.

Dat is voor het eerst dat ik dit hoor. Heb je daar meer informatie over?

[Reactie gewijzigd door svenslootweg op 23 juli 2024 13:01]

[baje]

Wie doet het onderzoek naar deze aanval? En in het algemeen naar (kleinere) aanvallen. De eigenaar of de politie of iemand anders?