In drie populaire plugins voor het contentmanagementsysteem WordPress, met meer dan 400.000 installaties, :
- in de plug-in , dat meer dan 300.000 actieve installaties heeft, maakt het mogelijk om zonder authenticatie als sitebeheerder in te loggen. Aangezien de plugin bedoeld is voor het centraliseren van het beheer van meerdere sites op een server, kan een aanvaller de controle over alle sites verkrijgen die worden beheerd met InfiniteWP Client. Voor de aanval is het voldoende om de gebruikersnaam van een gebruiker met beheerdersrechten te kennen, waarna men door het verzenden van een speciaal geconfigureerde POST-aanroep ( opgeven van de parameter "add_site" of "readd_site") kan inloggen op de beheerdersinterface met de rechten van deze gebruiker. De kwetsbaarheid wordt veroorzaakt door een fout in de implementatie van de automatische inlogfunctie.
Probleem in release InfiniteWP Client 1.9.4.5. - in de plug-in , dat op ongeveer 80.000 sites wordt gebruikt. De eerste kwetsbaarheid maakt het mogelijk om zonder authenticatie de inhoud van alle tabellen in de database terug te zetten naar de standaardstatus (door deze naar een verse installatie van WordPress te resetten, waarbij gerelateerde sitegegevens worden verwijderd). Het probleem wordt veroorzaakt door het ontbreken van een machtigingscontrole bij het uitvoeren van de resetfunctie.
De tweede kwetsbaarheid in WP Database Reset vereist dat een gebruiker is ingelogd (het is voldoende om een account met minimaal de rechten van een abonnee te hebben) en stelt in staat om beheerdersrechten voor de site te verkrijgen (het is mogelijk om alle gebruikers uit de wp_users-tabel te verwijderen, waarna de huidige overgebleven gebruiker als beheerder wordt behandeld). De problemen zijn opgelost in release 3.15.
- in de plug-in , met meer dan 20.000 installaties, maakt het mogelijk om als beheerder zonder authenticatie in te loggen. Voor de aanval is het voldoende om de string IWP_JSON_PREFIX aan de POST-aanroep toe te voegen, waarna zonder enige controle de functie wptc_login_as_admin wordt aangeroepen. Het probleem is opgelost in release 1.21.16.
Bron: opennet.ru
