welcome back to the net, Egypt

On January 27, 2011, the country of Egypt disabled the Internet for anyone within its borders. It did this in a couple of ways, both via the network (at the BGP level), as well as the name resolution (DNS) level. This means the take down not only impacted Egyptian nationals, but citizens of other countries that happened to be in Egypt during this time period, as well as anyone that was using a .eg ccTLD domain.

I don’t have a lot of time to form a well crafted post on the topic of Internet blockade at a national level – it suffices to say that I’m opposed.

Here are a couple of very interesting graphs, taken from http://stat.ripe.net/egypt

Start of the BGP withdrawal:

Re-announcement of Egyption BGP routes:

I’m glad that Egypt has decided to allow all those impacted by this outage access to the Internet once more. Welcome back .eg.

on security research

I’ve been pondering URL rewriting for the past couple of days – trying to come up with some way a client of a web site can first: determine if URL rewriting is occurring on a given web server, and second: in cases where it is used, determine what the rewrite rules are.
As I have been thinking about this, it occurred to me that, despite the proliferation of security research whitepapers and blog posts, there is a scarcity of ‘this is the process I went through to do this research’ information out there.

There are mountains of articles and documents, with dizzying arrays of statistics and metrics (often intermingled with a fair amount of marketing fluff), and yet most of the whitepapers, and certainly the various conference presentations, simply don’t talk about the process – preferring instead to present the end results.
As security professionals, we gather together at a multitude of conferences where we do a wonderful job displaying all of this shiny data and showing off new marvelous tricks to each other with varying degrees of self-indulgence. Yet most of how we came to have such cool stuff is left out of the picture entirely.

I understand why that is, of course. Simply put, the process is boring! It’s full of failure, and repeatedly throwing things at a wall and observing what happens. Nobody wants to sit in a small room with a couple hundred hackers listening to someone drone on for an hour about how “this didn’t work…and neither did this”, I get that. Added to that is the fact that, in some cases, the research is being done for a corporate (or government) entity. In such a situation, the process may be withheld not from a lack of desire to share on the researcher’s part, but because they are not permitted to do so by the organization for which the work was done.

Despite these reasons, in my opinion it is a disservice to ourselves, to the profession, and to others whom may be interested in performing their own research, when we all we do is deliver an end product in glossy PDF or a shiny PowerPoint presentation. That is simply not research, it’s promotion. Research, in an academic sense, implies documenting the entire process: both success and failure. This is not what I find when I look at the typical infosec industry output.

Accordingly, I’ve decided that I will share how I go about this particular project, and not just release some PDF or tool as a result of it. I’ll post my process here, any notes and thoughts, as well as any code I come up with. (Well, links to code anyway. I’ll probably keep the code itself in github).

One of the reasons I’m doing this is that I expect to fail. =)

As I’ve considered how one can detect URL rewriting, and as I’ve started investigating the details of how it works, my initial thought is that detecting it simply won’t be possible.

If that’s correct, I think it’s important that I present what I tried, along with the fact that ultimately it didn’t work. That’s vital information, in that it prevents someone else from wasting cycles repeating a process that’s already been done.

As well, understanding why something failed may lead to discovering a way to succeed.

OK… this rant being done now, my next post will start the process of documenting my research into detecting URL rewriting.

thinking sideways

Had an interesting question posed to me today. A web application was using portions of the GET request to create content on a page, and not properly sanitising the input. The result was a web page that was potentially vulnerable to cross-site scripting (XSS). However, there was a catch. The application, while not checking for security risks, was converting the GET request parameters to all uppercase.

This meant that, since javascript is case sensitive, the usual methods wouldn’t work For example you couldn’t use document.write(), or alert(), because they were rendered as DOCUMENT.WRITE() or ALERT() instead.

Here’s a quick and dirty PHP script I wrote that mimics this behaviour (note that you will need to have GPC_MAGIC_QUOTES turned off in the php.ini for this to work)

   echo '<form name="testform" method="post">';
   echo '<select name="test">';
   if (isset($_GET['options']) ) {
      echo strtoupper($_GET['options']);
   } else {
      echo '<option value="empty">EMPTY</option>';
   echo '</select>';
   echo '<input type="submit" name="submit" value="submit" />';
   echo '</form>';

To test it out, simply browse to http://yourhost.yourdomain/test.php?options=uppercaseftw

So, the question as a pen tester is, how can I break this?

Turns out the answer is pretty simple: you simply make your own javascript file, host it on a server somewhere, give it an uppercase file name, and create functions with uppercase names.

For example, I created the following XSS() function, in a file named XSS.JS:

function XSS() {
   alert('xss'); // or whatever

Now, I need to load this code into the page I’m requesting, and then somehow call the XSS() function. I did this by closing the select tag in my options GET parameter, and providing my own script tag. I then created a link to “foo”, and set an onMouseOver event to call the XSS() function.

Here’s what the request URL looks like to exploit this code:

http://localhost/sandbox/index.php?options=<option value="number1">number1</option></select><script language="javascript" src="XSS.JS"></script><a href="foo" onmouseover="XSS()">clicky</a>   <!--

The result is a nice link that, upon placing the mouse over it, triggers the javascript event which fires off the usual alert box.

The source code of the resulting page looks like this:

<form name="testform" method="post">
<select name="test">
<input type="submit" name="submit" value="submit" />

Nothing particularly awesome about this, but it was a situation I’d not come across before, and it took me a minute to figure out a way around it. So I thought I’d share =)