Einblick in URL-Attacken auf Webseiten
Heute geben wir einen kleinen Einblick in typische direkte und indirekte Angriffe auf Webseiten, die bei uns täglich stattfinden. Dazu zählen auch Ausspähversuche auf das Vorhandensein von URLs oder Dateien auf dem Webspace, die per Browser erreichbar sind.
Die folgenden Daten betreffen primär von WordPress-Seiten, gelten jedoch zum Großteil auch für andere Systeme.
1) Adminbenutzer herausfinden
Die Nutzung von “admin” oder “administrator” für den Standard-Benutzernamen bei WordPress kommt im Regelfall glücklicherweise heutzutage eher selten vor. Man kann jedoch relativ einfach über die Abfrage der ID aller Autoren im System, den aktuellen Benutzernamen herausfinden. Diese Abfrage kann in WordPress deaktiviert werden. Diese Abfrage erfolgt von außen sehr häufig in verschiedenen Varianten:
GET /?author=1
GET ///?author=1
2) Installation übernehmen
Attacken richten sich weiterhin auf die Install- und Konfigurationsverzeichnisse, um darüber z.B. eine Neueinstallation bzw. die Update-Funktion dazu zu nutzen, auf dem Webserver eine Phishing-Seite zu installieren. Sind andere Systeme als WordPress im Einsatz, so sind auch Zugriffe auf setup.php / update.php u.ä. regelmäßig zu sehen.
GET /installer.php
GET /installer-backup.php
GET /wp-admin/setup-config.php
GET /wp-admin/setup-config.php?step=1
3)Datenbankdumps und Backups übernehmen
URL-Aufrufe, mit dem Ziel an Backups zu gelangen, die direkt im Root-Verzeichnis der Domain liegen, sind sehr beliebt. Dabei wird sowohl nach Daten- als auch nach Datenbank-Dumps mit gängigen Bezeichnungen gesucht. Auch auf von einigen Plugins/Tools erstellte Backupnamen wird gezielt versucht zuzugreifen:
GET /InCreate-FullPackage.gz / .zip / .tar.gz
GET /backup.gz / .tar.gz / .zip
GET /installer-data.sql.gz / .tar.gz / .zip
GET /wordpress.zip / .gz / .tar.gz
GET /wp-content.zip / .gz / .tar.gz
GET /database_backup.sql
GET /backup.sql
GET /db.sql
GET /database.sql
GET /dump.sql
GET /main.sql
GET /fullbackup.sql
GET /origin.sql
GET /2019.sql
GET /www.sql
GET /upl.sql
GET /php.sql
uvm.
4) WordPress Login und Remote-Calls
Angriffe auf das Login und die XML-Schnittstelle werden ebenfalls zahlreich vorgenommen. Problematisch ist in beiden Fällen der Versuch durch Brute-Force-Attacken das Ausspähen/Herausfinden der Logindaten. Zusätzlich kann über die XMLrpc-Schnittstelle eine DDoS-Attacke ausgeführt werden:
GET /wp-login.php
POST /xmlrpc.php
5) Plugin Lücken ausnutzen
Weiterhin gibt es natürlich Angriffe auf Plugins, um dort bereits bekannte Lücken auszunutzen. Die Zahl der angegriffenen Plugins ist groß und eine Auflistung an dieser Stelle bringt in unseren Augen keinen Mehrwert. Wir möchten aber nocheinmal dringend darauf hinweisen, dass bei allen eingesetzten Systemen – egal welches CMS, Shopsoftware o.a. eingesetzt wird – regelmäßige Updates extrem wichtig sind.
6) Datenbank-Zugriffe
Versuche, auf die Datenbankverwaltung direkt zuzugreifen. Oft wird ein solches System/Skript zusätzlich auf dem Webspace abgelegt und ist direkt mit den Datenbanken verbunden. Wird dann auf eine Loginmaske mit Passwortabfrage verzichtet, kann man direkt auf die Datenbanken zugreifen:
GET /adminer.php
GET /sql.php
GET /phpmyadmin.php
GET /phpminiadmin.php
7) CMS-URLs herausfinden, alte Daten
Herausfinden, ob wordpress, Backups und nicht gesicherte Kopien von alten Installationen vorhanden sind:
GET /wordpress/
GET /wp/
GET /blog/
GET /new/
GET /old/
GET /test/
GET /oldsite/
GET /backup/
Für andere Systeme:
GET /magento/index.php/admin/
GET /magento/downloader/index.php
GET /store/index.php/admin/
GET /shopware/
GET /backend/Login/login/
GET /backend/?atsdBackendLogin=1
GET /shop/downloader/index.php
GET /shop/index.php/admin/
Wie man sehen kann wird /magento oder auch /shopware bei den Aufrufen einfach ersetzt durch “shop”, “store”, “backend” – so dass auch in diesen Fällen eine Prüfung erfolgt, selbst wenn das Verzeichnis umbenannt wurde oder die Domain über Weiterleitungen in andere Ebenen verlinkt.
Abwehr von oben genannten Attacken
Bei uns existiert ein mehrstufiges System, um Kunden und Webseiten gegen solche Angriffe zu schützen. Dazu zählen durch Kunden de-/aktivierbare spezielle Sicherheitseinstellungen für WordPress, sowie die Web-Application-Firewall (WAF), die für alle Webseiten greift.
Weitere system- und serverseitige Sicherheitsfeatures und Abwehrmechanismen werden regelmäßig aktualisiert und erweitert. Alle diese Dinge können natürlich nur als Ergänzung zu einem aktuellen System funktionieren und dürfen nicht als hundertprozentiger dauerhafter Schutz vor Attacken gesehen werden, da sich diese stetig weiterentwickeln.