In diesen Beitrag behandle ich die Theorie eines Spoofed Scan. Dieser ist ein raffinierte Version eines Portscan, welche für den Angreifer den entscheidenden Vorteil hat, dass er „anonym“ ist bzw. das Opfer nie erfährt von, wo der initiale Portscan durchgeführt wurde.
Für so einen Angriff braucht man ein Opfer, einen Stellvertreter und klar den Angreifer. Wichtig ist das, während des Vorgangs der Stellvertreter keine anderen Pakete sendet oder empfängt. Dieses sollte in großen Netzwerken leicht zu finden sein.
Schritt 1:
Im ersten Schritt geht es darum, dass der Angreifer ein gefälschtes IP Syn an den Stellvertreter sendet, um eine IP-ID zu bekommen (daher steht da auch frei wählbar, da es in den laufenden Schritten immer Hochgezählt wird). Diese IP-ID dient normalerweise dazu, die IP Pakete in der richtigen Reihenfolgen zusammen zu setzten. Daher wird dieses Feld im Normalfall immer eins hochgezählt.
Schritt 2:
Im zweiten (eigentlich schon der dritte) Schritt schickt der Angreifer ein gefälschtes Paket an den Webserver mit den Informationen von dem Stellvertreter. In diesem Paket fragt er, ob es einen Webserver auf den Port 80 gibt. Dieser Webserver kann in diesem Fall nicht unterscheiden, ob es hier um ein gefälschtes Paket gibt und antwortet dem Stellvertreter, als käme die Anfrage direkt von ihm und schickt fröhlich darauf los. Der Stellvertreter kennt die Kommunikation nicht, da sein Pakt gefälscht wurde und schickt als Antwort einen Reset in den Schritt 5 und erhöht dadurch die IP ID um 1.
Um nun fortzufahren wird der Angreifer die Schritte 1 und 2 wiederholen. Hier sendet der Angreifer wieder eine Verbindungsanfrage an den Stellvertreter, welche mit der IP-ID um 2 erhöht. Dadurch können wir jetzt den Rückschluss ziehen, dass ein Dienst auf den Port laufen muss. Wenn man die Schritte jetzt noch mal vergleichen wird, so wird man feststellen, dass die eigentliche IP-Adresse des Angreifers niemals bei den Server angekommen ist. Hier würde man nur die IP-Adresse des Stellvertreters sehen können.
Für den Fall, dass es an der Stelle nicht ganz eindeutig war, wie man diese Schlussfolgerung nun ziehen konnten, werde ich nun es auch an einem Beispiel darstellen wo man sieht, wie das Ergebnis ausfällt, wenn kein Dienst aktiv auf den Port ist. Im Negativbeispiel ist es so, dass der Angreifer einen Port anfragt wieder mit den gefälschten Daten (siehe Schritt 1-3) und der Server wird automatisch mit einem Reset den Stellvertreter Antworten. Für den Stellvertreter ergibt es hier keinen Sinn auf eine Reset Antwort mit einem Reset zu antworten (Erinnert mich irgendwie an „Nein du legst zuerst auf“ „Nein du“ … etc. ). Hier wird also Schritt Nummer 5 automatisch übersprungen und es werden danach die Schritte 6 und 7 weiter gemacht von dem Angreifer. Da Schritt 5 übersprungen wurde, weil es in Schritt 4 ja schon zu dem Reset kam, wird in Schritt 7 die IP-ID nur um 1 erhört. Also kann man nur darauf schließen, dass hier kein Dienst auf einen anderen Port läuft (Wie, wenn es z.B. Kein RDP gibt).
Ein Schutz vor so einen Angriff bietet am besten eine Firewall. Hier würden die Schritte 1-3 wie gewohnt ablaufen, aber bei Schritt 3 würde die Firewall die IP Pakte nicht durchlassen. Logischerweise würden die IP-ID Felder dann immer nur um 1 erhöht werden, was kein korrektes Ergebnis mehr darstellt.
Hier könnte der Angreifer nur noch seine Anonymität aufgeben und es direkt versuchen.
Add a Comment