Automatisierte Cyberangriffe: Kein System bleibt unberührt

Automatisierte Angriffe

Unabhängig von der Unternehmensgröße oder der Branche müssen alle Unternehmen damit rechnen das Ziel von Cyberangriffen zu werden. Diese Cyberattacken sind nicht nur zielgerichtet, sondern passieren zufällig sowie automatisiert. Bei der Inbetriebnahme eines neuen Servers zur Bereitstellung einer Schwachstellendatenbank, ist uns aufgefallen, dass bereits in den ersten 20 Stunden des Online-Betriebs des Servers fast 800 Anfragen auf dem Webserver geloggt werden konnten. In diesem Fachartikel werden wir genauer betrachten, welchen Ursprung diese Anfragen haben und aufzeigen, dass Angreifer längst nicht mehr nur bekannte Systeme und Unternehmen ins Visier nehmen. Natürlich geben wir auch konkrete Empfehlungen, um Systeme gegen diese Angriffe abzusichern.

Legitime Anfragen an die Schwachstellendatenbank (37%)

In einem ersten Schritt wollen wir alle Anfragen aus der Logdatei filtern, die reguläre Anfragen an die Schwachstellendatenbank darstellen und von uns zu Testzwecken ausgeführt wurden. Hierzu filtern wir alle bekannten Quell-IP-Adressen sowie gewöhnliche Anfragen auf bestehende Endpunkte. Die Schwachstellendatenbank stellt dabei die folgenden API Endpunkte für die Abfrage von Schwachstellendaten zur Verfügung:

  • /api/status
  • /api/import
  • /api/query_cve
  • /api/query_cpe
  • /api/index_management

Nach unserer ersten Analyse konnten wir feststellen, dass von insgesamt 724 Anfragen 269 Anfragen legitime Anfragen an die Schwachstellendatenbank darstellen:

Cyberangriffe Abbildung 1: Auszug legitimer Anfragen an den Webserver

 

Doch welchen Ursprung haben die verbleibenden 455 Anfragen?

Verzeichnisenummerierung von administrativen Backends für Datenbanken (14%)

Eine einzelne IP-Adresse fiel besonders auf: Mit 101 Anfragen versuchte ein Angreifer diverse Backends für die Datenbankadministrierung zu finden:logs 2 cut

Abbildung 2: Scannen von Verzeichnissen um Datenbank-Backends zu finden

Schwachstellenscans unbekannter Quellen (14%)

Weiterhin konnten wir 102 Anfragen identifizieren, bei denen unsere Versuche die Quell-IP-Adressen zu identifzieren (mittels nslookup, user-agent) erfolglos waren. Die 102 Anfragen stammen von 5 verschiedenen IP-Adressen oder Subnetzbereichen. Somit wurden pro Schwachstellenscan ca. 20 Anfragen ausgeführt.

logs 3 cut

Abbildung 3: Verschiedene Schwachstellenscans mit unbekannter Herkunft

Geprüfte Komponenten waren dabei:

  • boaform Admin Interface (8 Anfragen)
  • /api/jsonws/invoke: Liferay CMS Remote Code Execution und andere Exploits

 

Anfragen auf / (11,5%)

Insgesamt konnten wir 83 Anfragen feststellen, die die Index-Datei des Webservers angefragt haben. Diese dienen zur Ermittlung, ob ein Webserver online ist und zur Identifikation, welcher Dienst initial zurückgegeben wird.

logs 4

Abbildung 4: Index-Anfragen verschiedener Quellen

Hierbei konnten wir verschiedene Anbieter und Tools identifizieren, die unseren Webserver auf Erreichbarkeit geprüft haben:

Schwachstellenscans von leakix.net (9%)

Während unserer Auswertung der Logdatei konnten wir weitere 65 Anfragen identifzieren, die von zwei IP Adressen stammen, die in Ihrem User-Agent die Adresse “leakix.net” nennen:

logs 5

Abbildung 5: Schwachstellenscan von leakix.net

Auf der Seite selbst wird erklärt, dass der Dienst das gesamte Internet zufällig auf bekannte Schwachstellen durchsucht:

logs 6

Abbildung 6: leakix.net – About

HAFNIUM Exchange Exploits (2,8%)

Des Weiteren konnten wir 20 Anfragen identifizieren, die versuchen verschiedene Teile der HAFNIUM Exchange Schwachstellen auszunutzen oder aufzuspüren. (Gängige IOCs lassen sich z.B. finden unter https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-ProxyLogon-Is-Just-The-Tip-Of-The-Iceberg-A-New-Attack-Surface-On-Microsoft-Exchange-Server.pdf):

  • autodiscover.xml: Versuch, das Administratorkonto des Exchange Servers zu ermitteln
  • \owa\auth\: Ordner in den Shells nach einer Kompromittierung für weiteren Fernzugriff geladen werden

logs 7

Abbildung 7: Versuchte Ausnutzung der HAFNIUM/Proxlogon Exchange Schwachstellen

NGINX .env Preisgabe von sensitiven Informationen der Serverumgebung (1,5%)

11 Anfragen haben versucht die .env Datei im Webserver Wurzelverzeichnis auszulesen. Diese Datei kann oft sensitive Umgebungsvariablen (und Passwörter) enthalten.

logs 8

Abbildung 8: Versuch die .env Datei des Servers auszulesen

 

Verbleibende Anfragen (10,2%)

Weitere 58 Anfragen waren nicht Teil eines größeren Scans und haben gezielt einzelne Schwachstellen abgefragt:

  • Server-Side Request Forgery Versuche: 12 Anfragen
  • CVE-2020-25078: D-Link IP Kamera Admin Passwort Exploit: 9 Anfragen
  • Hexkodierte Exploits/Payloads: 5 Anfragen
  • Spring Boot: Actuator Endpunkt zur Darstellung von Serverinformationen: 3 Anfragen
  • Netgear Router DGN1000/DGN2200: Remote Code Execution Exploit: 2 Anfragen
  • Open Proxy CONNECT: 1 Anfrage

  • Verschiedene einzelne Exploits oder Schwachstellentests: 27 Anfragen

Weiterhin wurden die folgenden harmlosen Dateien angefragt:

  • favicon.ico – Lesezeichen-Grafik: 7 Anfragen
  • robots.txt – Datei für Suchmaschinenindizierung: 9 Anfragen

Fazit

Mit Tools wie zmap scannen Angreifer das gesamte Internet in unter 5 Minuten (siehe https://www.usenix.org/system/files/conference/woot14/woot14-adrian.pdf). Die aufgeführten Statistiken haben gezeigt, dass IT-Systeme ein unmittelbares Ziel automatisierter Angriffe und Schwachstellenscans sind, sobald diese von außen aus dem Internet erreichbar sind. Die Größe eines Unternehmens oder der Bekanntheitsgrad spielen hierbei keine Rolle, da Angreifer das komplette Internet nach anfälligen Hosts durchforsten und oftmals den vollständigen IPv4-Adressraum abdecken. Selbst unter Einsatz herkömmlicher IT-Infrastrukturkomponenten wie z.B. Reverse Proxies oder Load Balancers, die lediglich unter Angabe eines validen Hostnamens eine Anwendung zurückgeben, können sich automatisierte Angriffe ereignen. Der Hostname ist nämlich, wie oftmals fälschlicherweise angenommen, kein Geheimnis bzw. ein ausreichender Schutz vor unautorisierten Zugriffen. Bereits bei der Anforderung von SSL-Zertifikaten für Ihre Dienste und Applikationen werden Hostnamen in sogenannten SSL-Transparency-Logs protokolliert und stehen öffentlich zur Einsicht verfügbar. Hierdurch können sich erneut automatisierte Angriffe ereignen, da die Hostnamen durch Online-Dienste wie crt.sh öffentlich in Erfahrung gebracht werden können. Weitere Informationen finden Sie in unserem Fachartikel Subdomains unter der Lupe: SSL Transparency Logs.

Die Implementierung von Zugriffskontrollen oder Härtungsmaßnahmen zum Schutz vor unautorisierten Handlungen in Ihren Diensten und Anwendungen muss demnach noch vor der eigentlichen Veröffentlichung im Internet erfolgen. Denn sobald ein IT-System im öffentlichen Internet erreichbar ist, müssen Sie mit aktiven Angriffsversuchen rechnen, die im schlimmsten Fall Erfolg haben könnten.

Empfehlung

Lediglich notwendige Netzwerkdienste bereitstellen

Bei der Veröffentlichung von IT-Systemen in das öffentlich erreichbare Internet sollten lediglich diejenigen Netzwerkdienste preisgegeben werden, die für den Geschäftszweck notwendig sind und nach außen hin offenbart werden müssen. Bei dem Betrieb einer Webanwendung oder Dienst auf Basis des HTTP-Protokolls ist dies in der Regel der eingesetzte Webserver, dessen Netzwerkdienst üblicherweise über den TCP-Port 443 angeboten wird.

Halten Sie davon Abstand, den kompletten Host, also alle verfügbaren Netzwerkdienste eines IT-Systems, im Internet preiszugeben.

Netzwerktrennung

Implementieren Sie eine demilitarisierte Zone (DMZ) mittels Firewalls, um eine zusätzliche Netztrennung zwischen dem öffentlichen Internet und Ihrer internen IT-Infrastruktur zu erhalten. Platzieren Sie alle Infrastrukturkomponenten, welche Sie nach außen ins Internet preisgeben möchten, in der dafür entworfenen DMZ. Weitere Informationen finden Sie im IT-Grundschutz-Katalog des Bundesamts für Sicherheit in der Informationstechnik (BSI).

Patch-Management und Inventarisierung

Halten Sie alle Softwarekomponenten auf einem aktuellen Stand und richten Sie einen Patch-Management-Prozess ein. Führen Sie eine Inventarisierung über alle IT-Infrastrukturkomponenten ein, unter Auflistung der eingesetzten Softwareversionen, virtuellen Hostnamen, SSL-Zertifikatsablauf, Konfigurationseinstellungen und Co.

Weitere Informationen finden Sie unter: http://www.windowsecurity.com/uplarticle/Patch_Management/ASG_Patch_Mgmt-Ch2-Best_Practices.pdf

Härtungsmaßnahmen

Härten Sie Ihre offenbarten Netzwerkdienste und IT-Komponenten nach Angaben des Herstellers bzw. den spezifischen Härtungsempfehlungen des Center for Internet Security (CIS). Ändern Sie zudem alle Standardpasswörter oder einfache Logins aus der Entwicklungszeit ab und konfigurieren Sie Ihre Dienste für den produktiven Betrieb. Dazu gehört ebenfalls die Deaktivierung von Debug-Features oder Test-API-Endpunkte. Implementieren Sie weiterhin alle empfohlenen HTTP-Response-Header und härten Sie Ihre Webserver-Konfiguration. Stellen Sie sicher, dass sensitive Cookies über das Secure, HttpOnly und SameSite Cookie-Flag verfügen, falls möglich.

Transportverschlüsselung

Achten Sie darauf, Ihre Netzwerkdienste über einen verschlüsselten Kommunikationskanal anzubieten. Dies stellt die Vertraulichkeit und Integrität von Daten sicher und sorgt dafür, dass die Authentizität Ihres Servers validiert werden kann. Halten Sie Abstand von der Verwendung von veralteten Algorithmen wie RC4, DES, 3DES, MD2, MD4, MD5 oder SHA1. Verwenden Sie SSL-Zertifikate, welche von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt worden sind, wie z.B. von Let’s Encrypt. Halten Sie Ihre Zertifikate fortlaufend aktuell und erneuern Sie diese frühzeitig. Verwenden Sie für jeden Ihrer Dienste ein einzigartiges SSL-Zertifikat unter Nennung des korrekten (Sub)Domainnamen im Common Name des Zertifikats. Die Verwendung von SSL-Wildcard-Zertifikaten ist lediglich in seltenen Fällen notwendig und zu empfehlen.

Zugriffsschutz und zusätzliche Sicherheitslösungen

Beschränken Sie den Zugriff auf Ihre Netzwerkdienste, sollten diese nicht für alle Teilnehmer im öffentlichen Internet zur Verfügung stehen. Hierbei kann es sich anbieten, ein IP-Whitelisting einzurichten, wodurch lediglich Anfragen von vertrauenswürdigen, statischen IPv4-Adressen entgegengenommen werden. Konfigurieren Sie dieses Verhalten entweder in Ihrer eingesetzten Firewall-Lösung oder unmittelbar in dem bereitgestellten Netzwerkdienst, falls möglich. Alternativ können auch SSL-Client-Zertifikate oder Basic-Authentication eingerichtet werden.

Implementieren Sie für Ihre Netzwerkdienste zusätzliche Sicherheitslösungen wie Intrusion Prevention Systeme (IPS) oder eine Web Application Firewall (WAF), um einen zusätzlichen Schutz gegenüber Angriffen zu erhalten. Als IPS können wir die quelloffene Software Fail2ban empfehlen. Als WAF kann ModSecurity mit dem bekannten OWASP Core Rule Set eingerichtet werden.

Fail2ban ist ein in Python geschriebenes Intrusion Prevention System, welches auf Basis von Protokolleinträgen (Logs) und Regex-Filtern auffällige Aktivitäten identifizieren und automatische Maßnahmen ergreifen kann. So ist es z.B. möglich, automatisierte Schwachstellenscans, Brute-Force-Angriffe oder Bot-basierte Anfragen erfolgreich zu erkennen, blockieren und Angreifer mittels IP-Tables zu bannen. Fail2ban ist eine quelloffene Software und kann kostenfrei eingesetzt werden.

  • Installation von Fail2ban
    • Fail2ban kann in der Regel über die reguläre Paket-Verwaltung Ihrer Linux-Distribution installiert werden. Dazu genügt der folgende Befehl:
sudo apt update && sudo apt install fail2ban
    • Danach sollte der Fail2ban-Dienst automatisch gestartet worden sein. Überprüfen Sie dies mittels des folgenden Befehls:
sudo systemctl status fail2ban
  • Konfiguration von Fail2ban
    • Nach der Installation von Fail2ban steht ein neues Verzeichnis namens /etc/fail2ban/ zur Verfügung, worunter alle relevanten Konfigurationsdateien vorgefunden werden können. Standardmäßig werden zwei Konfigurationsdateien /etc/fail2ban/jail.conf und/etc/fail2ban/jail.d/defaults-debian.conf mitgeliefert. Diese sollten jedoch nicht bearbeitet werden, da sie bei einer Paketaktualisierung überschrieben werden können.
    • Stattdessen sollten spezifische Konfigurationsdateien mittels der .local Erweiterung angelegt werden. Konfigurationsdateien mit dieser Dateierweiterung überschreiben Direktiven in der übergeordneten .conf Konfigurationsdatei. Für die meisten Benutzer ist der einfachste Konfigurationsweg die mitgelieferte Datei jail.conf nach jail.local zu kopieren und anschließend die .local-Datei abzuändern. Die .local-Datei muss hierbei nicht alle Einstellungen aus der .conf-Datei enthalten, sondern nur diejenigen, die Sie überschreiben möchten.
  • Fail2ban für SSH
    • Nach der Installation von Fail2ban ist standardmäßig bereits der Schutz für den Netzwerkdienst SSH auf dem default TCP-Port 22 aktiv. Sollten Sie einen anderweitigen TCP-Port für Ihren SSH-Netzwerkdienst einsetzen, so müssen Sie die Konfigurationseinstellung port in Ihrer jail.local Datei für die SSH-Jail anpassen. Hier können Sie ebenfalls wichtige Direktiven wie findtime, bantime und maxretry anpassen, sollten Sie eine spezifischere Konfiguration benötigen. Sollten Sie diesen Schutz nicht benötigen, so können Sie ihn über die Direktive enabled auf den Wert false setzenWeitere Informationen finden Sie unter: https://wiki.ubuntuusers.de/fail2ban/
  • Fail2ban für Webdienste
    • Weiterhin kann mittels Fail2ban ein Schutz vor automatisierten Webangriffen eingerichtet werden. Hierbei können beispielsweise Angriffe zur Enumeration von Webverzeichnissen (Forceful Browsing) oder bekannte Anfragen von Bots zur Durchführung von Schwachstellenscans erkannt und blockiert werden.
    • Die Community stellt hierfür bereits vorgefertigte Konfigurationsdateien zur Verfügung, welche verwendet werden können:
    • Legen Sie diese beispielhaften Filter-Konfigurationen in dem Verzeichnis /etc/fail2ban/filter.d/ ab und konfigurieren Sie eine neue Jail in Ihrer jail.local Datei. Ein Beispiel folgt.
  • Blockieren von Suchanfragen durch Bots
    • Automatisierte Bots und Schwachstellenscanner durchforsten fortlaufend das gesamte Internet, um anfällige IT-Hosts zu identifizieren und Exploits auszunutzen. Hierbei kommen oftmals bekannte Tools zum Aufdecken solcher Schwachstellen zum Einsatz, dessen Namen bei HTTP-Anfragen im User-Agent HTTP-Header mitgeschickt werden. Anhand diesem Header können viele einfache Bot-Angriffe erkannt und aktiv blockiert werden. Angreifer können diesen Header jedoch auch abändern, wodurch ausgeklügelte Angriffe unentdeckt bleiben. Die Fail2ban-Filter *badbots.conf sind in der Regel solche Filter, die auf dem HTTP-Header “User-Agent” basieren. 
    • Alternativ bietet es sich an, alle Anfragen zu verwerfen, welche ein typisches Angriffs-Muster an den Tag legen. Dazu gehören unter anderem automatisierte Anfragen, welche fortlaufend versuchen, Dateien oder Verzeichnisse auf einem Webserver zu identifizieren. Da diese automatisierten Angriffe eine Vielzahl von Dateien und Verzeichnisnamen zufällig anfragen, ist die Wahrscheinlichkeit gegeben, dass viele dieser Versuche ins Leere führen und eine 404 Not Found Fehlermeldung verursachen. Anhand dieser Fehlermeldungen und dazugehörigen Logs kann Fail2ban einen Angriffsversuch erkennen und das Angreifer-System frühzeitig bannen.
    • Hier am Beispiel eines nginx Webservers:

1. Speichern Sie die folgende Datei unter /etc/fail2ban/filter.d/nginx-botsearch.conf

https://github.com/fail2ban/fail2ban/blob/master/config/filter.d/nginx-botsearch.conf

2. Fügen Sie die folgenden Konfigurationsanweisungen in Ihrer /etc/fail2ban/jail.local ein:

[nginx-botsearch]
ignoreip = 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
enabled = true
port = http,https
filter = nginx-botsearch
logpath = /var/log/nginx/access.log
bantime = 604800 # Bann für 1 Woche
maxretry = 10 # Bann bei 10 Fehlermeldungen
findtime = 60 # zurücksetzen von maxretry nach 1 Minute

3. Inkludieren Sie falls nötig weitere vertrauenswürdige IP-Adressen unter ignoreip Ihres Unternehmens, welche von Fail2ban erlaubt und nicht blockiert werden sollen. Passen Sie ggf. die anderweitigen Direktiven auf Ihre Wünsche hin an und verifizieren Sie den angegebenen Port Ihres Webservers sowie dass der Logpfad  /var/log/nginx/access.log vorhanden und ausgelesen werden kann.

4. Starten Sie anschließend den Fail2ban-Dienst neu

sudo systemctl restart fail2ban

Bei automatisierten Suchanfragen zum Auffinden von Verzeichnissen und Dateien können nun Bots gebannt werden, welche mehr als zehn 404-Fehlermeldungen innerhalb einer Minute erzeugen. Die IP-Adresse des angreifenden Systems wird anschließend von Fail2ban mittels IP-Tables automatisch für eine Woche gebannt und anschließend automatisch wieder freigegeben. Auf Wunsch können Sie sich durch weitere Konfigurationseinstellungen per E-Mail über IP-Banns informieren lassen. Eine Push-Benachrichtigung ans Smartphone über einen Telegram-Messenger-Bot in Fail2ban ist ebenfalls denkbar. Allgemein ist Fail2ban sehr anpassbar und erlaubt beliebig viele banactions, wie z.B. selbst entwickelte Shell-Skripte, sollte ein Filter greifen

Um bereits gebannte IP-Adressen anzeigen zu lassen, verwenden Sie den folgenden Befehl:

  • Verfügbare Jails anzeigen lassen
sudo fail2ban-client status
  • Gebannte IP-Adresse der Jail anzeigen
sudo fail2ban-client status 

Fail2ban bietet viele weitere Möglichkeiten, um Ihre Dienste zusätzlich abzusichern. Informieren Sie sich gerne über zusätzliche Filter und implementieren Sie diese, falls gewünscht. Alternativ können Sie auch eigene Filter unter Verwendung von Regex kreieren und diese auf Logeinträge testen.

Hier können Sie weitere vorgefertigte Fail2ban-Filterlisten entdecken: https://github.com/fail2ban/fail2ban/tree/master/config/filter.d