Hackers kraken servers Linux-kernel

Vorige maand hebben hackers toegang gekregen tot een aantal servers die worden gebruikt om de Linux-kernel te verspreiden. De gevolgen van de hack vallen waarschijnlijk mee: het is onwaarschijnlijk dat de broncode van Linux is gewijzigd.

In een mededeling op de voorpagina van Kernel.org wordt melding gemaakt van de hack, die op uiterlijk 12 augustus plaatsvond; dat staat in een mail die naar de Kernel.org-mailinglist is verzonden. De hack werd 28 augustus ontdekt. Het is nog onduidelijk tot hoeveel servers de hackers toegang hebben gekregen.

Op in ieder geval één server wisten de hackers root-toegang te verkrijgen. Waarschijnlijk konden de hackers op deze server inloggen door een wachtwoord te achterhalen. Hoe ze vervolgens root-toegang hebben verkregen, is nog onbekend. Bij de aanval werden bestanden van openssh gewijzigd en is een trojan geïnstalleerd. Ook werden alle interacties met gebruikers gelogd.

De Linux-developers ontdekten de hack toen in een logfile foutmeldingen van een niet-geïnstalleerd pakket opdoken. Het is op dit moment nog onduidelijk of de hackers broncode van de Linux-kernel hebben gewijzigd, maar dat is onwaarschijnlijk: dat zou zijn opgemerkt, omdat voor elk bronbestand een sha1-sleutel wordt gegenereerd die na wijziging niet meer zou kloppen.

Zijn er toch bronbestanden gewijzigd, dan zijn de gevolgen waarschijnlijk nog steeds beperkt. Vrijwel alle Linux-users gebruiken een Linux-kernel die met een distributie wordt meegeleverd. Alleen developers van Linux-distro's of do it yourself-knutselaars die zelf een Linux-kernel hebben gecompileerd, zouden in dat geval kwetsbaar zijn.

Op dit moment is Kernel.org bezig met het herinstalleren van de getroffen servers en wordt een analyse van de code uitgevoerd, om er zeker van te zijn dat er echt geen broncode is gewijzigd. Ook zijn de opsporingsautoriteiten in de Verenigde Staten en Europa ingelicht. De 448 gebruikers van Kernel.org moeten hun wachtwoorden en ssh-sleutels wijzigen.

Update, 9:26: Informatie over de mailinglist-melding toegevoegd.

Reacties (111)

[the_shadow]

Ik vind het mooi om te zien hoe mensen met twee standaarden kunnen meten. Bij hacks op een commercieel bedrijf (ik heb het nu even niet over DigiNotar, maar over bijvoorbeeld een RSA of een ander security bedrijf), dan schreeuwt iedereen hier dat het maar goed is dat dit gebeurt. Nu wordt de server met daarop de volledige source van de Linux kernel gehackt, en mensen noemen het opeens "hackers met geen leven" en vandalisme.

Het feit dat RSA weet-ik-hoeveel tokens terug heeft moeten roepen, maar waardoor alles weer veilig is wordt in het niet gelaten. Nu moet er een volledige audit worden gedaan van de Linux source, maar de absolute garantie dat er niet toch nog een paar regeltjes code als backdoor zijn achtergebleven is natuurlijk niet gegarandeerd te geven. Toch wordt dit door de meesten hier als "beter" bestempeld, dan wat commerciele bedrijven doen als ze gehackt worden.

Een hack is een hack, een fix is een fix. Dat dit nu bij kernel.org gebeurt, maakt het niet schrikbarend erger dan wanneer het bij een groot beveiligingsbedrijf gebeurt.

[psyBSD]

Je hebt gelijk dat er het lijkt alsof er hier met 2 maten gemeten wordt. Er zijn echter een paar details die hier soms niet worden vermeld die wel relevant zijn voor de discussie.

Bij de ontwikkeling, en het gebruik van het Source-Code-Management systeem dat gebruikt wordt voor de ontwikkeling van de linux-kernel is rekening gehouden dat dit vroeg of laat een keer zou gebeuren.

De architectuur van git stelt ELKE ontwikkelaar instaat om binnen enkele minuten een audit uit te voeren op ELKE versie van linux die ooit is gereleased. Mocht er een probleem zijn met de linux-kernel die in de git-repository op kernel.org staat dan kan doormiddel van een bestaande clone van een willekeurige ontwikkelaar het probleem hersteld worden.

Tevens is er een verschil in de manier waarop er over deze hack wordt gecommuniceerd. De hack is op 28 augustus (lees: zondag j.l.) ontdekt, men heeft 3 dagen de tijd genomen om de impact van de hack te analyseren, en komt vandaag naar buiten met de eerste bevindingen.

DigiNotar (om een voorbeeld te noemen) had geen adequate voorzorgsmaatregelen en procedures klaar liggen om om te springen met een eventuele hack. Hebben ze de verkeerde beslissingen genomen om de risico's te elimineren, en vervolgens hebben zij de hack, na ontdekking, verzwegen. Zij hebben hier pas over gecommuniceerd 'dat ze ervan op de hoogte waren', nadat bekend werd dat er mensen gedupeerd zijn (lees: mogelijk in levensgevaar verkeren), 1.5 maand nadat de hack heeft plaatsgevonden.

Als ik dit alles samenvat kan ik mij wel voorstellen dat er op een andere toon wordt gesproken over de 2 incidenten.

[the_shadow]

Met betrekking tot DigiNotar ben ik het met je eens, daar is niet adequaat gehandeld. Echter, er zijn de afgelopen tijd nog meer hacks langs gekomen, en dan bij met name de grote beveiligings firma's wordt er fel gereageerd. Het door mij genoemde RSA heeft in mijn ogen correct gehandeld: de tokens waarbij er niet meer gegarandeerd kon worden dat ze veilig werkten zijn terug geroepen, en nieuwe zijn verschaft aan de gedupeerden. Prima manier van handelen, ook al kost het ze veel geld. Maar toch wordt dit hier niet gewaardeerd. Ook is het zo dat als andere sites gehackt worden en er worden gebruikersgegevens buit gemaakt en online gezet, dan wordt dit hier nog wel eens bestempeld als "goed dat het zo gebeurt", terwijl niet het bedrijf, maar de gebruikers hier voornamelijk last van hebben.

Dat de repository weer hersteld kan worden, dat klopt, maar het is natuurlijk de vraag of er niet code is binnengesmokkeld op de een of andere manier. Ik weet niet hoeveel mutaties er worden gedaan, maar dan is 1 extra commit natuurlijk snel over het hoofd te zien. Ik hoop dat de audit snel afgerond kan worden en dat het reguliere werk aan de kernel weer voortgezet kan worden.

[freaky]

Je moet daar nog wat aan toevoegen.

Diginotar zijn taak is primair het garanderen van authenticiteit (vertrouwen). De kernel servers hun taak is primair het mogelijk maken van gezamenlijke ontwikkeling van stukken code (ze hosten meer dan alleen de kernel). Audits van code komen inderdaad achteraf.

De 2 instanties zijn compleet anders. Een CA hoort 24/7 aanvallen te monitoren. Zodra een CA certificaat op straat komt te liggen is dat schadelijk voor hun 100.000'en klanten, gezien het complete CA certificaat geannuleerd moet worden en geen van die certificaten dan nog vertrouwd wordt. Om nog maar niet te spreken over de problemen met het uitrollen van een evt. nieuw CA certificaat naar bestaande apparaten... Niet iedereen heeft de mogelijkheid even op update te klikken, zeker niet met mobiele apparaten e.d.

Een hack is een hack, een fix is een fix. Dat dit nu bij kernel.org gebeurt, maakt het niet schrikbarend erger dan wanneer het bij een groot beveiligingsbedrijf gebeurt.

Whow, mag ik je beveiling komen doen? Ik wordt graag je betaalde bodyguard die nooit in je buurt is maar wel incasseert... Als je neergeknuppeld wordt, wordt je neergeknuppeld, het maakt niet uit of dat gebeurt als je wel of geen bodyguard hebt ingehuurd toch? Het ligt uiteraard iets genuanceerder maar het maakt wel degelijk (een hoop) verschil.

[fdh]

1. Een hack met de bedoeling schade aan te richten, persoonlijke gegevens publiek te dumpen of eigen gewin is nooit goed.

2. Een hack om een kwetsbaarheid aan te duiden, waarbij enkel de site / server verantwoordelijke op de hoogte wordt gebracht en pas waneer die geen stappen onderneemt de media, is (meestal) te verantwoorden.

Stelling 1 ontslaat een bedrijf of organisatie niet van hun verantwoordelijkheid om hun klanten en gebruikers te waarschuwen als ze gehackt zijn.

RSA heeft uiteindelijk inderdaad veel tokens vervangen.
Maar pas nadat ze een tijd geen informatie wilden geven en alles minimaliseerden en zo hun klanten in de onzekerheid hielden.
Enkel nadat ze teveel weerstand kregen, zijn ze begonnen met te vervangen.

En naar mijn mening heeft hun oorspronkelijke reactie meer schade toegebracht dan de hack zelf.

[blouweKip]

Nu wordt de server met daarop de volledige source van de Linux kernel gehackt, en mensen noemen het opeens "hackers met geen leven" en vandalisme.

Ik heb juist de tegenovergestelde indruk, toen sony van miljoenen mensen gegevens liet stelen door nauwelijk aan beveilging te doen toen werd er massaal over de "hackers" gezeurd en was er nauwelijks aandacht voor de nalatigheid bij bedrijven, pas de laatste tijd is dat naar voren gekomen.

Dit is natuurlijk ook iets anders dan bij diginotar of sony, hier is het snel ontdekt en wordt er wat aan gedaan, bij commerciele bedrijven wordt er niets aan gedaan todat het een acuut probleem vormt.

[fdh]

Kijk, dat is nu een correct manier om om te gaan met een hack:

* waarschuwen van de gebruikers
* verplichten wachtwoorden te wijzigen
* herinstallatie servers
* audit uitvoeren om de impact van de hack vast te stellen

vergelijk dat met een response als: "we vonden het niet nodig om onze klanten op de hoogte te stellen".

Natuurlijk is het niet leuk om zo'n boodschap te moeten brengen, maar op de lange termijn is het de enige optie als je nog geloofwaardig en betrouwbaar wil zijn.

[raphidae]

Ik vind het anders redelijk beschamend dat op die servers blijkbaar sshd gewoon kan worden aangepast zonder dat er bellen gaan rinkelen en dat het uiteindelijk pas ontdekt wordt door een foutje van de 'hackers' (melding in de logfiles).

Als die melding er niet was geweest, hoe lang had het dan geduurd vraag ik me dan af.

[Noxious]

Ik vraag me altijd af of er op dergelijke servers ook tools als rkhunter draaien en/of de output van deze wordt gecontroleert (alhoewel een hacker, eenmaal met root-access, deze gewoon kan stoppen uiteraard).

[GiLuX]

ja vreemd inderdaad, vermoed dat deze servers steen oud zijn.
je verwacht op zijn minst ossec dat moord en brand zou schreeuwen bij een bestandswijziging en selinux dat het heel erg lastig maakt om zaken aan te passen die niet toegestaan zijn.. ook al zou je root zijn.

[sfranken]

Ik denk dat die servers al vanaf begin jaren '90 draaien. OSSEC en selinux zijn misschien niet eens geinstallered

[cornedor]

Volgens mij is het niet zo heel lang geleden dat er nieuwe severs zijn geinstalleerd.
wel netjes:

What Has Been Done so far:

[list]
• We have currently taken boxes off line to do a backup and are in the process of doing complete reinstalls.
• We have notified authorities in the United States and in Europe to assist with the investigation
• We will be doing a full reinstall on all boxes on kernel.org
• We are in the process of doing an analysis on the code within git, and the tarballs to confirm that nothing has been modified
[/list]

[EnsconcE]

Dat is toch het hele concept van (Black Hat) hacken? Illegaal toegang verlenen en daar misbruik van maken om vervolgens niet ontdekt te worden. Dat dit gebeurd is te verwachten op elk systeem, dat het ontdekt wordt is het kat en muis spel.

Ik snap niet dat je dit beschamend vindt, ik vind dat een systeembeheerder zich pas moet schamen wanneer er gebruik is gemaakt van een known hack. Die vraag is nog niet beantwoord en aangezien de handelswijze op dit moment uitmuntend is (@fdh). Pas wanneer het volledige onderzoek is geweest en de schuldige is aangwezen kan je kijken of er iemand zich moet gaan schamen. Het is nu te vroeg om conclusies te trekken.

[Verwijderd]

Ach, dat is een beetje de geest van deze tijd. Zodra er iets vervelends gebeurt moet er een schuldige of zondebok worden aangewezen. Of het nou een hack van kernel.org betreft, criminele Marokkaanse jongeren, een moordpartij op een Noors eiland of een tbs-er op proefverlof die in de fout gaat: het moet en zal iets of iemands schuld zijn.
(respectievelijk de systeembeheerder, de Islam, Geert Wilders en de minister of de rechter.)

[Verwijderd]

beschamend van die serveradmins of gewoon goede hackers?

Kies jij maar

[Niemand_Anders]

Als je werkt met SSH-keys waarom moet je dan je wachtwoord wijzigen? Het wachtwoord (passphrase) staat namelijk helemaal niet op de server, maar in de sleutel zelf.

Dat een aantal gebruikers daadwerkelijk shell toegang zouden hebben zoals Linux en Cox is logisch, maar het merendeel heeft 'normale' login nodig en volstaat een ssh-keyonly login..

Overigens als de hackers root toegang hebben tot een kernel server, dan kunnen ze net zo gemakkelijk natuurlijk de checksums aanpassen waardoor een aangepaste kernel nauwelijks wordt opgemerkt.

Wel is het verstandig om te controleren of de hackers niet een extra ssh-key hebben toegevoegd aan een account met hoge rechten. Want dan zouden zij commits kunnen doen namens die persoon. Waarschijnlijk doen ze daarom ook een audit op alle commits op de main branch..

[SuperDre]

tja, dat is jouw mening... Een manager zal daar een hele andere mening over hebben..

[AlBundy]

Slechte managers bedoel je, die alleen maar aan centjes denken en niet aan hun gebruikers.

Een goede manager zal deze manier van werken toejuichen, omdat gebruikers direct actie kunnen ondernemen en eventueel verdere verspreiding kunnen voorkomen. Stel dat er toch code gewijzigd is en in deze kernels een soort worm is ingebakken die samen een botnet vormen, zoiets wil je niet te lang in de lucht hebben.

Stel dat jouw bank erachter komt dat ze een maand lang kwetsbaar zijn geweest en al jouw financiele gegevens, inclusief bijv. creditcardgegevens mogelijk door derden toegankelijk zijn geweest. Heb jij dan liever dat de bank het gat op dat moment snel dicht en het in de doofpot stopt? Of heb je liever dat de bank het direct naar buiten brengt zodat jij uit voorzorg je creditcard kan blokkeren?

[killercow]

Gelukkig is de overheid het met de meeste mensen hier eens.

Lek je prive data, of heb je mensen in gevaar gebracht, dan moet je ze hiervan op de hoogte stellen.

Managers die denken dat security issues beter onder de pet kunnen blijven mogen van mij per direct aangeklaagd worden voor het in gevraag brengen van het bedrijf, de klanten en de gegevens van derden die in de gekraakte systemen bewaard / bewerkt werden.

[Tidob]

Ik kan nou niet bepaald een goede reden bedenken waarom je Linux zou hacken. Windows, oké, dat scheelt weer 90 euro, maar Linux? Is dit niet gewoon puur vandalisme uit verveling?

[xburchartz]

Niet? Als je als hacker er nou in zou slagen om een permanente backdoor te verkrijgen die niet opgemerkt wordt, dan kun je in de toekomst in elk Linux-systeem binnenkomen... lijkt me toch best wel substantieel...

[cornedor]

However, it's also useful to note that the potential damage of cracking kernel.org is far less than typical software repositories. That's because kernel development takes place using the git distributed revision control system, designed by Linus Torvalds. For each of the nearly 40,000 files in the Linux kernel, a cryptographically secure SHA-1 hash is calculated to uniquely define the exact contents of that file. Git is designed so that the name of each version of the kernel depends upon the complete development history leading up to that version. Once it is published, it is not possible to change the old versions without it being noticed.

[Korben]

Je bent wel een enorme ninja als je een bestand met C-code (of nog erger, ASM) kunt aanpassen zodat het compilet, werkt, een backdoor introduceert en dit allemaal zonder dat zelfs een CRC32-hash verandert.

[MSalters]

crc32? Eitje. Met C, maar ook met ASM. Beiden hebben free-form commentaar mogelijkheden. Zelfs binary code is relatief eenvoudig, dankzij wat vrije velden in de exe headers. Je maakt gewoon de wijzigingen die je wil maken, kijkt wat de "verkeerde" CRC-32 code is, en rekent terug wat je in je commentaar moet zetten om je CRC terug te krijgen.

[RielN]

Ze hebben een server gehacked waar linux-kernels gehost worden. Jij denkt nog een paar stappen te ver

[Verwijderd]

Mooi cowboy verhaal, maar dat soort dingen gebeuren enkel in films.

Het is niet zo dat codewijzigingen zomaar in het wild gebeuren;

hashing, versioning, diffs, enz.

Het is niet zo dat ze nu de complete code moeten gaan napluizen om te zien of er backdoor is. Ze vergelijken gewoon de code-tree van nu met de code-tree van voor de inbraak.

[Verwijderd]

Linux wordt op heel veel servers gebruikt die een website hosten. Elke hacker zou daar een achterdeur in willen hebben. En wat is er makkelijker dan je achterdeur in de linuxkernel weten te krijgen. Dan hoef je alleen nog maar te wachten tot de servers een update op de kernel uitvoeren en je hebt de eerste voet tussen de deur.

[rob12424]

Dan nog, deze hack komt echt wel naar boven: binnen 30 dagen hebben ze hem waarschijnlijk net gepatched en moetie nog getest worden. Dan praat ik over distro's zoals debian ,red Hat, Suse en IBM.

Als de broncode zelf is gehacked dan is dat gevaarlijk voor rolling distro's en Vannilla kernel gebruikers en iedereen weet dat je die niet in een productie omgeving moet gebruiken! (Arc, enz.)

Het is bekend dat zowel Red Hat en IBM een aantal supercomputers hebben die NA dat een kernel gepatched is (en dat duurt meestal langer als 30 dagen) alle fouten eruithalen die erin zitten. Dit gaat dan niet alleen maar om debuggen maar deze computers zijn intelligent genoeg om zelf/en soms met behulp van een systeembeheerder, virtuele netwerken aan te maken en elkaar aan proberen te vallen. (dit gaat vooral om penetratie-testing en niet om dossen al kunnen ze dat ook)

De trojan wil waarschijnlijk achterhalen wie allemaal een kernel gedownload hebben zodat ze deze kunnen traceren en hacken.
Zoals de meeste mensen weten moet je nooit een vannilla kernel in een productie omgeving gebruiken of je moet weten wat je doet! Vaak hebben deze mensen ook RK hunter draaien en dergelijke (denk aan LIDS --> Linux Intrussion Detection System, SELINUX, Apparmor) En goeie firewalls.

Oftewel een hacker komt binnen LIDS detecteerd het, logs van Apparmor en dergelijke zien het gelijk en SElinux slaat ook allarm.

Oftewel dit is wel een beetje een storm in een glas water.

[sfranken]

De kernel zelf is niet gehacked/aangepast. De server waar 't gehost werd (waarschijnlijk een van de servers van kernel.org's CDN) is gehacked. Das nogal een verschil, en zoals hierboven word vermeld merk je een hack snel op met behulp van diffs, hashing en versioning.

Bovendien gaan de releases zo snel dat een hack snel opvalt door bovengenoemde drie methodes.

[Verwijderd]

Ze hebben Linux niet gehacked, maar servers van kernel.org.

[Verwijderd]

En die servers draaien op ? Linux natuurlijk. Maar "hack" in dit geval wel in de ruimste zin des woords als er inderdaad een password bekend was bij de dader of daders. Daar is natuurlijk weinig tegen bestand al blijft het de vraag hoe ze vervolgens root access konden krijgen zonder dat er alarmbellen gingen rinkelen.

Ik verbaas me wel over opmerkingen hierboven van mensen die niet begrijpen hoe aantrekkelijk het is om toegang tot deze servers te krijgen. Dat kantooromgevingen nou bijna 100% windows zijn zegt niets over de verhoudingen binnen de servermarkt. Ontzettend veel databases, ISP's en financiele systemen draaien op Linux. En dat is veel interessanter dan server X met daarop een zooitje correspondentie in word.

[Elmo_nl]

Ik kan nou niet bepaald een goede reden bedenken waarom je Linux zou hacken.

Nou, uit het artikel: Bij de aanval werden bestanden van openssh gewijzigd en is een trojan geïnstalleerd.

Dan zouden (indien onopgemerkt gebleven) veel gebruikers 'jouw' aangepaste versie van openssh met trojan downloaden en gebruiken op hun servers/systemen. Dan heb je in theorie toegang tot die systemen en/of kun je het ssh verkeer afluisteren afhankelijk van wat die wijziging precies inhoud.

[arjankoole]

Dan zouden (indien onopgemerkt gebleven) veel gebruikers 'jouw' aangepaste versie van openssh met trojan downloaden en gebruiken op hun servers/systemen. Dan heb je in theorie toegang tot die systemen en/of kun je het ssh verkeer afluisteren afhankelijk van wat die wijziging precies inhoud.

Dat is echter niet de situatie hier. Ik ken die openssh trojan wel, ik ben 'm ook eens tegengekomen op een server. Die trojan stelt de hackers in staat om triviaal terug te komen op het systeem als root met een speciale username en wachtwoord (sn0w/letmein was er eentje, dacht ik - maar ik kan me vergissen). Die user hoeft niet lokaal te bestaan, als de getrojande openssh die username ziet, laat ie je direct binnen met een root shell.

Van de Linux kernel servers kun je echter niet openssh downloaden (AFAIK), maar wel de linux source. Het is dus puur een methode geweest voor de hacker om z'n toegang tot het systeem veilig te stellen, en op die manier z'n echte 'werk' te gaan doen.

[roy-t]

Ze hebben de servers waar de broncode op staat gehackt zodat ze een achterdeurtje konden inbouwen om zodadelijk iedereen die deze versie, of een nieuwere waar dit achterdeurtje nog steeds in zit kwetsbaar is voor hackers.

Je ziet steeds vaker dit soort aanvallen op de servers van Linux distributies, het wordt steeds moeilijker om te garanderen dat er geen achterdeurtjes zitten in Linux, de kernel is ontzettend complex, niemand kent alle regels code, en het is lastig/onmogelijk om alles te controleren voor elke release.

[Mellow Jack]

Wat ze al aangeven, als je kijk naar de hash kan je om en nabij (niet exact) zien of iets is veranderd. Dit is een vrij goede manier om te controleren of iets wat je verstuurd ook is was jij denkt dat het is. Dit wordt steeds vaker ook gebruikt bij wat kleinere downloads en werkt prima naar mijn mening

[Verwijderd]

Een hash-controle is valide voor een 'random'-wijziging, meestal door een technische fout. Het is echter goed mogelijk om nieuwe code te voorzien van dezelfde hash als oude code.
(als dit niet zo zou zijn zou je uit de hash de originele code weer kunnen herleiden, en dat is natuurlijk niet het geval.)

[Keneo]

Dit is in theorie inderdaad mogelijk. Echter bij het gebruik van SHA-1 is het in de praktijk niet echt gemakkelijk.

SHA-1 (secure hashing algorithm) is met opzet zo opgesteld om het vinden van collisions zeer moeilijk te maken, de aanpassing van 1bit in de input heeft invloed op alle outputbits, en deze invloed is niet-lineair.

Het vinden van een collision is mogelijk, maar komt overeen met bruteforce vinden van een correcte hash, of met wat optimalisaties (wegens fouten die gevonden zijn in sha-1) 2^51 hashes.

Bij md5 is dit 2^21.

Als men nu een SHA1 EN md5 hashwaarde gaat publiceren is het heel erg onwaarschijnlijk dat er een tekst gevonden wordt die een collision is voor alletwee deze hashes.
(En dan nog eens onopvallend is)

Echter, als men root toegang tot de servers heeft kan men ook de gepubliceerde hash waarden aanpassen.
Het is dus niet omdat de hash overeenkomt dat je alles kan vertrouwen, er moet door de webmaster ook gekeken worden of de gepubliceerde hashes niet opeens aangepast zijn.

[MSalters]

SHA en MD5 is overbodig. Je kunt beter wat extra bits en SHA2 gebruiken. SHA2-256 is beter dan de combinatie van SHA-1 en MD5. De probleempjes met SHA zijn zo klein (niet alle bits zijn zo onafhankelijk als ze zouden moeten zijn) dat wat extra bits een afdoende fix zijn.

Overigens is de kans voor een collision niet relevant voor kernel.org. Daar moet je een pre-image aanval voor uitvoeren. Zelfs als dat het geval zou zijn, dan is kost het nog geen 2^51 hashes. De publicatie die een theoretische aanval in 2^52 hashes claimde is teruggetrokken, en er is nog nooit 1 daadwerkelijke collision gepubliceerd.

[ThomasG]

In theorie is dat mogelijk ja. Maar probeer jij maar eens een wijziging aan te brengen die zowel de zelfde hashcode als bestandsgrootte heeft. Dat is extreem moeilijk, en als het al is gelukt om dat het zelfde te krijgen is het nog maar eens de vraag of de source cobe überhaupt nog werkt.

Daarnaast is het natuurlijk veiliger om meerdere hash functies te gebruiken. Bijvoorbeeld zowel met md5 als sha1 hashen, ipv alleen md5 of alleen sha1. En natuurlijk de bestandsgrootte meenemen, dan weet je zeker dat er niets veranderd is, of kan zijn.

[Goderic]

Dat is inderdaad mogelijk.
Echter, de kans dat je én code vindt die dezelfde hash oplevert én dat code is die überhaupt werkt én code is die niet opvalt (allemaal willekeurige commentaar tussen de code steken zou je kunnen helpen, maar dat valt wel erg op) is gelukkig kleiner dan de kans dat je morgen Euro Millions wint zonder een lot te kopen.

[robvanwijk]

Het is echter goed mogelijk om nieuwe code te voorzien van dezelfde hash als oude code.

Om een stuk code in te voegen heb je (in het beste geval, als je maar op één plaats wijzigingen aan wil brengen, een bestand dat er schematisch zo uitziet:

-- Origineel --
[Voor de wijziging]
[Na de wijziging]

-- Aangepaste versie --
[Voor de wijziging]
[Wijziging]
[Na de wijziging]

Het is extreem moeilijk (zie ook de andere reacties hierboven) om die wijziging er zo uit te laten zien dat de hash hetzelfde blijft; hash-functies zijn daar juist op ontworpen. Het wordt extra lastig als die aanpassing niet alleen moet compilen, maar ook nog eens een specifieke taak moet vervullen. Vergeet het maar, dat lukt niet.
Alle methodes waar ik ooit van gehoord heb om een aangepaste versie van een document dezelfde hash te laten hebben als de originele versie, vertrouwen op het gebruik van een blok van honderden bytes om de interne variabelen van het hashen "gelijk te zetten" met het origineel:

-- Aangepaste versie --
[Voor de wijziging]
[Wijziging]
[Blok "random bits"]
[Na de wijziging]

Op zich kan dat wel, gewoon een blok commentaar gebruiken. Maar dan blijven er twee problemen over: het valt ontzettend hard op en de lengte van het bestand wordt groter. Dit laatste is nog op te lossen door wat "overbodige functionaliteit" eruit te knippen, maar dat blok met random bitjes kun je op geen enkele manier verbergen.

[Zer0]

Wat ze al aangeven, als je kijk naar de hash kan je om en nabij (niet exact) zien of iets is veranderd

En waar haal je die hash meestal vandaan? Dezelfde servers als waar je de code van download, en voor eventuele hackers was het een koud kunstje die hashes opnieuw te genereren.

[simplicidad]

Ze hebben de servers waar de broncode op staat gehackt zodat ze een achterdeurtje konden inbouwen om zodadelijk iedereen die deze versie, of een nieuwere waar dit achterdeurtje nog steeds in zit kwetsbaar is voor hackers.

Ik ben allesbehalve een linux aanhanger maar veel geluk met dat gezien hoe git (hashes) werkt. Tampering zou redelijk snel opvallen.

Dus al die ze hebben "backdoors ingebouwd" of ze hebben dat als doel is pure FUD.

[Reactie gewijzigd door simplicidad op 24 juli 2024 16:40]

[RobertMe]

Zoals simplicidad al aangeeft. De code van de kernel staat in Git. Git houd alle data middels "objecten" bij (blob voor een bestand, tree voor een directory en commit voor een commit). Over elk object wordt de SHA1 hash berekend en deze wordt gebruikt voor o.a. de betandsnaam en onderling linken (een commit verwijst naar een tree op basis van die hash, een tree verwijst naar bestanden en subdirectories op basis van deze hash etc.) Als je dus al een wijziging wilt doen in Git moet je zorgen dat van elk bestand wat je wijzigt de SHA1 hash hetzelfde blijft. Dit is IMHO een redelijke onmogelijke opgave. Daarnaast vertrouwd Git vertrouwd 100% op het niet tegenkomen van collisions (zelfde hash == zelfde file). Op het moment dat de kans op collisions zo groot is dat er ongezien hacks gemaakt kunnen worden, zal de kans op gewone collisions nog groter zijn, en dat is gewoon iets waar Git "niet tegen kan". Dus collisions zullen "onmogelijk" zijn.

Ook lijkt de kans dat de Git repo. van Linus zelf word aangepast redelijk klein. Aangezien hij de enige is die naar zijn (publieke) Git repo. zal schrijven. Op het moment dat op die repo. een commit wordt toegevoegd, kan Linus zelf niet meer pushen naar die repository (omdat zijn versie achter ligt op de server versie) en zullen er toch al allemaal alarmbellen gaan rinkelen.

Edit:
Overigens is het wel mogelijk om de tarballs op de server aan te passen. Hashes maken dan denk ik ook niet meer veel uit, aangezien de file met de hashes natuurlijk ook aangepast kan worden. Bij de tarball hoef je ook niet per file dezelfde hash te behouden, dus dat zou allemaal toch net wat makkelijker te hacken zijn. Maar aangezien niemand ontwikkeld op de tarballs worden eventuele hacks in de code van de tarball bij de volgende versie toch weer overschreven.

[Reactie gewijzigd door RobertMe op 24 juli 2024 16:40]

[Verwijderd]

Ze hebben de servers waar de broncode op staat gehackt zodat ze een achterdeurtje konden inbouwen om zodadelijk iedereen die deze versie, of een nieuwere waar dit achterdeurtje nog steeds in zit kwetsbaar is voor hackers.

Nee ,ze hebben de ftp servers via welke de linux kernel verspreid wordt gehacked.
Als ze de code permanent zouden willen aanpassen zouden ze de git server moeten hacken. De kans dat dit onopgemerkt gebeurt is nihil. Er zijn vele ogen op de code gericht.

Je ziet steeds vaker dit soort aanvallen op de servers van Linux distributies, het wordt steeds moeilijker om te garanderen dat er geen achterdeurtjes zitten in Linux, de kernel is ontzettend complex, niemand kent alle regels code, en het is lastig/onmogelijk om alles te controleren voor elke release.

Is dat zo?

Daarbij kan de distro dit zelf goed controleren ze hebben uiteindelijk de originele code. Die kunnen ze vergelijken met de gedistribueerde code. Tevens wordt rpm code gesigneerd, zonder de key kun je geen valide code ongemerkt distribueren. Ik neem aan dat de apt pakketten ook gesigned worden.

[Mirved]

Ze plaatste een trojan volgens het artikel. Dus het zijn gewoon criminelen die op die manier toegang wilde krijgen tot de 448 bedrijven die hier gebruik van maken.

[Mellow Jack]

Tot de bedrijven die gebruik maken van de diensten van de 448 gebruikers (let op dit zijn lang niet alleen maar bedrijven)

[cornedor]

448 mensen die toegang hebben tot linux.org. Je vergeet wel dat dat veel meer bedrijven/gebruikers zo die kernel kunnen downloaden.

[Verwijderd]

Als je nagaat hoeveel bedrijven hun servers op Linux hebben draaien is het heel aantrekkelijk om een backdoor in de kernel zelf in te bakken. Wanneer deze namelijk niet opgemerkt wordt is het mogelijk om bij alle bedrijven binnen te komen die jouw besmette kernel hebben ontvangen (en als dat via kernel.org gaat zijn dat een heleboel bedrijven)

[sfranken]

Fout. Heel veel bedrijven draaien Red Hat/CentOS en compileren hun eigen kernel niet. En Red Hat controleert kernels op backdoors en andere software (en voert optimalisaties uit enzo)

Alleen devs en hobby knutselaars draaien eigen kernels. Zoals ik dus.

[brutus]

Nee hoor, ook instellingen en bedrijven. Heel af en toe compileren we ook een eigen kernel zoals een paar jaar terug toen Firewire support niet/unsupported was in Redhat Enterprise kernels. En zo zijn er misschien nog wel meer redenen te bedenken om een custom kernel te draaien.

[daft_dutch]

Maar die worden dan toch gecompileerd van uit de source van je Distributie.
Vele malen makkelijker dan de vanila kernel te pakken

[brutus]

Dat kan, maar de vanilla firewire support werkte veel beter dan de Redhat kernel source modules, maar misschien dat ik hier een heel specifiek geval aanstip. Voor xfs support in RH5 bijvoorbeeld heb ik inderdaad wel altijd de Redhat kernel source erbij gepakt om specifiek de xfs modules te bouwen.

[pegagus]

In plaats van PC voor PC te hacken, pak je op deze manier alle PC's waar de kernel op wordt geïnstalleerd. En gezien het feit dat men met OpenSSH heeft zitten knoeien, was het blijkbaar te doen om het afvangen van bepaalde beveiligde verbindingen.

[sfranken]

Nee fout! De server die gehacked was is een file sharing server (CDN node) waar de broncode (in gecompileerde/getarde vorm) opstaat.

Aangezien de Linux Kernel Sources daar niet leven, maar op GitHub geloof ik. En zoals hierboven word vermeld word zo'n hack (ALS ze in de kernelsource hebben gezeten) snel opgemerkt aan de hand van een diff in git en hashing.

[Joseph]

Inderdaad, zoals Tidob aangeeft.

Deze hackers hebben geen leven. Linux is een vrijwilligers project, met eigenlijk geen geheimen. Héél véél mensen over de hele wereld hebben hier tijd in gestoken. Waarom gooi je juist zoiets plat?

Waarschijnlijk gewoon omdat ze het leuk vinden, en zich vervelen.

Dit zie ik dan ook inderdaad als vandalisme.

[Reactie gewijzigd door Joseph op 24 juli 2024 16:40]

[HerrPino]

Deze hackers hebben geen leven. Linux is een vrijwilligers project, met eigenlijk geen geheimen. Héél véél mensen over de hele wereld hebben hier tijd in gestoken. Waarom gooi je juist zoiets plat?

In een ideale wereld zonder criminelen en mensen met andere belangen dan die de rest heeft, dan zou men er vanaf gebleven zijn. Dan zou beveiliging in het algemeen niet nodig zijn, ook niet voor Windows, OSX of op je eigen voordeur. Maar ja, we leven niet in een ideale wereld.

Linux en veel applicaties zullen nog wel vaker aangevallen worden via de zwakste schakel van Linux en andere open source applicaties ... de source code.
- pak de sourcecode;
- bouw een trojan in;
- en hoop dat er mensen/bedrijven zijn die het installeren voordat het opgemerkt wordt;

[freaky]

Whow duidelijk geen voorstander van opensource met een struisvogel politiek mentaliteit.

Open source is juist de kracht, niet de zwakste schakel. Aan gesloten bron bestanden kun je ook code toevoegen, hoe denk je dat virussen zich in executables en libraries nestelen?

Die code kan tenminste ge-audit worden door mensen die het snappen. Ook mensen die niet bij het bedrijf in kwestie werken en jouw politieke standaarden hanteren. Stukken veiliger dan mensen die belang hebben bij struisvogel politiek.

[Dreamvoid]

Dat de code geaudit *kan* worden betekent niet dat die ook geaudit *wordt*.

[blouweKip]

Indien er grote belangen spelen dan wordt dat echt wel gedaan.
Feit is dat een open source code i.t.t wat pino roept dus niet een zwakke schakel is, maar juist een een van de sterke punten.

[Collen]

hmm, maar als je een backdoor in Linux hebt/maakt,
kun je weer wel bij andere relevante systemen die Linux draaien.

een bank bv, of het leger (ik noem maar wat)

dus de gevolgen gaan verder dan je denkt.

[Verwijderd]

De belangrijke systemen van het leger hangen niet aan het internet.

[sfranken]

Ik heb dit al drie keer getypt, dus lees deze reactie van mij even, dan weet je ook hoe het zit.

Of lees het artikel nogmaals goed. Dan weet je het ook.

[JAVE]

Hmm...

Hacken is wat anders dan een ddos aanval uitvoeren.
Linux is een stuk belangrijker dan Windows als je jezelf stiekum toegang wil geven tot belangrijke servers op het internet.
En in plaats van een nieuwe hack voor elke machine is een backdoor in de code van de Linux kernel plaatsen ideaal: 1 hack to rule them all.

[arjankoole]

Waarschijnlijk gewoon omdat ze het leuk vinden, en zich vervelen.

of commercieele belangen. Hacks en botnets zijn veel geld waard, en in de malware wereld gaan miljarden aan omzet om. Meer dan in de security sector die het moet bevechten.

[LOTG]

Alleen developers van Linux-distro's of do it yourself-knutselaars die zelf een Linux-kernel hebben gecompileerd, zouden in dat geval kwetsbaar zijn.

En die distro's halen de source niet daar vandaan?

Een zeer ernstige zaak toch, op deze manier zou er heel makkelijk een groot beveiligingsgat in Linux geslagen kunnen worden. Gelukkig word er op servers niet zo heel vaak en snel een kernel update gedaan dus die zullen niet geraakt zijn.

Stel je voor dat er iets was veranderd en de inbraak was nooit opgemerkt.

[psyBSD]

Als men een wijziging doorvoert in de git repository op kernel.org dan wordt dit opgemerkt door de ontwikkelaars. Git hangt nl aan alle kanten aan elkaar van sha checksums. Als men een commit aanpast klopt de checksum niet meer en wordt er vastgesteld dat er is gerommeld met de source.

Dan heb je slechts 1 ontwikkelaar nodig met een recente clone van de master-repository om alles weer te herstellen.

[Khaine]

De distro's halen hun kernels daar wel vandaan, alleen voeren die over het algemeen eerst een audit uit. Gewoon simpelweg de changelog bekijken van de kernelrevisie die je hebt, ten opzichte van wat er wordt geleverd. Daarom is de kans op een backdoor bij "officiele" distro's ook wat kleiner, die wordt namelijk wel opgemerkt.

DYI knutselaars gaan doorgaans niet checken wat er allemaal gewijzigd is in de nieuwe kernel. Hoogstens doen ze dit omdat ze wat compatitbiliteitsproblemen verwachten met reeds geinstalleerde paketten.

Het hele idee achter de kernel is ook dat de community genoeg audits uitvoeren om een eventuele bug (of kwaadwillend stuk code) geen kans te geven.

[3dfx]

Stel je voor dat er iets was veranderd en de inbraak was nooit opgemerkt.

Ja maar dat is het mooie aan Linux, het is open source dus je kunt zelf de broncode bekijken!!!!111111111

Om even de linux-lovers voor te zijn

[HerrPino]

Ja maar dat is het mooie aan Linux, het is open source dus je kunt zelf de broncode bekijken!!!!

Idd maar er zijn maar weinig mensen (ongeveer exact 0) die de source code bekijken en analyseren voordat ze hem installeren. Zie het als een EULA ... die leest ook niemand ... van vele miljoenen regels

[sfranken]

Oh? Dan ben ik 0. Ik voer ALTIJD een controle (md5 en SHA1) uit op de packages die ik van kernel.org afhaal.

Om twee redenen
1) FIle corruptie
2) File changes die niet horen

Ben blij dat ik het doe Kerel 3.0.4 was ook niet 100% in orde maar dat kwam door een download corruptie aan mijn kant.

[Mijzelf]

Als je een download corruptie had neem ik aan dat hij toch niet uitpakte/compileerde?

[RitBit]

En hoe los je dat dat op als de MD% dus ook is aangepast door de hackers (om deze weer te leten kloppen met de aangepaste code) ?

MD5 is alleen bruikbaar tegen download-corrupties...

Ik weet ook heel zeker dat ook jij die miljoenen regel code niet gaat zitten lezen, laat staat er alles van begrijpt....Zelfs Linus Torvalds of Alan Cox hebben al meerdere malen toegegeven geen 100% zicht meer te hebben op alle onderdelen van de linux kernel.

[Verwijderd]

een md5 en sha1 is nog niet in de code kijken..... jij bent 1

[rob12424]

Uhm zie mijn reactie hierboven:

En dan erbij er zijn genoeg hackers die zelf hun vannilla kernel compileren omdat ze een zo veel mogelijk low profile willen blijven!

Als je bijvoorbeeld wilt gaam hachen wil je alles checken wat inkomend en uitkomend verkeer kan generen. Daarom zijn er ook pc's met 32 gb ram of meer uitgevonden. Niet alleen voor virtualiseren en servers maar soms is iemand aan het hacken en denkt shit ben dat vergeten en moet dan on the fly compileren op een andere pc. (en geloof het of niet vaak worden die modules nog met floppy's overgezet.

Overigens veel blackhat en cracker clan's zullen ook al zeggen ze soms geen regels te hebben, bij dit soort geintjes je zonder twijfel uit de clan gooien.

[Verwijderd]

Zoals HerrPino al zegt, dat zal niet snel gebeuren (is het project te groot voor en er zijn weinig mensen met voldoende kennis) wat wel zo is is dat de SHA1 keys bekend zijn. Deze hash heeft er dan ook voor gezorgd dat we redelijk zeker zijn dat de code niet gewijzigd is.
Daarnaast is het voordeel van open source wel dat er overal kopietjes ronddwalen (zo niet bij Torvalds lokaal, ook al staat hij niet bekend om zijn back-up beleid) en er dus een diff kan worden gemaakt tussen de gehoste versie en de lokale versie van hetzelfde versie-nummer.

[Dreamvoid]

Hoeveel gebruikers maken na installatie van een nieuwe kernel een diff tegen een aantal andere 'trusted' versies? Mijn gok: niet een.

[sfranken]

Ik

[Verwijderd]

Hoeveel gebruikers maken na installatie van een nieuwe kernel een diff tegen een aantal andere 'trusted' versies? Mijn gok: niet een.

Ik niet, draai de laatste stable in de pclinuxos repos

[Xthemes.us]

Tijdens zijn GIT presentatie bij Google doet hij zijn backup strategie uit de doeken. Hij doet er niet aan. Er zijn altijd vele anderen die dezelfde gegevens hebben .
Niet alleen een erg goede programmeur ook presentaties geven kan hij uitstekend.

[hackerhater]

Dat is ook een vorm van backup
de bestanden staan op meerdere plaatsen

[Bafti]

Is er nergens ter wereld een uberhaupt een backup gemaakt van deze data of kijk ik hier nu te makkelijk tegenaan?

Ook de linux kernel is toch opensource. Of gaat het erom dat dit systeem miljoenen verschillende aangepaste kernels bevat, naast DE kernel?

Verder snap ik het doel van de hack wel. De hackers mogen er misschien niet in geslaagd zijn om iets in de kernel te implementeren, maar als ze dat wel gelukt was dan is er de mogelijkheid om een backdoor op ieder linux systeem te maken. Dit zou een risico zijn voor vele trouwe linux gebruikers maar bijvoorbeeld ook voor veel datacentra en supercomputers die linux draaien.

edit: en wat dacht je van android telefoons? die zijn ook gebouwd op een linux kernel.

[Reactie gewijzigd door Bafti op 24 juli 2024 16:40]

[psyBSD]

Elke kernel-ontwikkelaar heeft een backup.

Bron:
http://git-scm.com/about

[Wolfos]

Nee, er zijn vele mirrors van de Linux kernel.

[sfranken]

Ik denk niet dat Google z'n sources van Kernel.org afhaalt, maar zelf een servertje heeft staan ergens aangezien Android heel specefieke code is he

[Verwijderd]

Ik denk niet dat Google z'n sources van Kernel.org afhaalt, maar zelf een servertje heeft staan ergens aangezien Android heel specefieke code is he

Dat niet alleen ze draaien een oudere stable versie

[Verwijderd]

Al dat gezeur over dat er een backdoor zou zijn ingebouwd. Dan doe je toch gewoon een rollback van een revisie voor de hack. Tada probleem opgelost.

[psyBSD]

Als je met een ander SCM systeem werkt dan git dan heb je daar niets aan, ik kan nl gewoon een 'oude' commit in je SCM aanpassen. Dan zie je het verschil niet.

[itsoutthere]

Misschien een backdoor of zoiets inbouwen in de source die door iedereen gebruikt wordt?

[Verwijderd]

Is er aangifte gedaan nbij de politie. Inbreken is toch niet toegestaan. Alle schrijvers hebben het over veiligheid, verbeteren, enz. Nuttig maar allereerst is het ontoelaatbaar.

[Spider.007]

quote: http://tweakers.net/nieuw...servers-linux-kernel.html

Ook zijn de opsporingsautoriteiten in de Verenigde Staten en Europa ingelicht.

[source]

"vorige maand"... 4 dagen geleden.

[schoene]

Je wordt met deze opmerking naar beneden gemod, maar ik vind je opmerking wel terecht:
Vorige maand lijkt een lange tijd, en dan denk je 'waarom weten wij dit nu pas', terwijl de hack pas gebeurd is, en er dus een snelle respons gekomen is

edit: Joost je hebt gelijk, dus uiteindelijk was de hack toch bijna een maand geleden, maar er was wel een snelle response. Ik moet toch een beetje aandachtiger leren lezen

[Reactie gewijzigd door schoene op 24 juli 2024 16:40]

[Joost]

Hack was uiterlijk 12 augustus:

n een mededeling op de voorpagina van Kernel.org wordt melding gemaakt van de hack, die op uiterlijk 12 augustus plaatsvond; dat staat in een mail die naar de Kernel.org-mailinglist is verzonden. De hack werd 28 augustus ontdekt. Het is nog onduidelijk tot hoeveel servers de hackers toegang hebben gekregen.

[Verwijderd]

12 Augustus is iets meer dan 4 dagen geleden... Eerst lezen en dan fipo plaatsen.

[Eppo ©]

Voordat je commentaar gaat hebben:

In een mededeling op de voorpagina van Kernel.org wordt melding gemaakt van de hack, die op uiterlijk 12 augustus plaatsvond; dat staat in een mail die naar de Kernel.org-mailinglist is verzonden.

Update, 9:26: Informatie over de mailinglist-melding toegevoegd.

Source plaatste zijn bericht al om 9:19 en toen stond de 12 augustus nog nergens in het bericht vernoemd...

[Verwijderd]

"vorige maand"... 4 dagen geleden.

Vorige maand was gisteren nog...