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 =)

on pen testing and fireworks

eEye posted a blog entry recently that attempted to compare providing free tools for pen testing to encouraging someone to use fireworks. This post from eEye is actually part of a growing pattern of ‘pen test/full disclosure == criminal’ BS being tossed around by various companies (notably, each of which perform vulnerability assessments themselves), but I don’t have time to fully address my thoughts on that at the moment (hint: there’s another post coming later on this topic).

Specifically, eEye’s post makes the following statements:

Penetration tools clearly allow the breaking and entering of systems to prove that vulnerabilities are real, but clearly could be used maliciously to break the law.

Making these tools readily available is like encouraging people to play with fireworks. Too bold of a statement? I think not. Fireworks can make a spectacular show, but they can also be abused and cause serious damage. In most states, only people licensed and trained are permitted to set off fireworks.

This analogy is flawed for a number of reasons, not least of which is the fact that the statement that most states disallow fireworks to people other than licensed pyrotechnicians is untrue.

I made a comment to their site about this, but as it has not been approved yet, I’m posting my comment here as well.

Here’s my two bits:

Since you relate the use of free pen test tools to fireworks as an argument, it should probably be pointed out that the majority of states in the US permit consumer fireworks, and only a very few disallow them. See: http://www.cpsc.gov/cpscpub/pubs/012.html

Perhaps the free pen test tools are “consumer grade” vs. the commercially licensed products that, to follow your analogy, should apparently only be used by licensed professionals (though frankly, I know folks in #metasploit that I trust with these tools more than many CISSPs that I know…)

Either way, I’m glad these tools are available, and free, and I am as grateful that I can use them as I am for the fond memories I have of lighting off fireworks with my family as a child. There’s something about being out in the field and participating that makes the moment much more enjoyable than simply watching someone else do it for you.

eEye has since replaced the entirety of the original post with one that essentially states “ummm… we meant that using free pen testing tools without permission is bad”. *sigh*.