Natalia Merzlyakova - Fotolia

F

Warum musste eine PHPMailer-Schwachstelle zweifach gepatcht werden?

Eine kritische Sicherheitslücke im populären PHPMailer erforderte zwei Updates. Die Hintergründe und Risiken der Schwachstelle im Überblick.

In der Open-Source-Bibliothek PHPMailer wurde Ende 2016 eine kritische Schwachstelle gefunden, die sich aus der Ferne ausnutzen lässt. Die Schwachstelle wurde zweifach gepatcht, denn der erste Versuch hat das Problem nicht ausreichend behoben. Wie funktioniert diese Schwachstelle? Und warum wurde sie nicht mit dem ersten Update geschlossen?

Code-Bibliotheken und Frameworks reduzieren die Zeit, die für das Erstellen neuer Applikationen notwendig ist. Sie ermöglichen es Entwicklungsteams, gemeinsam genutzte Komponenten direkt zu verwenden, statt sie für jedes Projekt neu zu entwickeln.

Die meisten Webdienste nutzen dabei die Bibliotheken und Frameworks von populären Drittanbietern. Das größte Problem mit dieser Mehrfachnutzung von Code ist, dass gefundene Schwachstellen in einer populären Bibliothek hunderte, ja tausende von Seiten, Applikationen und Diensten betreffen können.

Diese Situation tritt häufig auf, so fand der Sicherheitsforscher Dawid Golunski eine Sicherheitslücke in dem Open-Source-Programm PHPMailer. Ein Angreifer kann über diese Schwachstelle Zugriff auf den attackierten Server erhalten, er hat dabei die Benutzerrechte des Webserver-Accounts. Das kann potentiell zu einer Übernahme der kompletten Webapplikation führen.

PHPMailer wird in vielen Open-Source-Projekten genutzt, darunter beispielsweise WordPress, Drupal und Joomla. Insgesamt geht man von etwa neun Millionen Nutzern weltweit aus. Es gibt tausende Codebeispiele dazu, wie E-Mails mit Hilfe von PHPMailer verschickt werden. Oft wird die Funktion etwa für Kontaktformulare oder zur Registrierung von Nutzern verwendet.

PHPMailer nutzt die E-Mail-Funktion in PHP für den Versand der Nachrichten. Obwohl die Adressen eigentlich vor dem Versand überprüft werden, fand Golunski hier eine Schwachstelle. Er konnte eine Absendeadresse eintragen, die ausführbaren Code enthielt.

Obwohl die Absendeadresse eigentlich vom Entwickler gesetzt werden sollte, lässt sie sich oft vom Anwender ändern. Das ist ein Problem, da der Nutzer hier jeden Eintrag hinterlegen kann, den er möchte. Werden keine Informationen zum Absender eingetragen, wird auch hier die Absendeadresse genutzt. Diese Daten werden als Parameter an die Mailfunktion von PHP übergeben, ohne dass der Code vorher bereinigt wird. Angreifer können dadurch Kommandos einschleusen und diese vom Server ausführen lassen.

Sicherheitslücke geschlossen

Die Schwachstelle wird als CVE-2016-10033 geführt, die Entwickler von PHPMailer haben reagiert und die Lücke in PHPMailer Version 5.2.18 geschlossen. Diese Version integriert die escapeshellcmd-Funktion, die die übergebenen Daten bereinigt, bevor sie an die PHP-Mailfunktion übergeben werden.

Allerdings stellte Golunski fest, dass die escapeshellcmd-Funktion die Lücke nicht ausreichend schloss. Indem die ursprüngliche Attacke um weitere Informationen erweitert wird, lässt sich weiterhin Code übergeben und ausführen. Die neue Version der Schwachstelle wird als CVE-2016-10045 gelistet, ein weiterer Patch und PHPMailer Version 5.2.20 wurden veröffentlicht.

Das PHPMailer-Team hat auf GitHub Beispiele zur korrekten Anwendung der E-Mail-Adressen in Formularen veröffentlicht. Anwender sollten die Absendedaten und die genutzten Absendeadressen beispielsweise fest definieren.

Die Schwachstelle wird als hochkritisch angesehen. Sie zeigt, wie wichtig es für Administratoren und Entwickler ist, sich über aktuelle Sicherheitsprobleme zu informieren. Bietet der Entwickler einen Newsletter oder eine Alarmfunktion, sollte man diese in jedem Fall abonnieren. Entwickler sollten zudem alle Skripte überprüfen, die die PHPMailer-Funktion nutzen. Neben den bereits erwähnten Problemen könnte diese Lücke potentiell zu einer SQL-Injection-Schwachstelle führen.

Folgen Sie SearchSecurity.de auch auf Twitter, Google+, Xing und Facebook!

Nächste Schritte

Sicherheitsrisiko Open-Source- und Drittanbieter-Komponenten

Veraltete Open-Source-Komponenten gefährden kommerzielle Anwendungen

Wieviel Zeitaufwand ist fürs Patchen und Updaten gerechtfertigt?

Patch-Management – Tipps für die richtige Strategie

Artikel wurde zuletzt im Juni 2017 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Email-Sicherheitsbedrohungen

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchStorage.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close