Just another weblog

I recently participated in STEM CTF and there was one challenge that I found particularly fun to figure out. The situation was quite straight forward: gain access to an account on a social networking website.

At first you are presented with a login page, allowing you to register or request that your password be e-mailed to your account’s associated e-mail address through a POST of the username to an email_password function. So, I decided to create an account and see what else I could do. Sure enough, there was an update e-mail ability which turned out to POST the new values for account attributes. This means, that you could visit /EditProf?attribute=email&newValue= to update the e-mail address for your current logged in account.

These in combination seem like they could be great for a CSRF (can be pronounced sea surf) attack! CSRF is essentially the ability to change values in a URL and send that URL to the target, having them click it to update values, transfer money etc in their account. For example, if wutbook.com was vulnerable, somebody could click a link such as wutbook.com/EditProf?attribute=email&newValue=lulz@gmail.com to change their e-mail address to a possibly malicious address.

Now it would have been nice if the target just clicked on the link, but we had to take it a step further in the competition. The messaging system involved no removal of special characters, and simply wrapped your message with textarea tags. Once you notice that, you should be able to deduce that you can just close that tag, and add whatever you would like to the page. Now you can have a web browser attempt to load a URL through use of img tags. Of course no image will be loaded on the page, but the call will be made none the less.

With all of that in mind, I crafted (roughly) the following message to the user

hello!</textarea><img src="http://{url}/default/EditProf?attribute=email&newValue=my@email.com" /><img src="http://{url}/default/email_password?username=target" />

When the user viewed the message, it automatically set his e-mail to mine, and sent me his password!

So today I’ve decided to go back and go through some web challenges. Just compiling a list at this time, and going to play with Security Traps first. I’d suggest anybody that is just starting into security-related games to take a look at HackThisSite.org first – there is a lot of help as it’s an older more well known target.

HackThisSite.org
Security Traps
Smash the Stack
Hack Quest
Intruded.net

I’ll likely be posting some of my thoughts on random challenges in these sites, omitting the site name itself so that I’m not just giving out answers.

I’ve noticed that I’ve been very inactive on this blog, so today I’ll be touching on a rather recent topic that has struck my interest – Unrestricted File Uploads.

In this vulnerability, we consider the dangers of not having proper controls on a upload feature to stop an attacker from uploading malicious code. There are many types of attacks here, ranging from overwriting critical files (if the web user has rights to do so) to having a virtual interface to go further into the server. I was able to be introduced to the latter of the two – a situation where no handler was defined for PHP code, but the uploader allowed .htaccess files and even allowed those rules to be applied to the current directory. An example file that would allow PHP could would be configured as follows:

allow from all
AddType application/x-httpd-php .php
AddHandler application/x-httpd-php .php

Of course this could be modified to allow execution of most any filetype, and barring the idea that the web/apache user be denied rights to execute, a hacker could land anything they desired.

So, once that was in place, I was able to upload a PHP Shell and had direct access to a terminal running on the server. It turned out that the web user had read access nearly everywhere, and quite a bit of write access in web-facing directories. From this stage we would be able to do more thorough recon of the machine, and as we had local access to a terminal, ultimately find an elevation of privileges exploit to run.

Now aside from being able to get root, if you can land a shell on the machine, you’ll be able to see whatever the web user can see correct? Thinking further into that, you should be able to traverse the web site’s main directory and take a look at the source for server-side scripting languages, including those that may have SQL passwords in them! Once you have SQL passwords, you could very easily get all database information with no need for SQL injections – though if the upload hole is open, SQLi may very well be present as well.

Seems like a fun exploit right? It seems rather prevalent as well, especially in non-commercial applications, so keep your eyes open for this one!