Da es sicher recht interessant ist, mal dem Ablauf von einem echten Szenario zu sehen, zeige ich hier mal wie man die Webseite der AfD-Bayern defaced hat.
Schrit 1: Informationen Sammeln
Damit wir überhaupt irgendeine Stelle haben, an der wir "ansetzten" können, benötigen wir so viele Informationen wie möglich.
Es macht Sinn, dass man erstmal versucht herrauszufinden, ob ein CMS auf dem Webserver läuft (Falls ja: welches?).
Häufig reicht dafür schon ein Blick in den Quelltext, die Robots.txt oder dem Footer der Webseite.
In diesem Fall wurde zuerst in der Robots.txt nachgeschaut und wurde direkt fündig.
Die Webseite läuft also auf dem Wordpress CMS.
Da die Wordpress-Plugins mit das größte Sicherheitsrisiko der Webseite darstellen, ist es Sinnvoll, dass diese als nächstes identifiziert werden.
Das kann man entweder über einen Blick in den Source Code machen, oder man ist Faul und benutzt extra für diesen Zweck erstellte Tools.
Man kann das Tool "WPScan" verwendet. WPScan erkennt nicht nur die Wordpress-Version inklusive aktives Theme und Plugins, sondern sucht direkt nach Sicherheitslücken.
wpscan -u afdbayern.de
WPScan gibt uns direkt einige wertvolle Hinweise.
Wir haben also direkt 5 potentielle Sicherheitslücken. Das sollte vorerst für den Angriff reichen.
Schritt 2: Der Angriff
Da von 2 Plugins die Version nicht erkannt wurde, werden alle Sicherheitslücken angezeigt, die die Plugins mal hatten.
Bei den Lücken für den Revsliver wird direkt ein passender Exploit zur Verfügung gestellt. Leider stellt sich beim Testen herraus, dass die Lücken nicht mehr bestehen.
Auch die 2 Lücken vom Layerslider wurden geschlossen bzw. sind nicht sonderlich attraktiv.
Bei der Meldung "searchreplacedb2.php has been found " stellt sich herraus, dass es sich bei dieser Datei um ein Script zum bearbeiten der Datenbank handelt.
Wer sowas auf dem Server rumliegen hat muss schon ziemlich leichtsinnig sein, zumal das Script nichtmal eine Anmeldung erfordert.
Das Script bietet mir direkt an, die Logindaten für die Datenbank aus der wp-config.php zu laden und zeigt sie mir freundlicherweise auch direkt im Browser an. Jackpot!
Leider erlaubt MySQL nur verbindungen von localhost auf die Datenbank "afdbayy_DB1".
Also muss ein anderer Weg gefunden werden.
Das Script searchreplacedb2.php bietet die Möglichkeit nach einem String zu suchen und diesem mit einem anderen zu ersetzen.
Weitere Informationen zum Script: interconnectit.com/products/sea … databases/
Somit besteht die Möglichkeit die Emailadressen der Benutzer zu ändern um sich über die "Passwort vergessen"-Funktion ein neues Passwort zuschicken zu lassen.
Die letzte Hürde ist nun also die Mail-Adresse des Admins zu finden. Dank der Suchfunktion der Webseite ist die schnell gefunden.
Nachdem die Administratoremail durch eine anonyme Adresse ersetzt wird, konnte man sich einfach ein neues Passwort zuschicken lassen und man war im Backend der Seite eingeloggt.
Wie hätte dieser Angriff verhindert werden können?
Für das Backend die .htpasswd verwenden.
Keine Scripts zur Einrichtung der Seite auf dem Server liegen lassen!
"Passwort vergessen"-Funktion ausschalten.
Schrit 1: Informationen Sammeln
Damit wir überhaupt irgendeine Stelle haben, an der wir "ansetzten" können, benötigen wir so viele Informationen wie möglich.
Es macht Sinn, dass man erstmal versucht herrauszufinden, ob ein CMS auf dem Webserver läuft (Falls ja: welches?).
Häufig reicht dafür schon ein Blick in den Quelltext, die Robots.txt oder dem Footer der Webseite.
In diesem Fall wurde zuerst in der Robots.txt nachgeschaut und wurde direkt fündig.
d1sk schrieb:
User-agent: *
Disallow: /wp-admin/
Die Webseite läuft also auf dem Wordpress CMS.
Da die Wordpress-Plugins mit das größte Sicherheitsrisiko der Webseite darstellen, ist es Sinnvoll, dass diese als nächstes identifiziert werden.
Das kann man entweder über einen Blick in den Source Code machen, oder man ist Faul und benutzt extra für diesen Zweck erstellte Tools.
Man kann das Tool "WPScan" verwendet. WPScan erkennt nicht nur die Wordpress-Version inklusive aktives Theme und Plugins, sondern sucht direkt nach Sicherheitslücken.
wpscan -u afdbayern.de
WPScan gibt uns direkt einige wertvolle Hinweise.
d1sk schrieb:
...
searchreplacedb2.php has been found in: 'http://www.afdbayern.de/searchreplacedb2.php' (Achtung: CW)
...
8 plugins found:
Name: LayerSlider
We could not determine a version so all vulnerabilities are printed out
Title: LayerSlider 4.6.1 - Style Editing CSRF
(+ Einige Referenzen zur Lücke)
Title: LayerSlider 4.6.1 - Remote Path Traversal File Access
(+ Einige Referenzen zur Lücke)
...
Name: revslider
We could not determine a version so all vulnerabilities are printed out
Title: WordPress Slider Revolution Local File Disclosure
(+ Einige Referenzen zur Lücke, Exploit)
Title: WordPress Slider Revolution Shell Upload
(+ Einige Referenzen zur Lücke, Exploit)
Schritt 2: Der Angriff
Da von 2 Plugins die Version nicht erkannt wurde, werden alle Sicherheitslücken angezeigt, die die Plugins mal hatten.
Bei den Lücken für den Revsliver wird direkt ein passender Exploit zur Verfügung gestellt. Leider stellt sich beim Testen herraus, dass die Lücken nicht mehr bestehen.
Auch die 2 Lücken vom Layerslider wurden geschlossen bzw. sind nicht sonderlich attraktiv.
Bei der Meldung "searchreplacedb2.php has been found " stellt sich herraus, dass es sich bei dieser Datei um ein Script zum bearbeiten der Datenbank handelt.
Wer sowas auf dem Server rumliegen hat muss schon ziemlich leichtsinnig sein, zumal das Script nichtmal eine Anmeldung erfordert.
Das Script bietet mir direkt an, die Logindaten für die Datenbank aus der wp-config.php zu laden und zeigt sie mir freundlicherweise auch direkt im Browser an. Jackpot!
d1sk schrieb:
mysql -h sql117.your-server.de -u afdbayy_1 -pEnter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 992590
Server version: 5.5.44-0+deb7u1 (Debian)
mysql> use afdbayy_DB1;
ERROR 1044 (42000): Access denied for user 'afdbayy_1'@'%' to database 'afdbayy_DB1'
Leider erlaubt MySQL nur verbindungen von localhost auf die Datenbank "afdbayy_DB1".
Also muss ein anderer Weg gefunden werden.
Das Script searchreplacedb2.php bietet die Möglichkeit nach einem String zu suchen und diesem mit einem anderen zu ersetzen.
Weitere Informationen zum Script: interconnectit.com/products/sea … databases/
Somit besteht die Möglichkeit die Emailadressen der Benutzer zu ändern um sich über die "Passwort vergessen"-Funktion ein neues Passwort zuschicken zu lassen.
Die letzte Hürde ist nun also die Mail-Adresse des Admins zu finden. Dank der Suchfunktion der Webseite ist die schnell gefunden.
Nachdem die Administratoremail durch eine anonyme Adresse ersetzt wird, konnte man sich einfach ein neues Passwort zuschicken lassen und man war im Backend der Seite eingeloggt.
Wie hätte dieser Angriff verhindert werden können?
Für das Backend die .htpasswd verwenden.
Keine Scripts zur Einrichtung der Seite auf dem Server liegen lassen!
"Passwort vergessen"-Funktion ausschalten.
Hail Anime
