Analyse eines Angriffs (Teil 3)

Analyse eines Angriffs (Teil 1)
Analyse eines Angriffs (Teil 2)

Don Parker

In Teil 2 dieser Serie haben wir alle notwendigen Informationen für einen Angriff auf das Netzwerk des Opfers bereitgestellt. Vor diesem Hintergrund kommen wir nun zu einem tatsächlichen Angriff. Bei diesem Angriff werden einige der erforderlichen Programme weitergegeben, um einen Angriff genauer ausnutzen zu können.

Es wäre sinnlos, einen Computer einfach anzugreifen und sich dann zurückzuziehen. Deshalb führen wir einen starken Angriff durch. Üblicherweise besteht das Ziel eines böswilligen Angreifers nicht nur darin, seine Präsenz in einem Computernetzwerk zu verstärken, sondern diese auch aufrechtzuerhalten. Das bedeutet, er möchte seine Präsenz weiterhin verbergen und andere Aktionen ausführen. Interessantes

:

Wir nutzen nun das Metasploit Framework, um den eigentlichen Angriff zu erleichtern. Das ist besonders interessant, da es viele verschiedene Exploit-Typen und viele verschiedene Optionen für die Auswahl der Nutzlast bietet. Vielleicht möchten Sie kein Reverse Utility oder VNC-Inject. Die Nutzlast hängt in der Regel vom Ziel, der Netzwerkarchitektur und dem Endziel ab. In diesem Fall verwenden wir ein Reverse Utility. Dies ist oft der beste Ansatz, insbesondere wenn sich das Ziel hinter einem Router befindet und nicht direkt erreichbar ist. Beispiel: Sie greifen einen Webserver an, der jedoch lastverteilt ist. Es gibt keine Garantie dafür, dass Sie sich mit einem Forward Utility darauf verbinden können. Daher sollten Sie Ihren Computer ein Reverse Utility generieren lassen. Wir werden nicht näher auf die Verwendung des Metasploit Frameworks eingehen, da dies möglicherweise in einem anderen Artikel behandelt wird. Konzentrieren wir uns also auf Dinge wie die Paketebene.

Dieses Mal zeigen wir nicht jeden Schritt des Angriffs anhand von Screenshots und Snippets, sondern einen anderen Angriff. Wir stellen den Angriff mithilfe von Snort nach. Wir nehmen das Binärprotokoll des Angriffs und analysieren es mit Snort. Im Idealfall sieht Snort alles genauso wie wir. Tatsächlich führen wir ein Demonstrationspaket aus. Ziel ist es zu sehen, wie wir den genauen Ablauf rekonstruieren können. Dazu nehmen wir das Binärprotokoll des Pakets, das alles erfasst hat, und analysieren es mit Snort unter Verwendung einiger seiner Standardregeln.

Snort-Ausgabe

Die Syntax zum Aufruf von Snort lautet wie folgt:

C:\snort\bin\snort.exe –r c:\article_binary –dv –c snort.conf –A full

Diese Syntax veranlasst Snort, ein Binärpaket namens article_binary zu analysieren. Die Ausgabe ist unten dargestellt. Wir haben die Snort-Ausgabe gekürzt, um jeden Teil im Detail untersuchen zu können.

==============================================================
Snort processed 1345 packets.
==============================================================
Breakdown by protocol:
TCP: 524 (38.959%)
UDP: 810 (60.223%)
ICMP: 11 (0.818%)
ARP: 0 (0.000%)
EAPOL: 0 (0.000%)
IPv6: 0 (0.000%)
ETHLOOP: 0 (0.000%)
IPX: 0 (0.000%)
FRAG: 0 (0.000%)
OTHER: 0 (0.000%)
DISCARD: 0 (0.000%)
==============================================================
Action Stats:
ALERTS: 63
LOGGED: 63
PASSED: 0

Dieser Teil ist interessant, da 63 Alarme durch einen Angriff ausgelöst wurden. Wir werden uns die Datei alert.ids ansehen, die uns viele Details zum Vorfall liefern kann. Wie Sie sich erinnern, scannte der Angreifer zunächst das Netzwerk mit Nmap. Dadurch wurde auch der erste Alarm ausgelöst, der von Snort ausgelöst wurde.

[**] [1:469:3] ICMP PING NMAP [**]
[Classification: Attempted Information Leak] [Priority: 2]
08/09-15:37:07.296875 192.168.111.17 -> 192.168.111.23
ICMP TTL:54 TOS:0x0 ID:3562 IpLen:20 DgmLen:28
Type:8 Code:0 ID:30208 Seq:54825 ECHO
[Xref => http://www.whitehats.com/info/IDS162]

Auf diese Weise nutzte der Angreifer Netcat, um den Webserver aufzulisten und herauszufinden, um welchen Typ es sich handelte. Diese Aktion löste keine Snort-Warnungen aus. Wir wollen auch herausfinden, was passiert ist, also werfen wir einen genaueren Blick auf das Paketprotokoll. Nach dem üblichen TCP/IP-Handshake sehen wir das folgende Paket.

15:04:51.546875 IP (tos 0x0, ttl 128, id 9588, offset 0, flags [DF], proto: TCP (6), length: 51) 192.168.111.17.1347 > 192.168.111.23.80: P, cksum 0x5b06 (correct), 3389462932:3389462943(11) ack 2975555611 win 64240
0x0000: 4500 0033 2574 4000 8006 75d7 c0a8 6f11 E..3%[email protected].
0x0010: c0a8 6f17 0543 0050 ca07 1994 b15b 601b ..o..C.P.....[`.
0x0020: 5018 faf0 5b06 0000 4745 5420 736c 736c P...[...GET.slsl
0x0030: 736c 0a sl.

Dieses Paket ist nicht bemerkenswert, außer dass es eine GET-Anfrage gefolgt von etwas wie slslsl enthält. Snort kann also praktisch nichts tun. Es wäre sehr schwierig, eine effektive IDS-Signatur zu erstellen, um einen solchen Enumerationsversuch auszulösen. Deshalb gibt es keine solchen Signaturen. Im nächsten Paket enumeriert sich der Webserver des Opfernetzwerks selbst.

Nach Abschluss der Enumeration sendet der Angreifer sofort einen Code zur Ausführung des Exploits an den Webserver. Dieser Code gibt dann eine Ausgabe mit aktivierten Snort-Signaturen zurück. Diese Snort-Signatur ist speziell für den unten gezeigten Exploit sichtbar.

[**] [1:1248:13] WEB-FRONTPAGE rad fp30reg.dll access [**]
[Classification: access to a potentially vulnerable web application] [Priority:
2]08/09-15:39:23.000000 192.168.111.17:1454 -> 192.168.111.23:80
TCP TTL:128 TOS:0x0 ID:15851 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0x7779253A Ack: 0xAA1FBC5B Win: 0xFAF0 TcpLen: 20
[Xref => http://www.microsoft.com/technet/security/bulletin/MS01-035.mspx][Xref
=> http://cve.mitre.org/cgi-bin/cvename.cgi?name=2001-0341][Xref => http://www.s
ecurityfocus.com/bid/2906][Xref => http://www.whitehats.com/info/IDS555]

Sobald der Angreifer Zugriff auf den Webserver erlangt hat, überträgt er mit dem TFTP-Client vier Dateien: nc.exe, ipeye.exe, fu.exe und msdirectx.exe. Nach der Übertragung sendet er mit netcat ein Reverse-Utility an seinen Computer. Von dort aus kann er die Verbindung trennen und ein anderes Utility, das aus dem ursprünglichen Angriff resultierte, aufrufen und alle restlichen Aufgaben im netcat-Utility ausführen. Interessanterweise wurde keine der vom Angreifer mit dem Reverse-Utility ausgeführten Aktionen von Snort protokolliert. Unabhängig davon nutzte der Angreifer jedoch das per TFTP übertragene Rootkit, um die Prozessinformationen für netcat zu verbergen.

Fazit:

Im dritten Teil dieser Serie haben wir den Angriff mit Snort demonstriert. Wir können einen der Angriffe bis auf den Einsatz des Rootkits vollständig reproduzieren. Ein IDS ist zwar eine nützliche Technologie und Teil Ihrer Netzwerkabwehr, aber nicht immer perfekt. IDSs können Sie nur auf Datenverkehr aufmerksam machen, den sie erfassen können. Vor diesem Hintergrund beschäftigen wir uns im letzten Teil dieser Serie mit der Erstellung von Snort-Signaturen. Dabei prüfen wir auch, wie eine Signatur auf ihre Wirksamkeit getestet wird.