SysInternals kaster lys på Rootkits

Vi har ikke fundet noget der ikke kunne finders!

Jeg sad og læste den beskrivelse af rootkits. Og er der nogen som kan sige om det her er forstået rigtigt:

"Rootkits er ikke nyt spyware / trojan osv, men bare en fælles betegnelse for en teknik til at gemme de programmer fra andre programmer? "

Og hvis det forholder sig sådan, betyder det så at vi nu, inden vi kører antivirus/spyware scan, først skal køre rookit scan?

Og endelig, hvorfor kan windows ikke bare lave en funktion som sammenligner ID på de procesor den faktisk kører , med de procesor som står foreskrevet i task manager?? Alt som ikke er registreret kan så bare endes.

#2 et Rootkit er et program ( eller en samling af programmer ) som er beregnet på at agerer som bagdør til dit system - der benyttes så ( i unix verdenen ) udskiftede udgaver af ps,ls,mm. så det ikke er muligt at se at programmet kører / har ændret filer.


Det med at det principielt skulle være muligt for programmet at skjule sig totalt, er vist en sandhed med modifikationer - det kræver ikke mere end at man booter med en boot disk og så skanner - hvis programmet ikke kører har det jo *ingen* muligheder for skjule sig selv.

fenomenet rootkits er langt fra nyt, de fleste unix admins har vist chkrootkit i sin crontab - det nye skulle bestå i at de nu kommer til windows. men æh, jeg er vel ikke den eneste der husker backorfice?

#3 BO var da ikke et rootkit, det er tæt på, men også kun det :)

#2 migogdig

Og endelig, hvorfor kan windows ikke bare lave en funktion som sammenligner ID på de procesor den faktisk kører , med de procesor som står foreskrevet i task manager??

Et rootkit går ind og ændrer på systemet, i princippet ændres alle de funktioner som kunne have afsløret rootkitets eksistens. Så hvis Windows blev udvidet med sådan en funktion, så skulle et rootkit bare opdateres til at også modificere den.

#3 guppy

udskiftede udgaver af ps,ls,mm

Sådan fungerer de primitive rootkits. De mere avancerede ændrer i stedet lidt på kernen.

det kræver ikke mere end at man booter med en boot disk og så skanner

Det er da rigtigt, hvis du har en bootdisk, som du er sikker på er ren, og en scanner, som kender det pågældene rootkit. Men hvor tit gør folk så lige det? Og hvordan opdaterer man sin scanner uden at risikere at få noget skidt på sin bootdisk?

de fleste unix admins har vist chkrootkit i sin crontab

Hvilke systemer kan chrootkit bruges på? Jeg ved den virker på Linux, men den er så systemafhængig, at den næppe kan fungere på forskellige systemer uden modifikationer. Det den gør er i øvrigt ikke blot at kigge efter et rootkit, den kigger også efter, om systemet returnerer inkonsistente oplysninger. Det er nemlig svært at lave et rootkit hvor man ikke kan se på et eller andet resourceforbrug, at der er noget galt. Det har dog også givet falske positiver, da man opgraderede fra Linux 2.4 til Linux 2.6 begyndte chrootkit at brokke sig hver gang man havde et multitrådet program kørende.

#5

Det er da rigtigt, hvis du har en bootdisk, som du er sikker på er ren, og en scanner, som kender det pågældene rootkit. Men hvor tit gør folk så lige det? Og hvordan opdaterer man sin scanner uden at risikere at få noget skidt på sin bootdisk?

eh.. ved ikke hvad du skulle gøre som windows bruger, men ellers tag din favorit livecd ( www.sysresccd.org hvis du ikke har en ) og boot - nu henter du så nyeste udgave af chkrootkit ( eller sources og compiler selv ) og scanner dit system.

Ovenstående trick virker også til at scanne efter virus på windows pc'er ( med clamAV ) - lad dog være med at bruge captiveNTFS, da man principielt ikke kan være sikker på at der ikke er noget galt med ntfs drivern på det system du scanner.

#2 I Windows er langt de fleste vira såkaldte user-mode applikationer som har samme rettigheder som brugeren når disse eksekveres. Derfor er det også uheldigt at så mange benytter Windows med admin rettigheder. Hvis admin/root komprimitering er alvorligt så er et rootkit en katastrofe da det er globalt i operativsystemet.

Og hvis det forholder sig sådan, betyder det så at vi nu, inden vi kører antivirus/spyware scan, først skal køre rookit scan?

Kernel-mode vil i Windows forstand være såkaldte ring 0 processer (device drivere etc). Eksempelvis kan du ikke få adgang til printer porten direkte i Win2K/XP uden at du skriver software der kører i ring 0. God antivirus software kører typisk også i ring 0. Derfor vil en god antivirus i teorien godt kunne detektere og forhindre kendte virus angreb men hvis først systemet er inficeret (eller virusen er ukendt) så vil denne virus få frit spil.

Og endelig, hvorfor kan windows ikke bare lave en funktion som sammenligner ID på de procesor den faktisk kører , med de procesor som står foreskrevet i task manager?? Alt som ikke er registreret kan så bare endes.

Husk på, at task manager benytter API kald til at få fat i disse informationer. Det er ikke svært at overstyre (kaldet hook/subclass) et sådant API kald og blot filtrere sig selv fra - dette gør mange nuværende vira. I ring 0 vil dette overhovedet ikke være nødvendig fordi der ikke er tale om en process i traditionel forstand.

Rootkit detektorer fungerer ved at gå uden om API'et og fortolke af sig selv, på denne måde vil den kunne afgøre om et API er komprimiteret ved at sammenligne dens egne resultater med hvad API-kaldet rapporterer.

Jaaaa.. Hentede programmet kørte det.. Og det gør præcis det der står den kan.. Finder rootkits.. Fandt et par stykker hos mig engang!.. Og så gør den ikke mere.. Hvordan fjerner man dem så?.. Gider den ikke hjælpe med det, håber da at MS gider at lave sit program færdigt.. :)

Når man snakker root kits - er det ikke ala Backorifice - eller hvad det nu hed?

Hvordan ved man så om man har et root kit, hvis man scanner med root kit revealer?
Altså hvad skal man se efter?
Bør den slet ikke outputte noget?
Hos mig kommer den bl.a. med en masse "access denied".

#7 mrmorris

God antivirus software kører typisk også i ring 0.

Nej, bestemt ikke. Man skal ikke have mere kode end højst nødvendigt i ring 0. Jo mere kode i ring 0, des større risiko for fejl. Og en fejl i ring 0 kode betyder et ustabilt og usikkert system.

Hvis tredjepartssoftware kræver ring 0 vil jeg som udgangspunkt nægte at installere det. Et fornuftigt designet antivirus program burde knap nok have lov til at køre med administrator privelegier. Antivirus laver nogle ikke-trivielle analyser af filer på systemet. Koden til analysen kan nemt være fejlbehæftet, og sådan en fejl kan udnyttes af en passende konstrueret fil. Derfor udgør det en sikkerhedsrisiko at køre sit antivirusprogram med administrator rettigheder.

#11 Nu har jeg tilfældigvis set Symantec Antivirus skabe blue-screen-of-death på en Win2k server pga. manglende ressourcer med en UNEXPECTED_KERNEL_MODE_TRAP, derfor ved jeg den kører i ring 0!

Der er vel også en rigtig god grund til at køre i ring 0, hvis samtlige I/O operationer skal opsnappes og analyseres så effektivt som muligt (før alle andre programmer) er laveste niveau attraktivt.

Hvordan i alverden vil du scanne en hel reg-database eller reparere inficerede filer hvis du ikke har skrive (admin) rettighed???

Ang. Windows og Antivirus er her 2 rigtigt gode interviews med en IO Filesystem udvikler hos MS. Han kommer bl.a ind på hvordan man bygger forskellige filtre ind oven på et filsystem i Windows. Der nævnes mange forsk. filtre, men kryptering, antivirus, sikkerhed, etc. er eksempler.

Jeg vil klart anbefale enhver IT interesseret at se desse to interviews.

Part 1 (klik på "save knappen under billedet")
http://channel9.msdn.com/ShowPost.aspx?PostID=3690...

Part 2 (samme procedure..)
http://channel9.msdn.com/ShowPost.aspx?PostID=3730...

#12 mrmorris

Der er vel også en rigtig god grund til at køre i ring 0, hvis samtlige I/O operationer skal opsnappes og analyseres så effektivt som muligt (før alle andre programmer) er laveste niveau attraktivt.

Hvis man vil undersøge hver eneste I/O operation er der noget galt i ens design. Det koster ganske enkelt alt for meget i performance, uanset hvad niveau det foregår på.

Hvordan i alverden vil du scanne en hel reg-database eller reparere inficerede filer hvis du ikke har skrive (admin) rettighed???

Det vil jeg ikke. Virus skal opdages før skaden er sket. Har virusen først haft skriveadgang til noget som kun administratoren kan nå, så er slaget tabt.

Hvis man vil undersøge hver eneste I/O operation er der noget galt i ens design. Det koster ganske enkelt alt for meget i performance, uanset hvad niveau det foregår på.

Og hvorledes tror du ellers at Antivirus, Quota-managere, Drive-Space, dekryptering osv. foregår. Det skal jo helst være transparent for API'et således at øvre lag ikke skal belemres med dette. Denne call-through model er grundlæggende i NT kernen og vil først blive modificeret med Longhorn.

Det vil jeg ikke. Virus skal opdages før skaden er sket. Har virusen først haft skriveadgang til noget som kun administratoren kan nå, så er slaget tabt.

Nu er TSR/JIT paradigmet ikke altid anvendeligt. Hvis du f.eks. har haft din TSR/JIT slået fra eller har være uheldig at blive inficeret med en ny virus som din antivirus endnu ikke kendte på et givet tidspunkt, vil du være ude at stand til at reparere dit system? Det er heldigvis langt fra sådan i virkeligheden!!!

#15 mrmorris

Og hvorledes tror du ellers at Antivirus, Quota-managere, Drive-Space, dekryptering osv. foregår.

Antivirus anvendes de steder hvor ny kode kan komme ind på systemet. Af dem er mailserveren det vigtigste sted at checke (man naturligvis ikke det eneste).

Kvote håndtering er langt simplere end antivirus. Kvoter er typisk indbygget i kernen og kræver derfor ikke noget tredjepartssoftware. Og man behøver ikke kigge på hver eneste I/O for at implementere kvoter. Kvotehåndtering indgår helt naturligt som en del af blokallokering/deallokering. Og det er jo blot et spørgsmål om at opdatere en tæller.

Hvad angår kryptering, så er det selvfølgelig nødvendigt at håndtere hver enkelt I/O, og det går hårdt ud over performance. Et så stort performance tab er der mange, som slet ikke vil acceptere. Heldigvis er det performancemæssigt langt billigere at scanne for kendte vira, ellers var der nok ikke mange, der ville gøre det.

Faktisk er diskkryptering langt mere compliceret end blot at kryptere/dekryptere hver enkelt I/O, men lad være med at spørge mere om det, for så bliver jeg slet ikke til at stoppe igen. :-)

Nu er TSR/JIT paradigmet ikke altid anvendeligt.

TSR er navnet på en designfejl i DOS, og JIT er et princip, der anvendes i virtuelle maskiner. Ingen af delene har mig bekendt noget med antivirus at gøre.

eller har være uheldig at blive inficeret med en ny virus som din antivirus endnu ikke kendte på et givet tidspunkt, vil du være ude at stand til at reparere dit system?

Det kommer naturligvis an på den virus du bliver ramt af. Så vidt jeg ved er der mange vira, som scannerne kan detektere men ikke fjerne. Og har en virus først opnået kontrol over systemet, så kan den faktisk gøres umulig at fjerne uden som minimum at boote fra et rent medie. Jeg tror kun det er et spørgsmål om tid før vi ser en virus, der anvender et p2p netværk til at opdatere sig selv hurtigere end antivirusproducenterne kan få opdateringer ud af deres scanner.

TSR er navnet på en designfejl i DOS, og JIT er et princip, der anvendes i virtuelle maskiner. Ingen af delene har mig bekendt noget med antivirus at gøre.

Lad os nu ikke drukne i semantik, jeg tror godt du er klar over hvad jeg referer til med disse paralleller; Terminate-Stay-Resident som vi brugte i DOS til at "intercepte" Interups og Just-In-Time fordi AV software scanner data lige før det rent faktisk blive brugt af øvre lag.

Og forresten så var hele DOS jo en design-fejl! ;)