Practical Website Hacking CTF: Exercise 2

posted


Note: This post is part of a series related to the InfoSec Institute's Practical Website Hacking CTF. If you're interested check out the whole series.

Stated Mission Goal

Some folks have decided to make a web calculator. You, on the other side, think to play a prank on them. Your task is to inject the PHP statement that shows information about Apache and things like the PHP version, as well as all kinds of other funny data.

Stated Mission Vulnerability

Injection - OWASP Vulnerability Information

Introduction

We'll be going over the mission in great detail, but unlike last time, I won't be digging into every facet of how to open and navigate the Developer Tools for your browser. I'll kind of just expect that when we talk about it, you'll understand what I'm referring to.

If you are looking for a paint-by-numbers flag capture, this isn't the place for you.

Note: The game is still in effect.

Let's get to it, then.

Calculator

Just like last time, let's go ahead and see what happens when we enter something in this form and submit it. Unlike last time, let's open up our Developer Tools to the Network tab and watch what's happening.

Start with something simple, something with an expected outcome. Let's enter 123 in the first operand input and 456 in the second operand input. Adding the two together should yield 579. Go ahead and hit the Calculate button.

That output looks to be what we expected, but did you notice the page reloading it's assets? Your Network tab should show you what's going on, even if the reload happens too fast to see.

We can see a POST request for this page which passes our operands and operator to the page. Seeing all of this already tells us a few things, and we can dig just a little deeper to find out a little bit more. Before I recap what we've already learned, let's check one other thing.

Let's peruse the page's JavaScript and see if we notice anything related to the form submission, like what we had with Exercise 1. The only mission specific code seems to be related to the hint system and to the OWASP vulnerability name at the bottom of the page. That gives us a pretty good indicator that nothing is happening on the front end.

To recap what we know:

  1. Operands and operator are sent to this page as a POST request
  2. There is no front end validation
  3. Calculation must happen on the server

Now, you may be asking yourself, "Didn't the mission briefing basically hint at that last one by asking us to inject PHP?" Why yes, yes it did. However, do you think we'll always have mission briefings like this in the real world?

Spoiler Alert: We won't. We'll need to perfom lots of recon in real life scenarios.

Because our values are being sent to the server and evaluated there, we need to see what the server will and won't let us do. Enter abc for the first operand and def as the second operand and submit the form.

We get an error telling us we have invalid operands; the server must either be checking these inputs for valid numbers or testing to see if the generated value is a valid number. Let's start testing some possibilities.

If we enter 123 for the first operand and 456 - 123 for the second operand, we'd expect 456 as a value if the server is just evaluating what we give it. This gives us the same error.

Maybe editing the values isn't the right approach? Let's change the operator's value to the function we need to call and see what happens.

Enter 123 for the first operand and 456 for the second operand, then inspect the operator dropdown. Double-click the "+" of the value attribute for the first <option> and change the + to phpinfo();

This time we get a different error letting us know the calculation could not be completed. That means we probably need the code that is trying to perform our mathematical operation to execute or this thing will just keep throwing errors at us.

If you aren't really sure where to go from here, I'd suggest reading up on injecting phpinfo(). If you can't get any further, read on for the solution.


Warning: Mission Spoilers Below!


To complete this mission, we know we will need to alter the operator's value attribute and we know we will need the execution of our math to not throw an error.

We can reasonably assume there is probably an eval() going on in the code, and if you weren't entirely sure, the mission hints will outright tell you as much.

So, we're going to need to escape out of the operation the site runs normally and get it to also evaluate our phpinfo() method call.

It turns out this is pretty easy.

Enter 123 as your first operand and 456 as your second operand and then inspect the operator dropdown and open the first value for editing like we did above.

Replace the + with ; phpinfo();, which will allow the code to evaluate the first operand, think everything is going fine, then execute phpinfo(), and then evaluate the second operand. Both operands will evaluate as their integer value and the phpinfo() method will run.

If you leave off either ;, you will get the error message telling you that there was an error while trying to perform the calculation.

You can read the success popup if you want, but I'd close it and quickly hit CTRL + A (or CMD + A on OS X) and then CTRL + C (or CMD + C on OS X) to copy the output just in case it comes in handy in a later mission. Go ahead and add that information to the notes your keeping (You are keeping notes, right?). If you don't get it in time, you can always go back to Exercise 2 and run it again.

You should have been redirected to Exercise 3 by now.

comments powered by Disqus