Rapport från undersökningen av intrånget på Debians servrar

2 december 2003

Debians administratörsgrupp och säkerhetsexperter kan till slut konstatera hur intrånget på fyra av våra projektmaskiner ägde rum. Den skyldige har dock ännu inte avslöjats.

Paketarkiven ändrades inte av inträngaren.

Debians administratörs- och säkerhetsgrupper kontrollerade tidigt under undersöknings- och återinstallationsproceduren att arkiven (säkerhetsuppdateringar, us, non-us) var intakta, varför projektet kunde åter kunde öppna säkerhetsarkivet och bekräfta att uppdateringen av den stabila utgåvan (3.0r2) inte påverkats.

Om projektet hade förutsett att utsättas för ett intrång samtidigt som en uppdatering av den stabila utgåvan skedde kunde de involverade personerna ha skjutit upp uppdateringen. De uppdaterade paketen hade dock redan installerats i den stabila utgåvans arkiv och på filspeglarna vid den tidpunkt intrånget upptäcktes, så det var inte längre möjligt att skjuta upp uppdateringarna.

Baserat på olika sorters styrinformation användes flera olika metoder för att verifiera paketen och försäkra att inträngaren inte hade ändrat arkiven:

Förlopp

Nedan beskrivs tidsförloppet vad gäller upptäckten av maskinerna det gjorts intrång på. Några av tiderna är uppskattade eftersom vår konversation inte innehöll exakta tidsstämplar.

Upptäckt

På kvällen (GMT), torsdagen den 20 november, upptäckte administratörsgruppen att kärnan på master utfört flera ”oops”:ar. Eftersom systemet kört utan problem under en längre tid var man på väg att ta ner systemet i underhållsläge för att vid en genomgående undersökning försöka hitta eventuella maskinvarufel. Samtidigt uppträdde dock exakt samma symptom på ytterligare en maskin, murphy, vilket gjorde administratörerna misstänksamma.

Dessutom har klecker, murphy och gluck ”Advanced Intrusion Detection Environment” installerat (paketet aide) för att övervaka ändringar i filsystemet och runt samma tidpunkt började det varna för att /sbin/init hade ersatts och att mtime- och ctime-värdena för /usr/lib/locale/en_US hade förändrats.

Ytterligare undersökning avslöjade att orsaken till båda dessa problem var rootkit:et SucKIT (1.3b). Det innehåller lösenordssniffning och funktioner för att förbigå upptäckt (dvs. verktyg för att dölja processer och filer) vilka installeras direkt i kärnan, vilka i sin tur orsakade oops:arna som noterades.

Utförlig analys av angreppet

På onsdagen den 19 november, runt klockan 17 GMT, användes ett sniffat lösenord för att logga in på ett oprivilegierat användarkonto på värden klecker (.debian.org). Angriparen hämtade sedan via HTTP källkoden för ett (då) okänt sätt att lokalt utnyttja ett fel i kärnan och uppnådde rootbehörighet via detta säkerhetshål. Därefter installerades rootkit:et SucKIT.

Samma konto- och lösenordsuppgifter användes sedan för att logga in på maskinen master, för att uppnå rootbehörighet via samma säkerhetshål och även där installera SucKIT.

Angriparen försökte därefter få tillgång till värden murphy med samma konto. Detta misslyckades eftersom tillgången till murphy är begränsad och dess uppgift enbart är att fungera som sändlisteserver, varför bara ett fåtal av utvecklarna har möjlighet att logga in på maskinen. Eftersom de första inloggningsförsöket misslyckades använde personen sin rootbehörighet till få tillgång till ett administrativt konto som används för säkerhetskopiering och fick tillgång även till murphy. Rootkit:et SucKIT installerades även på denna maskin.

Dagen därpå använde angriparen ett lösenord som sniffats från master till att logga in på gluck, uppnå rootbehörighet där och även där installera rootkit:et SucKIT.

En teknisk undersökning avslöjade exakt datum och tid när programmet /sbin/init skrevs över och rootkit:et installerades. Analytikerna upptäckte även den exekverbara fil som användes för att uppnå rootbehörighet på maskinerna, ett program som var skyddat och förvanskat med Burneye. Vid uppackning och disassemblering av programmet kunde säkerhetsexperter bestämma vilket fel i kärnan som användes.

Ett heltalsspill i systemanropet brk användes för att skriva över kärnans minne (ändra sidskyddsbitarna). Genom att göra det uppnådde angriparen full tillgång till kärnans minnesrymd och kunde ändra godtyckligt värde i minnet.

Även om denna kod i kärnan förbättrades av Andrew Morton i september och den har funnits med i förhandsutgåvorna av kärnan sedan oktober, övervägdes inte säkerhetskonsekvenserna med ändringen, varför ingen av Linuxdistributörerna sände ut någon säkerhetsbulletin. När det upptäcktes att felet kunde utnyttjas till att uppnå lokal rootbehörighet tilldelade projektet Common Vulnerabilities and Exposures CAN-2003-0961 till detta problem. Det rättades i Linux 2.4.23 som släpptes i slutet av förra veckan och i Debians säkerhetsbulletin DSA 403.

Linux 2.2.x påverkas inte av denna sårbarhet eftersom intervalltester förekom tidigare. Det antas även att Sparc- och PA-RISC-kärnor inte heller är sårbara eftersom användar- och kärnadresser lagras i olika adressrymder på dessa maskiner.

Vi ber om förståelse för att vi inte kan ge alla och envar tillgång till den kod som användes för att utnyttja problemet, så be oss inte om att få det.

Återställning

Efter att maskinerna kopplats från skapades avbildningar av hårddiskarna, vilka lagrades på en annan maskiner och distribuerades till de som utförde den tekniska undersökningen. De tre maskinerna i USA (master, murphy, gluck) ominstallerades därefter och deras tjänster återställdes en efter en efter att tillämpliga tjänsteadministratörer hade undersökt dem.

På klecker sköts dock detta upp till ett planerat underhåll så att säkerhetsarkivet kunde tas i drift tidigare än de andra tjänsterna. Vid den tidpunkten hade vi inte heller konsoltillgång till klecker, så all återhämtning fick göras utifrån. Efter att en diskavbildning skapats via en seriekonsolinloggning på en lokal maskin på en brandväggsskyddad nätverksanslutning togs rootkit:et bort, byttes kärnan ut och härdades, binärer dubbelkollades och säkerhetsarkivet verifierades mot flera olika externa källor. Maskinen kommer att ominstalleras under de kommande veckorna.

Som en säkerhetsåtgärd för att förhindra intrång på ytterligare maskiner inaktiverades samtliga utvecklarkonton i LDAP och SSH-nycklar togs bort från de viktigare maskinerna. Detta omöjliggjorde dock så gott som allt offentligt arbete på Debian, vilket normalt kräver möjlighet att sända in filer och tillgång till CVS-arkiven.

Alla lösenord som används på quantz (dvs. all Alioth-, arch- och subversionlösenord) har också stängts av och samtliga auktoriserade SSH-nycklar har tagits bort. Använd systemet för glömt lösenord för att begära ett nytt lösenord.

När alla tjänster är igång igen och maskinerna är tillräckligt skyddade kommer LDAP att återställas så att utvecklarna kan skapa ett nytt lösenord igen. När detta sker kan vi dock inte säga för närvarande.

Vid återställningen ominstallerades SSH på de maskiner det gjorts intrång på, varför det lagts upp nya RSA-värdnycklar och nyckelfingeravtryck för dessa värdar. Nycklarna kommer läggas in i LDAP så fort som de skapats och kan hämtas från detta skript.

Konsekvenser

Byt dina lösenord!

Eftersom lösenord sniffats på de värdar det gjorts intrång på kan alla utgående anslutningar som innehåller ett lösenord också anses vara komprometterade, dvs. lösenorden måste anses vara kända för inträngaren. De bör därför bytas omedelbart.

Om någon dessutom haft tillgång till en Debianmaskin och använt samma lösenord eller lösenfras på andra maskiner eller nycklar rekommenderar vi å det bestämdaste att dessa lösenord eller lösenfraser byts ut så fort som möjligt.

Om en SSH-nyckel genererats eller lagrats på en av dessa maskiner och använts för att logga in på andra maskiner (dvs. genom att lägga in den i .ssh/authorized_keys), bör även den tas bort.

De hemliga GnuPG-/PGP-nycklar som hittades på debian.org-maskiner har också tagits bort från Debians nyckelringar och därför inaktiverats.

Utvecklare som bekymrar sig för sina egna maskiner bör åtminstone köra chkrootkit och se vad det visar. Matt Taggart underhåller en bakåtanpassning av aktuell version för Woody på följande adress:

Dessutom finns en utförlig förteckning över försiktighetsåtgärder skriven av Wichert Akkerman och Matt Taggart.

Rootkit:et SucKIT

SucKIT är ett rootkit som presenterades i Phrack utgåva 58, artikel 0x07 (”Linux on-the-fly kernel patching without LKM”, av sd & devik). Detta är ett fullt fungerande rootkit som läses in via /dev/kmem, dvs. det behöver inte en kärna med stöd för inläsbara kärnmoduler. Det har ett lösenordsskyddat bakåtkopplat fjärrskal som startas via ett förfalskat paket (som går runt de flesta brandväggskonfigurationer), och kan dölja processer, filer och anslutningar.

SucKIT startar vanligtvis som /sbin/init vid systemstart och startar då en kopia av den ursprungliga ”init”-binären från föräldraprocessen (med process-id 1). Alla följande starter av /sbin/init omdirigeras till det ursprungliga init.

TESOs Burneye-skydd

Burneye är ett sätt att förvanska ELF-binärer på Unixplattformen som presenterades i Phrack utgåva 58, artikel 0x05 (”Armouring the ELF: Binary encryption on the UNIX platform”, av grugq & scut). Genom att använda verktyg som TESOs Burneye kan en angripare ändra ett körbart program och därmed kryptera dess egentliga ändamål och dölja det från brandväggsfilter, intrångsdetekteringssystem, antivirusprogramvara och forskare.

Tack

Täckning i pressen

Kontaktinformation

För ytterligare information, se Debians webbsidor eller sänd e-post till press@debian.org.