hallo dominik,
grundlegend sind grob korrekt, aber ich versuche mal eine genauere Beschreibung.
In Windows wird unter anderem RPC/DCOM genutzt, um eine Kommunikation unterschiedlicher Prozesse zum austausch von Daten lokal oder über Netzwerk zu ermöglichen. Vor einiger Zeit wurde ein Fehler innerhalb DCOM entdeckt, der verursacht, daß gewisse Pakete, die an DCOM übermittelt werden nicht genau überprüft werden und einen Buffer Overflow verursachen können. Schlicht gesagt überschreibt der Inhalt einer Variablen die Grenzen des Speichers, die für diese Variable von dem Prozess reserviert wurde und überschreibt dadurch Werte anderer Variablen und was noch schlimme rist, die Rücksprungadressen welceh nach den Variablen abgelegt werden und dem Prozess sagen, an welche Stelle des Codes er zurück muß nach dem Einlesen.
So ein BO hat zur Folge, daß ein Angreifer, wenn er diese Lücke nutzt, eigenen Code innerhalb des Programmflusses injizieren und ausführen kann. Blaster macht genau dies.
Blaster sendet also diese präparierten Pakete an IP-Adressen, die er zufällig ab einer frei gewählten und zufälligen Startadresse wählt. Jetzt kommt das Problem. Für Windows2000 muß das Paket anders aussehen als für WindowsXP. Da Blaster aber nicht weiß (er könnte es, wenn er anders geschrieben wäre) ob er einen XP oder einen 2000 Rechner vor sich hat wählt er rein zufällig das Paket aus.
Wählt Blaster nun zufällig falsch und sendet an einen Windows2000-Rechner das Paket für einen XP-Rechner, so passiert das, was alle Blastergeschädigten kennen: "svchost.exe hat einen Fehler verursacht...blablabla...".
Warum nun svchost.exe? In Windows (den NT-Derivaten ab 2000) verwaltet der ServiceHost (svchost.exe) viele verschiedenen Dienste als "Überprozess", darunter auch RPC. Stürzt nun RPC ab, aufgrund des falsch gewählten Paketes (bei dem falschen Paket wird ein falscher Offset als Sprungadresse angesprochen), so reisst es den svchost mit und der Rechner will neu starten, da in der Diensteverwaltung standardmäßig ein Neustart bei Fehler dieses Dienstes vorgesehen ist.
Ergo, der Rechner stürtzt nur ab, wenn der Eploit fehlschlug!
Wählt Blaster hingegen zufällig den richtigen Exploit für das Opfersystem, so passiert folgendes:
-
- Der Code wird in DCOM injiziert und ausgeführt
-
- Der Code startet den Download der eigentlichen Schadprogramme über das ThinFTP-Protokoll (tftp)
-
- Das eigentliche Schadprogramm wird gestartet (msblast.exe, eventuell in abgewandelten Versionen auch penis32.exe oder teekids.exe)
-
- Es wird eine Backdoor im System installiert, welche auf Port 4444 einen Shellzugang anbietet
-
- Port 69 wird für den eigenen TFTP-Server geöffnet um weiteren infizierten Rechnern den Download der Schadroutine zu ermöglichen
-
- Blaster wählt eine neue Startadresse zufällig aus entweder als Internetadresse oder als Adresse im Internet
-
- Blaster sendet ab dieser Adresse sequentiell seine manipulierten RPC/DCOM-Pakete an den TCP-Port 135, ungeachtet ob dort wirklich ein System zu finden ist oder nicht
-
- Wird ein weiterer Rechner infiziert, so lässt Blaster ihn über TFTP die Schadroutine herunterladen
-
Im Großen und Ganzen war dies der Ablauf bei Blaster, abgesehen von dem nicht stattfindenden dDoS-Angriff aus windowsupdate.com.
Daß sowohl bereit infizierte Rechner, als auch nicht infizierte Rechner abstürzen können liegt wie oben angedeutet daran, daß Blaster recht schlampig programmiert wurde. Zum einen überprüft er nicht, ob ein System bereits infiziert ist, zum anderen sendet er seine Schadpakete nicht systemspezifisch, sondern zufällig, wodurch die Abstürze erst zustande kommen durch den falschen Offset bei der Ausführung.
Hätte der Programmierer von Blaster sich mehr Mühe gegeben bei dem Aufbau und hätte zuerst überprüft, ob ein System bereits befallen ist und hätte vor dem eigentichen Angriff getestet, ob es ein Windows2000 oder ein XP-System ist oder hätte erkeinen festen Offset gewählt, so wäre sein "Erfolg" wohl etwas größer ausgefallen, da die Leute nicht durch die ständigen Abstürze auf die Gefahr hingewiesen worden wären und die infizierten Systeme wochenlang ihre Arbeit hätten verrichten können.
Ich hoffe der ganze Kram, den ich hier geschrieben habe nutzt Dir was. Bei weiterem Interesse kannst Du ja mal auf den Seiten von CERT (Computer Emergency Response Team) weitere Details nachlesen.
[Diese Nachricht wurde nachträglich bearbeitet.]