Cybersecurity

Letztens wurde leider meine Website mit meinen Blogposts gehackt. Dabei stellte ich mir die Frage, wie das passieren konnte und wie ich sowas in Zukunft vermeide, oder es den Hackern zumindest schwieriger zu machen. Mein Webhosting-Anbieter konnte die Seite glücklicherweise wiederherstellen. Auf der Übersicht meiner Wordpress-Seite sah ich die folgenden Sicherheitshinweise:

• Veraltete PHP Version
• Veraltete Wordpress Version

PHP 7.4

Vor dem Angriff auf meine Website verwendete ich noch die Version 7.4 von PHP. Diese wird nicht mehr unterstützt, was sie anfällig für Sicherheitslücken macht. Viele der Sicherheitslücken sind bereits bekannt.

XML External Entity (XXE) Injection

Eine XXE Injection ist ein Angriff, bei der bösartige XML-Daten in eine Anwedung eingeschleust werden und versucht wird, vertrauliche Informationen auszulesen oder Angriffe durchzuführen. Dies kann passieren, wenn die Anwendung unsicher konfiguriert ist und externe Entitäten in XML-Dokumenten ohne ausreichende Validierung erlaubt sind. 

Angenommen, eine Anwendung akzeptiert XML-Daten von Benutzern. Ein Angreifer sendet die folgende XML-Anfrage an die Anwendung:

<!DOCTYPE foo [

  <!ELEMENT foo ANY>

  <!ENTITY xxe SYSTEM "file:///etc/passwd">

]>

<foo>&xxe;</foo>

In dieser XML-Anfrage definiert der Angreifer ein externes Entity namens "xxe", welches auf die Datei "/etc/passwd" zugreift. Somit erhält er die Informationen dieser Datei zurück und hat sensible Daten, auf welche er eigentlich keinen Zugriff haben sollte.

Out-of-Bounds

Eine Out-of-Bounds Vulnerability tritt auf, wenn eine Anwendung versucht, auf einen Speicherbereich zuzugreifen, welcher ausserhalb des reservierten Bereiches liegt. Dies kann zu unerwartetem Verhalten führen und Angreifern die Möglichkeit bieten, die Anwendung zu manipulieren oder sogar Code auszuführen. 

Die Ausnutzung einer Out-of-Bounds Vulnerability erfordert in der Regel jedoch ein tiefes Verständnis der Anwendung und ist nicht einfach durchzuführen.

Out-of-Bounds

Eine Integer Overflow or Wraparound Vulnerability tritt auf, wenn ein Integer einen Wert überschreitet, der ausserhalb des zulässigen Bereiches liegt. Dies kann zu unerwarteten Verhalten führen. Angreifer können dies ausnutzen, um Sicherheitsmechanismen zu umgehen.

In diesem Beispiel hat eine Anwendung einen 32-Bit-Integer, um die Anzahl der Produkte in einem Warenkorb zu speichern. Die Anzahl wird daraufhin mit dem Preis multipliziert. 

units = 2000000000 # 2 Milliarden Produkte

price_per_unit = 3 # 4 Franken pro Produkt

total_price = units * price_per_unit

Da "total_price" den Maximalwert überschreitet, ist das Ergebnis ein negativer Wert. Der Angreifer könnte nun die Produkte zu einem negativen Preis kaufen.

Server Side Request Forgery (SSRF)

Auf der Wordpress Version, welche ich verwendete, wurde von Simon Scannell und Thomas Chauchefoin eine Sicherheitslücke entdeckt, welche es Angreifern ermöglicht, sensible Daten und Services auf dem System auszulesen. Es handelt sich dabei um eine SSRF-Sicherheitslücke. Dieses Problem wurde jedoch noch nicht gelöst und es gibt noch keine neue Wordpress Version. (https://patchstack.com/database/vulnerability/wordpress/wordpress-6-1-1-unauth-blind-ssrf-vulnerability?_a_id=110)

Server Side Request Forgery (SSRF) ist eine Sicherheitslücke, bei der ein Angreifer Anfragen von einem Server auslösen kann, auf die er normalerweise keinen Zugriff hat. Dies passiert oft, indem der Angreifer Anfragen über die Schwachstellen einer Anwendung an den Server sendet, der dann Daten an den Angreifer zurückgibt. Dies kann dazu führen, dass vertrauliche Informationen offengelegt werden. SSRF-Angriffe sind gefährlich, da sie die gesamte Sicherheitsinfrastruktur eines Systems bedrohen.

Beispiel

Angenommen, eine Webanwendung akzeptiert Benutzereingaben für eine URL, die von einem internen Dienst abgerufen werden soll, um beispielsweise Metadaten einer Webseite anzuzeigen. Der Benutzer gibt die folgende URL ein:

http://internal-service/api/getdata?url=http://malicious-site.com/secret

Die Anwendung verwendet den Input, um eine HTTP-Anfrage an die angegebene URL zu senden und die Daten auf der Webseite malicious-site.com/secret abzurufen. Allerdings hat der Angreifer die URL so manipuliert, dass sie auf einen internen Dienst zeigt, den er auskundschaften möchte:

http://internal-service/api/getdata?url=http://internal-service/admin/credentials

In diesem Fall würde die Anwendung die Anfrage an den internen Dienst senden und die vertraulichen Anmeldeinformationen zurückgeben. Der Angreifer hat erfolgreich eine Anfrage manipuliert, um auf interne Ressourcen zuzugreifen, auf die er normalerweise keinen Zugriff hätte.

Schlussfolgerung

Ich kann mir Vorstellen, dass die veraltete PHP Version ein Grund für den Angriff auf meine Website war. Die PHP Version habe ich umgehend aktualisiert, um die Sicherheitslücken zu entfernen.

Es könnte auch sein, dass auf meiner Website ein SSRF-Angriff durchgeführt wurde, um meine Anmeldedaten zu erhalten. Das ist jedoch nur eine Annahme und ich kann nicht sicherstellen, ob das wirklich passiert ist. Ich werde die neue Version herunterladen, sobald sie verfügbar ist.