Ein anonymer Poster warnt auf der Sicherheits-Mailingliste Full-Disclosure vor modifizierten Exploits. Er sei zufällig auf ein solches Demo-Programm gestoßen, in dem gegenüber dem Original der Shellcode ausgetauscht wurde. Die trojanisierte Version versucht, alle Dateien auf dem Testsystem zu löschen.
Der Shellcode ist der oft angeführte "beliebige Code", der bei Pufferüberläufen eingeschleust und ausgeführt werden kann. Er besteht aus Assembleranweisungen, die in C-Programmen meist als Hexadezimalwerte auftauchen und für Normalsterbliche nicht direkt lesbar sind.
char shellcode[] = // binds 4444 port
"\x31\xc0\x50\x68\x66\x20\x2f\x58\x68\x6d\x20\x2d\x72\x68\x2d"
...
Dieser Code soll auf den Stack des anfälligen Programms geschrieben und dort ausgeführt werden. Dann öffnet er zum Beispiel eine Hintertür, über die der Angreifer dann auf das System zugreifen kann.
In den modifizierten Exploits haben Unbekannte diese Codesequenz durch Assembleranweisungen ersetzt, die den Befehl rm -rf /* ausführen. Des Weiteren wird der Code nicht in das zu testende Programm eingeschleust, sondern direkt lokal auf dem System des Testers ausgeführt. Arbeitet dieser als Root -- was bei Exploits häufig erforderlich ist, um beispielsweise Zugriff auf Raw Sockets zu haben -- löscht der Code auf Unix-Systemen rekursiv alle Dateien.
Bei weiteren Untersuchungen will der Poster über zwanzig derartig modifizierte Exploits entdeckt haben. Manche davon installierten sogar ein zusätzliches Kernelmodul -- also wahrscheinlich ein komplettes Rootkit. Er spekuliert, dass diese Trojanischen Pferde gezielt von einer Gruppe namens "dikline" verbreitet werden, die kürzlich in eine Security-Site eingebrochen sei.
Solche Trojaner-Exploits sind nicht neu. Bereits in der Vergangenheit wurden auf Mailinglisten Exploits veröffentlicht, die exakt den aufgeführten Shellcode zum Löschen aller Dateien enthielten. Neu ist allerdings die von dem Poster festgestellte systematische Vorgehensweise.
Demo-Exploits aus dem Internet sollte man grundsätzlich nur auf Testsystemen in isolierten Testumgebungen ausprobieren. Sonst kann der "schnelle Test" auf eine Verwundbarkeit fatale Folgen haben. Das Vorliegen des Quellcodes schützt nicht, solange man es bei einer oberflächlichen Analyse belässt.
(heise,de)
