Incident Response

Labor zur Untersuchungvon

Computer-Vorfällen

Projektteilnehmer

Windows Jan Menne Julia Fix Benjamin Hoherz Silvio Krüger Christoph Rößner Kerstin Schwarze Irina Tsalman Jörg Ziemann

Linux Nils Michaelsen Jan Kuhn Torsten Sorger

Leitung: Prof. Dr. rer. nat. Klaus Brunnstein

Risk

Exploit

Incident

Detection

Analysis

Response (incl. Avoidance) Incident

Response Labor

Einordnung eines IRT

Beispiel für Aufbau eines kommerziellen IR Teams

Quelle: Handbook for Computer Security Incident Response Teams (CSIRTs)

Reporting

Point

- Eingehende Kunden-Meldungen entgegennehmen- Auf Incident-Meldungen reagieren die Kunden

betreffen könnten

Analysis Verifizieren der Meldungen, Vorgang technisch verstehen: - Log-Files Analysieren, betroffene Stellen identifizieren- Zuständig für technische Dokumentation und Rat, technische Unterstützung, Schadensbehebung

Notification Informationen an Kunden und (netterweise) an andere potentielle Opfer bzw. CSIR Teams weitergeben

Zwei Ansätze zum Incident Response

1. Dynamische Analyse: Vorgänge im System werden fortlaufend analysiert– File-Monitor, Registry-Monitor, Sniffer

2. Komparativ statische Analyse: zwei Systemzustände werden verglichen– Live/Post Mortem Analyse

Unsere Umsetzung

• Windows-Gruppe:– Dynamisch: Ethereal, File Monitor, Registry

Monitor, Process Monitor

• Linux-Gruppe:– diff, Tripwire

Definition „Incident“

Die Bezeichnung „Incident“ (engl., Vorfall) bezieht sich auf ein schädigendes Ereignis in einem Informationssystem bzw. Netzwerk. (Quelle: NASA INCIDENT RESPONSE CENTER)

Ein „Ereignis“ ist jede merkliche Zustands-änderung innerhalb eines Systems bzw. Netzwerkes.

Incident-Arten 1. Malware (Viren, Trojaner, Würmer)

2. Nicht erlaubter Zugriff (z.B. unerlaubtes Einloggen in einen fremden Account)

3. Unerlaubte Nutzung von Diensten (z.B.: Verwendung des Netzwerk-Dateisystems (NFS), um auf das Dateisystem einer remote Server-Maschine zuzugreifen)

4. Versagen eines Dienstes (Benutzer verlassen sich auf Dienstleistungen, die durch ein Netzwerk bereitgestellt werden)

5. Missbrauch (z.B.: wenn jemand ein Computersystem für andere Zwecke benutzt, als offiziell beabsichtigt, z.B.: Spamming)

6. Spionage (Stehlen von Informationen, die im Interessen einer Korporation oder einer Regierung strengstens geheim bleiben sollten)

7. Hoaxes (unzutreffende Information über Vorfälle oder nicht existierende Bedrohungen wird verbreitet)

Probleme mit Standarddiensten und Standard-Einstellungen

• Bei der Installation von Betriebssystemen werden oft Standarddienste aktiviert.

• Oft werden installierte Dienste „vergessen“.• Viele der sogenannten „netzwerkfähigen“ Software-Produkte

sind nicht für große Netze mit potentiellen Hackern ausgelegt.

• Viele Systeme besitzen Standardzugänge mit Standard-Passwörtern. (Wartungs-Accounts, Gast-Accounts, Demo-User)

• Bei vielen Serverprogrammen ist nach der Installation keine Sicherheitseinstellung aktiv: Alles ist erlaubt.

Typische Angriffe nach Statistiken des CERT CC

1988: Passwörter

1994: Internet-Sniffersendmail-AngriffeTrojaner für Systemprogrammegroß angelegte Scans (z.B. Portnummern)

1995: Angriffe auf WWW-Server (httpd)

1996: Lücken in Java und in WebbrowsersAnalyse von SUID-Programmen

danach: TCP-HijackingDenial-Of-Service

Nimda Aktivität

Quelle: MessageLabs, Download am 22.12.02

W32/Nimda.A@MM• Schnelle Verbreitung durch mehrere Spreading-

Mechanismen

• Befällt Webserver Microsoft IIS

• Infektion von Windows 9x und NT/2000/XP u.U. allein durch Browsen mit IE 5.01, IE 5.5 ohne SP2, IE 6.0

• Datei im Anhang:– konstante Länge von 57344 Bytes,– verschiedene Namen

Anfragen pro Stunde am 18.09.01 für Port 80

0

50000

100000

150000

200000

250000

300000

11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00

Quelle: SANS Institute, 2001

Geographische Verteilung des Wurms nach Ländern am 18.09.01

Quelle: SecurityFocus

Auffinden der Angriffsziele

• Generiert IP-Adressen und prüft, ob auf den angetroffenen IIS-Server für die Expansion notwendige Sicherheitslücken vorhanden sind

• Greift bevorzugt die Netzwerknachbarn an erste Oktetts gleich - 25%

beide ersten Oktetts gleich - 50%

zufällig - 25%

• Microsoft IIS/PWS Escaped Characters Decoding Command Execution Vulnerability (MS01-026)

• Microsoft IE MIME Header Attachment Execution

Vulnerability (MS01-020)

• Microsoft IIS and PWS Extended Unicode Directory Traversal Vulnerability (MS00-078)

• Microsoft Office 2000 DLL Execution Vulnerability (MS02-052)

Außerdem: CodeRed II-Hintertür

Einige ausgenutzte Vulnerabilities

4 unterschiedliche Verbreitungsmechanismen:

1. Über WebserverDer Wurm sucht das Internet nach den Webservern ab und versucht eine Reihe von bekannten Windows-Verwundbar-keitsstellen auszunutzen, um die Kontrolle über den Server zu erhalten.

2. Über E-Mail Der Wurm sammelt E-Mail-Adressen aus

• Windows Adressbuch, • Eingangs- und Ausgangspostfach der Benutzer• lokalen HTML/HTM-Dateien

und sendet sich an alle gefundenen Adressen als Anhang readme.exe.

3. Über HTTP-SeitenWenn der Wurm einen Server erfolgreich infiziert hat, versucht er mittels HTTP-Service die Klienten, die auf den Serverseiten navigieren, anzustecken.

4. Über freigegebene Laufwerke Der Wurm legt eine Kopie von sich selbst auf alle Laufwerke, auch im Netzwerk, für die der Benutzer eine Schreibberechtigung hat. Er sucht alle Direktorien nach exe-Files und hängt sich an diese an. Jeder andere Host im Netzwerk, der auf den infizierten File zugreift, wird damit angesteckt.

4 unterschiedliche Verbreitungsmechanismen:

Payload 1/2

• erzeugt oder aktiviert einen „Guest“-Account und gibt ihn die Rechte des Administrators

• stellt den vollen Zugriff auf den C: Laufwerk für jeden Benutzer bereit, falls der IIS Server auf C: installiert ist

• Scannt freigegebene Ordner und Laufwerke nach EXE-Dateien und ersetzt diese unter der Beibehaltung der Dateinamen durch sich selbst

• scannt lokale Festplatte nach HTM, HTML, und ASP-Dateien und fügt diesen ein Stück JavaScript hinzu, um Spreading über Webbrowser zu ermöglichen

Payload 2/2

• erzeugt in dem selben Verzeichnis eine readme.eml-File, die eine MIME-enkodierte Version der Nimda enthält

• Sicherheitseinstellungen der Freigaben werden gelöscht

• modifiziert die Datei system.ini, so dass der Wurm automatisch mit jedem Systemneustart ausgeführt wird.

• erzeugt multiple Instanzen von den *.eml-Dateien und riched20.dll auf den offenen Netzlaufwerken, sogar wenn keine HTML-Dateien im System gefunden werden.

• Nimda tritt alle10 Tage in seine EmailPropagationsphase ein.

Wichtigste Symptome im System

• Anwesenheit von Dateien

C:\ADMIN.DLL, D:\ADMIN.DLL, und E:\ADMIN.DLL

• Anwesenheit von vielen .EML Dateien mit den gleichen Namen

(typischerweise README.EML oder DESKTOP.EML)

• freigegebene Netzwerk Shares

Folgende Dateinamen werden von dem Wurm gebraucht:

• readme.exe• readme.eml• admin.dll• mmc.exe• load.exe• riched20.dll

Eigenschaften der VariationenW32/Nimda.b@MM

W32/Nimda.d@MM

W32/Nimda.e@MM

W32/Nimda.f@MM

W32/Nimda.g@MM

Quelle: McAfee (Stand vom 30.4.02)

This variant is packed with a PE packer and the filenames README.EXE and README.EML are replaced with PUTA!!.SCR and PUTA!!.EML respectively.

This variant uses different filenames. README.EXE is now SAMPLE.EXE MMC.EXE is now CSRSS.EXE ADMIN.DLL is now HTTPODBC.DLL

Functionally the same as the D variant; minor differences only.

Functionally the same as the D variant; minor differences only.

Functionally the same as the D variant; minor differences only.

Allgemeine Testumgebung

Ergo

Netzsniffer

Phoebe*Kathy* Hub

Testumgebung

Server

* mit diversen Monitoren (z.B. für Datei- und Registry-Operationen, Prozessbeobachtungen)

Nimda-Testumgebung

ErgoNetzsniffer

PhoebeKathy Hub

Testumgebung

Netzsniffer:• Win 2000 SP3• Ethereal• NAV

Kathy, Phoebe:• W2000, IIS 5.0, SP1• Internet Explorer 5.0• Shares: Ein Verzeichnis auf C freigegeben• Process Monitor, File Monitor, Registry Monitor

Der erste Versuch…

Verbreitungsarten von Nimda:• Via offenen Network-Shares:

von Client zu Client• Über Scannen nach und Ausnutzen

von IIS4.0/5.0 Directory traversal vulnerability: von Client zu Web-Server

• Über Nimda-infizierte Webseiten: von Web-Server zu Client

• Via email: von Client zu Client• Über von „Code Red II“ hinterlassene

Backdoors: von Client zu Web-Server

ErgoNetzsniffer

PhoebeKathy Hub

Testumgebung

Nimda

Risk

Exploit

Incident

Detection

Analysis

Response

Schwächen von MIME, IIS, …

Nimda-Wurm

am 18.09.2001

im Labor

Removal Tools, Patches, Neuinstallation?

am 18.09.2001

Linux/Slapper.Worm

Details

• Internet Wurm• Erstes Auftreten: 13.09.2002 (nai)• Infiziert Linux mit Apache und mod_ssl• Produkt aus PUD und openssl-too-open

Exploit• Payload: baut p2p-Netzwerk für DDoS

auf

Entstehung

PUD (Sept. 02) open-too-ssl.c IRC Bot

Slapper.A SlapperII.A(13.09.2002) alias Slapper.D

(27.09.02)

Slapper.B Slapper.C(24.09.2002) (24.09.2002)

Slapper.C2 SlapperII.A2(27.09.2002) (01.10.2002)

Schwachstelle

• KEY_ARG Buffer Overflow in OpenSSL bei SSLv2 Handshake

• Bekannt seit Ende Juli 2002 (CA-2002-23)

• Betroffen: open-ssl Libary < 0.96e / 0.97beta2

• Existiert auch in anderen UNIX-Derivaten (BSD Scalper , Solaris, MAC OS X)

• Exploit (bisher) nur unter Linux

Infektion (Slapper A)

• Bannerscanning nach Apache mod_ssl• Entscheidung nach Linux Distribution• Buffer Overflow auf Port 443 (SSL)• Überträgt /tmp/.bugtraq.c

Kodierung als /tmp/.uuencode auf Opferhost• Kompilation zu /tmp/.bugtraq • Ausführung als user apache

PUD-Server Backdoor auf Port 2002/UDP

PUD

• p2p-Netz Rahmenwerk für DDoS• Exploit muss an markierter Stelle

eingefügt werden• Ein Rechner kennt alle anderen aktiven

Rechner des Netzes• Befehle werden an andere weitergeleitet• Steuerung über pud client

Quelle: F-Securehttp://www.f-secure.com/v-descs/slapper.shtml

Anzahl aktiver Hosts

Quelle: F-Secure(http://www.f-secure.com/slapper/)

Bezug: Jahr 2002

Versuchsaufbau

Sniffer (Daphne: Ethereal)

Victim Attack(Ergo: Apache 1.3.23 mit mod_ssl; tripwire) (Kathy: Slapper.A)

Software: Red Hat Linux 7.3, individuelle Paketauswahl

HUB

Versuchsdurchführung (1)

• Statisch komparative Untersuchung• Wegen p2p-Netz:

Netzaktivität beobachten• 1. directory map auf victim• Tripwire-DB erstellen auf victim• Ausführung auf Attack

Versuchsdurchführung (2)

• 2. directory map auf victim• Vergleichen der Directory maps mit diff• Integritätscheck der tripwire Datenbank

Probleme

• Unsere Systeme sind keine Standardinstallation

• Zuerst Fehler der Kompilierung wegen – fehlender Packete

• openssl-devel• uuencode

– Nicht gesetzter Pfade

Symptome

• Folgende Dateien– /tmp/.bugtraq

– /tmp/.bugtraq.c

– /tmp/.uuencode

• Offener Port 2002/UDP• Netzaktivität durch scannen nach

anderen Systemen

Entfernung & Vorsorge

• Prozess bugtraq töten

• /tmp leeren

• Filterung: Firewall

• Patches einspielen

• Keine überflüssigen Packete (Entwicklung)

• Wenn Kompiler nötig eigener Benutzer