contentmanagementsysteem . De release is opmerkelijk vanwege de voltooiing betreffende de implementatie van de controle van updates en aanvullingen met digitale handtekening.
Tot nu toe was vertrouwen in de infrastructuur en servers van WordPress de belangrijkste factor voor beveiliging bij het installeren van updates (na het downloaden werd de hash gecontroleerd zonder verificatie van de bron). In het geval van een compromittering van de servers van het project zouden aanvallers de mogelijkheid hebben om updates te vervalsen en kwaadaardige code te verspreiden onder websites die gebruikmaken van WordPress' automatische updates. Volgens het eerder toegepaste vertrouwensmodel voor levering zou een dergelijke vervalsing onopgemerkt zijn gebleven aan de gebruikerszijde.
Gezien het feit dat volgens het project w3techs WordPress platform op 33,8% van de websites op het internet wordt gebruikt, zou zo'n incident catastrofale proporties aannemen. Bovendien was het gevaar van compromittering van de infrastructuur niet hypothetisch, maar zeer reƫel. Bijvoorbeeld, een paar jaar geleden ontdekte een van de beveiligingsonderzoekers een kwetsbaarheid die het een aanvaller mogelijk maakte om code uit te voeren aan de serverzijde api.wordpress.org.
Bij gebruik van digitale handtekeningen zou het verkrijgen van controle over de server voor distributie van updates niet leiden tot compromittering van gebruikerssystemen, aangezien voor een aanval ook de apart opgeslagen privƩsleutel nodig zou zijn, waarmee de updates worden ondertekend.
De implementatie van broncontroles van updates met digitale handtekeningen werd bemoeilijkt doordat de ondersteuning voor de vereiste cryptografische algoritmen relatief recent in PHP is opgenomen. De noodzakelijke cryptografische algoritmen kwamen beschikbaar door de integratie van de bibliotheek in de kern . Maar als de minimaal ondersteunde versie in WordPress release 5.2.4 (vanaf WordPress 5.2 ā 5.6.20). De toevoeging van ondersteuning voor digitale handtekeningen zou leiden tot een aanzienlijke verhoging van de eisen voor de minimaal ondersteunde versie van PHP of de toevoeging van een externe afhankelijkheid, iets wat de ontwikkelaars niet konden doen gezien de verspreiding van PHP-versies in hostingomgevingen.
De oplossing was en de opname in WordPress 5.2 van een compacte versie van Libsodium ā , waarin een minimale set algoritmen is geĆÆmplementeerd in PHP voor het controleren van digitale handtekeningen. De implementatie laat te wensen over wat betreft prestaties, maar lost het compatibiliteitsprobleem volledig op en stelt plugin-ontwikkelaars in staat moderne cryptografische algoritmen te integreren.
Voor het genereren van digitale handtekeningen wordt het algoritme , ontwikkeld met medewerking van Daniel Bernstein. De digitale handtekening wordt gegenereerd voor de SHA384-hash van de inhoud van het archief met de update. Ed25519 biedt een hoger veiligheidsniveau dan ECDSA en DSA, en vertoont een zeer hoge snelheid bij het verifiƫren en aanmaken van handtekeningen. De breekbaarheid van Ed25519 is ongeveer 2^128 (gemiddeld zijn voor een aanval op Ed25519 ongeveer 2^140 bit-bewerkingen nodig), wat overeenkomt met de breekbaarheid van algoritmen zoals NIST P-256 en RSA met een sleutelgrootte van 3000 bit of een 128-bits blokversleuteling. Ed25519 is ook niet gevoelig voor problemen met hashes met botsingen, is ongevoelig voor aanvallen via cache-timing en vooraanvaltechnieken.
In de release van WordPress 5.2 dekt de controle van digitale handtekeningen alleen de belangrijkste platformupdates en leidt deze standaard niet tot een blokkering van de update, maar informeert de gebruiker over een opgetreden probleem. Vanwege de noodzaak van volledige controle en omzeiling is besloten de blokkering standaard niet in te schakelen. In de toekomst is het ook gepland om de controle via digitale handtekeningen toe te voegen voor de verificatie van de bron van installatie van thema's en plugins (producenten kunnen hun releases met hun sleutel ondertekenen).
Naast de ondersteuning van digitale handtekeningen in WordPress 5.2 zijn er ook de volgende wijzigingen:
- In de sectie 'Site Health' zijn twee nieuwe pagina's toegevoegd voor het debuggen van typische installatieproblemen, en er is een formulier beschikbaar gemaakt waarmee ontwikkelaars debug-informatie kunnen achterlaten voor sitebeheerders.
- De implementatie van het 'witte scherm van de dood' is toegevoegd, dat wordt weergegeven in geval van fatale problemen en de beheerder helpt om problemen gerelateerd aan plugins of thema's zelf op te lossen door in een speciale herstelmodus na een fout te gaan.
- Een systeem voor compatibiliteitscontrole met plug-ins is geĆÆmplementeerd, dat automatisch controleert of een plug-in kan worden gebruikt in de huidige configuratie met inachtneming van de toegepast versie van PHP. Als de plug-in een nieuwere versie van PHP vereist, blokkeert het systeem automatisch het inschakelen van deze plug-in;
- Ondersteuning voor het inschakelen van modules met JavaScript-code is toegevoegd met behulp van en ;
- Een nieuwe sjabloon privacy-policy.php is toegevoegd, waarmee de inhoud van de pagina met privacyvoorwaarden kan worden ingesteld;
- Voor de thema's is een wp_body_open-hook handler toegevoegd, waarmee code direct na de body-tag kan worden ingevoegd;
- De vereisten voor de minimale PHP-versie zijn verhoogd naar 5.6.20, in plug-ins en thema's is het nu mogelijk om namespaces en anonieme functies te gebruiken;
- Er zijn 13 nieuwe pictogrammen toegevoegd.
Daarnaast kan worden vermeld kritieke kwetsbaarheid in de WordPress-plug-in (CVE-2019-11185). De kwetsbaarheid maakt het mogelijk om willekeurige PHP-code op de server uit te voeren. De plug-in wordt gebruikt op meer dan 27.000 websites voor het organiseren van interactief chat met bezoekers, waaronder op de websites van bedrijven zoals IKEA, Adobe, Huawei, PayPal, Tele2 en McDonald's (Live Chat wordt vaak gebruikt voor het implementeren van irritante pop-upchats op websites van bedrijven met de aanbieding om met een medewerker te chatten).
Het probleem doet zich voor in de code voor het uploaden van bestanden naar de server en maakt het mogelijk de controle op toegestane bestandstypen te omzeilen en een PHP-script op de server te uploaden, waarna het kan worden uitgevoerd via een directe oproep via het web. Interessant is dat er vorig jaar al een soortgelijke kwetsbaarheid in Live Chat was ontdekt (CVE-2018-12426), die het mogelijk maakte om PHP-code te uploaden onder het mom van een afbeelding door een ander content-type in het Content-type veld op te geven. Ter fixatie van het probleem zijn er aanvullende controles op witte lijsten en MIME-typen toegevoegd. Het bleek dat deze controles onjuist waren geĆÆmplementeerd en gemakkelijk konden worden omzeild.
Concreet is directe upload van bestanden met de extensie '.php' verboden, maar de extensie '.phtml' is niet aan de zwarte lijst toegevoegd, wat op veel servers verbonden is met de PHP-interpreter. De witte lijst staat alleen het uploaden van afbeeldingen toe, maar kan worden omzeild door een dubbel extensie op te geven, bijvoorbeeld '.gif.phtml'. Voor het omzeilen van de MIME-typecontrole was het voldoende om aan het begin van het bestand, voor het openen van de PHP-code-tag, de regel 'GIF89a' op te geven.
Bron: opennet.ru
