In het ATT&CK-framework van MITRE is privilege-escalatie een tactiek op zich: de aanvaller probeert rechten van een hoger niveau te krijgen door zwakke plekken in het systeem, verkeerde configuraties of kwetsbaarheden te benutten. De CWE-catalogus plaatst de meest voorkomende oorzaak onder "onjuist beheer van rechten": de software kent de rechten van een gebruiker niet goed toe, houdt ze niet goed bij of controleert ze niet goed. Op een WordPress-site is het een van de gevaarlijkste soorten lekken, want ze maakt van een simpel registratieformulier een beheerderstoegang.
Verticale en horizontale escalatie
Er zijn twee richtingen. Verticale escalatie levert een hogere rol op: een anonieme bezoeker wordt beheerder, een abonnee wijzigt de instellingen. Horizontale escalatie blijft op hetzelfde niveau maar doorbreekt de grens tussen gebruikers: een klant leest de bestellingen van een andere klant. Die tweede vorm loopt vaak via een IDOR-lek, waarbij je alleen een ID in het verzoek hoeft te veranderen.
Voorbeelden in WordPress
- Ultimate Member, CVE-2023-3460: vóór versie 2.6.7 verhinderde de plugin niet dat bezoekers accounts met willekeurige capabilities aanmaakten, dus beheerders. Het lek werd al misbruikt toen het werd gepubliceerd. Het volledige verhaal beschrijft de controles die je achteraf moet doen.
- LiteSpeed Cache, CVE-2024-28000: een onjuiste toekenning van rechten, zonder authenticatie, tot en met versie 6.3.0.1, met een score van 9,8 op de CVSS-schaal. De drie LiteSpeed Cache-lekken uit 2024 laten zien hoe een functie om een gebruiker te simuleren een toegangspoort werd.
Voor WordPress: als ontwikkelaar
Elke gevoelige actie moet een capability controleren met current_user_can(), op het moment van de actie, en niet alleen een knop in de interface verbergen. De officiële documentatie raadt af om op een rolnaam te testen, omdat het resultaat onbetrouwbaar kan zijn: je controleert de capability die echt nodig is, en voor specifieke inhoud geef je het ID mee.
if ( ! current_user_can( 'edit_post', $post_id ) ) {
wp_die( 'Actie niet toegestaan.', 403 );
}Routes van de REST API moeten een permission_callback opgeven: sinds WordPress 5.5 geeft het ontbreken ervan een waarschuwing, en __return_true is alleen acceptabel voor een route die echt openbaar is. Tot slot beschermt een nonce tegen vervalste verzoeken, maar zoals de documentatie benadrukt mag die nooit op zichzelf als autorisatie dienen.
Voor WordPress: als beheerder
- Vink in Instellingen, Algemeen "Iedereen kan zich registreren" alleen aan als de site dat nodig heeft, en houd Abonnee als standaardrol.
- Pas het principe van minimale rechten op rollen en capabilities toe: een redacteur hoeft geen beheerder te zijn, een bureau buiten de opdrachten ook niet.
- Werk plugins die accounts, registraties of rollen beheren met voorrang bij.
- Controleer regelmatig de lijst met beheerders, bijvoorbeeld met
wp user list --role=administrator.
Een geslaagde escalatie laat bijna altijd een spoor na: een aangemaakt account of een gewijzigde rol. Het activiteitenlogboek van WP Masquerade Pro registreert die gebeurtenissen met datum, wat helpt om een onverwachte beheerder op te merken; het houdt het misbruik van het lek zelf niet tegen, dat blijft een zaak van updates en een firewall.