Harvesting Cross Site Scripting (XSS) Victims - Clicks, Keystrokes and Cookies - Linux
Am Thursday, 7. Jul 2011 im Topic 'Vulnerabilities'
XSS-Harvest.
It is multi-threaded pre-forking web server written in Perl, and requires no dependencies other than a couple of common Perl modules; you do not need a web server or database to use this tool. Before going into the detail, I'll list the high level functionality below:
Infection script adds relevant event listeners (keystrokes, onload() and mouse clicks) to the vulnerable page and sets up communication with the XSS-Harvest server.
Any key entered will be sent covertly to the server.
Any mouse click performed will be analysed and the data covertly sent to the server.
Optionally 'redress' the vulnerable page to display a different page on the same subdomain - e.g. a login form.
If redressing the victim's browser, allow subsequently loaded pages to be also 'infected' - assuming they don't break the same-origin policy (i.e. they're on the same subdomain).
Keeps track of victims for the lifetime of the XSS-Harvest cookie (future visits are recognised as a returning victim).
Each victim has a separate history file containing all events, cookies and keystrokes.
Server console displays real time data received (due to multi-threaded nature, keystrokes are displayed as '.' characters to avoid confusion).
Tested in IE6-9 (reflected XSS protection in IE9 will limit exploitation to stored XSS only in most cases), FF5, Chrome and various mobile browsers (Safari and Android). Please let me know your success with other browsers.
Overcomes browser oddities, such as Internet Explorer throttling requests to the same URL when exfiltrating keystrokes.
How to Exploit XSS with XSS-Harvest
Identify a page vulnerable to XSS (reflected or persistent will be fine - unless the victim is running IE9 or another plugin such as NoScript).
Understand the markup of the page. You should be looking to insert syntactically correct tags in to the source of the vulnerable page. Most attackers will insert something like 'alert(1)' at this stage to ensure the page is actually vulnerable.
Start the XSS-Harvest server as root if you wish to bind to a TCP port < 1024 (default port is 80), or as a limited user on a port > 1024 using the -p option. To start the server you must instruct it to listen with the -l option.
Insert the following 'injection string' into the vulnerable page:
This will return the client-side JavaScript to the victim, indicated by the 'i' in the URL.
Entice visitors to the infected page (or to follow a link in the case of reflected XSS).
Watch your victims roll in - a new history file will be created for each new victim.
If you wish to make use of the redress function, start the server with the -r parameter:
./xss-harvest.pl -l -r http://vulnerablepage.local/login.html
Download:
https://docs.google.com/leaf?id=0B-yhjV3y1-D2ZmVlMmUxMWUtNjJhYy00Njc5LWI0M2ItZTMwMmIxMTQ0NTNh&hl=en_GB
It is multi-threaded pre-forking web server written in Perl, and requires no dependencies other than a couple of common Perl modules; you do not need a web server or database to use this tool. Before going into the detail, I'll list the high level functionality below:
Infection script adds relevant event listeners (keystrokes, onload() and mouse clicks) to the vulnerable page and sets up communication with the XSS-Harvest server.
Any key entered will be sent covertly to the server.
Any mouse click performed will be analysed and the data covertly sent to the server.
Optionally 'redress' the vulnerable page to display a different page on the same subdomain - e.g. a login form.
If redressing the victim's browser, allow subsequently loaded pages to be also 'infected' - assuming they don't break the same-origin policy (i.e. they're on the same subdomain).
Keeps track of victims for the lifetime of the XSS-Harvest cookie (future visits are recognised as a returning victim).
Each victim has a separate history file containing all events, cookies and keystrokes.
Server console displays real time data received (due to multi-threaded nature, keystrokes are displayed as '.' characters to avoid confusion).
Tested in IE6-9 (reflected XSS protection in IE9 will limit exploitation to stored XSS only in most cases), FF5, Chrome and various mobile browsers (Safari and Android). Please let me know your success with other browsers.
Overcomes browser oddities, such as Internet Explorer throttling requests to the same URL when exfiltrating keystrokes.
How to Exploit XSS with XSS-Harvest
Identify a page vulnerable to XSS (reflected or persistent will be fine - unless the victim is running IE9 or another plugin such as NoScript).
Understand the markup of the page. You should be looking to insert syntactically correct tags in to the source of the vulnerable page. Most attackers will insert something like 'alert(1)' at this stage to ensure the page is actually vulnerable.
Start the XSS-Harvest server as root if you wish to bind to a TCP port < 1024 (default port is 80), or as a limited user on a port > 1024 using the -p option. To start the server you must instruct it to listen with the -l option.
Insert the following 'injection string' into the vulnerable page:
This will return the client-side JavaScript to the victim, indicated by the 'i' in the URL.
Entice visitors to the infected page (or to follow a link in the case of reflected XSS).
Watch your victims roll in - a new history file will be created for each new victim.
If you wish to make use of the redress function, start the server with the -r parameter:
./xss-harvest.pl -l -r http://vulnerablepage.local/login.html
Download:
https://docs.google.com/leaf?id=0B-yhjV3y1-D2ZmVlMmUxMWUtNjJhYy00Njc5LWI0M2ItZTMwMmIxMTQ0NTNh&hl=en_GB
