Last week I was thinking about some new research ideas and I have some stuff which’s (at least from my point of view) really interesting. Something I’d like to present now is Ranum. Today many things are based on random numbers but the problem we have there is, that normal computers can just generate so called pseudo random numbers and so you can run into security problems. Now I thought about what the problem is and it’s just, that if a machine generates “random” numbers, you can try to enumerate the next number. So my idea was now to have “Distributed Random Number Generator” because there you don’t have the possibility to analyze a machine to enumerate anything because every participating machine is different and you’ll never now from which machine you’ll get your next random number. It’s not that easy to explain so we better go to the POC stuff which’s an easy Firefox Extension I called Ranum (-> Random Numbers) and some small server side PHP scripts which communicates with a MySQL database.

Ranum:
This is the main part of the Distributed Random Number Generator because when you install this Firefox extension, your browser will generate pseudo random numbers all the time in the background and build a SHA-256 hash out of it and then send this hash to the server which will collect this values in a MySQL database.

Download Ranum here.

PHP scripts:

index.php is the script where Ranum will send the numbers to and which will store them into the database.

ranum.php gives you X random numbers out of the database (and delete them afterwards). Also the number you will get are once more pseudo random so that even if for example only one person is sending pseudo random numbers for a hour you never will be able to enumerate the next random number you’ll get because you won’t get just the next number.
One random number
Ten random numbers (I’ve set the maximum to 20 numbers per request)

ranum_info.php is nearly the same as ranum.php but it contains some more information.
One random number
Ten random numbers (I’ve set the maximum to 20 numbers per request also here)

MySQL database:
Nothing interesting here:

CREATE TABLE `ranum` (
`id` int(10) NOT NULL auto_increment,
`number` varchar(64) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `number` (`number`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

So, now I need people who like to help generating pseudo random numbers for getting a database with real or at least much better random numbers

PS: Hope the server wouldn’t go down because of the load

Normally I’ll try to keep my blog technical and don’t write too much about personal stuff because even if there are some people who would be interested in that, most of my readers are not that interested in my personal life and want to know for example if I’ve got a girlfriend, where I life or what my favorite dish is (if you’d like to invite me to a dinner, Curry’s never a bad choice ) but for this blog posting I think it’s at least for my person very important to communicate what I’m going to do probably for the next four years.
Because I’ve got a professional Maturity of Technical Type and a certificate of proficiency as a “Mediamatician” I’m allowed to study at colleges of higher education in Switzerland and so I’ll start studying Computer Science this September at the Berne University of Applied Sciences Engineering and Information Technology. This means, that I’ll have hopefully more time for research, which I can present here in my blog and there are still very much things I’d like to work on or stuff I started working on but never had the time to finish it.

PS: A big sorry to Dinis Cruz (remember the 6th OWASP AppSec Conference in Milan)

About two weeks ago I wrote to the OWASP Leaders mailinglist the following proposal:

Hi everyone,
a working colleague of mine, just pointed me to a project called “Planet”. With something like this it would be possible to catch all the news by OWASP related people, written in their own blogs, even if they don’t use an OWASP blog.

See the following website for more information and projects which already use it like Gnome and Debian:
http://www.planetplanet.org/

What do you think about using this for the OWASP for having a centralized news channel about webappsec, the OWASP at all and also about the individuals who are involved in the OWASP?

Regards,
Sven

The goal was to have all OWASP related stuff together and so all the webappsec stuff going on anyway. As a response I’ve got a mail from Mark Curphey who recommended to use for example Yahoo pipes because this will not need an installation on the OWASP server. Now, to write something which belongs to the title of this posting, Christian Matthies and Ronald van den Heetkamp just launched a new website with exactly the service I wanted to have. They called it “Planet-Websecurity” and at the moment you can find there already the news feeds of ten well known blogs about web application security including mine. It’s nice to see, that also other people see a need for a centralized information pool about web application security

Many people tried to compare buffer overflows (BOF) with XSS and even the new XSS Book has the subtitle “XSS Is the New Buffer Overflow, JavaScript Malware Is the New Shell Code”. The conclusion’s most of the time, that there are many similar things but the most important difference is, that XSS vulnerabilities are much easier to exploit that BOFs. I agree, that some things are about the same if we look at this two vulnerability types but I really don’t agree with the fact, that XSS vulnerabilities are easier to exploit. In an eweek.com article, they’ve talked to Brian Chess, who’s Founder and the Chief Scientist of Fortify Software and by the way also a very cool guy

Where it diverges, though, is that buffer overflows are somewhat hard to exploit, Chess said, requiring an attacker to be fairly knowledgable about a system’s architecture and what’s happening on that machine. “XSS vulnerabilities are much easier to exploit,” he said. “Just go to your local bookstore, buy a book on JavaScript and you can get started on XSS.”

If you say this in exactly that way, then I fully agree with this statement but only because there’s the part “get started on XSS”. Of course when you know the basics on XSS and also on JavaScript, it’s no problem to find some websites where you can display an alert box or something. So, now you may ask why I started this posting with saying that I don’t agree that XSS vulnerabilities are easier to exploit. The answer’s very simple, it’s because I think there are different kinds of really exploiting XSS vulnerabilities. Normally to find a buffer overflow possibility it’s very hard but when you found it, you can use your standard pre-prepared shell codes and own the machine. Now, XSS works from my point of view exactly the different way. To find an XSS hole, it’s most of the time very easy and also to have a alert box popping up or changing the content of a website it’s not that hard but now asking yourself when is the exploitation of a XSS vulnerability really dangerous. This is the case as soon as the attack tries to attack the logic behind your application, for example by using functionalities in the name of a targeted user. To find out how an application works, so that you as an attacker can reach your goal by “exploiting the logic” or better say re-using the logic of the application through you XSS exploit, this is from my point of view some times very hard and this is why I would say, that exploiting an XSS vulnerability could be as complicated and difficult as exploiting a BOF.

To have a small conclusion:
BOFs are most of the time very hard to find but when you’ve identified where the vulnerability exactly’s located and what the vulnerability exactly is the final exploitation’s not that hard because you can use per-prepared shell codes which should be executed on the target machine.
XSSs can be found normally very easy but because (mostly) every application’s different from all the others, you have to write a special exploit and payload for every vulnerability (of course this depends on what’s your goal).

Christian Matthies aka. christ1an has announced the first public release of the so called PHPIDS which was written by him, Mario Heiderich and Lars Strojny.

PHPIDS (PHP-Intrusion Detection System) is a simple to use, well structured, fast and state-of-the-art security layer for your PHP based web application. The IDS neither strips, sanitizes nor filters any malicious input, it simply recognizes when an attacker tries to break your site and reacts in exactly the way you want it to. Based on a set of approved and heavily tested filter rules any attack is given a numerical impact rating which makes it easy to decide what kind of action should follow the hacking attempt. This could range from simple logging to sending out an emergency mail to the development team, displaying a warning message for the attacker or even ending the user’s session.

It really seems to have good filters in place and I’ll do some further testing on it as soon as I’ve got some time for it. I also liked, that they released it under the LGPL.

Keep up the good work guys

Today I received the following mail over the Full Disclosure mailinglist and it’s of course just for fun but exactly because of this I’d like to share it with the readers of my blog

Dear list,

You asked for it, and we delivered! Due to the increased demand
for more “Month of” projects, and the growing popularity of posting
hashes to this list, we proudly present… THE MONTH OF RANDOM
HASHES.

Every day for the next month we will be providing a list of not
one… not two… not three… not four… not five… not six…
not seven… not eight… not nine… not ten… not eleven… not
twelve… not thirteen… not fourteen… not fifteen… not
sixteen… not seventeen… not eighteen… not nineteen… not
twenty… not twenty-one… not twenty -two… not twenty-three…
not twenty-four… not twenty-five… not twenty-six… not twenty-
seven… not twenty-eight… not twenty-nine… not thirty… not
thirty-one… not thirty-two… not thirty-three… not thirty-
four… not thirty-five… not thirty-six… not thirty-seven…
not thirty-eight… not thirty-nine… not forty… not forty-
one… not forty-two… not forty-three… not forty-four… not
forty-five… not forty-six… not forty-seven… not forty-
eight… not forty-nine… not fifty… not fifty-one… not fifty-
two… not fifty-three… not fifty-four… not fifty-five… not
fifty-six… not fifty-seven… not fifty-eight… not fifty-
nine… not sixty… not sixty-one… not sixty-two… not sixty-
three… not sixty-four… not sixty-five… not sixty-six… not
sixty-seven… not sixty-eight… not sixty-nine… not seventy…
not seventy-one… not seventy-two… not seventy-three… not
seventy-four… not seventy-five… not seventy-six… not seventy-
seven… not seventy-eight… not seventy-nine… not eighty… not
eighty-one… not eighty-two… not eighty-three… not eighty-
four… not eighty-five… not eighty-six… not eighty-seven…
not eighty-eight… not eighty-nine… not ninety… not ninety-
one… not ninety-two… not ninety-three… not ninety-four… not
ninety-five… not ninety-six… not ninety-seven… not ninety-
eight…

not even ninety-nine…

but… ONE HUNDRED!

To make the project even more successful, this number (100) only
represents the number of random strings that hashes are generated
for, and not the total number of hashes we provide daily! You will
receive an md5sum, sha1sum, and sha256sum of all 100 random strings
every day.

That is THREE HUNDRED hashes. In your mailbox. Free. Every day.

Stay tuned for more details!

Over a month ago I wrote a blog posting called “Protect your Web Applications through Encryption” in which I started to talk about “crypto-defense” for web applications or better say, I started with it one posting before where I wrote about “Secure Data Transfer over HTTP without SSL“. The basic idea was very simple, I tried to build an integrity check for all attributes we send to the client whenever we know which values can come back to us. This idea brings us to a point, where we don’t need any whitelisting filters anymore to protect us against any kind of attacks on web applications where proper input validation is the problem, like in XSS, SQL-Injection, Path Traversal and so on. From my point of view we can “fix” about 30% or more of all webapp vulnerabilities out there very easy with the technique I describe in this posting.

Now let’s go deeper into the idea, for that you should really first read the “Protect your Web Applications through Encryption” posting because I don’t want to explain everything I already wrote there once more.

The last POC worked fine for demonstration purposes but as I already mentioned there, it’s not really secure and it’s possible to bypass it, even if it takes some time to do it. After that I’ve talked about the problem with Endre Bangerter who’s a professor of computer science at Bern University of Applied Sciences and was before part of the Network Security and Cryptography research group of the IBM Zurich Research Lab, so I really think that he’s the right man to ask. After I explained my problem to him, he gave me the advise to have a look at so called Message Authentication Codes or short MACs or better say, for a special type called HMAC which stands for “keyed-hash message authentication code”.

Because it’s not an encryption anymore now, I don’t have the problem I had before because I’ve the possibility to generate a hash value and because it’s important, that nobody can generate the hashes himself, a HMAC takes also a key as an input so the combination of these two information (value to hash and the key) is exactly what I need.

So now let’s stop talking about HMACs because everyone who wants to get more information about it can search the Internet. So, now I’ve done a new POC, using a HMAC and yes it works just as expected. Just try to edit a value:
POC / Source (index.php) / Source (hmac.php)

I’m really looking forward for feedbacks on this and I hope, that you understand what to do with it out of my explanation

Just as an additional information:
During all of this, we found out that there exists a patent by IBM which may “cover” my idea but in a way that I think that they didn’t know what’s really possible with it. The only part of interest is perhaps the following but there’s nothing about a hash or even a MAC in there:
"The URI (20) is split or extracted (30) into transparent part (40) and opaque part (50). According to the example URI in (20), the transparent part (or <transparent part>) (40) may be represented as http://<host>[:<port>], and the opaque part (50) may be represented as [<abs_path>[?<query>]]. As indicated in block (60). the opaque part (50) may be combined with additional information (70), which may comprise, for example, a client's Internet Protocol (IP) address, timestamp, time-to-live, magic number, nonce, sequence counter, hash value, means to ensure integrity, or other application specific information, etc., as those of skill in the art will recognize."

Once more this is just an information for the readers of my blog. Yesterday Ronald van den Heetkamp has published a blog posting about what Cross Site Request Forgeries aka CSRFs are. From my point of view it’s the best explanation on this attack class on the Internet. Great job Ronald

You can find the blog posting here.

From time to time, I’m reading the latest changes on the wiki at owasp.org so that I don’t miss any news. Today there was something really strange in the change history. At the OWASP Papers Section a guy named UzMan (Wiki username was “Ukehmf231″) has “hacked” this page:
See the “hacked” page here

OK, what happend? This great Hacker, found out how to use a Wiki
He just made a user and changed the content of the site. Normally I won’t write anything about such a crap but this time it’s that funny, that I have to share it with you folks out there.

And now, let’s go and hack the wikis all over the world, make a user and edit a page

Just as an information: The last days disenchant.ch forwarded to an upgrade message because I change that every time when I upgrade my WordPress but this time I forgot to change it back to forwarding to the normal site. Sorry to all of you out there who liked to go to my blog during this time.
PS: disenchant.ch/blog still worked.