Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

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.

Door Joost Schellevis

Redacteur

01-09-2011 • 09:15

111 Linkedin Google+

Submitter: Icingdeath

Reacties (111)

Wijzig sortering
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

Op dit item kan niet meer gereageerd worden.


Apple iPhone XS Red Dead Redemption 2 LG W7 Google Pixel 3 XL OnePlus 6T (6GB ram) FIFA 19 Samsung Galaxy S10 Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V.
Alle rechten voorbehouden © 1998 - 2018 Hosting door True