Penetration Testing with Kali Linux OffSec

Figure 114: Demonstrating the XSS vulnerability 
Excellent. We have injected an XSS payload into the web application’s database and it will be 
served to any administrator that loads the plugin. A simple alert window is a somewhat trivial 
example of what can be done with XSS, so let’s try something more interesting, like creating a 
new administrative account. 
8.4.5
Privilege Escalation via XSS 
Since we are now capable of storing JavaScript code inside the target WordPress application and 
having it executed by the admin user when loading the page, we’re ready to get more creative and 
explore different avenues for obtaining administrative privileges. 
We could leverage our XSS to steal 
cookies
372
and session information if the application uses an 
insecure session management configuration. If we can steal an authenticated user’s cookie, we 
could masquerade as that user within the target web site. 
Websites use cookies to track 
state
373
and information about users. Cookies can be set with 
several optional flags, including two that are particularly interesting to us as penetration testers: 
Secure
and 
HttpOnly
. 
The Secure
374
flag instructs the browser to only send the cookie over encrypted connections, 
such as HTTPS. This protects the cookie from being sent in clear text and captured over the 
network. 
The HttpOnly
375
flag instructs the browser to deny JavaScript access to the cookie. If this flag is 
not set, we can use an XSS payload to steal the cookie. 
Let’s verify the nature of WordPress’ session cookies by first logging in as the 
admin
user. 
Next, we can open the Web Developer Tools, navigate to the 
Storage
tab, then click on 
http://offsecwp
under the 
Cookies
menu on the left. 
Figure 115: Inspecting WordPress Cookies 
We notice that our browser has stored six different cookies, but only four are session cookies. Of 
these four cookies, if we exclude the negligible 
wordpress_test_cookie
, all support the HttpOnly 
feature. 
Since all the session cookies can be sent only via HTTP, unfortunately, they also cannot be 
retrieved via JavaScript through our attack vector. We’ll need to find a new angle. 
372
(Wikipedia, 2022), https://en.wikipedia.org/wiki/HTTP_cookie 
373
(Wikipedia, 2022), https://en.wikipedia.org/wiki/Session_(computer_science) 
374
(Wikipedia, 2022), https://en.wikipedia.org/wiki/Secure_cookie 
375
(Mozilla, 2022), https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Secure_and_HttpOnly_cookies 

---

Penetration Testing with Kali Linux
PWK - Copyright © 2023 OffSec Services Limited. All rights reserved. 
241 
When the admin loads the Visitors plugin dashboards that contains the injected JavaScript, it 
executes whatever we provided as a payload, be it an alert pop-up banner or a more complex 
JavaScript function. 
For instance, we could craft a JavaScript function that adds another WordPress administrative 
account, so that once the real administrator executes our injected code, the function will execute 
behind the scenes. 
In order to succeed with our attack angle, we need to cover another web application attack class. 
To develop this attack, we’ll build a similar scenario as depicted by Shift8.
376
First, we’ll create a 
JS function that fetches the WordPress admin 
nonce
.
377
The nonce is a server-generated token that is included in each HTTP request to add randomness 
and prevent 
Cross-Site-Request-Forgery
(CSRF)
378
attacks. 
A CSRF attack occurs via social engineering in which the victim clicks on a malicious link that 
performs a preconfigured action on behalf of the user. 
The malicious link could be disguised by an apparently-harmless description, often luring the 
victim to click on it. 
Check out 
these awesome cat memes! 
Listing 123 - CSRF example attack 
In the above example, the URL link is pointing to a Fake Crypto Bank website API, which performs 
a bitcoin transfer to the attacker account. If this link was embedded into the HTML code of an 
email, the user would be only able to see the link description, but not the actual HTTP resource it 
is pointing to. This attack would be successful if the user is already logged in with a valid session 
on the same website. 
In our case, by including and checking the pseudo-random nonce, WordPress prevents this kind 
of attack, since an attacker could not have prior knowledge of the token. However, as we’ll soon 
explain, the nonce won’t be an obstacle for the stored XSS vulnerability we discovered in the 
plugin. 
As mentioned, in order to perform any administrative action, we need to first gather the nonce. 
We can accomplish this using the following JavaScript function: 
var ajaxRequest = new XMLHttpRequest(); 
var requestURL = "/wp-admin/user-new.php"; 
var nonceRegex =