Veröffentlichung des Content-Management-Systems . Diese Version zeichnet sich durch den Abschluss bei der Umsetzung von Updates und Erweiterungen mittels digitaler Signatur aus.
Bisher basierte die Sicherheit bei der Installation von Updates in WordPress hauptsächlich auf dem Vertrauen in die Infrastruktur und Server von WordPress (nach dem Download wurde der Hash überprüft, ohne die Quelle zu verifizieren). Im Fall einer Kompromittierung der Projektserver konnten Angreifer das Update manipulieren und schadhafter Code unter den Websites verbreiten, die auf der automatischen Update-Installation basierten. Nach dem zuvor angewandten Vertrauensmodell wäre eine solche Manipulation für die Nutzer unbemerkt geblieben.
Angesichts der Tatsache, dass laut w3techs die WordPress-Plattform auf 33,8 % aller Websites im Netz verwendet wird, hätte ein solcher Vorfall katastrophale Ausmaße angenommen. Darüber hinaus war die Gefahr einer Kompromittierung der Infrastruktur nicht hypothetisch, sondern durchaus real. Vor einigen Jahren demonstrierte ein Sicherheitsforscher Eine Sicherheitslücke, die es einem Angreifer ermöglichte, seinen Code auf der Serverseite von api.wordpress.org auszuführen.
Im Falle von digitalen Zertifikaten wird die Kontrolle über den Server zur Verteilung von Updates nicht zur Gefährdung der Benutzer Systeme führen, da für einen Angriff zusätzlich der separat gespeicherte private Schlüssel erforderlich wäre, mit dem die Updates signiert werden.
Die Implementierung der Überprüfung der Update-Quellen durch digitale Signaturen wurde dadurch erschwert, dass die Unterstützung der erforderlichen kryptografischen Algorithmen erst kürzlich mit der Standardlieferung von PHP eingeführt wurde. Die benötigten kryptografischen Algorithmen kamen durch die Integration der Bibliothek in den Kern von . Als minimal unterstützte PHP-Version in WordPress Version 5.2.4 (ab WordPress 5.2 — 5.6.20) angegeben. Die Einbeziehung der Unterstützung für digitale Signaturen würde erhebliche Erhöhungen der Anforderungen an die minimal unterstützte PHP-Version oder die Hinzufügung einer externen Abhängigkeit zur Folge haben, was die Entwickler aufgrund der Verbreitung der PHP-Versionen in Hosting-Systemen nicht riskieren konnten.
Die Lösung war und die Integration einer kompakten Version von Libsodium in WordPress 5.2 — , die in PHP implementiert ist und einen minimalen Satz von Algorithmen zur Überprüfung digitaler Signaturen bereitstellt. Die Performance lässt zwar zu wünschen übrig, doch die Lösung behebt vollständig das Kompatibilitätsproblem und ermöglicht es Entwicklern von Plugins, moderne kryptografische Algorithmen zu integrieren.
Für die Erstellung digitaler Signaturen wird der Algorithmus verwendet , entwickelt in Zusammenarbeit mit Daniel J. Bernstein. Die digitale Signatur wird für den SHA384-Hashwert erstellt, der aus dem Inhalt des Archivs mit dem Update berechnet wurde. Ed25519 bietet ein höheres Sicherheitsniveau als ECDSA und DSA und weist eine sehr hohe Geschwindigkeit bei der Verifizierung und Erstellung von Signaturen auf. Die Widerstandsfähigkeit von Ed25519 gegen Angriffe beträgt etwa 2^128 (im Durchschnitt sind für einen Angriff auf Ed25519 2^140 Bit-Operationen erforderlich), was dem Widerstand solcher Algorithmen wie NIST P-256 und RSA mit einer Schlüssellänge von 3000 Bit oder einem 128-Bit-Blockcipher entspricht. Ed25519 ist auch nicht anfällig für Hash-Kollisionsprobleme, unempfindlich gegen Angriffe durch Cache-Timing-Analysen und Angriffe über Seitenkanäle.
In der Version WordPress 5.2 umfasst die Überprüfung der digitalen Signatur derzeit nur die Hauptupdates der Plattform und führt standardmäßig nicht zu einer Sperrung des Updates, sondern informiert lediglich den Benutzer über ein aufgetretenes Problem. Die Standard-Sperrung wurde zunächst nicht implementiert, um eine vollständige Überprüfung und Umgehung . In Zukunft wird auch eine Überprüfung der digitalen Signatur für die Verifizierung von Design- und Plugin-Installationsquellen geplant (Hersteller können ihre Releases mit ihrem Schlüssel signieren).
Neben der Unterstützung digitaler Signaturen bringt WordPress 5.2 folgende Änderungen mit sich:
- Der Bereich „Site Health“ erhielt zwei neue Seiten zur Fehlersuche bei typischen Konfigurationsproblemen sowie ein Formular, über das Entwickler Debugging-Informationen für die Website-Administratoren hinterlassen können;
- Es wurde eine Implementierung des „weißen Bildschirms des Todes“ hinzugefügt, die bei schwerwiegenden Problemen angezeigt wird und dem Administrator hilft, Probleme im Zusammenhang mit Plugins oder Themen selbst zu beheben, indem er in einen speziellen Wiederherstellungsmodus nach einem Absturz wechselt;
- Ein System zur Kompatibilitätsprüfung für Plugins wurde implementiert, das automatisch überprüft, ob ein Plugin in der aktuellen Konfiguration mit der verwendeten PHP-Version verwendet werden kann. Wenn eine neuere PHP-Version für den Betrieb des Plugins erforderlich ist, blockiert das System automatisch die Aktivierung dieses Plugins;
- Die Unterstützung für die Aktivierung von Modulen mit JavaScript-Code wurde hinzugefügt mit und ;
- Ein neues Template privacy-policy.php wurde hinzugefügt, das es ermöglicht, die Inhalte der Seite zur Einhaltung der Datenschutzbestimmungen anzupassen.
- Für Design-Themen wurde ein wp_body_open Hook hinzugefügt, der es ermöglicht, Code direkt nach dem body-Tag einzufügen.
- Die Anforderungen an die Mindestversion von PHP wurden auf 5.6.20 angehoben, in Plugins und Gestaltungsthemen wurde die Verwendung von Namensräumen und anonymen Funktionen ermöglicht.
- 13 neue Piktogramme wurden hinzugefügt.
Außerdem kann erwähnt werden einer kritischen Sicherheitsanfälligkeit im WordPress-Plugin (CVE-2019-11185). Die Sicherheitsanfälligkeit ermöglicht die Ausführung beliebigen PHP-Codes auf dem Server. Das Plugin wird auf über 27.000 Websites zur Einrichtung eines interaktiven Chats mit Besuchern verwendet, darunter Websites solcher Unternehmen wie IKEA, Adobe, Huawei, PayPal, Tele2 und McDonald’s (Live Chat wird häufig verwendet, um auf Websites der Unternehmen lästige Pop-up-Chats anzubieten, in denen man mit einem Mitarbeiter sprechen kann).
Das Problem tritt im Code zum Hochladen von Dateien auf den Server auf und ermöglicht es, die Überprüfung zulässiger Dateitypen zu umgehen und ein PHP-Skript auf den Server hochzuladen, das dann durch einen direkten Zugriff über das Web ausgeführt wird. Interessanterweise wurde im letzten Jahr im Live-Chat bereits eine ähnliche Schwachstelle (CVE-2018-12426) festgestellt, die es erlaubte, PHP-Code als Bild hochzuladen, indem ein anderer Inhaltstyp im Feld Content-type angegeben wurde. Im Rahmen der Problemlösung wurden zusätzliche Überprüfungen mit Whitelists und MIME-Typen hinzugefügt. Wie sich herausstellte, wurden diese Überprüfungen jedoch nicht korrekt implementiert und sind leicht zu umgehen.
Insbesondere ist das direkte Hochladen von Dateien mit der Endung „.php“ verboten, jedoch wurde die Endung „.phtml“, die auf vielen Servern mit dem PHP-Interpreter verbunden ist, nicht auf die schwarze Liste gesetzt. Die Whitelist erlaubt nur das Hochladen von Bildern, aber man kann sie umgehen, indem man eine doppelte Erweiterung angibt, wie zum Beispiel „.gif.phtml“. Um die Überprüfung des MIME-Typs zu umgehen, reicht es, zu Beginn der Datei, vor dem Öffnen des PHP-Codes, die Zeile „GIF89a“ anzugeben.
Quelle: opennet.ru
