Von Rootkits und Würmern

Folgender Text war zu lang für's Heise-Forum. Deshalb hier.

Der Permalink dieses Textes lautet permalink.de/tino/wurmt

SQL-Slammer war zwar kein Rootkit, aber uns könnte Schlimmeres bevorstehen

SQL-Slammer war in seiner Form herausragend (im wahrsten Sinne des Wortes).

Und SQL-Slammer war vergleichsweise harmlos. Stellen wir uns dasselbe vor, nur "stealthy", sprich hinterhältig unsichtbar.

SQL-Slammer dürfte so jedes größere Firmennetzwerk erreicht haben. Stellen wir uns also ein Rootkit vor, dass dasselbe erreicht, und ein "fast unsichtbares" Netzwerk baut, vorbei an den Firewalls.

Bitte bedenken:

SQL-Slammer war nicht einmal TCP, also etwas, was selbst schlechte NAT-Firewalls automatisch blocken sollten. Trotzdem erreichte SQL-Slammer hochgesicherte Intranets, die allerdings eben das Problem hatten, dass sie hin und wieder eine Kommunikation nach außen schalten. Dazu musste aber auch eine transparente UDP-Verbindung zugelassen werden, was offensichtlich überhaupt nicht so selten war.

Bei regulären SQL-Verbindungen ist das eher noch schlimmer, diese laufen meist ohne Application-Firewall, somit kann man die vielleicht sogar über einen SSL-Proxy schalten. Im Rückschuss wird die DB dann infiziert, wenn man eine Verbindung von einem kompromittierten System annimmt. Diese gesamte Sache ist schleichend.

Hinzu kommt, dass aus SQL-Slammer nicht viel gelernt wurde. Die Patches werden inzwischen vielleicht etwas schneller installiert und nicht mehr fast 2 Jahre schleifen gelassen, aber gegen "flashige" (damit ist deren Geschwindigkeit gemeint) Rootkits ist kein wirkliches Kraut gewachsen.

Datenbanken sind oft extrem wichtig. Die Datenbestände sind weit mehr Wert als die Hardware, der Betrieb und die Software zusammen. Viele Datenbanken müssen 24/7 verfügbar sein.

Stellen wir uns ein wirklich hinterhältiges Rootkit vor, dass die Daten intern in der Datenbank verschlüsselt. Es reicht wenn es ROT13 verwendet, aber eben im RAM hält, welche Datensätze schon "Rotiert" wurden. Die Datenbank läuft weiter, aber wenn man das Rootkit entfernt sind viele Daten Makulatur.

Wenn das Rootkit, abgesehen davon, "offensichtlich harmlos" ist (Datenbank läuft weiter), wird keine Firma die Welle machen können und den letzten sauberen Datenbestand einspielen. Man schaltet temporäre Gegenmaßnahmen und läßt das Rootkit laufen, bis ein Removal-Tool verfügbar ist, das die entsprechende Datensicherheit mit sich bringt.

Zeitlich bedeutet das folgendes:

• Tag 0: Freitag: Das Rootkit kommt heraus.
  
• Tag 1: Samstag: Das Rootkit wird entdeckt. Gegenmaßnahmen werden eingeleitet.
• Tag 2: Sonntag: Nicht alle Admins wurden erreicht. In den meisten Netzen wütet das Rootkit.
• Tag 3: Montag: Die weitere Verbreitung des Rootkit ist eingedämmt.

Sprich, das Rootkit hat über 2 Tage um sich zu verbeiten und in den Datenbanken festzusetzen! Danach ist die Verbreitung gestoppt, aber es hatte bereits Stunden Zeit um Datenbestände zu infizieren.

Das Backup von Freitag, Samstag und Sonntag ist Makulatur, die Daten am Montag wären auch verloren. Am Montag wird deshalb beschlossen, das Rootkit weiterlaufen zu lassen um die Daten zu retten.

Hinweis: Das Rootkit ist extra so konstruiert, damit die Entscheidung so fällt!

• Tag 6: Emergency Hotfixes kommen heraus, die die Lücke nachhaltig (also auch für veränderte Rootkits) stopfen. Ein Restore mit Rollforward wäre nun möglich, es steht auch ein Tool bereit, das die Änderungen in der Datenbank rückgängig macht, allerdings muss die Datenbank dafür Offline genommen werden (dafür wird ein Backup der DB angestoßen, anschließend der Speicherinhalt gedumpt, das Tool identifiziert dann die falschen Datensätze und korrigiert sie, allerdings offline!).

Dies ist eine gute Schätzung. Hotfixes können zwar in weniger als 1 Tag bereitgestellt werden, aber diese taugen nicht richtig. Sie sind nicht nachhaltig (beseitigen nicht alle Lücken) und können das Datenproblem nicht beseitigen. Somit besteht die Gefahr, dass man Daten verliert oder dass selbst in gepatchte Systeme ein leicht veränderter Wurm wieder eindringt.

Da man auch im Datenbankbereich "mit Wasser kochen kann", muss auf den nachhaltigen Patch gewartet werden, dieser muss mit entsprechenden "Samples" durchgeprüft werden usw. Dies braucht Zeit, d. h. die Freigabe erfolgt eben erst 5 Tage nachdem die Analyse des Problems fertig war.

• Tag 7: (Freitag) Die meisten Firmen wollen patchen. Es stellt sich aber heraus, dass das Wochenende nicht reicht um den Rollforward einer Woche nachzuholen, da die Hardware für solch einen extremen Fall nicht ausreichend dimensioniert ist. Auch das Tool läuft nicht schnell genug.

Nur kleinere Datenbanken bis hundert GB und hyperkritische Systeme werden mit Riesenaufwand gepatcht. Data-Warehouses, die Ladezeiten von mehreren Monaten haben, können in dieser Form gar nicht angegangen werden.

• Tag 14: (Freitag) Mit viel Aufwand sind die weiteren Maßnahmen erfolgreich. Sauber gepatchte Systeme die parallel zum alten System laufen sind installiert und "hot", sprich die Daten können von der alten Datenbank online in die neue gepumpt werden, die dann Rootkit-frei ist.

Das ist eine optimale Schätzung. Selbst mit Business on Demand ist eine derart schnelle Bereitstellung und Abnahme einer Datenbank nur im unternehmenskritischen Umfeld derart schnell möglich. Wichtig: Die Datenbanken sind abgenommen, die entsprechenden Serviceverträge stehen, entsprechende Garantien für den Datenbankbetrieb sind vorhanden!

Augen-zu-und-Durch-Methoden kann man in "Frickelbuden" haben, in unternehmenskritischen Anwendungen muss für jede Maßnahme jemand die Verantwortung übernehmen. In sofern ist eher zu erwarten, dass das Ränkespiel der Entscheider länger als 14 Tage in Anspruch nimmt, trotz Krisensitzungen.

• Tag 18: (Dienstag) Die neuen Datenbanken laufen parallel, abschließende Checks sind positiv.

Dies betrifft nur kleinere Datenbanken im Bereich unterhalb von einigen Terabyte.

Größere Data-Warehouses im Bereich mehrerer Terabyte in solch einer Situation mehrere Monate. Das Problem ist, dass die Hersteller dieser Warehouses nicht genug Kapazitäten aufbringen können, um die Firmen mit der notwendigen Zusatzhardware auszustatten. Es kann sogar auf dem Weltmarkt zu Knappheit von bestimmter Serverhardware (Mainboards, RAMs und Prozessoren) kommen, weil der Weltmarkt auf den plötzlichen Anstieg dieser Hardware nicht vorbereitet ist. Deshalb werden die Data-Warehouses dieser Größe mit einem Hotfix versorgt, der den Wurm entfernt und die Daten wieder zurückdreht. Das kann mehrere Monate dauern.

• Tag 20: (Donnerstag) Die neuen Datenbanken sind live, die meisten alten mit Rootkit werden abgeschaltet.
• Tag 21: Es steht der abschließende Patch zur Verfügung, der eine implizite Rückkonvertierung der Daten übernimmt und den laufenden Betrieb der Datenbank nicht unterbricht.

Solch einen Patch zu bauen ist nicht so einfach wie man sich das denkt. Es kann dafür zwar die Technik des Wurms verwendet werden, aber hier stehen mögliche Regress-Forderungen dagegen, dass man "einfach mal so schnell handelt". Unter Umständen könnte solch ein Patch nämlich mehr Schaden anrichtet als der Wurm selber.

Der Wurm kann durchaus seine Marker, welche Daten er bereits verdreht hat und welche nicht, im RAM halten. Sprich eine "schalte mich ab und Du bist tot"-Mentalität besitzen. Ist er erst einmal gekillt, ist es zu spät, um noch zu reparieren. Somit muss der Patch wirklich gut getestet sein bevor er genutzt wird. Nochmals: Das betrifft Datenbanken, die mit 24/7 laufen, und die nicht einfach so (oder nur kurze Zeit um den Speichersnapshot zu ziehen, den Patch Einzuspielen, die Speicherinformationen auszuwerten und die Datenbank wieder anzufahren) abgeschaltet werden können.

So sieht IMHO ein mögliches Szenario aus. Nochmals: Das sind "gut"-Schätzungen, wenn die Leute "fit" sind. Das Problem ist, dass die normalen Fallback-Szenarien hier nicht wirken.

Wäre die Datenbank ausgefallen wäre das Problem bereits bei Tag 5 beseitigt (Desaster-Recovery vom "Tag -1" und Rollforward). Aber hier hilft keine "Backup-Hardware", hier sind direkt die Daten und die Software selber betroffen. Und perfiderweise funktioniert alles (wenn der Wurm gut gemacht ist), d. h. das Business sieht keinen Grund, den Schaden zu vergrößern, so lange nicht klar ist, dass dies ein gefährlicher Kurs ist. Besonders wenn sich das "Abschalten tötet die Datenbank" schnell rumspricht.

Und es ist ein gefährlicher Kurs. Der Wurm kann sehr kompliziert sein. So kompliziert, dass es mehrere Monate dauert, den Code komplett zu inspizieren.

Der Wurm kann eine Routine enthalten, die es ihm möglich macht, weitere Löcher aufzureißen, an die man bisher nicht gedacht hat. Löcher, die dazu da sind, den eigentlichen Schadcode eindringen zu lassen.

Sprich, nachdem der Wurm es sich hat 14 Tage lang gut gehen lassen, lädt er Schadcode nach. Wird er daran gehindert, ist die Datenbank tot. Kann er es aber, kannst Du nicht mehr patchen. Der Wurm kann sogar die Mitarbeit vom Admin fordern, a la:

"Gehe auf Seite X, downloade Programm Y und installiere es auf dem Rechner. Tust Du es nicht, ist die Datenbank tot. Du hast 2h Zeit."

Keine Chance auf Gegenmaßnahmen.

Die Gegenmaßnahmen müssen jetzt erfolgen. Deshalb sind Black-Hats so wichtig.

Deshalb ist Hacking so wichtig. Deshalb ist Kriminalisierung dieser Leute (durch Strafgesetze) das fatalste, was einem Staat einfallen kann.

Macht es ihnen nicht schwer, macht es ihnen leicht. Stellt nicht das Hacking (Forschen) unter Strafe, sondern nur das Cracking (Schaden). Und übrigens, Kunstfehler kommen vor. Nicht nur bei Ärzten.

Deshalb wäre es gut, diese Leute (damit meine ich Hacker und Ärzte) vor den Folgen solcher Fehler zu schützen. Das bedeutet nicht, dass man dann gefahrlos "rummetzeln" darf, sondern dass im wirklichen Fall eines Kunstfehlers (im Sinne eines Unfalls) die Existenz des Verursachers nicht vernichtet wird (das Opfer muss aber entschädigt werden!). Denn nur wer etwas tut kann Fehler machen.

OK, ich weiß, das geht sicher zu weit. Also fangen wir einfach mal damit an, das Hacking alleine nicht verboten sein darf.

Aber darauf hört ja sicher ebenfalls keiner.

Ich bin mir aber trotzdem sicher, dass kein Szenario wie oben geschildert ausbricht. Bevor das passiert, findet sich ganz sicher ein "böser Hacker" der einen entsprechenden Warnschuss losläßt, obwohl das an sich illegal ist.

Ich vermute immer noch, dass SQL-Slammer genau solch ein Warnschuss war. Denn SQL-Slammer war frei von Schadcode, Code, den man leicht im SQL-Slammer hätte unterbringen können: "Vernichte die Maschine nach 8h" hätte voll ausgereicht um Welt in ein IT-Desaster zu stürzen. Genau das ist nicht passiert.

-Tino, 2006-01-24
PS: Haben wir aus SQL-Slammer etwas gelernt? Nein. Werden wir aus solchen Situationen je etwas lernen? Nein. Das ist die Natur des Menschen.