Tuesday, December 20, 2011

Over the last two cycles of OWASP top 10, insecure direct object reference has been included as major security risk. An object reference is exposed and people can manipulate that to access other objects they aren’t supposed to. But an apparently lesser-known problem is when the object itself is directly exposed. This happens when an object maps user-controlled form data directly to it’s properties with out validation.

Perhaps this issue gets less press because every language calls this problem something different. In ruby, people call this mass assignment. In .NET and Java it’s often referred to as reflection binding. Regardless of name, it is how the object obtains it’s data which is of concern.

In ruby, vulnerable code might look like this:

@foo = Foo.new(params[:foo])

The params call wants to make life easy and will automagically map any form data that matches the object’s parameters for you—unless you say otherwise. This is a very common convention used in MVC frameworks, because manually mapping a form POST to an object is annoying. The problem here is that it makes no difference to the controller whether you’ve exposed that field in the presentation layer. It just has to exist on the object.

In other words-- if you were updating a product quantity for your shopping cart, you might be able to change the price by guessing that a price field exists. Just add the price field to your POST parameters and it might override the value. This approach can be effective—but it is mostly a guessing game at that point. Some frameworks let you throw tons of arbitrary data and whatever sticks, sticks. Others will barf on invalid parameters.

There is a second route, however, which is why vulnerability deserves more attention. When I said that you are allowed to map to anything on the object, I meant it. You can map complex objects to other complex objects, as far as they related to each other. Lets look at an example in C#:

Behind the scenes, the framework maps all of the form data directly into the foo object. Developers also sometimes do this directly by calling the UpdateModel() function. In either usage, if someone sent a malicious POST to the “Create” view:

Foo.Bar.name=“hello”&Foo.Bar.is_admin=true&Foo.name=“myfoo”;

You’d end up with a full fleshed out object where:

Foo.name = “myfoo”Foo.Bar.name = “hello”Foo.Bar.is_admin = true

The Bar object is instantiated automatically through it’s empty constructor, and it’s properties are mapped as well. Any reference the exposed object has, you can bind to. This also works for arrays of simple or complex types too. If instead of a single instance you had an array or List<Bar> you would just do the following:

Foo.Bar[0].name=“hello”&Foo.Bar[0].is_admin=true

With out any other validations, this is all kosher.

In the wild I’ve used this attack to escalate privileges by updating my profile and walking down to a permissions table. I’ve also run across places where you could register every user to come to an event. And another instance where you could take over other people’s blog posts simply by editing your own profile.

If you search for this during tests, here are some key things I’ve learned:

This vulnerability is best identified with access to source code—and very few developers seem to protect against it.

When reviewing code, pay attention to how the constructor works and how fields are set on the object. Some properties are set via functions and you can’t bind them directly. Other objects don’t have empty constructors. This causes the attack to fail.

I frequently find this vulnerability on “update” and “create” controller actions.

You can, and I have, found this w/o source—its just harder. You do so by creating a loose type map through browsing the site.

You can create a type map by following a process like this:

Going to the object's “create” page and note all the form fields that are there. That is your basic “object”. As you see these objects in other places on the site, they might reveal more about their structure.

The site will guide you in what you need to know about object relationships. If you are looking at your cart, and it has a list of products & their details-- the cart object has a list of products.

For everything else, there are common object relationships you can just assert. Carts do generally have products, just as people generally have permissions. Take some time and look over common object models on the interwebs.

This attack route exists on pretty much every MVC based framework. In particular, Spring, Struts, MVC.Net and Ruby on Rails are all vulnerable. Maybe others, but those are so popular I’ve not really looked much deeper into it.

It is true that developers can prevent this by white listing specific fields to bind—but they don’t. The whole point of the convenience functions is convenience. If you’ve built an MVC application and didn’t go out of your way to protect against this—you are most likely vulnerable to it.

Tuesday, December 13, 2011

Stephen, @averagesecguy, wrote a post on owning a ColdFusion server. its pretty good and he wrote some code to help things along.

Code: https://github.com/averagesecurityguy/scripts

I thought I'd add to the conversation with some stuff I found doing CF research. The code he wrote and the metasploit module works great if things are in their default locations. Of course, this will never be the case when you are on a PT and need to break into that mofro.

Anyway, there is a misconfiguration that, when its present, can greatly help you exploit that locale traversal attack. Alot of time you can get the sha1.js and verify that the patch is not applied.

Anyway, more than once I've gotten that far but the host was Linux and locating the password.properties file failed. You're essentially guessing blind. So what i discovered is that sometimes the componentlist.cfm [Site/CFIDE/componentutils/componentlist.cfm] file is available. It looks like this:

Click on one of the components and you get full path to the installed component:

Not the best example, because stuff is where we would expect it to be. This one is better:

Now you know where to direct that directory traversal to get the proper file.

Friday, December 9, 2011

So assuming we have some sort of SQL Injection in the application (Blind in this case) and we've previously dumped all the available databases (--dbs), we now want to search for columns with 'password' in them.

We now know that we want to go back and enumerate/dump the column values from dbo.mytable and database MYDATABASE to see if there is anything good there. Mostly likely there is also a userID or LogonId in there we need to extract as well.

In IKE Aggressive mode the authentication hash based on a preshared key (PSK) is transmitted as response to the initial packet of a vpn client that wants to establish an IPSec Tunnel (Hash_R). This hash is not encrypted. It's possible to capture these packets using a sniffer, for example tcpdump and start dictionary or brute force attack against this hash to recover the PSK.

This attack only works in IKE aggressive mode because in IKE Main Mode the hash is already encrypted. Based on such facts IKE aggressive mode is not very secure.

Default is charset is "0123456789abcdefghijklmnopqrstuvwxyz" can be changed with --charset=

$ psk-crack -b 5 --charset="01233456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" 192-168-207-134keyRunning in brute-force cracking moddeBrute force with 63 chars up to length 5 will take up to 992436543 iterations

You may find yourself wanting a bit more flexibility or options during bruteforcing or dictionary attacking (i.e. character substition). For this you'll need to use Cain. The problem I ran in to was Cain is a Windows tool and ike-scan is *nix. I couldnt get the windows tool that is floating around to work. Solution...run in vmware and have Cain sniff on your VMware interface. The PSK should show up in passwords of the sniffer tab, then you can select and "send to cracker". Its slow as hell, but more options than psk-crack.