WordPress Plugin Survey & Poll 1.5.7.3 — ‘sss_params’ SQL Injection

This is a guide that validates the WordPress vulnerability EDB-ID:45411. This vulnerability specifically exploits a fault in the code for a plugin that adds a survey/poll, which allows for SQL injection via editing the cookie. This write-up features the following sections:

1: Overview of the vulnerability

2: How to set up the application

3: How to exploit the vulnerable code

4: Analysis of how it works

5: Final thoughts

EDB-ID: 45411

Description:

The vulnerability allows an attacker to inject SQL commands by editing the value of a cookie parameter when a target has the Plugin Survey & Poll version 1.5.7.3 or earlier.

Basically, using a cookie editor extension for Firefox, you can replace a cookie with a different value which then executes an SQL injection. After that, by looking in the source code you can see the result of the attack and extract data that users are not normally able to see, like the version number of MySQL, the hostname of the machine being used, and more.

Setup:

Installing XAMPP and WordPress:

To verify this vulnerability, I installed WordPress and hosted it using XAMPP on my Kali Linux VM (version 2020.4), however this can be done on any operating system. To install XAMPP I followed the official guide found here. If you want to install XAMPP on Windows, a guide can be found here. After that is complete, you can then install WordPress for your Linux or Windows.

Requirements:

In order to exploit this properly, you need to have a cookie editor extension for your browser. The target needs to be using the proper WordPress Plugin, which in this case is Survey & Poll Version 1.5.7.3 or earlier. Once you are set up and you have your target, it is time to exploit the vulnerable code.

Exploitation:

The payload I used to exploit this vulnerability can be found on exploit-db. From there it is also possible to download the specific vulnerable plugin that you can place into WordPress, as well as the payload.

After that is all set up, you need to set up a simple poll in order to exploit it. In this example I asked:

Well, yes, it obviously is cool, so lets choose that. Here is where the exploit happens. After voting on a survey or poll using this plugin, there is a cookie created called wp_sap that is not secured very well. Using your cookie editor extension, you can change its default value to something handcrafted to give you information that you are otherwise not supposed to see. In this example I set up the script to show me the location of the database files.

After you change the cookie and save it, refresh the page, and vote again on the poll. Then instead of the usual message that says “Thank you for your feedback!”, it displays the result of the injected code, as seen here:

Explanation:

So let’s dig into this SQL injection a little bit to really understand how this works. The SQL injection in full is:

[“1650149780')) OR 1=2 UNION ALL SELECT 1,2,3,4,5,6,7,8,9,@@datadir,11#”]

The first section of the code with the numbers is mainly just a normal data string in order to let the plugin accept the cookie as normal input. Then it uses “ ')) ” as an escape character so that it will inject the following portion into the code. OR 1=2 is a logic statement that forces a false flag which will give the proper result, as when the string is 1=1, it will just put forward the first result instead of the modified one. The UNION ALL command combines the set of results that are returned from two or more SELECT statements, without getting rid of duplicate information. This allows us to see the result of our query in the response or source code. The SELECT statement that follows pulls out information from rows of data 1 through 11, with spot 10 being replaced with our custom parameter. When tinkering with the injection, I did find that all these numbers were indeed required to have it all function as intended.

Here are some other possible injection parameters that you can use instead of using @@datadir:

@@hostname : Current Hostname

@@tmpdir : Temp Directory

@@version : Version of DB

@@basedir : Base Directory

user() : Current User

database() : Current Database

version() : Version

schema() : current Database

UUID() : System UUID key

current_user() : Current User

current_user : Current User

system_user() : Current System user

session_user() : Session user

@@GLOBAL.have_symlink : Check if Symlink Enabled or Disabled

@@GLOBAL.have_ssl : Check if it have ssl or not

Final Thoughts:

This vulnerability, although not particularly dangerous on its own, can be made very powerful if it is used alongside other methods of attack. You can find out a lot of information about a machine using this exploit, and using a program like Metasploit, it may even be possible to gain a reverse shell on the system hosting the WordPress page.

To remedy this problem, it is as simple as making sure your webpages and databases are up to date and properly secured. There are many ways to secure your website against SQL injection, like validating user inputs and only allowing the characters needed in a certain field (like allowing only @ and . in a email field). This alone is a pretty tame vulnerability, but combined with others, becomes a trove of valuable information which can be used for numerous attacks.

Stay safe and secure out there,

Clayton Van Dyke