Browbeating Web Apps W/Their Own Javascript

We’ve talked a bit about reconnaissance, NMAP and SQL Injection. But sometimes, our jobs aren’t strictly limited to demonstrating how vulnerable an application is to known exploits. Sometimes, we get the chance to demonstrate how vulnerable a web application is just by existing.

An administrator or developer can put in defense after defense and make it so we have to jump hoops in order to get to known exploits and that’s good. Defense-in-depth is a great concept and it should be used as a building block of any sound security plan. However, if we can develop an understanding of how an application works well enough (and I mean mind-melding like Spock with that rock creature—you know, the one with the silicon eggs *shudder* ), if we can really get to know an app and understand the code in front of us in a web page, then we should be able to test its security without some of the tools we’ve talked about before.

I’m going to demonstrate how, with the help of a web proxy, we can manipulate an application’s code so much so that we can see information we weren’t supposed to see, gain administrative privileges, even dump a database.

Now, all you critics out there, these are extremely basic examples of how to manipulate javascript and HTML to get us escalated access to data. These are not meant to be elaborate examples, by any means and they aren’t.

But they should serve as a great stepping stone for your education and give you a place to start to learn how to do this.

Ready to begin?

The Web Application

The following examples, while simplistic of nature, are real. They have been found out in the field. I can’t divulge where, but I can divulge how to exploit these loops of logic.

Javascript in the URL bar

Now, there are a couple of different ways to skin this particular cat. Some people would take the resulting URL from this particular manipulation and just copy and paste it into a new browser window and change the URL. This is ordinarily a fine idea. However, SOMEtimes you find a sneaky programmer who has figured out that they need to deny direct URL access if it wasn’t the result of a Javascript call. So, the only way to do this particular trick is by manipulating the javascript that we are given in the first place.

First, we log into our Web Application (a management portal, for this particular example) and we are presented with this screen:

Our menu to the left, shows that we can perform “Salary Review”, look at “New Hires”, execute “Performance Reviews”, take a look at our current employees’ “Leave Status” and review our employees’ “Education, Skills & Training”.

Clicking on “Salary Review”, we are presented with a screen such as this:

This screen shows us a list of the employees we’re in charge of and their current salaries. If we wanted to review a particular employee’s salary history (perhaps we need to know what percentage raise he was given in previous years), we could perform this by click on the “Salary History” link in the right frame.

The legitimate results of our doing this would look something like this:

From this, we can see that we clicked the “Salary History” link for employee 11253 and from the window in the background, we can tell that employee 11253 is, indeed, one of our legitimate employees and we SHOULD have the privilege of seeing his salary history.

But we’re supposed to be wearing the darker colored hats of the attacker, aren’t we? So, let’s start to think a bit darker about the information that’s in front of us. We have under us, employees 11253-11256 and an employee with the ID number 11259. So, someone else’s employees are 11257 and 11258. Let’s see how secure our actual program is. Let’s see if we can see information for either employee 57 or 58.

First, let’s take a look at the HTML source code for the page that we’re presented. This is one of the first things I do when interacting with a web application I’m testing. I can’t bend it to my will if I don’t understand what it’s doing.

So, let’s take a look.

Interestingly, each of our “Salary History” links utilize the same javascript function over and over again. All they do is pass the employee’s ID number along to the function.

The logical question to ask is: “What would happen if I feed this “SalaryHistory()” function the WRONG employee ID number? What would I see?” (Remember, we’re getting paid to think like the bad guys here.

So, we’ll copy “javascript:SalaryHistory(‘11253’)” from the source code and we’re going to use this to manipulate our app around a bit.

Let’s paste this into notepad three times to modify it. Let’s change the second line to reflect the employee ID number 11257 and the third one to reflect the employee ID number 11258.

So, our 3 lines will look like this:

javascript:SalaryHistory(‘11253’)

javascript:SalaryHistory(‘11257’)

javascript:SalaryHistory(‘11258’)

The first thing I always do when puttering around with applications is attempting something legitimate before I try something malign. This way I know that, if the legitimate transaction works, I at least have a better than 50% shot the malign transaction will work, too.

So, let’s paste “javascript:SalaryHistory(‘11253’)” into the URL bar of the application and see where it brings us. If, when you hit enter, you don’t get the right action (a popup box), you might need to open the frame in its own window first. This isn’t always the case, but know you can do it, if necessary.

We paste “javascript:SalaryHistory(‘11253’)” and what happens?

Look familiar? It should, it’s the exact same results as if we clicked the link to start with.

OK, now, we’re going to step across the boundary from legitimate application use to the darker hat area.

We’re going to paste the second line from our notepad into the URL bar. We paste “javascript:SalaryHistory(‘11257’)” in.

What happens?

Success!! We’ve successfully gotten the app to return the employee salary history of employee 11257, even though (from the list in the window beneath), he is clearly NOT one of our employees.

And what happens if we do the same with “11258”?

Again, we get their salary history.

While this is basic URL manipulation (in essence), it’s a way to think around a problem that a lot of people skip or miss when evaluating the security of a web application. They rely on automated tools and don’t look beneath the hood to see if there’s anything they can do to mess with the application’s logic.

And that’s a real shame. Why? Because no scanner’s going to figure out that you can glean unauthorized information from the app by manipulating what’s presented to you, the user. And a lot of times, the data that you can gain access to are the crown jewels that you should not be able to see.

Changing the HTML in Front of You

Sometimes, manipulating the code in front of you is not as simple as just changing a couple of characters in a URL bar. Sometimes, you need to actually figure out a way to change the HTML as it’s being fed into your web browser.

This is a perfect situation for using a web proxy. There are several web proxies out there: BurpSuite, WebScarab and Paros to name a few. What is a web proxy and what does it do? Well, to make things incredibly simple: a web proxy is a piece of software that will sit between a web client (a browser) and a web server (http://xxx.xxx.xxx) and will intercept requests from the client and responses from the server. Why does it do this? So that you may manipulate the code in transit to either destination.

It looks a little like this:

And for more detailed information, check out WebScarab’s Getting Started guide on their web 

site (https://www.owasp.org/index.php/WebScarab_Getting_Started) and for information on how to set up your web browser to use a proxy, check out this rather complete (f not a tad old) list of browsers and how to change proxy settings. (http://www.cavency.com/browser-proxy.html )

NOTE: One of my favorite ways to use proxies is to use Mozilla Firefox and get the FoxyProxy plugin from their addons.mozilla.org site. FoxyProxy creates a button in the browser window that lets you quickly switch from one proxy to another.

Starting the Web Proxy and Using It

Once you’ve downloaded your particular web proxy (for my examples, I use WebScarab, although it’s a great idea to use a couple and find which one suits your needs and skills best).

For WebScarab, we need to invoke it using the “java –jar webscarabXXXX.jar” syntax.

Then, once it’s started (note that in the picture, WebScarab tells you which port it’s running on, port 8008), you’ll need to configure your web browser to use it.

The settings page you’re looking for commonly looks something like this:

Now, every single request from our web browser and response from the server will be processed through this proxy. Later on, we’ll turn on interception and we’ll be able to manipulate the actual HTML as it goes back and forth.

Checking out the Javascript Under the Hood

First, before we do anything else, let’s check out how the application’s navigation menu works. The navigation panel on the left side of the screen is the nuts and bolts of our application. It’s how I, the user, get to places I’m supposed to get around. Chances are, in a security evaluation, this is also a great place for me to find ways to get to places I’m NOT supposed to get around.

So, I’m going to view the source (found here: http://pastebin.com/r7vC3ity ).

Let’s see what’s going on.

The javascript first declares two variables:

            var nextAction = "";

Then it declares a function called “navigateTo” and 4 things are passed to it: “screen”, “title”, “rights”, and “timeout”. But the meat of the thing is in the “nextAction = “ line and the “eval(nextAction)”.

            function navigateTo(screen, title, rights, timeout){     

                 nextAction = 'navigateTo'+screen+'("'+title+'",'+rights+')';     

                 eval(nextAction);           

            }          

Why are those two lines the meat of the function? Because, whatever we pass to the function in the “screen” variable, it is appended to the phrase “navigateTo”. So, if we were to pass it the phrase “GOOBER”, the nextAction variable would be set to “navigateToGOOBER” and a bunch of extra stuff.

So, that means that down below, where the app’s HTML says:

<tr>        

            <td onmouseover = "showUnderline(this)"      

            onmouseout = "hideUnderline(this)"    

            onclick="navigateTo('NEWHIRES','New Hires', false, 0);">      

            <div class='bottomText'>           

            New Hires         

            </div>    

            </td>      

            </tr>

What is really happening, is when we click on the words “New Hires”, the “onClick=” event passes the navigateTo function the following things 'NEWHIRES', 'New Hires', false, and 0. Most of this is irrelevant. However when we pass the “navigateTo” function the phrase “NEWHIRES”, what ends up happening?

“nextAction” becomes “navigateToNEWHIRES”.

And then the code executes the “eval(navigateToNEWHIRES”…blah-blah-blah code.

This in turn executes this code:

            function navigateToNEWHIRES(Title, BrowseOnly) {   

            parent.frameB.location.href = "NEWHIRES.htm"        

            }             

Which means that it redirects the code to NEWHIRES.htm in the long run.

So now we better understand how the navigate menu moves us, the user, around the application.

Now.

How can we break it? Let’s don our darker hat.

The rest of the code actually gives a few clues as to some mischief we can get into. When reviewing all the “navigateToXXXXXX” functions, there are few functions that the developer left in the code. Why did they leave it in the code? Probably because the functionality we’re given as a regular user doesn’t use it and maybe it was easier to leave it in. Who knows why? Who cares? It’s in there and we might get some use out of it.

One thing that stands out at me in a big way is the “navigateTOEXPORT” function. Sounds like something we should check out. (And yes, naysayers, we COULD just navigate to export1.php, however, there could be code that blocks a direct reference. This way, we’re using the native functionality of the application against itself).

Let’s see what we can do with the “navigateTOEXPORT” function.

Manipulating the Javascript

So, we talked before about using a web proxy and how it can intercept traffic between a web client or browser and a web server. The reason we discussed it is that we’ve got some code we want to execute (“navigateTOEXPORT”) and the best way to handle that natively is to get one of our EXISTING navigation buttons (let’s say “NEW HIRES”) and change how that button functions.

First, let’s see how the NEWHIRES code works normally. By click on the Navigation Menu item marked “New Hires”, we see that we only have 1 record returned back to us:”Bob Lebiewski”. He is a new hire.

So, what we’re going to do is change how the “New Hires” button works. We’re going to fake out the application and make this button now invoke the EXPORT function. This way we’ll see if we can gain unauthorized access to the database export functions.

In order to start, we’re going to go into WebScarab and check off the “Intercept Responses” checkbox. This means that what we’re going to do is change the HTML code we render in the browser.

Now, when we refresh the screen, the request will pass through the proxy and because we’ve told WebScarab to intercept server responses, we see the response in a new window. Scrolling down that window, we come to the actual response and can click on the TEXT tab to view and edit the raw HTML.

And we’re going to go ahead and modify the phrase “navigateTo(‘NEWHIRES”  to “navigateTo(‘EXPORT”. Why are we doing this? Well, we certainly could copy and paste the entire <tr> clause and modify the whole thing. But, here’s the thing. We want to do this quick and lazy. If we can gain access to the EXPORT function without a lot of work (and let’s face it, 6 keystrokes is quick and easy), then this is the quickest way to go.

So, now we’ve changed the HTML to reflect that our “New Hires” menu button won’t take us all the way to NEWHIRES. It will in fact, when clicked, bring us to the EXPORT function. Hit the “Accept Changes” button on our proxy and we should get a new Navigation Menu that looks exactly like our last one.

Let’s take a look and see what happens when we click it.

It looks like we got a dump of the entire database to the screen. I’d say that’s a win. Was there an authorization check for that web page? Did it check to see if my user account could access it? No. The programmer relied on the fact that my role in the application wasn’t supposed to get the menu item for database export and that was good enough. Clearly it wasn’t.

Gaining Unauthorized Access to Admin Functions

Same drill as before. We want to gain access to admin functionality and we’re not admin. The programmer left the code in the HTML for it but thought we, as regular users, were too insignificant to worry about.

Let’s look at that code:

function navigateToADMIN(Title, BrowseOnly) {

   parent.frameB.location.href = "admin1.htm"

   // <!-- parent.frameB.location.href = "admin.htm" -->

}

So, there’s a comment in the code that redirects us instead to “admin.htm”, rather than “admin1.htm”, the page we’re presented to ordinarily. Again, simple URL manipulation can probably get us where we want to go. But this is a lesson on how to use the Application’s javascript against itself.

Let’s see how the ADMIN function behaves normally.

Admin-access-denied.jpg

Access denied. Interesting.

Now, let’s send this traffic through the proxy and change it up a bit.

First, we see the ADMIN code as is (meaning, the live, uncommented link is to “admin1.htm”).

And with our changes put into the proxy, we have implemented the commented line as our new live link and commented out the “admin1.htm” link.

Let’s see what happens when we use the “Administration” button now.

Well, our access is no longer denied. And weird enough, we are presented with a Command text box. What happens when we put “ls” into that box and hit “submit”?

Well, it looks like we’ve gotten into a way to enter commands into the Operating System. That should really just be for administrators. Not regular users like us.

I mean, we could really do some interesting things. Like this:

Conclusion

As stated at the beginning of this article, there are many ways to skin a cat. I wanted to demonstrate for you a quick way to manipulate javascript in a web page to circumvent certain pieces of logic that a developer may have put in place to deter us. By using a web proxy to change the HTML coming into our browser, can alter the application’s behavior and give ourselves access to parts of the application we probably should not have access to.

Hopefully this small demonstration helped get your feet wet with using a proxy and manipulating HTML / Javascript in your browser and playing with web applications and how they behave.

Want to try any of this on your own?

Grab yourself a Virtual Machine that’s already built for LAMP (Linux, Apache, mysql and PHP). There’s one here you might try: http://www.vmware.com/appliances/directory/54966

And then grab yourself this tar file (https://sites.google.com/site/hackonadime/home/files/webapp.tar?attredirects=0&d=1) and untar it in the /var/www directory of your LAMP server. You will have the vulnerable web application we browbeat in this article for your own mischief and mayhem.

Have fun!