For Web Challenge 300, you were presented with a news website, BluesNews.
Although we’re not told what we need to do, we probably want administrator access. Let’s take a look at all the possible attack vectors to help us get the access we want. Clicking one of the news title takes us to a url:
http://csawctf.poly.edu/challenge1/view.php?id=1
Playing around with the id parameter shows it may be vulnerable to SQL Injection. For the sake of brevity I’ll let you know it’s not. I put in some code to make it look like an attack vector to throw people off, but it didn’t stop most people from solving it.
Continuing, let’s try making a post.
http://csawctf.poly.edu/challenge1/post.php
Oh no, we have to be registered! Let’s do that now. Once we click, we see that registration is closed. What’s up with that? Maybe we should take a closer look at the URL.
http://csawctf.poly.edu/challenge1/register.php?register=false
The next logical step to getting an account and owning the website would be to mess with the parameters. What happens when we change the value of register to true?
After registering an account, we see that our account has been created and we can try to log in. Logging in presents us with this message:
> > You entered a correct username and password but do not have permission to log in right now. > >
What’s the big deal? We finally register but we can’t log in? Let’s take a closer look at the registration page.
<!-- !!REGISTRATION DEBUG!!
INSERT "username|realname|password|steve@poly.edu|admin:no|comment:new user" INTO USER DB FILE -->Registration succeeded!</div>| A debug message! At first glance it looks like some type of SQL but in reality it was placed as a hint as to how user credentials are stored. This led to a lot of SQL injection attacks on the registration form but because it isn’t really SQL, none of them succeeded. To go about attacking this website and owning an administrator account, one must understand how the previous line is being parsed. Right away we can see that parameters are separated by a “ | ” symbol, and we can see where our details correspond to which parameters. However, there are two parameters which don’t get their values straight from the registration form; the admin and comment field, with the interest obviously being in admin. |
| Like I stated earlier, to attack the registration form, we must understand how the data is parsed. For those familiar with PHP, the explode() function may come to mind, as we need to break up the data delimited by “ | ” symbols. Here is the result in doing so: |
php > $data = "username|realname|password|steve@poly.edu|admin:no|comment:new user";
php > $data = explode('|', $data);
php > print_r($data);
Array
(
[0] => username
[1] => realname
[2] => password
[3] => steve@poly.edu
[4] => admin:no
[5] => comment:new user
)| The value we want to modify is element [4]. How can we do so if its value is not influenced by anything we submitted? Let’s assume right now nothing we type is sanitized. We know it’s not real SQL so a SQL injection is out of the question. What if we try adding our own “ | ” symbol to our registration fields? Using explode() in PHP as an example, we know this would result in an extra element. Let’s try out a username containing “ | ” and see what the debug says. |
INSERT "asd|asd|asd|asd|asd|asd|admin:no|comment:new user" INTO USER DB FILE -->Registration succeeded!</div>Hmm, looks like the symbols weren’t sanitized. Let’s see what explode() has to say about this!
> php > $data = "asd|asd|asd|asd|asd|asd|admin:no|comment:new user";
> php > $data = explode('|', $data);
> php > print_r($data);
> Array
> (
> [0] => asd
> [1] => asd
> [2] => asd
> [3] => asd
> [4] => asd
> [5] => asd
> [6] => admin:no
> [7] => comment:new user
> )
We’re getting close! The “admin:no” field is no longer element [4]! Instead, it is a value of our choosing. Let’s try something a little more targeted this time. What would happen if we put our username as this entire line?
> > steve|realname|password|steve@poly.edu|admin:yes|comment:cool user > >
Because our symbols are not being sanitized, we have changed element [4] from the default “admin:no” to “admin:yes”! On top of that, [5] which normally contains a default comment now says we are a cool user! Here is the resulting user line:
INSERT "steve|realname|password|steve@poly.edu|admin:yes|comment:cool user|whocares|whocares|whocares|admin:no|comment:new user" INTO USER DB FILE
Essentially what we have done is pushed all the server’s assigned values to the side where they will probably never be looked at, and placed our variables. Element [4] now contains “admin:yes” which should grant us administrator access!
After logging in with our new account, we are greeted with the key.
Over all, this was a relatively simple challenge. The ?register=false didn’t stop many people, but the fake SQL injection page really threw a lot of people off course. A lot of people also assumed the debug statement in the registration page to be SQL, which led to a ton of brute forcing with tools such as sqlmap. There really wasn’t much room for creativity in this challenge either, which probably made it a bit easier.