Erfahrungsbericht Conficker Befall

Wir möchten die Gelegenheit nutzen, eine Geschichte über einen Virenbefall mit „Conficker“ zu erzählen. Eine wahre Geschichte, die wir in der dagewesenen Heftigkeit vorher nicht für möglich gehalten haben. Wenige unserer Kunden hatten in den vergangenen Jahren wirklich ernsthafte Probleme mit Viren. Um ehrlich zu sein, ist bei der QGROUP das Thema Virenbefall aus diesem Grund dahingehend relativ unterrepräsentiert, da wir gemäß dem Grundschutz des BSI bei allen Kunden auf ein 4-stufiges System für Viruserkennung setzen und wir in den letzten Jahren kaum ernsthafte Ausbrüche zu vermelden hatten, die sich nicht relativ leicht beheben ließen.
Die wenigen Ausbrüche, die es gab, waren immer sehr leicht durch entsprechende Removal-Tools und Fleißarbeit in den Griff zu bekommen - jedoch sollte alles ganz anders kommen dieses Mal ... man lernt nie aus! Der Kunde Um es vorab zu sagen: Der Kunde, um den es sich hier handelt, ist entsprechend unserer Empfehlungen extrem gut und sicher ausgestattet. Gemäß BSI Richtlinien und unseren Empfehlungen ist alles Wichtige vorhanden, was Stand der Sicherheitstechnik war und ist. 4-stufiges System gegen bösartigen Code auf allen Gateways, Servern, Mailservern und Endgeräten (Desktops / Notebooks) von TrendMicro Backup System mit „Backup to disk to tape“-Strategie mit großen Overland LTO4 Tape-Robotern - das Backup wird täglich manuell überprüft, die Tapes in einen brandschutzsicheren Datensafe deponiert. Als zentrales Firewallsystem wird ein QTrust Server eingesetzt. Die Server stehen in einem separaten Servernetz und sind von den Clients durch den QTrust Server separiert. Die Firewall-Regeln sind restriktiv sowohl von innen wie auch von außen. Benutzer, die im Internet surfen, werden zwangsweise durch einen transparenten Proxy und durch die Viruswall von TrendMicro geleitet. Alle Systeme sind mit lokalen Firewalls ausgerüstet und nur der notwendigste Datenverkehr ist erlaubt. Es existiert eine Security Policy, in der zusätzlich geregelt ist, was die Benutzer im Netzwerk dürfen oder nicht dürfen. Patches werden gezielt manuell 1x im Monat auf allen Systemen installiert. Alle Endgerät-Systeme im Netzwerk sind Windows XP oder Vista Maschinen. Es gibt auch bereits drei bis vier virtuelle Windows 7 Systeme. Bei den Servern handelt es sich um primär virtualisierte Windows 2003 und Windows 2008 Systeme. Es handelt sich also definitiv nicht um ein Unternehmen, welches in irgendeiner Form grob fahrlässig mit der Sicherheit in der IT umgeht. Trotzdem ist es vor wenigen Wochen einem neuen und extrem aggressiven Conficker-Wurm gelungen, dieses Netzwerk lahm zu legen. Wie konnte das passieren?
Das Problem Am 30.Oktober meldeten fast zeitgleich verschiedene Endgeräte den Ausbruch eines Virus. Das TrendMicro Outbreak-Management schlug Alarm, so dass innerhalb von 3h nach dem ersten Ereignis bereits die Arbeit gegen den Wurm aufgenommen werden konnte. Auch soweit, kann man sagen, lief alles optimal. Aber was war passiert? Wie kam es zum Befall? Ein in dem Unternehmen beschäftigter Praktikant (Student) war mit der Leistung des ihm zur Verfügung gestellten PCs nicht zufrieden. Da er sich eine Woche zuvor ein aktuelles und sehr schnelles Notebook gekauft hatte, dachte er sich nichts Böses und brachte dieses Notebook mit in das Unternehmen. Da er bereits seit Monaten im Unternehmen war und von Anfang an mit dem für Ihn zugeteilten Desktop ohne Probleme arbeitete, fiel niemandem auf, dass er mit einem "privaten" Rechner arbeitete. Damit setzte er sich ganz klar über die Security Policy hinweg, die er selbst unterschrieben hatte. Allerdings war er sich keines Unrechts bewusst. Das Notebook war mit Windows Vista Service Pack 2 ausgestattet und war relativ aktuell gepatcht. Allerdings hatte die Firma Acer das Gerät ohne Antivirensoftware ausgeliefert, und der Praktikant sah keinen dringenden Handlungsbedarf, sofort, bei sowieso knapper Kasse, Geld in eine Antivirensoftware zu investieren. Durch das Surfen im Internet in seinem privaten Heimnetz holte sich der Praktikant den Conficker Wurm und einige andere Viren auf das Notebook. Was nun passierte, ist selbst für "alte IT Hasen" ein echter Sorgengrund. Aber der Reihe nach. Wie konnte sich der Virus ausgehend vom Notebook innerhalb des Netzwerks verbreiten? Das Notebook war nicht Teil der Windows Domäne und hatte aus diesem Grund keine Zugriffsberechtigung auf den Rest des Netzwerks! Dazu muss man wissen, dass der Wurm sich primär über 2 Wege ausbreitet: Über Filezugriff auf gemeinsame Shares wie z.B. SMB Windows File-Server. Über Sicherheitslücken innerhalb der Microsoft Betriebssysteme bei nicht 100% aktuell gepatchten Systemen. Das Notebook des Praktikanten hatte in Ermangelung eines autorisierten ActiveDirectory Accounts keinen Zugriff auf die zentralen File-Server des Unternehmens. Also konnte nur der zweite Weg die Infektion ausgelöst haben, ergo musste zwangsläufig ein System innerhalb des Unternehmens nicht richtig gepatcht gewesen sein. Eine Sicherheitslücke auf diesem System musste durch den Wurm ausgenutzt worden sein. Dieses System wurde erst viel später gefunden. Zu diesem Zeitpunkt musste lediglich anhand der vorliegenden Fakten angenommen werden, dass es überhaupt ein solches ungepatchtes System geben musste, trotz des vorbildlichen Patchmanagements. Ebenfalls musste dieses eine unsichere / ungepatchte System innerhalb der Domäne laufen, um von dort aus alle anderen Domänenrechner infizieren zu können. Die weitere Infektion der anderen Systeme ließ sich relativ leicht erklären: Es war der berechtigte gemeinsame Dateizugriff auf die File-Server des Unternehmens. Die Antivirensoftware von TrendMicro war leider nur in der Lage, den Virus oder Teile davon zu erkennen und zu melden, jedoch konnte TrendMicro den bösartigen Code nicht entfernen. Auch war die von TrendMicro gefundene Bezeichnung des Virus nicht richtig, da das Verhalten des Wurms und seine permanente Neuinfektion nicht zum dokumentierten Verhalten passte. Unsere Sorge wurde größer, allerdings eher im Bezug auf sehr viel befürchtete manuelle Arbeit. Jedoch machten wir uns noch keine Sorgen darüber, ob wir den Wurm überhaupt herunterbekommen. Denn das stand für uns natürlich außer Zweifel. Wir begannen, auf allen Rechnern die laufenden Prozesse zu analysieren, auf denen TrendMicro angeschlagen hatte - und tatsächlich - auf einigen Systemen fanden wir kryptische Prozesse. Diese ließen sich ganz einfach beenden und löschen. Das war es schon? Das war einfach. Wir suchten gezielt nach diesen Prozessen, beendeten diese auf allen Rechnern und löschten die entsprechenden Dateien manuell. Der Virenscanner blieb stumm. Sieg auf ganzer Linie. Leider nicht ganz... die Virenscanner blieben genau 40 Minuten lang stumm. Nach 40 Minuten schlugen die Virenscanner erneut an, mit der gleichen Meldung. Allerdings gab es einen entscheidenden Unterschied: Es gab keine laufenden verdächtigen Prozesse, die wir fanden, auf keinem der Systeme! Und nicht nur auf Windows 2003 oder XP Systemen. Nein, auch auf Windows 2008 und sogar Windows 7 gab es alle 40 Minuten Virenmeldungen aber keine laufenden verdächtigen Prozesse. Langsam aber kontinuierlich stieg die Sorge. Der Wurm der von TrendMicro identifiziert worden war, konnte das nicht, das war klar. Das hier war etwas Fortgeschritteneres. Also standen wir nach erheblicher manueller Arbeit komplett wieder am Anfang und das Gespenst „Neuinstallation“ aller Systeme wandelte durch die Räume des Kunden. Die Situation eskalierte. Es musste irgendein Prozess laufen, der alle 40 Minuten alle Systeme im Netz erneut infiziert, aber es gab keinen unbekannten Prozess! Noch dazu war der erkannte Virus ganz klar nicht der Virus, mit dem wir es hier zu tun hatten. Es musste sich also um ein Rootkit handeln, ein Code, der soweit unten im System verankert ist, dass er sich selbst verstecken kann. Solche Prozesse kann man nicht sehen, auch nicht als Administrator. Einen Prozess zu suchen, den man nicht sieht, auf einem Rechner, von dem man nicht weiß, wo er ist – aussichtslos - gelinde formuliert.
Die Lösung Wir beriefen ein internes Krisenmeeting ein, um alle Kollegen an der Lösung des Problems mitarbeiten zu lassen. Die wichtigste Frage war: „Wie können wir den oder die Rechner identifizieren, der oder die alle 40 Minuten alle anderen Systeme infiziert, ohne deren Prozesse zu sehen?“ Die Kollegen aus der QTrust Entwicklung hatten die zündende Idee: Honeypot (Honigtopf) und QTrust-Server IDS (Intrusion Detection System) sollten uns die Rechner offenbaren, welche die anderen ständig wieder infizierten. Also richteten wir einen Honeypot ein. Dazu wählten wir einen Rechner mit einem neu aufgesetzten aber komplett ungepatchten Windows XP. Auf diesem Rechner installierten wir außerdem ein Netzwerkanalysetool (Etherreal). Das QTrust IDS wurde ebenfalls aktiviert und auf einen Monitor Port auf dem zentralen Switch aktiviert. Dann integrierten wir unseren Honigtopf-Rechner in das Netzwerk. Plötzlich sahen wir im Netzwerkanalysetool den Urheber des Problems. Und alle 40 Minuten wieder und wieder. Das Angriffsszenario hatten wir identifiziert. Nun fütterten wir das IDS System am QTrust-Server mit dem Angriffsmuster und beobachteten das ganze Netz. Und siehe da, wir fanden 2 Systeme, welche die Neuinfektion aller anderen Rechner ständig, d.h. alle 40 Minuten initiiert hatten. Es handelte sich um zwei Test-Systeme (virtuelle Maschinen), die zu Testzwecken kurz aufgesetzt worden waren. Diese Systeme sind jedoch nie produktiv genommen worden und waren somit nicht Teil des Patchmanagements. Dies war zwar sicherlich ein Prozessfehler. Solche Probleme gibt es unserer Ansicht nach bei 100% aller Unternehmen. Wir trennten testweise diese Systeme vom restlichen Netz und siehe da, das 40 minütige Reinfektionsintvervall war durchbrochen. Wir begannen mit der Analyse der Systeme, von denen wir nun wussten, dass sie 100%ig den bösartigen Code enthielten, um sicher zu gehen, dass dieser Code nicht auf anderen Rechnern im System ist (z.B. auf den Servern). Aus diesem Grund begannen wir über Tage, mit diversen Werkzeugen den Prozess oder den schädlichen Code zu isolieren. Das Ergebnis war: Überhaupt kein Erfolg. Eine Infektion unseres Honeypots erfolgte trotzdem regelmäßig, ohne dass die beiden Rechner in irgendeiner Weise verdächtig waren. Der Code wurde nicht gefunden und konnte nicht isoliert werden. Unsere Sorge wuchs. Was, wenn ein solcher Virus auf zentralen extrem wichtigen Servern auftauchen würde? Ohne Chance auf Heilung!? Am Tag der Lösung veröffentlichte Microsoft eine Zwischenversion des Microsoft Tools zur Reinigung für bösartigen Code. Mehr aus Verzweiflung als aus echtem Glauben heraus eine Lösung zu haben, setzten wir das Tool ein. Das vorige MS-Tool, welches wir auch ausprobiert hatten, fand nichts und konnte somit auch nicht cleanen. Das neue Microsoft Tool fand den Code und konnte ihn beseitigen! Wir waren fassungslos. Das Tool war erst 4h vorher veröffentlicht worden und nur dieses eine Tool konnte den Schädling erfolgreich bekämpfen! Wir installierten das Tool vorsorglich auf allen Rechnern des Kunden und ließen es laufen. Es wurden noch 2 weitere Server identifiziert (Domänen-Controller), auf denen der Code wohl ebenfalls vorhanden war. Aber auf diesen Systemen lauerte der Virus passiv ohne andere Rechner zu infizieren. Der Meldungsspuk hatte ein Ende. Die Rechner wurden alle erfolgreich gescannt und gecleaned. Ohne das Microsoft Tool hätten wir keine Chance gehabt...
Fazit: Die Kosten nur für die Dienstleistung in Summe von ca. 16.000€ ohne Produktivitätsschaden (Vermögensschäden). Trotz gut ausgebildeten Mitarbeitern und tiefgreifendem Fachwissen war es uns nicht möglich, ohne die Hilfe von Microsoft das Problem zu lösen. Wir haben einen Eindruck davon erhalten, wie verloren man sein kann, wenn bösartiger Code im Netz unterwegs ist. Die alte Regel: Es gibt keinen 100%igen Schutz haben wir erlebt. Trotz hohem IT Security Budget und wirklich vorbildlicher Sicherheitslösungen und ordentlicher Prozesse wurde dieses Unternehmen Opfer von bösartigem Code. Keiner der teuren Antivirus-Hersteller (McAffee, TrendMicro, Symantec, Kaspersky und diverse andere) war in der Lage, den Code zu cleanen. Einige waren nicht mal in der Lage, den schädlichen Code überhaupt zu erkennen. Ausschließlich das Microsoft-Tool war dazu in der Lage! Und das gab es erst seit wenigen Stunden. Die Kosten für diese professionellen Antiviren-Systeme sind erheblich, aber der Nutzen im Schadensfall eher gering bis nicht vorhanden. Teilweise waren die angebotenen Lösungen dermaßen schlecht, dass man hier tatsächlich nicht immer davon ausgehen kann, dem Hersteller läge die Sicherheit des Kunden am Herzen, vielmehr dessen Geldbeutel. Es gab erhebliche Produktionsausfälle, da Anwendungen durch die hohe Auslastung der Virenscanner nicht mehr reagierten, wie z.B. Datenbanksysteme. Normalerweise hat man nach einem Schaden eine Menge guter Tipps, was man tun kann, um den gleichen oder ähnlichen Fall in Zukunft zu verhindern. In diesem Fall - Fehlanzeige. Der Befall in dieser oder in einer ähnlichen Situation kann derzeit nicht vermieden werden. Um es noch einmal klar zu sagen: Wir haben bereits viele Sicherheitsprobleme bei Kunden gelöst, alle waren im Vergleich hierzu aber harmlos und eher lästig. Hier haben wir eine komplett neue Form der Bedrohung erlebt. Solche Infektionen können in jedem Netz auftreten! Je größer, desto wahrscheinlicher! Anmerkung: Wir behaupten: Microsoft hat Hintertüren (Backdoors) in seine Betriebssysteme eingebaut. Obwohl das Cleaning-Tool in einem Userkontext gestartet worden ist, auf dem der ausführende User keine Berechtigungen auf bestimmte Teile des Systems hatte, scannte das Tool auch diese Teile vollständig. Unserer Meinung nach bedeutet dies, dass Microsoft bewusst Mechanismen eingebaut hat, um selbst auf tatsächlich alle systemrelevanten Komponenten im laufenden Betrieb zugreifen zu können (wie ein rootkit). Wenn es aber einen solchen Mechanismus gibt, kann auch ein bösartiger Code diesen Mechanismus verwenden, um Schaden anzurichten. Dies ist alles andere als der Ansatz des "Trusted Computing", den Microsoft marketingmäßig seit einiger Zeit propagiert. Den Ansatz, den z.B. Argus mit PitBull oder Linux mit SELinux verfolgt, ist hier die ehrlichere und effizientere Form des Trusted Computing. Microsoft und alle anderen Hersteller, aber auch die Kunden und die öffentlichen Institutionen, müssen nun ernst machen mit dem Thema Trusted Computing.