Wer nicht hören will... Marc Ruef | 03.08.2005 Ich arbeite nun schon bald 3 Jahre bei scip AG (http://www.scip.ch) in Zürich. Seit der Firmengründung geniesse ich die fachliche Kompetenz und den menschlichen Umgang von Simon und Rocco. Momentan sind wir eigentlich ganz gut mit Aufträgen bedient. Na ja, für mein Privatleben ansich ist das nicht so toll, denn die eine oder andere Überstunde ergibt sich halt zwangsweise aus der Fülle an interessanten Projekten, die uns zugetragen werden. Letzter Donnerstag war einer der wenigen Tage jener Woche, an denen keine festen Termine - vor allem solche mit Kunden - in meinem Kalender vorgesehen waren. Entsprechend entspannt kam ich am späteren Morgen auf 09:00 Uhr ins Büro, denn die kleineren Aufgaben, wie das Abfüllen unserer Verwundbarkeitsdatenbank (http://www.scip.ch/cgi-bin/smss/showadvf.pl) oder das Eintragen der zu verrechneten Stunden liess mich nicht hetzen. Simon blickte mich jedoch schon beim Eintritt ins Büro - es schien, als wäre er gerade am Telefon mit einem Kunden - mit ernster Mine an. Er ist viel eher der Morgenmensch weder ich und so deuten derlei Blicke meistens auf "Probleme" hin. Als er den Hörer des noch nicht mal einen Monat alten Siemens-Telefons zurück in die Gabel gelegt hatte, wendete er sich zu mir: "Es gab einen Zwischenfall bei einer Firma X - ein Neukunde - und jemand von uns muss sofort hin..." - Incident Handling und forensische Analysen sind einige meiner Spezalitäten. Ich fragte nach den Rahmenbedingungen des Projekts, was in etwa passiert war, was es anzuschauen gilt und wer meine Kontaktperson sei. Nach einem kurzen Vorab-Briefing fuhr mich Simon zum Kunden und der unvorhergesehene Tag nahm weiter seinen Lauf. Der Security Officer des Unternehmens holte mich am Empfang ab und ich wurde sofort in die Sitzung mit einigen Technikern geladen. In der Luft hatte sich eine gewisse Anspannung niedergelegt - Man rechnete mit dem schlimmsten: Werksspionage. Selten komme ich am Morgen zu einem Kunden und die obligatorische Frage nach einem Kaffee bleibt aus. Das war verdächtig. Diese Leute hier hatten jedoch zur Zeit andere Probleme, weder koffeinhaltige Getränke zu servieren. Kurz und knapp wurde mir erzählt, dass in den gern genutzten Web-Shop des Unternehmens eingebrochen wurde. Ein Angreifer habe in der Nacht auf den heutigen Tag die Startseite mit einem Spruch versehen und damit zugleich das Angebot für die Kunden unbrauchbar gemacht. Der Server wurde nach Feststellung dieses Zwischenfalls sofort vom Netz genommen. Meine Aufgabe bestand nun darin zu klären, wie diese Attacke umgesetzt wurde, welche anderen Teile des Systems sowie der Umgebung ebenfalls betroffen waren und wie die unverzüglich einzuleitenden Massnahmen auszusehen haben. Ich war noch keine 15 Minuten vor Ort und fand mich schon an der Konsole eines Microsoft Windows 2000 Servers wieder. Für eine forensische Analyse ist Windows nicht besonders dienlich und ich stellte mich auf einige spassige Stunden mit dem Zusammenkratzen von Detailinformationen ein. Der Server-Raum war verhältnismässig gross und wie immer unangenehm laut. Dies sollte mich jedoch nicht davon abhalten, meine Standard-Prozedur für solche Zwischenfälle durchzugehen. Als erstes trug ich sämtliche Daten des Hosts zusammen: System- und Netzwerkkonfigurationen, Benutzereinstellungen und -Rechte, Protokoll-Einstellungen und -Dateien. Zum einen ist dies eine extrem wichtige Beweissicherung - Zum anderen kann ich mir so gleich einen Überblick des Systems, mit dem ich zuvor noch nie in Berührung gekommen war, verschaffen. Nach dem ich das handgestrickte Log-Konzept auf dem System verstanden hatte (die Dateien wurden in einem proprietären Format an einen speziellen Ort gespeichert), schaute ich mir die vom Eindringling erstellten Defacement-Dokumente an. Eine Einsicht in die HTML-Dateien zeigte mir, dass der Angreifer nicht viel Ahnung von der relativ primitiven Seitenbeschreibungssprache hatte. Es war offensichtlich, dass das neue default.html aus drei verschiedenen HTML-Dateien zusammenkopiert wurde, denn eine solche Inkonsistenz im Aufbau sowie der Nutzung von HTML-Tags und -Attributen konnte nicht aus einer Feder stammen: Gross- und Kleinschreibung war grundsätzlich durcheinander, die Sonderzeichen wurden stets anders behandelt und die Absätze wurden immerwieder anders gesetzt. Dies - und der viel zu offensichtliche Defacement-Angriff ansich - waren das erste Indiz, dass von einem professionellen Angreifer abgesehen werden konnte. Wirtschaftskriminalität passiert heimlich und leise, um möglichst effizient und unbeobachtet einen Vorteil zu erschleichen. Nachdem ich die vom Angreifer hinterlassenen Dateien samt Pfadangaben und Namen dokumentiert hatte, untersuchte ich die Protokoll-Dateien auf jene Aktivitäten, die mit diesen Zugriffen zu tun haben konnten. Spätestens in den Logs des Webservers - ein Microsoft IIS 6.0 - wurde ich fündig. So stellte ich fest, dass die Dateien simpel durch das HTTP PUT-Kommando auf den Webserver geladen wurden. Eine sehr einfache Sache, die man technisch überbewerten würde, würde man sie als "Hack" bezeichnen. Also ein weiteres Indiz, dass wir es hier eher mit einem Skript-Kiddie zu tun haben. Weitere Analysen konnten dieses Profiling nur bestätigen. Am frühen Nachmittag trug ich vor den Verantwortlichen meine ersten Resultate vor. Ich berichtete von der Einfachheit des Angriffs und von meinen Vermutungen, dass es sich hier um eine einmalige "Spass-Aktion" und nicht um Industriespionage handelte. Als Profil des Angreifers habe ich einen jungen Mann zwischen 20 und 25 Jahren, türkischer Herkunft, einem überdurchschnittlichen Bildungsniveau und mit unfundierten Kenntnissen zum Thema Computersicherheit determiniert. Die Attribute des Angriffs wie die das Resultat eines plumpen Defacements, die mangelnde Qualität der HTML-Dateien, die Einfachheit des Einbruchs, das mehrmalige Umsetzen der Zugriffe aufgrund von Fehlern im HTTP-Syntax sowie das Nutzen von Microsoft Windows XP mit Service Pack 1 und Internet Explorer 6.0 in englischer Version liessen mich diese Ableitungen machen. Sämtliche Anwesenden am Tisch konnte ich von meiner Expertise überzeugen, weshalb wir schnell zur Besprechung der Sofortmassnahmen übergingen. Im Verlauf der weiteren Interviews mit den involvierten Personen dieses Tages fiel mir unweigerlich auf, dass das HTTP PUT-Problem schon länger bekannt war. Im Rahmen eines Security Audits einer unserer Mitbewerber wurde das erste Mal auf diese Schwachstelle der Webserver hingedeutet - Und dies war vor Rund zwei Jahren der Fall. Eine Umsetzung der in besagten Report empfohlenen Gegenmassnahmen blieb aber bis heute aus. Begründung: Ressourcen-Mangel. Diese Nachlässigkeit hat sich nun mit voller Wucht gerächt. Hektik und Stress sind die Folgen einer Ignoranz, der so manche Firma schon zum Opfer gefallen ist. Die Leidtragenden sind dabei meistens die ausführenden Techniker. Auch in einer virtuellen Welt gilt also: Wer nicht hören will, muss fühlen. Dies gilt im Übrigen auch für Angreifer, die nicht genau wissen, was sie tun. Ich bin mir ziemlich sicher, dass der in diesem Fall ausgemachte Angreifer sich gar nicht im Klaren darüber ist, wie und welche Informationen innert weniger Stunden über ihn zusammengetragen werden konnten. Es bleibt nun unserem Kunden überlassen, ob und inwiefern Klage gegen den Täter eingereicht wird. Eines ist Sicher: (Computer-)verbrechen lohnt sich nicht in der Zeit mit der Möglichkeit umfassender forensischer Analysen.