Veröffentlichung von WordPress 5.2 mit Unterstützung für die Überprüfung von Updates durch digitale Signatur

Eingereicht von Veröffentlichung eines Web-Content-Management-Systems WordPress 5.2. Die Veröffentlichung zeichnet sich durch ihre Fertigstellung aus Sechs-Jahres-Epos zur Umsetzung Fähigkeiten Überprüfung von Aktualisierungen und Ergänzungen mithilfe einer digitalen Signatur.

Bisher war bei der Installation von Updates in WordPress das Vertrauen in die WordPress-Infrastruktur und die Server der wichtigste Sicherheitsfaktor (nach dem Herunterladen wurde der Hash überprüft, ohne die Quelle zu überprüfen). Wenn die Server des Projekts kompromittiert wurden, konnten die Angreifer ein Update fälschen und Schadcode unter WordPress-basierten Websites verteilen, die ein automatisches Update-Installationssystem verwenden. Nach dem bisher verwendeten Trust-Delivery-Modell wäre eine solche Substitution auf Nutzerseite unbemerkt geblieben.

Unter Berücksichtigung der Tatsache, dass Nach Da nach Angaben des w3techs-Projekts die WordPress-Plattform auf 33.8 % der Websites im Netzwerk verwendet wird, hätte der Vorfall das Ausmaß einer Katastrophe angenommen. Gleichzeitig war die Gefahr einer Infrastrukturkompromittierung nicht hypothetisch, sondern durchaus real. So zum Beispiel vor einigen Jahren einer der Sicherheitsforscher gezeigt eine Schwachstelle, die es einem Angreifer ermöglichte, seinen Code auf der Serverseite von api.wordpress.org auszuführen.

Bei digitalen Signaturen führt die Erlangung der Kontrolle über den Update-Verteilungsserver nicht zu einer Kompromittierung der Benutzersysteme, da für die Durchführung eines Angriffs zusätzlich ein separat gespeicherter privater Schlüssel erforderlich ist, mit dem Updates signiert werden.

Die Implementierung der Überprüfung der Aktualisierungsquelle mithilfe einer digitalen Signatur wurde durch die Tatsache erschwert, dass die Unterstützung für die erforderlichen kryptografischen Algorithmen erst vor relativ kurzer Zeit im Standard-PHP-Paket enthalten war. Durch die Integration der Bibliothek entstanden die notwendigen kryptografischen Algorithmen Libnatrium zur Hauptmannschaft PHP 7.2. Aber als minimal unterstützte Version von PHP in WordPress angegeben Version 5.2.4 (von WordPress 5.2 - 5.6.20). Die Aktivierung der Unterstützung für digitale Signaturen würde zu einem erheblichen Anstieg der Anforderungen an die unterstützte Mindestversion von PHP oder zum Hinzufügen einer externen Abhängigkeit führen, was Entwickler angesichts der Verbreitung von PHP-Versionen in Hosting-Systemen nicht tun könnten.

Die Lösung war Entwicklung und die Aufnahme einer kompakten Version von Libsodium in WordPress 5.2 - Natriumkompatibel, bei dem ein Mindestsatz an Algorithmen zur Überprüfung digitaler Signaturen in PHP implementiert ist. Die Implementierung lässt hinsichtlich der Leistung zu wünschen übrig, löst aber das Kompatibilitätsproblem vollständig und ermöglicht Plugin-Entwicklern auch den Einstieg in die Implementierung moderner kryptografischer Algorithmen.

Zur Generierung digitaler Signaturen wird ein Algorithmus verwendet Ed25519, entwickelt unter Beteiligung von Daniel J. Bernstein. Für den aus dem Inhalt des Update-Archivs berechneten SHA384-Hashwert wird eine digitale Signatur generiert. Ed25519 bietet ein höheres Sicherheitsniveau als ECDSA und DSA und weist eine sehr hohe Geschwindigkeit bei der Überprüfung und Signaturerstellung auf. Die Hacking-Resistenz für Ed25519 beträgt etwa 2^128 (im Durchschnitt erfordert ein Angriff auf Ed25519 2^140-Bit-Operationen), was der Resistenz von Algorithmen wie NIST P-256 und RSA mit einer Schlüsselgröße von 3000 Bits entspricht oder 128-Bit-Blockverschlüsselung. Ed25519 ist außerdem nicht anfällig für Probleme mit Hash-Kollisionen und ist nicht anfällig für Cache-Timing-Angriffe oder Seitenkanalangriffe.

In der WordPress-Version 5.2 deckt die Überprüfung digitaler Signaturen derzeit nur wichtige Plattform-Updates ab und blockiert das Update nicht standardmäßig, sondern informiert den Benutzer nur über das Problem. Es wurde beschlossen, die Standardblockierung nicht sofort zu aktivieren, da eine vollständige Überprüfung und Umgehung erforderlich ist mögliche Probleme. Zukünftig ist auch die Einführung einer digitalen Signaturprüfung geplant, um die Installationsquelle von Themes und Plugins zu verifizieren (Hersteller können Veröffentlichungen mit ihrem Schlüssel signieren).

Neben der Unterstützung digitaler Signaturen in WordPress 5.2 sind folgende Änderungen festzustellen:

• Dem Abschnitt „Site Health“ wurden zwei neue Seiten zum Debuggen häufiger Konfigurationsprobleme hinzugefügt. Außerdem wurde ein Formular bereitgestellt, über das Entwickler Debugging-Informationen den Site-Administratoren überlassen können.
• Implementierung des „White Screen of Death“ hinzugefügt, der bei schwerwiegenden Problemen angezeigt wird und dem Administrator hilft, Probleme im Zusammenhang mit Plugins oder Themes selbstständig zu beheben, indem er in einen speziellen Crash-Recovery-Modus wechselt;
• Es wurde ein System zur Überprüfung der Kompatibilität mit Plugins implementiert, das unter Berücksichtigung der verwendeten PHP-Version automatisch die Möglichkeit der Verwendung des Plugins in der aktuellen Konfiguration prüft. Wenn ein Plugin eine neuere PHP-Version benötigt, um zu funktionieren, blockiert das System automatisch die Einbindung dieses Plugins;
• Unterstützung für die Aktivierung von Modulen mit JavaScript-Code hinzugefügt Webpack и Babel;
• Es wurde eine neue Vorlage „privacy-policy.php“ hinzugefügt, mit der Sie den Inhalt der Seite mit den Datenschutzrichtlinien anpassen können.
• Für Themes wurde ein wp_body_open-Hook-Handler hinzugefügt, der es Ihnen ermöglicht, Code direkt nach dem Body-Tag einzufügen;
• Die Anforderungen für die Mindestversion von PHP wurden auf 5.6.20 erhöht; Plugins und Themes haben jetzt die Möglichkeit, Namespaces und anonyme Funktionen zu verwenden;
• 13 neue Symbole hinzugefügt.

Darüber hinaus können Sie erwähnen Erkennung Kritische Sicherheitslücke im WordPress-Plugin WP-Live-Chat (CVE-2019-11185). Die Schwachstelle ermöglicht die Ausführung beliebigen PHP-Codes auf dem Server. Das Plugin wird auf mehr als 27 Websites verwendet, um einen interaktiven Chat mit einem Besucher zu organisieren, darunter auf den Websites von Unternehmen wie IKEA, Adobe, Huawei, PayPal, Tele2 und McDonald's (Live-Chat wird häufig verwendet, um Pop-up-Bedienung zu implementieren). Chats auf Unternehmensseiten mit Angeboten (Chat mit dem Mitarbeiter).

Das Problem manifestiert sich im Code zum Hochladen von Dateien auf den Server und ermöglicht es Ihnen, die Prüfung gültiger Dateitypen zu umgehen und ein PHP-Skript auf den Server hochzuladen und es dann direkt über das Web auszuführen. Interessanterweise wurde letztes Jahr bereits eine ähnliche Schwachstelle im Live-Chat (CVE-2018-12426) entdeckt, die das Laden von PHP-Code unter dem Deckmantel eines Bildes ermöglichte und im Feld „Content-type“ einen anderen Inhaltstyp angab. Als Teil des Fixes wurden zusätzliche Prüfungen für Whitelists und den MIME-Inhaltstyp hinzugefügt. Wie sich herausstellt, werden diese Kontrollen falsch durchgeführt und können leicht umgangen werden.

Insbesondere ist das direkte Hochladen von Dateien mit der Erweiterung „.php“ verboten, die Erweiterung „.phtml“, die auf vielen Servern mit dem PHP-Interpreter verbunden ist, wurde jedoch nicht zur Blacklist hinzugefügt. Die Whitelist erlaubt nur das Hochladen von Bildern, Sie können sie jedoch umgehen, indem Sie eine doppelte Erweiterung angeben, zum Beispiel „.gif.phtml“. Um die MIME-Typprüfung am Anfang der Datei zu umgehen, reichte es vor dem Öffnen des Tags mit PHP-Code aus, die Zeile „GIF89a“ anzugeben.

Source: opennet.ru