Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
Veröffentlicht von:Theresia Kestenbaum Geändert vor über 10 Jahren
1
Labor zur Untersuchung von Computer-Vorfällen
Incident Response Labor zur Untersuchung von Computer-Vorfällen 2002 wurde im Dezember das Incident Response Team am Fachbereich Informatik, Universität Hamburg gegründet.
2
Leitung: Prof. Dr. rer. nat. Klaus Brunnstein
Projektteilnehmer Leitung: Prof. Dr. rer. nat. Klaus Brunnstein 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
3
Einordnung eines IRT Risk Exploit Incident Detection Analysis
Incident Response Labor Analysis Response (incl. Avoidance)
4
Beispiel für Aufbau eines kommerziellen IR Teams
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 Triage Incident Announcement Feedback Report/Request Constituency Im bzw. als Unternehmen: Quelle: Handbook for Computer Security Incident Response Teams (CSIRTs)
5
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
6
Unsere Umsetzung Windows-Gruppe: Linux-Gruppe:
Dynamisch: Ethereal, File Monitor, Registry Monitor, Process Monitor Linux-Gruppe: diff, Tripwire
7
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.
8
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)
9
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.
10
Typische Angriffe nach Statistiken des CERT CC
1988: n Passwörter 1994: n Internet-Sniffer n sendmail-Angriffe n Trojaner für Systemprogramme n groß angelegte Scans (z.B. Portnummern) 1995: n Angriffe auf WWW-Server (httpd) 1996: n Lücken in Java und in Webbrowsers n Analyse von SUID-Programmen danach: n TCP-Hijacking n Denial-Of-Service
11
Nimda Aktivität Quelle: MessageLabs, Download am
12
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 Bytes, verschiedene Namen
13
Anfragen pro Stunde am 18.09.01 für Port 80
Quelle: SANS Institute, 2001
14
Geographische Verteilung des Wurms nach Ländern am 18.09.01
Quelle: SecurityFocus
15
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%
16
Einige ausgenutzte Vulnerabilities
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
17
4 unterschiedliche Verbreitungsmechanismen:
1. Über Webserver Der 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 Der Wurm sammelt -Adressen aus Windows Adressbuch, Eingangs- und Ausgangspostfach der Benutzer lokalen HTML/HTM-Dateien und sendet sich an alle gefundenen Adressen als Anhang readme.exe.
18
4 unterschiedliche Verbreitungsmechanismen:
3. Über HTTP-Seiten Wenn 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.
19
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
20
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 Propagationsphase ein.
21
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
22
Folgende Dateinamen werden von dem Wurm gebraucht:
readme.exe readme.eml admin.dll mmc.exe load.exe riched20.dll
23
Eigenschaften der Variationen
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. Quelle: McAfee (Stand vom )
24
Allgemeine Testumgebung
Ergo Netzsniffer Phoebe* Kathy* Hub Testumgebung Server * mit diversen Monitoren (z.B. für Datei- und Registry-Operationen, Prozessbeobachtungen)
25
Nimda-Testumgebung Kathy, Phoebe: W2000, IIS 5.0, SP1
Hub Phoebe Kathy, Phoebe: W2000, IIS 5.0, SP1 Internet Explorer 5.0 Shares: Ein Verzeichnis auf C freigegeben Process Monitor, File Monitor, Registry Monitor Ergo Netzsniffer: Win 2000 SP3 Ethereal NAV Netzsniffer
26
Der erste Versuch… Verbreitungsarten von Nimda:
Ergo Netzsniffer Phoebe Kathy Hub Testumgebung 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 von Client zu Client Über von „Code Red II“ hinterlassene Backdoors: von Client zu Web-Server
27
Nimda Risk Schwächen von MIME, IIS, … Exploit Nimda-Wurm Incident
am Detection am Analysis im Labor Response Removal Tools, Patches, Neuinstallation?
28
Linux/Slapper.Worm
29
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
30
Entstehung PUD (Sept. 02) open-too-ssl.c IRC Bot Slapper.A SlapperII.A
( ) alias Slapper.D ( ) Slapper.B Slapper.C ( ) ( ) Slapper.C2 SlapperII.A2 ( ) ( )
31
Schwachstelle KEY_ARG Buffer Overflow in OpenSSL bei SSLv2 Handshake
Bekannt seit Ende Juli 2002 (CA ) 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
32
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
33
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
34
Quelle: F-Secure
35
Anzahl aktiver Hosts Quelle: F-Secure
( Bezug: Jahr 2002
36
Versuchsaufbau Sniffer Victim Attack
(Daphne: Ethereal) Victim Attack (Ergo: Apache mit mod_ssl; tripwire) (Kathy: Slapper.A) Software: Red Hat Linux 7.3, individuelle Paketauswahl HUB
37
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
38
Versuchsdurchführung (2)
2. directory map auf victim Vergleichen der Directory maps mit diff Integritätscheck der tripwire Datenbank
39
Probleme Unsere Systeme sind keine Standardinstallation
Zuerst Fehler der Kompilierung wegen fehlender Packete openssl-devel uuencode Nicht gesetzter Pfade
40
Symptome Folgende Dateien Offener Port 2002/UDP
/tmp/.bugtraq /tmp/.bugtraq.c /tmp/.uuencode Offener Port 2002/UDP Netzaktivität durch scannen nach anderen Systemen
41
Entfernung & Vorsorge Prozess bugtraq töten /tmp leeren
Filterung: Firewall Patches einspielen Keine überflüssigen Packete (Entwicklung) Wenn Kompiler nötig eigener Benutzer
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.