Hi all, I’m here to talk about a little known web vulnerability that Bryce Boe already touched on. Execution After Redirects are logic flaws in web applications that can lead to Information Disclosure and Broken Access Controls.

What’s an EAR?

Well, an Execution After Redirect (EAR) flaw is when a developer causes an HTTP redirect to occur, typically via a web framework. The developer assumes that execution stops after the redirect, however, execution continues.

Let’s look at a Ruby on Rails example (names have been changed to hide the guilty):

class TopicsController < ApplicationController
  def update
    @topic = Topic.find(params[:id])
    unless current_user.is_admin?
      redirect_to "/"
    end
    if @topic.update_attributes(params[:topic])
      flash[:notice] = "Topic updated!"
    end
  end
end

It appears that if the current user is not an admin, they are redirected to “/”, the web site root. In fact, if you access the update controller using a browser while not an admin, it will redirect you to the web site root like expected. However, if an attacker who is not an admin makes a request with topic parameters, she will be able to update your topic without being an admin!

How do I fix it?

The fix is pretty simple, always return after a redirect!

EARs can be more complicated. For example, there’s a controller that calls a method that calls a redirect. The real fix is to know where your redirects are, and what they’re for, especially if you use a redirect during authentication.

What else is vulnerable?

Web application frameworks differ on if they stop execution after a redirect. Check your web framework’s documentation to see if the redirect method stops execution.

What am I doing about it?

Bryce Boe and I are writing a paper studying this problem in depth. However, since I am alerting developers to potential EARs in their code, I wanted to have this informational blog post giving an overview. In addition, I developed a tool to staticially detect EARs in Ruby on Rails. Look for more blog posts in the future about the tool.

Permalink | Leave a comment  »

What is this?

In an effort to improve my writing and analysis skills, I’m going to review papers using less than 500 words. This is my first attempt.

Overview

Saner: Composing Static and Dynamic Analysis to Validate Sanitization in Web Applications is a paper written by Davide Balzarotti et. al., and was published at the IEEE Symposium on Security and Privacy in 2008.

Saner attempts to solve the problem of verifying the correctness of sanitization functions. Previous work on analyzing web applications for vulnerabilities assume that built-in sanitization functions completely protect the application from vulnerabilities. This assumption is typically extended to custom sanitization functions (regular expressions, string replacements, etc.)

Proper analysis of sanitization functions would enable a tool to be more precise about the vulnerabilities that it discovers. It can also be used to analyze a language’s built-in sanitization functions.

Saner utilizes static and dynamic approaches to analyze sanitization functions.

The static part was built by extending Pixy to keep track of the string values that each variable can hold. Saner can see if a variable can be used as output and if it is used in the output. However, the method used to keep track of the string values is an over-approximation, which might produce false-positives (but not false-negatives).

A dynamic approach is used to reduce the number of false-positives by generating inputs and seeing if those inputs trigger a vulnerability. In this way, Saner can present all the verified vulnerabilities, but if the user wishes, also present all the possible vulnerabilities so the user can investigate.

Thoughts

Possible Problems

Saner inherits the same limitations as Pixy, namely it does not support PHP’s eval function and aliased array elements.

Future Work

Context-aware

An extension to this (and other static web analyzers) would be to use the context of a variables output in the HTML page. For instance, variables that output to the headers of an HTTP response are vulnerable to HTTP Response Splitting and need to disallow ‘\r’ and ‘\n’, while these characters are safe when output in the HTML response. Another example is a variable that is output after a starting script tag but before the ending tag to customize the JavaScript sent to the user. Here’s a simple example of this:

<script>
var userName = "<?php echo $userName; ?>";
</script>

In this case, restricting only ‘<’ and ‘>’ will not work. The idea of context can be extended to attributes of HTML tags.

Database-aware

Another problem is how to treat variables from the database: are they sanitized or not? A static analyzer that is able to properly model and taint the flow of data into and out of the database would be very cool (and if you know of someone who’s done this, let me know).

Permalink | Leave a comment  »

Why?

While learning more about clojure, I wanted to do some network sniffing. Following a guide to raw traffic in clojure I needed to install jpcap in order to use libpcap from java.

Jpcap doesn’t provide a 64-bit version so I had to compile my own. Here’s the documentation of how I did it. A patch is provided at the end of the post.

Compiling jpcap 0.7 on 64-bit Ubuntu 10.10

1. First install sun java on ubuntu 10.10

2. Download jpcap or use the following command: wget http://netresearch.ics.uci.edu/kfujii/Jpcap/jpcap-0.7.tar.gz

3. Untar jpcap tar -xvf jpcap-0.7.tar.gz

4. Move into src directory cd jpcap-0.7/src/c/

5. Open up Makefile in your favorite editor (mine’s emacs) emacs Makefile

6. Change this line: JAVA_DIR = $(JAVA_HOME)

To This: JAVA_DIR = /usr/lib/jvm/java-6-sun/

1. Change the compile options from this: COMPILE_OPTION = -shared -L.

To this: COMPILE_OPTION = -shared -L. -fPIC

1. Save your file and close your editor.

2. Run make: make

3. Follow the jpcap installation instructions

Patch for more advanced users

Patch to do this automatically

How to patch

Let me know if you have any problems!

Permalink | Leave a comment  »

I found some information about how to do this on the web, but everything I saw talked about using an .htaccess file. I didn’t want to use an .htaccess file.

Here’s what I had to do in Ubuntu (this was on an old 8.10 server).

1. Enabled mod_rewrite:

   sudo a2enmod rewrite

2. Add the following in the VirtualHost section of my regular http setup to my config at /etc/apache2/sites-enabled/ :

   RewriteEngine On RewriteCond %{SERVER_PORT} 80 RewriteCond %{REQUEST_URI} ^/foldername/.* RewriteRule ^(.*)$ https://host.name.com$1 [R,L]

3. Restart Apache:

   sudo service apache2 restart

Make sure if you use this to change foldername to the name of the folder where you want to enforce HTTPS and host.name.com to the name of your host.

Permalink | Leave a comment  »

So after struggling for a while with this, the answer is surprisingly simple.

For a bridge that you've created with brctl, you can use this simple command:

brctl setageing <bridgename> 0


This command tells Linux to forget every MAC address that it sees on
the bridge, making it act as a hub.

Here's the source.

Permalink | Leave a comment  »

This is my new office at Microsoft.

Permalink | Leave a comment  »

Master's defense poster!

Permalink | Leave a comment  »

Thanks UCSB! Can you find my name?

Permalink | Leave a comment  »

Baby Opossum

Permalink | Leave a comment  »

Another fire in the Santa Barbara hills!

Permalink | Leave a comment  »

Two chicks at the same time.

Permalink | Leave a comment  »

 The problem was that I had Custom Nameservers enabled. With this you
can't enable TotalDNS. The solution is simple, switch from Custom
Nameservers to Parked Nameservers. Then you can enable Total DNS
to have your domain point where ever your little heart desires.

Permalink | Leave a comment  »

Doing research.

Permalink | Leave a comment  »