release van een webcontentmanagementsysteem . De release valt op door de voltooiing ervan op de implementatie het controleren van updates en aanvullingen met behulp van een digitale handtekening.
Tot nu toe was bij het installeren van updates in WordPress de belangrijkste beveiligingsfactor het vertrouwen in de WordPress-infrastructuur en -servers (na het downloaden werd de hash gecontroleerd zonder de bron te verifiëren). Als de servers van het project werden gehackt, konden de aanvallers een update vervalsen en kwaadaardige code verspreiden onder op WordPress gebaseerde sites die een automatisch update-installatiesysteem gebruiken. In overeenstemming met het eerder gebruikte vertrouwensleveringsmodel zou een dergelijke vervanging aan de kant van de gebruikers onopgemerkt zijn gebleven.
Rekening houdend met het feit dat van het w3techs-project het WordPress-platform wordt gebruikt op 33.8% van de sites op het netwerk, zou het incident de omvang van een ramp hebben aangenomen. Tegelijkertijd was het gevaar van compromissen op het gebied van de infrastructuur niet hypothetisch, maar zeer reëel. Een aantal jaren geleden bijvoorbeeld een van de beveiligingsonderzoekers een kwetsbaarheid waardoor een aanvaller zijn code op de serverzijde van api.wordpress.org kon uitvoeren.
In het geval van digitale handtekeningen zal het verkrijgen van controle over de updatedistributieserver niet leiden tot het compromitteren van gebruikerssystemen, aangezien u voor het uitvoeren van een aanval bovendien een afzonderlijk opgeslagen privésleutel nodig heeft, waarmee updates worden ondertekend.
De implementatie van het controleren van de bron van updates met behulp van een digitale handtekening werd belemmerd door het feit dat relatief recent ondersteuning voor de noodzakelijke cryptografische algoritmen in het standaard PHP-pakket verscheen. Dankzij de integratie van de bibliotheek ontstonden de nodige cryptografische algoritmen naar het hoofdteam . Maar als de minimaal ondersteunde versie van PHP in WordPress release 5.2.4 (van WordPress 5.2 - 5.6.20). Het inschakelen van ondersteuning voor digitale handtekeningen zou leiden tot een aanzienlijke verhoging van de vereisten voor de minimaal ondersteunde versie van PHP of de toevoeging van een externe afhankelijkheid, wat ontwikkelaars niet zouden kunnen doen gezien de prevalentie van PHP-versies in hostingsystemen.
De oplossing was en de opname van een compacte versie van Libsodium in WordPress 5.2 - , waarin een minimale set algoritmen voor het verifiëren van digitale handtekeningen is geïmplementeerd in PHP. De implementatie laat veel te wensen over op het gebied van prestaties, maar lost het compatibiliteitsprobleem volledig op en stelt plug-inontwikkelaars ook in staat moderne cryptografische algoritmen te implementeren.
Er wordt een algoritme gebruikt om digitale handtekeningen te genereren , ontwikkeld met medewerking van Daniel J. Bernstein. Er wordt een digitale handtekening gegenereerd voor de SHA384-hashwaarde, berekend op basis van de inhoud van het updatearchief. Ed25519 heeft een hoger beveiligingsniveau dan ECDSA en DSA, en vertoont een zeer hoge snelheid van verificatie en handtekeningcreatie. De weerstand tegen hacken voor Ed25519 is ongeveer 2^128 (gemiddeld vereist een aanval op Ed25519 2^140 bit bewerkingen), wat overeenkomt met de weerstand van algoritmen zoals NIST P-256 en RSA met een sleutelgrootte van 3000 bits of 128-bits blokcodering. Ed25519 is ook niet gevoelig voor problemen met hash-botsingen en is niet gevoelig voor cache-timing-aanvallen of zijkanaalaanvallen.
In de WordPress 5.2-release heeft de verificatie van digitale handtekeningen momenteel alleen betrekking op grote platformupdates en blokkeert de update niet standaard, maar informeert de gebruiker alleen over het probleem. Er is besloten om de standaardblokkering niet onmiddellijk in te schakelen vanwege de noodzaak van een volledige controle en omleiding . In de toekomst is het ook de bedoeling om digitale handtekeningverificatie toe te voegen om de bron van installatie van thema's en plug-ins te versifiëren (fabrikanten zullen releases kunnen ondertekenen met hun sleutel).
Naast ondersteuning voor digitale handtekeningen in WordPress 5.2 kunnen de volgende wijzigingen worden opgemerkt:
- Er zijn twee nieuwe pagina's toegevoegd aan de sectie “Site Health” voor het opsporen van veelvoorkomende configuratieproblemen, en er is ook een formulier beschikbaar waarmee ontwikkelaars foutopsporingsinformatie aan sitebeheerders kunnen overlaten;
- Implementatie toegevoegd van het “witte scherm van de dood”, weergegeven in geval van fatale problemen en de beheerder helpen zelfstandig problemen met betrekking tot plug-ins of thema’s op te lossen door over te schakelen naar een speciale crashherstelmodus;
- Er is een systeem geïmplementeerd om de compatibiliteit met plug-ins te controleren, dat automatisch controleert of de plug-in in de huidige configuratie kan worden gebruikt, rekening houdend met de gebruikte PHP-versie. Als een plug-in een nieuwere versie van PHP vereist om te werken, blokkeert het systeem automatisch de opname van deze plug-in;
- Ondersteuning toegevoegd voor het inschakelen van modules met JavaScript-code met behulp van и ;
- Een nieuwe privacy-policy.php-sjabloon toegevoegd waarmee u de inhoud van de privacybeleidspagina kunt aanpassen;
- Voor thema's is een wp_body_open hook handler toegevoegd, waardoor je code direct na de body-tag kunt invoegen;
- Vereisten voor de minimale versie van PHP zijn verhoogd naar 5.6.20; plug-ins en thema's hebben nu de mogelijkheid om naamruimten en anonieme functies te gebruiken;
- 13 nieuwe iconen toegevoegd.
Daarnaast kunt u vermelden kritieke kwetsbaarheid in de WordPress-plug-in (CVE-2019-11185). Door de kwetsbaarheid kan willekeurige PHP-code op de server worden uitgevoerd. De plug-in wordt op meer dan 27 sites gebruikt om een interactieve chat met een bezoeker te organiseren, onder meer op de sites van bedrijven als IKEA, Adobe, Huawei, PayPal, Tele2 en McDonald's (Live Chat wordt vaak gebruikt om vervelende pop-ups te implementeren chats op bedrijfssites met aanbiedingen (chat met de medewerker).
Het probleem manifesteert zich in de code voor het uploaden van bestanden naar de server en stelt u in staat de controle op geldige bestandstypen te omzeilen en een PHP-script naar de server te uploaden en dit vervolgens rechtstreeks via internet uit te voeren. Interessant is dat vorig jaar al een soortgelijke kwetsbaarheid werd geïdentificeerd in Live Chat (CVE-2018-12426), waardoor PHP-code kon worden geladen onder het mom van een afbeelding, waarbij een ander inhoudstype werd gespecificeerd in het veld Content-type. Als onderdeel van de oplossing zijn er extra controles toegevoegd voor witte lijsten en MIME-inhoudstypes. Het blijkt dat deze controles verkeerd worden uitgevoerd en gemakkelijk kunnen worden omzeild.
Met name het direct uploaden van bestanden met de extensie “.php” is verboden, maar de extensie “.phtml”, die op veel servers aan de PHP-interpreter is gekoppeld, werd niet aan de zwarte lijst toegevoegd. De witte lijst staat alleen het uploaden van afbeeldingen toe, maar u kunt dit omzeilen door een dubbele extensie op te geven, bijvoorbeeld “.gif.phtml”. Om de MIME-typecontrole aan het begin van het bestand te omzeilen, voordat de tag met PHP-code werd geopend, volstond het om de regel “GIF89a” op te geven.
Bron: opennet.ru