Today I was playing around with the well known password cracking tool John the Ripper (JtR) and was looking forward to crack some MD5 hashes. Unfortunately, John still not supports raw-MD5 out of the box and so I was searching the web for a solution. It took me some minutes until I found out, that there are unofficial patches for John’s source code and so I simply patched it and tried to compile. For any reason, I run into problems (doesn’t matter now what problems ) and even after about half an hour searching the web for a solution I didn’t find anything. Then a few minutes later I found a simple howto for how to patch and compile John so that you won’t have any problems. The site which solved my problem was gurx.net and I couldn’t find it faster because it’s not written in English nor German. Now of course I’ll show you how to do it the gurx.net-way but with support for even many more algorithms than just MD5.

mkdir john
cd john
wget http://www.openwall.com/john/f/john-1.7.2.tar.bz2
tar -xvf john-1.7.2.tar
cd john-1.7.2
wget ftp://ftp.openwall.com/pub/projects/john/contrib/john-1.7.2-all-9.diff.gz
gzip -d john-1.7.2-all-9.diff.gz
patch -p1 < john-1.7.2-all-9.diff.gz
cd src
make
make clean linux-x86-any

Now you can use John out of the “run” directory.

./john -format=raw-MD5 /home/disenchant/md5_hashes_to_crack.txt

raw-MD5 means that you’ve got an input file (/home/disenchant/md5_hashes_to_crack.txt) like the following:

Alice:5f4dcc3b5aa765d61d8327deb882cf99
Bob:1c0b76fce779f78f51be339c49445c49
…

PS: My machine’s a Xubuntu Edgy but this should work with any Linux box

Because of the sister of a friend needed to download videos of spiegel.de for school, I searched for a possibility to do that. It took just a few minutes (or even seconds) to find what I was looking for by analyzing the HTTP traffic, sent to the server by the Movie-Player of SPIEGEL ONLINE, which is completely in Flash. This showed me once again that I can’t just destroy stuff with my knowledge, I can also help people. Because someone else could also be interested in how to do this and it’s more or less the same thing everywhere you’ve got a similar situation on the web, I’ve created a small video HowTo.

Download/Watch HowTo (830 kB)

You’ll find the movies at http://www.spiegel.de/videos, the Firefox extension I’m using is Firebug and of course at the end you see Wget and VLC.

What is it about?
This blog posting describes a way on how you can patch security problems and real vulnerabilities in your PHP code, when you’re not allowed to change the code or for example if this is just not possible for any reason. What you’ll learn here is something like virtual patching, as we know it from web application firewalls but we don’t change the code of the already existing application in any way and we don’t even need new components like such an application firewall. Does this this sounds like black magic to you? Don’t worry, it’s not complicated at all

What is it not about?
This blog posting will not show you for example how to fix all vulnerabilities you can expect in your PHP code nor is the described technique working against every kind of security problem. If you have the possibility to change the existing code, this is for sure the way to go and not what I’m writing in this posting. This is really only a technique which you can use when you can’t change the existing code.

Please also be aware, that I don’t give you any guarantee, that your PHP web applications are secure after you’ve done what’s written in this posting.

Skills you need
I tried to write everything as clear as possible but it’s good if you’ve got some basic knowledge of the PHP programming language because I won’t describe my simple code examples.

So let’s start with the main content

The php.ini
First we should talk about the so called php.ini, which will be our interface between the fixes and the already existing source code. The php.ini is the configuration file for PHP and you can see it’s actual configuration by simply have a look at the file or by creating a PHP script like the following:

<?php
phpinfo();
?>

Get your own php.ini on shared Servers
(If you’ve got your own dedicated server, this might not be relevant to you)
This subsection now shows you, how you can work with the php.ini even if you’re application is hosted on a shared server and you don’t have access to the main php.ini file. As a first step, you have to create a file with the name .htaccess, which means that it’s a htaccess file. Under Unix like systems this is not a problem at all but under Windows systems you’ll get an error when you try to rename a file to “.htaccess”, so with the following two steps, you can also create such a file under Windows:

1. Open Notepad or any other text editor.
2. Go to Save As, and chose “.htaccess” for the file name including the quotes.

Now you can upload the file into your wwwroot directory and add the following line to the .htaccess file, when your php.ini file can be found at /home/disenchant/php.ini:

suPHP_ConfigPath /home/disenchant

Now, the new defined php.ini will be used instead of the one, your web hoster has set up globally.

The auto_prepend_file Option
So let’s go into the part of the php.ini which is interesting for us, it’s the auto_prepend_file option. Just add a line to your php.ini like the following, so that it points for example to the PHP file we made before to display the PHP info page or just create a smaller file with just <?= "test" ?> in it.

auto_prepend_file = /abc/xyz.php

As you can see, if you now have a look at any of your PHP scripts in your web browser, the auto_prepend_file option in our php.ini has included our script at the beginning of every file. This is exactly what we need because this way, we can interact with the existing code, even if we never changed something in the original source code. So let’s go on and fix some vulnerable code.

The vulnerable Code
First we need some vulnerable PHP. The following code is vulnerable to an attack type called “Cross-Site Scripting“.

<?php
echo $_GET['var'];
?>

We have now to implement an input encoding functionality for the variable called var (of course this can also be done for all variables or just some pre-defined variables). Let’s have a look at how to write a simple patch for this vulnerability.

The Patch
If we can change the original source code, we would probably use something like the following:

<?php
echo htmlentities($_GET['var'], ENT_QUOTES);
?>

This will replace (all) characters which can be dangerous or better say, can be used for executing malicious script code, with their equivalent HTML entity. This makes this piece of code secure but in our situation, we won’t be able to change the code and that’s why we need the technique I described in this posting, over the php.ini. Instead of modifying the existing source code, we create a new file like this:

<?php
$_GET['var'] = htmlentities($_GET['var'], ENT_QUOTES);
?>

Because of the auto_prepend_file option we set in our php.ini, this code will fix our vulnerability

Final words
As you’ve seen, this technique can become very helpful under some circumstances and of course I showed you just the basic use of it and you can go much further and for example implement login stuff, session management, white listings and so on through this.

Long time ago I said, that we’ll run into the same security problems we already started to fix in our web applications at the point, where we start using AJAX aka. Web 2.0 stuff. For example XSS is well known in the web development since a while and many developer try to avoid such vulnerabilities in their code which could be PHP, JSP, ASP or even others. Now they are confronted with AJAX and everyone should implement it in new and even already existing applications. The problem is now, that the developers aren’t aware of the security risks of sending HTTP requests from a script to their application. To say it more clearly, many developers aren’t aware of the fact, that all the data which will be transfered by Javascript are visible and can be modified by everyone. This means, that everyone can manipulate the requests, which will be sent to your application, even if the target for the requests isn’t thought to be accessible by users. Of course this is always the case but it’s not as clear as in old school web application development.

I was ill today and so I thought that it would be time to give a proof on what I said long time ago and so I was looking for a target. Because I never had a look at facebook.com anyway and it’s one of the big players in the AJAX world, it was a good place for make the final test of my assertion.

First I was checking some input fields with basic XSS test but not the crazy decoded stuff or something similar. Of course I found no vulnerabilities this way Then I started analyzing the Javascript stuff aka. AJAX. It took me just about 2 minutes to find the first XSS hole and in the next 5 minutes I found even more. At this point I’ve stopped with my test because this was the proof to me: AJAX is Evil!

For those of you who would like to test it yourself, login to your facebook.com account, choose one of the following links and replace [uid] with your own uid. These links show four non-persistent (reflected) XSS which aren’t that dangerous on the first view but it shows that using AJAX can lead to new security holes in an application.

XSS 1
XSS 2
XSS 3 (no uid of target needed, just login)
XSS 4

PS: If AJAX is Evil (it is!), why is Google using it anyway?

A few days ago, I’ve got the following Mail (it’s in German):

Hallo,
das warst doch du, der unser Sprachportal (MobiLingua, Uni Passau) über das Forum gehackt hat und mir damit einen gehörigen Schrecken eingejagt hat, oder?
Jedenfalls danke für den Hinweis – das ist halt der Nachteil von CMS: Man kann zwar mit relativ wenig Hintergrundwissen ein Layout anpassen und Inhalte bereitstellen, denkt aber in der Regel nicht an Sicherheitsaspekte (in der Hoffnung, dass das System das schon macht )

LG, [name of the sender]

In English this means, that someone of the University of Passau thinks, that I’ve hacked their online platform called MobiLingua. Of course I didn’t hack their page and also I never heard about this MobiLingua before. Because of this, I answered the following:

Hallo,
ich beschäftige mich zwar beruflich sowie privat mit der Sicherheit von Webanwendungen, doch habe ich noch nie von genanntem Portal (MobiLingua, Uni Passau) gehört, geschweige denn habe ich dieses angegriffen.

Ich würde mich sehr darüber freuen, wenn Sie mich so schnell als möglich darüber informieren könnten, wie Sie auf mich kommen in diesem Zusammenhang.

Freundliche Grüsse und ein schönes Wochenende,
Sven Vetsch

This means, that I just wanted to know, why they think that I have attacked their site because it’s true that I have to deal with web application security every day but why they think I’ve done something when I know, that I didn’t do anything? The next mail I get answered this question:

Hallo,
bitte entschuldigen Sie, wenn ich mit meiner Vermutung falsch lag. Jemand hatte ein Online-Portal mit einem Foreneintrag gehackt, in dem HTML und Javascript untergebracht worden war. Dies war ein nett gemeinter Hinweis, auf eine bestehende Sicherheitslücke, offensichtlich ohne böse Absichten. Jedenfalls wurde dadurch in mein Layout statt dem üblichen Logo ein “Hacked”-Logo eingebaut, bei dem die URL auf Ihre Domain verwies. Ein Blick auf die Inhalte dieser Seite hat gezeigt, dass Sie sich mit eben solchen Sicherheitslücken auseinandersetzen und ich glaubte den “Verursacher” gefunden zu haben.

Ich entschuldige mich deshalb vielmals für meinen Fehler..

Mit freundlichen Grüßen und ein schönes Wochenende,
[name of the sender]

First it was written, that they’re sorry for suspecting me and afterwards it was described, why they think that I’ve done the hack on their platform and also what happened. Someone has inserted a “Hacked”-logo through a HTML- and Javascript-Injection (today aka. XSS) and on request I get the injected code:

<script>
alert('Ihre Festplatte wird formatiert wenn Sie OK klicken. Schalten Sie Ihren Rechner aus um abzubrechen.');
document.getElementsByTagName("body")[0].style.backgroundColor = "fuchsia";
document.getElementById("site-logo").src = "http://www.disenchant.ch/blog/images/entries/hacked.gif";
document.getElementById("page").lastChild.innerHTML += '<br>Defacement: Da 3v1l H4X0rZ 2007 ;) lol';
for(i = 0; i < 50; i++){
document.getElementsByTagName("div")[i].style.backgroundColor = "fuchsia";
}
</script>

Now it was clear what happened. The image (http://www.disenchant.ch/blog/images/entries/hacked.gif) which was used for the hack or better call it now a defacement, was the one I’ve uploaded for my blog posting “owasp.org hacked“, where I wrote about someone who “hacked” the OWASP website/Wiki. When the people from the University of Passau checked the code, they found out, that the image was hosted on my domain and that I’ve got something to do with web application security. Now everything is clear and life goes on but this story really make me think of what can happen by just linking to or on the other side hosting images, even if it’s just mistake. It really shows, how easy someone can become a suspect in our so called information century.

PS: I really have to translate the alert message of the used payload to English. “Ihre Festplatte wird formatiert wenn Sie OK klicken. Schalten Sie Ihren Rechner aus um abzubrechen.” means “Your hard disk will be formatted when you click OK. Turn off your computer to cancel.”. And I thought that at least these idiots became extinct years ago

When I started to study computer science, I thought that it would cost me less time than it does now. Because of this I don’t have as much research time as expected. I know, that some people are waiting for my announced papers ans so i decided to release my paper called “Developing Firefox Extensions”, even if it’s not finished and also not reviewed. The reason for this step is, that I hadn’t time to modify the document since the 19. August 2007 and I really think that this is too long to not release any part of it.

Because I’m not sure how much time I’ve got to work on it during the next month(s) I’ll offer also the *.tex documents to everyone who would like to do further work on the paper.

To say a few words about the paper itself, it’s simply a (at the moment) 31 pages long how-to with examples on how to develop your own extensions for Mozilla Firefox and with some additional work, I think it could be also interesting for schools to use it as teaching material.

Download

I hope some of you enjoy the paper, even if it’s not finished

The topic of web application security is definitely a new topic, if we compare it for example to network security or something like cryptography but in all of this thematics, it’s important to give newcomers the basics because if they don’t have them, they’ll never be able to become good in what they’re going to do there. Let’s have a look at network security or better say at man-in-the-middle (MITM) attacks. I would say, that all of the security professionals today, even if their not specialized on network technologies know about this kind of attack but now have a look on web application security. Take the example of Cross Site Scripting (XSS). In the webappsec scene everyone will know about XSS and what you can do with it but are you sure that every network infrastructure pentester will know about it? Now I’d like to point you to a small experiment, if we can call it this way. About two weeks ago, I’ve given a presentation at the 0sec, a small security conference in Switzerland. Of course I spoke about web application security but I asked myself: “Most of the guys (and girls) there are low-level hackers, does it really make sense to talk about my newest research and the latest attack vectors?”. The answer for me was clear, the newest stuff will be the most exciting and if less than 50% of the audience knows what you’ve talked about, after your presentation, it’s was really cool and crazy stuff but from my point of view it’s much more important, to show people the basic possibilities we’ve got so far in hacking web technologies. Because of this, I decided to talk about the big picture of web application security, instead of the latest and greatest webapp hacking stuff and below you’ll find the short abstract for my talk:

Most of the actual vulnerabilities which security researchers and also bad guys (doesn’t) report every day, are related to web applications. Even if this is the case, the security community didn’t get the big picture of what security related problems we’ve got through web applications. In this demonstration, Sven Vetsch (aka. Disenchant) will show you an overview of the most important web vulnerabilities like SQLi, XSS, CSRF, Path Traversal, Session Fixation and much more. The focus in this demonstration is not to show you the latest research results in webappsec, it’s to show the big picture of this topic to the attendees.

As I already wrote before, it was some kind of an experiment because I didn’t know if the attending security people really want to hear old stuff but from my point of view it was really a success. I only get positive feedbacks and as I expected, most of the attendees where low-level hackers. Unfortunately I was not allowed to disclose the source code of my demo application, which is a vulnerable social networking platform, where I can simulate most of the web application related security problems we have today and I’d also like to implement even XML and AJAX security stuff. Because of this, it wasn’t that easy to show everything in a clear way but I think the attending people get from the demonstration what I expected, the big picture of web application security.

This small story showed me, that many people in the security community know about some web application security stuff but even not the basics and at least from my point of view it makes much more sense to start with basic stuff instead of presenting state of the art hacking, only a few people will understand.

PS: I would really like to create a web application security 101 video training but I have to check some licensing stuff before and in the worst case, I’ve to rewrite my whole demo application.

Yes it’s true, that it’s over a whole month ago since I wrote my last blog entry. This has different reasons, so for example I started studying computer science and had to become familiar with this new situation, especially because I’m still work for Dreamlab Technologies at the same time. Also it took me some time to hold a talk about the OWASP Testing Framework at this years Security-Zone in Zurich and I also spoke at the 0sec like I did last year. Then there is of course also the usual stuff like organizing the next OWASP Switzerland Local Chapter meeting, where we can expect two or three good talks and once again a sponsor for dinner. Some of you might also remember my blog posting called “What I’m Working on“, I already released the XSIO paper and the PHP code fixing paper is nearly ready but needs some small additional corrections. As you can see, I’ve got much to do at the moment anyway and now I’ve also to learn for school. I really hope, that I can again write more blog postings in the near future because there are more then enough interesting things to talk about.

Last week I was at the Security-Zone 2007, which is the most important security related event we’ve got here in Switzerland (and it’s by the way absolutely for free). At this event Hans-Peter Waldegger and I had a talk in the name of the OWASP Switzerland Local Chapter, which was focused on structured application security testing. For this, we first demonstrated how an application could be attacked and afterwards we presented the OWASP Testing Framework based on the Testing Project. We had an audience of about 80 people so the presentation room was full, which shows me that the topic of web application security finally also arrived in Switzerland.

From my point of view it was a great success and many security people in Switzerland know now about the OWASP because of our talk, the article I wrote for their newsletter or at least the big OWASP logo they’ve printed on each free ticket. I really hope that this will help the mission of the OWASP and will also bring us new people to the OWASP Local Chapter here in Switzerland so that we can for example start working on projects.

Last but not least, I really like to thank all the people behind the Security-Zone (especially Rafael Cruz) for giving that great support to the OWASP and I’m really looking forward to be there again next year.

I finished this paper about one month ago but I had to clarify some stuff with my employer Dreamlab Technologies Ltd. Now everything’s clear and I can publish my paper about an attack type I call XSIO – Cross Site Image Overlaying. It’s about something which I think many of you have already done but I wasn’t able to find something written about it and even I don’t think, that most of you are aware of how big the impact of something like this could be. But just read the paper if you’re interested in hear some more about it

Download – XSIO Paper