Microsoft maakt zich zorgen om rootkits voor Windows

Beveiligingsexperts van Microsoft waarschuwen voor een nieuwe generatie rootkits, programma's die kwaadwillende gebruikers in staat stellen commando's uit te voeren met administratorrechten. Dit was een van de onderwerpen die afgelopen week op de RSA Security-conferentie in San Francisco zijn behandeld. De onderzoekers verwachten dat deze malware een groot gevaar zal vormen, omdat ze erg moeilijk kunnen worden gedetecteerd met de huidige beveiligingsprogramma's. Kernelrootkits, de nieuwe generatie rootkits die steeds vaker voorkomt, passen de kernel van het Windows-besturingssyteem aan en kunnen zo systeemaanroepen blokkeren of aanpassen. Dit heeft als gevolg dat detectiemethoden als het zoeken naar bestandsnamen, actieve processen en configuratie-instellingen in het register kunnen worden misleid en de rootkit voor de computergebruiker onzichtbaar gemaakt kan worden.

Er zijn weinig methoden om een kernelrootkit te ontdekken, voornamelijk omdat elke rootkit verschillende technieken gebruikt om zichzelf te verbergen. Wel is het bijvoorbeeld mogelijk om een systeem vanaf een andere computer in het netwerk te laten controleren. Een andere manier, die hier sterk op lijkt, is het vergelijken van een mogelijk geïnfecteerd systeem met de eigen kernel en een schone kernel. Deze strategie wordt uitgebreid beschreven in een paper van Microsoft. Hoewel kernelrootkits niet alleen in Windows voorkomen, zorgen de populariteit en de veelzijdige programmeeromgevingen ervoor dat steeds meer ontwikkelaars dit besturingssysteem uitkiezen als hun doelplatform. Microsofts Internet Explorer is ook een populaire ingang voor hackers en malware om een rootkit bij een kwetsbaar systeem naar binnen te brengen.

Reacties (85)

[VNA9216]

vanaf een andere machine via netwerk scannen kan wel... nou dat is een geruststelling... aangezien je als je de rootkit goed schrijft ook het tcp/ip verkeer wel kan scannen en manipuleren.. (als je het doet moet je het goed doen) en als het bestand in gebruik is (wat me wel waarschijnlijk lijkt) kan je het dus haast niet verwijderen tenzij je het systeem met een bootdisk opzo opstart....

misschien moeten computers toch echt eens helemal opnieuw ontworpen worden of iets dergelijks (soft en hardware) zodat het weer een jaartje of 5-10 duurt voor dit weer zo mainstream word en bijna ieder n00bje het kan

ik ben benieuwd hoe dit opgelost gaat worden...
zou dat SELinux dit soort dingen voorkomen op linux machines (zoals de mijne) ik heb wel eens gehad dat ik een waarschuwing kreeg dat een actie niet kon door SELinux maar ik heb geen idee of het ook betrekking hier op heeft... heb iemand een idee?

[Olaf van der Spek]

zou dat SELinux dit soort dingen voorkomen op linux machines

Volgens mij heb je heel of half SELinux hier niet voor nodig.
Gewoon zo min mogelijk als root doen.

Ook de huidige normale manier van werken met Linux is IMO niet (volledig) veilig, maar in iedergeval een stuk veiliger dan werken met administrator/root rechten.

[neh]

Een gemiddelde rootkit op een linux/solaris/whatever systeem komt daar terecht via een worm of persoon die zich toegang weet te verschaffen via een gat in een networkdaemon.

In zo'n geval is SELinux juist wel een uitkomst, aangezien een redelijk strict profiel is te bouwen van wat elke netwerkdaemon wel of niet mag. Stappen die nodig zijn om een rootkit te installeren vallen daar meestal niet onder.

[Jit]

Vaak is draaien als root ook niet nodig

Jawel. Als je bijvoorbeeld een proces aan een poort beneden de 1024 wilt binden, dan zul je dat proces moeten laten opstarten met root-privileges. Je kan dan na het binden die privileges laat droppen, maar als je net een geinfecteerde binary te pakken hebt (gehackte rpm/deb mirror bijv) dan kan het leed al geschied zijn.

Met bijvoorbeeld SELinux kun je een proces de rechten geven om aan een privileged poort te binden terwijl deze niet het recht heeft om bijvoorbeeld devices met raw i/o te benaderen. Je bent effectief af van het risico dat een enkele, bekende god-user (root) nog openlaat.

[_JGC_]

Linux is ook niet alles, er worden de laatste tijd nog al eens wat lekken gevonden in de verschillende kernels. Zelf draai ik een 2.6.10-as3 kernel, een kernel met tig backports uit bitkeeper voor verschillende security fixes. Tussen 2.6.10 en 2.6.11 kan een maand of 2 zitten, terwijl je al die tijd gewoon een lekke kernel draait. Daarom is het ook belangrijk dat je of zorgt dat je die security fixes over je kernel heenhaalt, of dit door je distro laat doen (en dus niet eigenwijs gewoon 2.6.10 downloaden en compileren omdat dat "beter" is dan een distro kernel)

Wat betreft kernel rootkits op windows: was dit niet al heel simpel. Ik bedoel maar, een of ander vaag DLL bestandje of VXD/SYS bestandje aanpassen en je hebt in principe al iets wat niet 1-2-3 te detecteren is. Geen hond die drivers nakijkt, en dingen als adaware en hijackthis vinden dat soort dingen niet. Verder het verwijderen ervan? Reinstall, een bak die vol trojans staat of die een rootkit bevat is niet te vertrouwen, je weet nooit wat er allemaal op zo'n systeem is achtergebleven. Ik zie het nut dan ook niet in van virusscanners die meer doen dan detecteren en preventief controleren.

@abraxas:
2.4 is ook regelmatig lek, je ziet regelmatig bugs verschijnen die ook in 2.4 al zaten. Het nadeel van 2.6 is dat je tussen 2 releases gewoon een compleet andere speeltuin kunt verwachten, ze doen met 2.6 waar ze eigenlijk 2.7 voor moeten openen helaas.

[Olaf van der Spek]

In zo'n geval is SELinux juist wel een uitkomst, aangezien een redelijk strict profiel is te bouwen van wat elke netwerkdaemon wel of niet mag.

Vaak is draaien als root ook niet nodig.

[Verwijderd]

als kernel security je zo aan 't hart gaat kan ik je aanraden 2.4 te gebruiken

[VNA9216]

idd.. als je niets als root doet jah.. maar er kan altijd eens een worm zijn ofzo die het installeert natuurlijk (laatste worm is al lang geleden d8 ik maar toch) en SELinux zou volgens wat ik lang terug heb gelezen kunnen herkennen wanneer er met de kernel word geknoeid en "foute" code in de kernel word verwerkt... maar ik heb geen flauw idee hoe correct die informatie is

[daft_dutch]

@VNA9216
compile gewoon je kernel zonder modules
doordat de meeste rootkits modules zijn kunnen ze niet werken
daarbij linux is vrij geterst in rootkits

Windows rootkits is iets nieuws
2 jaar geleden Had je het niet over windows rootkits doordat iedereen als root (administrater) van zijn windows bak gebruik maakte
nu mensen de (brakke) usere windows mode gaan gebruiken gaan de crackers met root kits aan de slag.

Snel naar longhorn met een 4Ghz cpu en 2 GB ram pc

[Jit]

Linux zonder modules is nog steeds niet veilig voor die rootkits: http://www.phrack.org/phrack/58/p58-0x07

Je creeert er alleen maar een onderhoudsprobleem voor jezelf mee. Voor elke pc die niet identiek is moet je een aparte kernel bakken en de meeste mensen zijn daar nou niet zo heel erg bedreven in. Grote kans dat ze dan meer openzetten dan nodig is.

[Verwijderd]

Inderdaad ja. Laatst toen ik ergens op bezoek was, pc met 4 accounts, allemaal administrator.. Gek he dat ie sloom was van de spyware en andere troep?
Als je er een kopje naast hield had je binnen no-time een kop koffie.., wat was dat een koffiemolen.

Als je iets wil installeren doe je dat toch gewoon via 'uitvoeren als'..?

[VNA9216]

en op de gebruikersaccount zit zoveel spyware dat die gewoon je wachtwoord ff noteerd en vervolgens installeert via administrator... maw... GOED PLAN

[Verwijderd]

We hebben het hier niet over de spyware, ik ging er even vanuit dat deze niet aanwezig is het systeem van de meeste mensen hier.
Het 'uitvoeren als' is inderdaad niet 100% veilig, maar al stukken beter als continu als admin ingelogd zijn.
En daar komt bij dat je de meeste dingen wel kan installeren / downloaden. Alleen dingen die zich echt in het systeem weg willen schrijven hebben admin permissies nodig.

[VNA9216]

inderdaad ik hoop in ieder geval dat er wat minder mensen als admin in gaan loggen op hun windows machines.... (ik doe het wel maar herlaad steeds windows van image als ik het ff nodig heb )

[Olaf van der Spek]

En daar komt bij dat je de meeste dingen wel kan installeren / downloaden.

Alles wat in Program Files moet, kun je niet als gewone gebruiker installeren.

[Verwijderd]

tweakit! schreef:
En daar komt bij dat je de meeste dingen wel kan installeren / downloaden. Alleen dingen die zich echt in het systeem weg willen schrijven hebben admin permissies nodig.

Bij standaard permissies wel ja. Die mogen voor thuisgebruik misschien voldoende zijn maar in een productie/kantooromgeving zou ik er toch voor kiezen om daar een aantal striktere (group) policies op los te laten die instaleren ALLEEN met admin rechten toestaan. En dan er op blijven hameren: applicaties instaleren KAN maar dan wel door een 2e lijns medewerker of susteembeheerder (en dat kan gerust op afstand of 's nachts tijdens een batch update)

[Olaf van der Spek]

Als je iets wil installeren doe je dat toch gewoon via 'uitvoeren als'..?

Nee, eigenlijk niet. Het explorer van de huidige gebruiker kun je niet vertrouwen, door uitvoeren als ook niet.

[Verwijderd]

Dat is voor jou "gewoon", dat is voor mij "gewoon", maar wij zijn de doelgroep dan ook niet.

[wh1t3 sh4d0w]

jullie kijken geloof ik een beetje verkeerd tegen kernelland rootkits aan,,, jullie zitten nog iin userland te denken. Het zijn geen bestanden meer die je kan waarnemen het zijn gewoon subroutines die als het ware rechtstreeks in de shell geinjecteerd worden. Hier hooken ze systemcalls en kunnen de antwoorden op deze calls manipuleren door bepaalde waarden weg te filteren.

Als je in windows een map opent worden er een paar systemcalls gedaan, onder andere een voor het krijgen van de bestanden in die map (eigenlijk wel meer dan 1, maar goed). De subroutines die vangen die call op, veranderen hem zodat hij waardes met bijvoorbeeld [HIDE] ervoor weglaat en stuurt dan de gewijzigde call door naar de originele functie. Hierdoor kan je dus al bestanden met een bepaalde prefix weglaten, maar ook voor services, processen, connecties en alles wat je maar kan bedenken worden system calls gebruikt. Door deze allemaal te hooken kan je de rootkit dus vrijwel undetected maken.

Vroeger werden programma's al netstat vervangen en lieten ze verbindingen van bepaalde hosts weg, tegenwoordig wordt het gewoon weggevangen door de hooks. Dit is de verandering die het zo gevaarlijk maakt, het wordt veel midner tastbaar en veel moeilijk te detecteren.

[Olaf van der Spek]

jullie

Wie?

[wh1t3 sh4d0w]

de meeste mensen die hier gepost hebben, als ik dat mag oordelen naar de inhoud van hun posts.

Is ook eigenlijk helemaal niet belangrijk, toch?

[Olaf van der Spek]

Is ook eigenlijk helemaal niet belangrijk, toch?

Het lijkt me juist zeer belangrijk. Ik heb namelijk helemaal niet het idee dat de meeste mensen een verkeerd idee hebben van rootkits.

[wh1t3 sh4d0w]

raad ik je aan deze thread eens door te lezen en je eens te verdiepen in kernelland rootkits....

[Olaf van der Spek]

En dan?

[wh1t3 sh4d0w]

Dan zie je dat bijna niemand hier iets zinnigs/corrects zegt over kernelland kits.

[Olaf van der Spek]

Dan zie je dat bijna niemand hier iets zinnigs/corrects zegt over kernelland kits.

Ik heb geen zin 'at random' informatie over kernelland kits te gaan lezen in de hoop dat ik precies dat lees waar jij op doelt.

[Verwijderd]

;-) Sorry, maar dat is een erg grappige opmerking gezien je commentaar verder hierboven.

Je hebt *hier* inderdaad helemaal gelijk (qua werking van het probleem, niet qua kritiek op anderen). Maar elders trek je je eigen uitleg nog niet ver genoeg door. Ook verzoeken aan de geinfecteerde machine mbt. info over het systeem kunnen zo gefaked worden.

[wh1t3 sh4d0w]

zoals ik daar zojuist uitgelegd heb is dat de bedoeling

[Verwijderd]

Wat is hier nu zo bijzonder aan?? Windows Kernel rootkits die de System Service Descriptor Table (SDDT) of Interrupt Descriptor Table (IDT) patchen bestaan al jaren (>5 jr). De truc bestaat uit het gebruik van een ongedocumenteerde entry in de export list van de kernel (NTOSKRNL). Een kernel mode driver of loadable module kan middels deze entry (in dit geval een pointer naar de Descriptor Tables) de pointers naar de systeem functies (Windows Native API oftewel kernel syscalls) hooken. Hierdoor kunnen de syscall aanroepen van user en kernel mode threads afgevangen worden, aanroep parameters en functie resultaten kunnen dan zonder meer door de driver of module gemodificeerd worden.

De layout en het gebruik van deze Descriptor Tables (er zijn meer tables --> GDI, Microsoft IIS voegt er zelfs eentje toe) zijn sinds NT 4.0 niet bijzonder veranderd. Bij de nieuwe OS'en (W2K3/XP) zijn de page table entries die de vm pages van de syscall tabellen beschrijven write protected zodat modificering van de tabellen 'moeilijker' wordt. Een kernel mode system thread kan deze beveiling omzeilen door het WP flag in het CR0 cpu register uit te zetten en vervolgens de lees/schrijf attributen van de page table entries te modificeren. En voila, de tabellen kunnen weer gepatched worden...


Het zijn overigens niet alleen rootkits die van dit soort interrupt / syscall hooking gebruik maken. Veel gebruikte tools als REGMON of TOKENMON maken gebruik van kernel mode syscall hooking. Vanuit de executable wordt dan gewoon een kernel mode driver geinstalleerd en gestart. Par example: REGMON hooked alle native API syscalls die registry I/O afhandelen. Alle usermode / kernelmode threads die registry I/O uitvoeren maken gebruik van deze functies en de betreffende calls kunnen zo worden afgevangen, de resultaten worden dan weer doorgegeven naar de Regmon GUI voor presentatie.

Hooking kan dus ook in positieve zin gebruikt worden, b.v. voor het toevoegen van kernel functionaliteiten.

[Guru Evi]

Het bijzondere is dat Microsoft dat uiteindelijk ontdekt heeft en nu zich zorgen begint te maken dat het kan...

[Arcane Apex]

Voor degenen die niet weten wat een rootkit is:


"A rootkit is a collection of tools that allows a hacker to provide a backdoor into a system, collect information on other systems on the network, capture passwords and message traffic to and from a computer, mask the fact that the system is compromised, etc. "


En een nog wat volledigere uitleg:


A hacker security tool that captures passwords and message traffic to and from a computer. A collection of tools that allows a hacker to provide a backdoor into a system, collect information on other systems on the network, mask the fact that the system is compromised, and much more. Rootkit is a classic example of Trojan Horse software. Rootkit is available for a wide range of operating systems.


Bron: Texas State Library
http://www.tsl.state.tx.us/ld/pubs/compsecurity/glossary.html

[Bigs]

Rootkits zijn niet relaxed Ik heb er in de Unix wereld ook wel eens mee zitten spelen en daar kwamen ze gewoon compleet met aangepaste netstat, ps, ls en zelfs ifconfig binaries om alle activiteit van de rootkit maar te verbergen. Erg knap

[_JGC_]

Wat denk je van kernel rootkits dan?
We hebben zelf eens zitten prutsen met knark en adore, beetje mixup van die twee gemaakt en uiteindelijk konden de controleertooltjes het hele ding niet meer vinden. Nooit in het wild losgelaten, weet ook niet meer waar ie is. Leerzaam om eens de linux kernel te onderzoeken en hoe je daarin programmeert (zelfs de C/C++/Java docent kwam gewoon ff helpen en wist niet waar ie mee bezig was )
Je doet een ls call, vervolgens is er een hook in de kernel die gewoon de systemcalls van ls opvangt en de helft van het resultaat weglaat.
Zelfde met processen of modules verbergen, je vraagt het met doodgewone tools uit, maar je tools krijgen van de kernel gewoon verkeerde antwoorden terug.

Voor al die mensen die denken dat met CRC checks van files alles wel op te lossen is: je voegt gewoon een extra driver toe en verbergt dit door alle systemcalls die drivers opvragen in windows voor de gek te houden. Vervolgens haal je de nodige rottigheid uit en klaar ben je. CRC check zal dat ding niet detecteren omdat het gewoon een extra driver is die in kernelspace alle userspace meuk voor de gek houdt.

[leuk_he]

<i>en uiteindelijk konden de controleertooltjes het hele ding niet meer vinden. Nooit in het wild losgelaten, weet ook niet meer waar ie is.</i>

Hij draait nog met de opdracht zichzelf te verbergen uiteraard Maar als hij zich goed geneog verberd heb je nergens last van.

[trogdor]

Hiervoor zijn dus dingen als knoppix en "ultimate boot cd" bedacht.

[Verwijderd]

booten vanaf cd uitzetten? lijkt me redelijk standaard actie om dat te regelen (evenals booten vanaf usb stick etc....)

[Mac_Cain13]

Het booten vanaf een bepaalde device is een actie die in de BIOS word ingesteld, dus het lijkt me vrij lastig om dit in te stellen als Windows-rootkit zijnde. Als het je al lukt kun je het als gebruiker zo weer terug zetten in je BIOS. Dus dan kun je alsnog Knoppix starten en de boel eens goed onder de loep nemen.

Zo gek is het scannen via een cd als Knoppix eigenlijk helemaal nog niet, je weet tenminste zeker dat er geen rare software is die je loopt te dwarsbomen. Dus kun je een betrouwbare scan doen waarbij je de rootkit helemaal buitenspel zet.

[Olaf van der Spek]

Het booten vanaf een bepaalde device is een actie die in de BIOS word ingesteld, dus het lijkt me vrij lastig om dit in te stellen als Windows-rootkit zijnde.

Dan flashed de rootkit toch gewoon die hele optie uit het BIOS?
Technisch knap complex, maar theoretisch zeker mogelijk.

[Major 7]

@Olaf van der Spek

Goed Idee!
Maar dan is het helaas wel al te duidelijk dat die PC niet fris meer is, dus de zin van een root-kit, om on-ontdekt te blijven, is dan wel voorbij
Voor zulke hardnekkige gevallen is er altijd nog de stekker

[Aaargh!]

Dan flashed de rootkit toch gewoon die hele optie uit het BIOS?

Er zijn moederborden waar je eerst een setting in de BIOS moet aanzetten voordat je kan flashen, en soms moet je zelfs een jumper op het mobo omzetten om de flash mogelijk te maken.

[Eric Oud Ammerveld]

Wat mij verbaast is dat het aantal BIOS virussen vooralsnog nihil is.

Als een virus maker ECHT ophef wil veroorzaken zou hij best een BIOS flasher kunnen maken dat bijvoorbeeld op een specifieke datum je complete systeem lam legt.
Tegenwoordig is een groot aantal BIOSsen de standaard AWARD welke kijkend naar de verschillende mainboards zeer overeenkomstige assembly code heeft.
Een kwestie van de BIOS uitlezen, ASM code aanpassen en weer wegschrijven en klaar, BIOS gehackt.

Ik mag hopen dat Windows alle data richting de BIOS op kan vangen in standaard User mode.
Als er echter een kernel gehackt kan worden betekent dit ook dat onbeperkte toegang tot I/O gerealiseerd kan worden via een patch.
Oftewel.. de BIOS flash virussen zijn dichter bij dan we denken ben ik bang...

[Verwijderd]

Ik dacht altijd dat bios hacks moeilij waren doordat 1. diverse system boots nodig zijn en 2. iedere fabrikant z'n eigen access programma maakt, met eigen protocollen.

Klopt dat dan niet (meer)?

[Olaf van der Spek]

Wel is het bijvoorbeeld mogelijk om een systeem vanaf een andere computer in het netwerk te laten controleren.

Dit is juist niet mogelijk, omdat de rootkit ook zo'n scan volledig om de tuin kan leiden.

[VNA9216]

dat leek mij ook al... zo'n scan is denk ik nog makkelijker om de tuin te leiden dan een op het systeem zelf omdat je bij een externe eigenlijk alleen maar de pakketjes moet uitfilteren...

[wh1t3 sh4d0w]

dat is dus niet juist, zo'n scan is niet (simpel) om de tuin te leiden, omdat je gewoon een dump van de kernel maakt vanaf een externe machine, die externe machine gaan we dan vanuit dat hij niet infected is. Dus die maakt gewoon een dump van de kernel van de infected machine zonder dat deze gehooked kan worden om iets weg te laten, deze vergelijkt hij vervolgens met een dump van zijn eigen ongeinfecteerde kernel. Aan de hand van de verschillen kan je dan zien of er sprake is van een rootkit, verschillen zijn dan de hooks. Het is lastig om er zo tegenaan te kijken, omdat het vrij abstract is en je het je moeilijk kan voorstellen omdat je het simpelweg niet kan zien.

[Verwijderd]

Ik kan mis zijn, maar op een dump te doen van een kernel via remote, dan kan de infected systeem toch een orgineel copie doorsturen via het netwerk. Je bent juist dat het infected systeem zijn hooks niet kan gebruiken op de niet geinfecteerde netwerk pc, maar het kan wel zijn hooks gebruiken om te controlleren welke data over het netwerk gaat, en als het ondekt dat men de kernel data wilt accessen, kan het gewoon een orgineel kernel data doorsturen.

De enige manier om dit 100% te omzeilen, is het infected systeem te laten opstarten vanop een cd bootable os, en ofwel direct vergelijken met die cd os, of het cd os gebruiken voor de netwerk verbinding. Als de infected os de kans krijgt om op te starten, dan zullen ook zijn hooks actief zijn.

Dit is dezelfde methode als een 100% veilige anti virus aanpak. Verhinder dat de virus actief is op deze manier, en dat kan de virus zichzelf niet verdedigen tegen uitroeiing.

[wh1t3 sh4d0w]

En wat heeft de infected kernel met mijn dump te maken dan? Alleen die kernel is infected. En omdat er geen subroutines van de infected kernel gebruikt worden om een dump te maken, kan dat gewoon.

[borft]

hoe wou jij een kerneldump maken van een machine die niet draait? of anders, hoe wou jij een machine booten zonder de kernel te laden?

[wh1t3 sh4d0w]

waar zeg ik dat de machine niet draait?

Het is overigens heel goed mogelijk een machine te booten zonder die specifieke kernel te laden.

De infected machine is gewoon geboot en met die uninfected machine maak je dan een dump. Die dump wordt dus NIET gemaakt door de infected kernel. Hierdoor kan er dus ook NIET met de dump geknoeid worden.

[MaxxBass]

Volgens mij kun je beter kijken (met een sniffer) wat zo'm machine allemaal uithaald, weet je zo of ie slecht is of niet... daarom moet je eigenlijk ook een aparte firewall hebben die van binnen naar buiten ook blocked tenzij gewenst...

[wh1t3 sh4d0w]

Das geen apparte firewall hoor, das vrij normaal....

Maar wat een sniffer ziet kan ook beinvloed worden. De winpcap library moet ook calls doen

[Olaf van der Spek]

De infected machine is gewoon geboot en met die uninfected machine maak je dan een dump.

De uninfected machine kan de HDD van de infected machine niet (direct) aanspreken, daarvoor zul je via de infected kernel/machine moeten. Op dat moment is de 'dump' te filteren en dus niet effectief.

[wh1t3 sh4d0w]

je boot de infected machine

je doet: dir /s /a >> infected.txt

reboot naar een uninfected kernel (WINPE cd)

je doet: dir/s /a >> uninfected.txt

windiff.exe eroverheen en klaar. Maar dit had je natuulijk ook zelf kunnen lezen in de link in de bron....

van een remote machine werkt het ongeveer hetzelfde. Dan gebbruik je namelijk ook dezelfde hdd maar een andere kernel en dus een andere dir command

[Olaf van der Spek]

je boot de infected machine

je doet: dir /s /a >> infected.txt

En dan?
De changed files van de rootkit vind je niet op die manier terug. Ook niet over een netwerk.

[_JGC_]

De infected machine is gewoon geboot en met die uninfected machine maak je dan een dump. Die dump wordt dus NIET gemaakt door de infected kernel. Hierdoor kan er dus ook NIET met de dump geknoeid worden.

En hoe wil jij die dump dan uitlezen? Juist ja: ophalen uit het infected systeem... hoe kom je daarbij? Juist ja, via netwerk. Als ik wist hoe dit soort dingen te hooken, zou ik zo een virus in je kernel kunnen bakken die gewoon op het moment dat jij dump opvraagt, een dump van jou kunnen vragen en die teruggeven. Het moet tenslotte over het netwerk, en alles wat over het netwerk gaat is te onderscheppen.

[wh1t3 sh4d0w]

@olaf: je quote de helft van men verhaal... de tweede helft geeft dus het "en dan" deel weer

@Jan: Hoe kom je dan opeens met een virus in mijn kernel
Als je met een UNINFECTED kernel over een netwerk die dump van hdd af wil halen dan zou de kit idd een andere terugsturen, MITS de kit de naam weet van de dump. Die kit kan natuurlijk niet zien dat de file die jij opvraagt een dump is Je vraagt gewoon een file op voor zover die kit kan zien, wat die file is kan hij niet zien aangezien je het naar elk mogelijk formaat kan dumpen. Dus dat is gewoonweg onmogelijk. Alles wat over het netwerk gaat is idd te onderscheppen, maar als de kit ook echt alles blocked, dan is de hele intentie weg, want dan is het natuurlijk niet hidden meer.

[Verwijderd]

Het punt van beiden is als volgt. Zodra je functies van de geinfecteerde machine gebruikt, kan deze gaan faken. Doe een dir <iets> en uiteraard wordt verdachte info niet vrijgegeven; jouw methode levert dus niets verdachts op. Vraag om de inhoud van het systeem en getallen worden aangepast zdd. niets te zien is. Een rootkit kan heel ver gaan - afhankelijk van de inventiviteit van de maker.

De enige manier om iedere slimme actie van een rootkit te voorkomen is door geen functionaliteit van de geinfecteerde machine te gebruiken. Heel simpel, en heel vervelend.

[wh1t3 sh4d0w]

je kan wel functies van de geinfecteerde machine gebruiken, zolang ze maar niet uit een geinfecteerde kernel komen

dus als je eerst op de geinfecteerde kernel een dir opvraag doet dan is die aangepast, en dat is ook de bedoeling... want als we nu naar een safe kernel booten en daar hetzelfde command (op de fysiek zelfde schijf) uitvoeren dan geeft deze wel alle files, ook de hidden door de rootkit omdat deze kernel clean is. Door het vergelijken van deze files wordt de kracht van de rootkit (het hiden) zijn zwakte.

[Verwijderd]

waarom is er nog geen soort windows pe versie met een functie die alle cruciale windows bestanden kan controleren (ook services en de daarbij horende standaard registry instelling, of een veranderde explorer? )
fit vraag ik me al vaker af...

[WinL]

An sich mogelijk. Maar je moet dan wel rekening houden dat je dan vanaf het internet definities moet downloaden. Aangezien een PE environment niet weet of een bestand juist is of niet, aangezien te wel eens (legaal) gepatched worden.

[Verwijderd]

mooie taak voor microsoft toch?wordt tijd dat je de complete Windows installatie 's kunt gaan valideren. of elementaire bestanden niet door een virus gewijzigd zijn. voorkomen wordt steeds moeilijker dus zal genezen 's de aandacht moeten krijgen, en dit niet aan derden overlaten.

[Verwijderd]

MS begint stilaan een slachtoffer te worden van zijn jarenlange beleid: Iedereen administrator en grote marketingmachine die zegt dat alles veilig is en als het dat niet is, dat wordt er aan gewerkt. MS begint meer en meer in de knoei te raken op deze manier. Als MS zichzelf wil redden, zullen ze het roer echt volledig moeten omgooien, ipv het ene te zeggen en het andere te doen.

[Abom]

Je moet natuurlijk wel weten waar je het over hebt, Neurofobia...

Enig idee wat er van de security van je Linux of UNIX systeem overblijft, wanneer je bak eenmaal geroot is?

[nhimf]

Het gaat niet om als hij eenmaal geroot is

Wat hij zegt is helemaal waar, waarom wordt je bij MS bijna verplicht om als administrator je aan te melden?
IIS bijv _moet_ als administrator werken, Apache wil dat niet, je kan het wel, maar met veel moeite. Als dan je webserver wordt gehacked, heb je nog geen administrator/root rechten en dus kan je niet de kernel direct patchen en daarmee dus de bak rooten.

MS moet inderdaad het erg moeilijk maken om mensen als root in te laten loggen en ook zorgen dat hun services (IIS, SQL) _niet_ standaard als administrator draaien, maar hun eigen, non privileged, acount krijgen. (onder unix is het gebruikelijk om deze "gebruikers" geen inlog rechten te geven, dus je kan niet inloggen)

ps. Bij apache moet je dus een optie als --BIG_SECURITY_HOLE meegeven bij het compilen om hem als root te laten draaien, anders weigert apache dienst als root, xchat geeft aan (bij het opstarten) dat het absoluut niet handig is om als root op IRC te gaan zitten. Maw. onder unix/linux wordt je nogal vaak aangeraden, of zelfs moeilijk gemaakt om dingen als root te doen.

[Abom]

Ik heb even geen ervaring met IIS, maar alle andere services (zoals Exchange) hoor je een service account te gebruiken om de services onder te draaien (wanneer je een MS course hebt gevolgd, hoor je dit te weten).

Dat beheerders teveel onder root/administrator werken en het zaakje inrichten (omdat dat makkelijk en snel is), is toch niet de fout van de software ontwikkelaar?

[Abom]

Nhlmf,

Met alle respect, maar je bent nu wel appels met peren aan het vergelijken. Eerst heb je het over Apache en IIS, daarna over XP home...

Om eerlijk te zijn boeit het mij geen reet wanneer een XP home machine compromised wordt, in mijn ogen kun je dit met het niveau van de gemiddelde thuis PC gebruiker nooit voorkomen. Ik vind dat MS heel goed bezig is wanneer het gaat over het beveiligen van de PC's thuis. Dit zie ik Linux nooit op deze schaal voor mekaar krijgen (mocht het zo zijn dat zij ooit een keer de thuis-PC markt overnemen van MS). Alleen al door de framentatie van de ontwikkelteams voor een complete distributie.

Bedrijfs netwerken moeten gewoon goed veilig zijn en dat bereik je niet wanneer Microsoft alles voor je regelt.
Af en toe sta ik te kijken watvoor kritiek hier op MS geuit wordt; de ene keer is alles te simpel en daardoor niet transparant genoeg, de volgende keer moet de beheerder weer teveel doen om zijn systeem te beveiligen.

[nhimf]

Wat ik zeg, is dat in de standaard situatie niet uitgegaan moet worden van administrator, dat _juist_ de mensen zonder allerlei cursussen niet dingen "per ongeluk" als administrator draaien. Je moet uitgaan van het feit dat niets als administrator draait, tenzij je specifiek aangeeft dat het wel moet, en dat het je moeilijk gemaakt moet worden om als administrator te draaien.
Dit geld helemaal voor MS, aangezien zij zo druk bezig zijn met de security, maar ze gaan nog steeds (bij thuisgebruik) uit van het feit dat je als gebruiker administrator rechten moet hebben. (wij winxp home is het zelfs onmogelijk om goed te werken met een non-privileged account).

[CerL]

Weet wel waarover je blaat!

IIS maakt standaard gebruik van de user UISR_<MACHINE_NAME>
Deze gebruiker mag onder Windows 2003 nog nieteens een bestandje wegschrijvin in een TEMP folder.

[Regman_XP]

Er zullen toch bestanden worden aangepast moeten worden?

En met een CRC check van die bestanden is te achter halen over die bestanden zijn aangepast.

Het lijkt mij toch niet het grootste probleem.

Een AntiVirus programma loopt altijd wel achter maar dit moet redelijk snel weer afgevangen kunnen worden.

[Milt]

Het probleem is nou juist dat dit soort trojans voorkomen dat je de gewijzigde bestanden ziet. Door de OS API calls af te vangen en de waarden daarvan aan te passen, kunnen bestanden onzichtbaar worden gemaakt. Het wordt daarmee bijv. mogelijk dat als een bestand wordt geopend om te lezen (bijv. virusscan of CRC berekening) dat dan het orginele bestand wordt geopend terwijl als het programma door het OS in het geheugen wordt geladen voor executie, dan wordt het gewijzigde bestand geladen (dit bestand is normaal onzichtbaar).