XSS Rootkit [complete revision]

XSS Rootkit [complete revision]

0 × 00 Preface

As we all know, the risk definitions of XSS vulnerabilities have been vague, and cross-site scripting (XSS) vulnerabilities are both high-risk and low-risk vulnerabilities that have been controversial for a long time. There are two types of XSS vulnerabilities: persistent and non-persistent:

1. The non-persistent XSS vulnerability is generally found in URL parameters. You need to access a specific URL constructed by a hacker to trigger the vulnerability.

2. The persistent XSS vulnerability usually exists in rich text and other interactive functions, such as posting and leaving messages. Hackers can use the XSS content to access the database for persistent storage through normal functions.

3. dom xss vulnerabilities can also be classified into persistent and non-persistent types. They are mostly caused by obtaining the address bar, referer, or encoding the specified HTML Tag content through the javascript DOM interface.

Generally, persistent XSS vulnerabilities have a higher level of risk than non-persistent XSS vulnerabilities. In essence, this is true. However, the use of vulnerabilities still requires scenarios, sometimes, when we look at the scenario more deeply, we can find unexpected things.

0 × 01 vulnerability Scenario Analysis

First, I will provide a simple PHP paging XSS vulnerability code:

Demo. php ――――――――――――――――――――-

<? Php

Foreach (Array ('_ get',' _ Post', '_ cookie') as $ _ request)

{

Foreach ($ _ request as $ _ k = >$ _ v) $ {$ _ k} = $ _ v;

}

?>

 

In the DEDECMS core code, the order of simulating the global variable registration mechanism is GPC, that is, C can overwrite the variables registered by GP.

We can use the code 0x02 for testing to persistently Save the gotopage variable in the cookie. If the Administrator triggers our XSS vulnerability, We can persistently Save the gotopage variable in the cookie of the Administrator, change the hidden form value of gotopage to any script content. In the future, as long as the administrator accesses the background page, the XSS vulnerability will be triggered. We can hijack the Administrator's entire login process, the Administrator's password can be obtained without sound information.

Of course, the flexible use of DEDECMS is more dependent on the divergent thinking of hackers. For example, IE8/9 can intercept url xss, we can use a persistent XSS or dom xss as the payload for this type of XSS Rootkit vulnerability. In addition, the cookie setting is not limited to the same-origin policy, and the cookie set in any subdomain name, this cookie can be accepted by the entire Domain Name application. Hackers can break away from the restrictions of the DEDECMS program and attack the background of DEDECMS on the weak points of the entire website architecture.

0 × 04 in-depth XSS Rootkit scenarios

In the scenario of PHP global variable registration mechanism, adjusting the order of GPC registration variables can reduce the XSS Rootkit attack effect, such as the discuz program:

Foreach (array ('_ cookies',' _ Post', '_ get') as $ _ request ){

Foreach ($ _ request as $ _ key => $ _ value ){

$ _ Key {0 }! = '_' & $ _ Key = daddslashes ($ _ value );

}

}

The order of variables to be registered is the central sign ("). Our C can never overwrite the variables registered by GP. However, a certain process of the program causes the variables to not be initialized and still generate the XSS Rootkit effect, as shown in figure

Http://xx.163.com/logging.php? Action = logout & referer = alert () & formhash = rootkit <

/Div>

An XSS vulnerability exists in the exit code of the DISCUZ program. If the user does not log on, the referer variable in the exit code is not initialized, so that we can control the variable at will.

In this case, we do not have to worry about the registration order of the central node (BMP), but we need to construct a specific URL to trigger the XSS vulnerability only when the variable is not initialized, in this way, the effect of XSS Rootkit attacks is greatly reduced. Normal exit operations after login cannot trigger our XSS vulnerabilities, which is out of the XSS Rookit advantage.

Another scenario is the misuse of request variables. In different scripts and server environments, the effects of request variables may be different, for example, asp/asp is mentioned in my previous several methods to bypass WAF.. net and other request variables have the complex parameter feature. Therefore, all the content of gpc can enter the registration variable at the same time, and the XSS Rootkit vulnerability may also occur.

There is also a special case of dom xss. A member of 80sec was found a few years ago that the user ID in the COOKIE read from the homepage of a large website is not HTML encoded on the webpage, if an XSS vulnerability occurs, you can install XSS Rookit on the home page.

Of course, there are more scenarios. I have mentioned the rootkit in the web application in Jianxin, And I have explained the XSS Rootkit scenario here, more scenarios leave us with divergent thinking.

0 × 05

So far, we have completed a transformation from a non-persistent XSS vulnerability to an XSS Rootkit, and once again revealed how important the vulnerability scenario is. It is wonderful to dig deep into the vulnerability scenario to complete an essential sublimation.

Programmers need to pay attention to every detail of program security. Any inconspicuous vulnerability may cause unexpected harm.

Some web vulnerability scanner reports indicate that non-persistent XSS vulnerabilities are marked as high-risk vulnerabilities and are generally controversial. You can refer to this article and further explore the scenarios to define risks, so the most important purpose of this article is achieved.