Entweder haben Sie diese Erfahrung bereits gemacht, oder – auch wenn ich keinem von Ihnen die Erfahrung wünsche – werden Sie sie wahrscheinlich noch machen. Es liegt daher nahe, dass man sich darauf vorbereitet. Verneinung und das Prinzip-Hoffnung sehe ich als keine erfolgsversprechenden Strategien. Wie der Titel bereits sagt, geht es in diesem Artikel um Incident Response. Er entstand im Anschluss an eine anspruchsvolle Nachtschicht. Ein Kunde bat uns, bei der Abwicklung eines Systemeinbruchs, seine interne IT-Abteilung zu unterstützen.

Am Anfang kommt der Anruf

Aus unserer Perspektive steht am Anfang der Anruf. Nicht selten kommen diese genau kurz vor oder nach 17 Uhr und ebenfalls nicht selten an einem Freitag. Es scheint, als mögen es die Angreifer, ihren Opfer das ruhige Wochenende zu ruinieren.

Da uns die Arbeit jedoch Spass macht und sie nicht nur sehr spannend, sondern auch herausfordernd ist, haben sie bei uns schlechte Karten. Die Motivation für einen solchen Auftrag ist sofort präsent. So auch an diesem besagten Freitagabend. Nach den ersten Vorabklärungen vereinbarten wir mit dem Kunden ein sofortiges kommen. Je nach Situation kann aber auch anders reagiert und die Arbeit auf den nächsten Morgen verschoben werden. Wenn es das Geschäftsfeld des Kunden jedoch bedarf, sollte man es auf keinen Fall verschieben.

Überblick verschaffen

Bereits durch unser projektbasierte Geschäft kennen wir die Situation: In kurzer Zeit möglichst viel Wissen über eine Lösung anzueignen. Bei einem Incident kann oft bereits auf das vorhandene Know-how aufgebaut werden, neues Wissen muss dafür umso schneller akquiriert werden. Der beste Einstieg ist aus unserer Erfahrung ein detailliertes Briefing. Man lernt sich kennen, klärt die Zuständigkeiten, bringt Details zum Angriff und was bisher geschah zur Sprache und klärt den aktuellen Status der Systeme.

Danach ist es von zentraler Wichtigkeit, dass man das Ziel des Einsatzes nochmals genau definiert. Soll eine strafrechtliche Untersuchung angestrebt werden, müssen anderer Schritte eingeleitet werden, als bei einer reinen Absicherung und Wiederherstellung des Systems. Ohne diese Definition verliert man nicht nur Zeit, sondern auch potentiell wichtige Daten.

Bei diesem Incident konzentrierten wir uns auf drei Schritte:

1. Analyse: des Systems und Einbruchs
2. Sofortmassnahmen: Absicherung für schnelle Wiederinbetriebnahme
3. Weitere Massnahmen: weitere Erhöhung der System-Sicherheit mit einem längeren Zeithorizont

Systemanalyse

Die Baustellen

Wir fanden ein System vor, welches verschiedene Probleme aufwies. Die aus unserer Sicht grössten Probleme findet man in der nachfolgenden Liste. Dabei handelt es sich nicht ausschliesslich um Punkte, welche ein spezifisches Produkt betreffen:

• veraltetes Betriebssystem
• veraltete Software
• keine Firewall Restriktion ins Internet
• keine Übersicht über Normalzustand
• kein Monitoring
• kein Intrusion Detection System
• keine Trennung von Services

Dieser Kunde hatte zum Glück ein aktives Logging. Auch hier gibt es noch Verbesserungspotential, aber nicht selten treffen wir auf Situationen, in denen das betroffene System oder auch die ganze Umgebung ein ungenügend oder sogar nicht vorhandenes Logging hat.

Die Spuren

Der Angreifer hinterliess in diesem Fall einiges an Spuren. Er überliess uns sogar ein ansprechend und umfassendes Exploit-Kit – dazu später mehr. Durch die vielen Baustellen konnte der Eintrittspunkt nur auf einen Bereich des Systems eingeschränkt werden. Während der ganzen Analyse schauten wir an die verschiedensten Ecken des Systems.

Wir hatten hatten verschiedene Teile im Visier:

Sofortmassnahmen

Parallel zur Systemanalyse arbeitete ein zweites Team, bestehend aus jemandem von uns und des Kunden, an verschiedenen Konzepten, um das System möglichst schnell abzusichern und den Betrieb wieder aufnehmen zu können. Dank eines stetigen Informationsaustausches zwischen dem Analyse- und dem Solution-Team, konnten die Ansätze gleich auf die Machbarkeit geprüft werden. Durch diese gleichzeitige Arbeitsweise konnte insgesamt Zeit gespart und die Offline-Dauer reduziert werden.

Nach ungefähr drei Stunden wurde eine temporäre Lösung mit CloudFlare auserkoren. Der ausformulierte Action-Plan wurde für jeden gut ersichtlich aufgelistet und Schritt für Schritt abgearbeitet.

Mittlerweile war ca. 3 Uhr und die Konzentration liess bei allen beteiligten nach. Ein sauberes und kontrolliertes Vorgehen kostete zwar Zeit, brachte aber persönliche Sicherheit. Die Lösung beinhaltete den gesamten externen Verkehr, auf den Webserver kommend, über CloudFlare zu leiten. Bereits im CloudFlare PRO Plan gibt es eine grundlegende Web Application Firewall-Funktionalität (WAF), welche zentral für unser Konzept gewesen war. Eine eigene WAF in dieser kurzen Zeit aufzubauen, zu konfigurieren und zu testen, wäre nicht möglich gewesen. Dennoch wird dieser Schritt früher oder später noch gemacht werden.

Weitere Massnahmen

Im Anschluss an als Folge des Incidents, wurde ein Massnahmenkatalog auf Grund unserer Erkenntnissen erstellt. Dieser gibt der IT-Abteilung unseres Kunden die Möglichkeit, verschiedene Optionen zu analysieren, die Vor- und Nachteile abzuwägen und ein Zukunftsplan zusammenzustellen. Ein Punkt, der immer in einem solchen Massnahmenkatalog zu finden sein wird, ist eine IST-Analyse. Auch nach den vielen Stunden haben wir erst die Oberfläche der ganzen Infrastruktur und punktuell Details gesehen. Es ist daher anzunehmen, dass noch weitere – grosse und kleine – Probleme vorhanden sein werden.

Der Payload

Wie bereits zu Beginn angedeutet lud der Angreifer diverse Dateien und komprimierte Pakete von verschiedenen Servern nach. Gefunden wurde neben einem Plesk Exploit und weiteren Scripts, auch noch ein komplettes Exploit-Kit, basierend auf dem Enlightenment Kit ist sehr umfassend. Es berücksichtigt verschiedene Architekturen und prüft sogar spezifische Betriebssysteme.

In der vorgefundenen Version enthielt das Paket 10 Exploits:

Eines der übrigen Scripts wurde unweigerlich als Ausgangspunkt verwendet. Es deaktiviert die History, lud weiteren Code nach und kompilierte ein Programm. Bei einer Sourcecode-Analyse erkannten wir, dass sich dabei das Script in der Crontab verewigt. Durch das regelmässige Ausführen des Cronjobs ist sichergestellt, dass bei Beendigung des Prozesses dieser neu gestartet wird. Ausserdem konnten wir erkennen, dass es sich bei diesem spezifischen Programm um ein Tool handelt, um restriktive ausgehende Proxy-Server zu umgehen. In diesem Fall war dies wohl eher irrelevant, da ja zu beginn keine Einschränkungen für ausgehenden Netzwerkverkehr vorhanden waren.

Ein anderes Programm startete einen Prozess und nannte ihn klogd. Mit der Wahl dieses Namens wurde offensichtlich versucht, eine Legitimität vorzutäuschen. Im Wesentlichen wurde ein Netzwerklistener kreiert, welcher auf den lokalen Sendmail Service verwiesen hat. Bei einem Testversuch konnte denn auch auf diesen Dienst zugegriffen werden.

Fazit

Die absolute Sicherheit gibt es nicht. Durch verschiedene Massnahmen können Sie jedoch Ihr Risiko – Opfer eines solchen Angriffs zu werden – deutlich verringern. Verschiedene Ansätze wurden oben bereits beschrieben. Ein zentraler Fehler, der zu diesem Incident führte, waren die offene Kommunikationsmöglichkeiten von intern nach extern. Nur dank diesem Umstand konnten die Programme und Exploits nachgeladen werden.

Ebenfalls wichtig ist eine vorgängige Auseinandersetzung mit einem möglichen Incident. Definieren Sie einen Incident Response Plan und trainieren Sie das Vorgehen regelmässig durch. Klare Prozesse, die alle involvierten Personen verinnerlicht haben, ermöglichen Ihnen, eine schnelle und souveräne Reaktion.

About the Author

Oliver Kunz has been in information security since 2010. Mainly, he deals with incident response, forensics and the security of mobile devices.

Links

• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1897
• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2267
• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2698
• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2908
• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0415
• http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2049
• http://www.exploit-db.com/exploits/9627/
• https://vuldb.com/?id.4053
• https://www.cloudflare.com/
• https://www.cloudflare.com/plans