Hacking into WordPress Using a Vulnerable Plug-in
Last updated on: September 7, 2020
WordPress is currently the most popular blogging system in use on the Web, powering over 60 million websites worldwide. There are over 15,000 WordPress plug-ins that extend the functionality of WordPress. But these plug-ins also add numerous security risks making the website vulnerable to attacks. Although core WordPress vulnerabilities exist and may be more challenging to find, most WordPress attacks these days are results of plug-in vulnerabilities followed by default passwords and obsolete software.
Recently, I started exploring various WordPress plug-ins to test if installing a plug-in made the site more vulnerable, and to determine how big of a concern the security of the plug-in was. I started with a few of the popular and top-rated plug-ins. During that exercise, I discovered an HTML Code and Script Injection Vulnerability in the WP Photo Album Plus plug-in.
The vulnerability in WP Photo Album Plus Plugin was reported to the vendor and the plugin developer fixed it very promptly. It has been patched in WP Photo Album Plus Version 5.0.11 which was released today.
Even script kiddies don’t get excited by script injections these days, so I was curious to find out if a plug-in vulnerability could lead to something substantial. Let’s take a look to see how much damage a WordPress plug-in vulnerability could cause.
Plug-in and the Discovered Vulnerability
“wppa-album-admin-autosave.php” in WordPress plug-in WP Photo Album Plus Version 5.0.10 and earlier does not properly sanitize the "edit_id" parameter allowing for HTML Code Injection and cross-site scripting (XSS). See Figures 1 and 2.
Figure 1: XSS in WP Photo Album Plus plug-in
Figure 2: HTML Code Injection in WP Photo Album Plus plug-in
Meh…It’s just client-side script injection
Since script injection and XSS vulnerabilities no longer arouse significant interest, let’s take a look at the impact this simple plug-in vulnerability can cause and how an attacker may use this to cause havoc. A lot of freely available tools can be leveraged for this. Since the vulnerability in the plug-in makes the website vulnerable to the attack, let’s use BeEF (Browser Exploitation Framework) to demonstrate the real-time impact of XSS and code injection browser vulnerabilities.
Creating a BeEF hook is trivial – All you need to do is inject the following script into the vulnerable site.
In our case, this is through the parameter “edit_id” which is vulnerable to script injection in the WP Photo Album Plus plug-in. Once a browser has been hooked, there are a number of possibilities to explore – from browser exploitation to keystroke logging to tracking credentials!
A couple of screenshots have been shown below to demonstrate the possibilities of what can be achieved using BeEF. The first example allows an attacker to execute a command prompt dialog on the victim’s hooked brower (Figure 3a – Attacker Screen, Figure 3b – Victim Screen). The second example shows how an attacker could conduct phishing attacks (Figure 4a – Victim prompted to enter Facebook credentials) and trick the user into revealing their credentials. Figure 4b shows the Attacker screen with the credentials entered by a victim.
Figure 3a: Creating Prompt Dialog Using BeEF (Attacker)
Figure 3b: Creating Prompt Dialog Using BeEF (Victim)
Figure 4a: Facebook Credentials Please! (Victim Screen)
Figure 4b: Facebook Credentials appear to Attacker
Administrative Access to WordPress – A Possibility!
One might think that all of the above requires the user to be naive and be tricked into entering details. Let’s see if we can leverage information that has been stored prior to hooking the browser (a.ka. Cookies and Passwords). A lot of users do tend to store credentials in the browser for ease. Yes, ‘Remember Password’ is one of the convenience features of the browser that we’ve all used at some point. If that is the case, those credentials can be easily retrieved using a tool like BeEF. If the WordPress user has stored his/her administrative credentials to avoid typing it every time, the attacker is in for a treat. On executing ‘Get Stored Credentials’ module available in BeEF, the command results show that the password for WordPress user ‘admin’ is ‘abc1234’ (See Figure 5). And voila, we have administrative access to WordPress. Once you have administrative access, the possibilities are infinite.
Figure 5: Administrative Credentials to WordPress retrieved via BeEF.
WordPress has another “interesting feature” that is probably by design and hence not treated as a security issue. The "wp-comments-post.php" allows certain user roles to post ‘unfiltered_html’. Users having “Administrator” and “Author” roles are allowed to post HTML code which is not filtered by the WordPress application before being rendered to the user. Using the credentials obtained earlier (via Figure 5), an attacker could create a legitimate user with privileges on the affected WordPress site and continue exploiting more targets.