#Web 400
Upon visiting the site we are greeted with a login page.
My, that person certainly is TALL.
No credentials were provided as a hint for this challenge, so we’ll have to brute force them. Some common combinations to try are administrator:123456, user:qwerty, admin:password, etc. It just so happens that the 3rd is the correct one.
Looks like someone left us a message.
So this wasn’t the account we needed, but we’re definitely on the right track. First thing we should to is to view the source of the page and look for anything suspicious. However, we won’t find anything of interest on this particular page. That Change Password link looks like an excellent place to continue looking:
This page looks much more promising. We have a form which we can use to change our password and that is a potential SQL Injection vector. But before we try that, let’s try viewing the source of this page. Who knows, we might find something interesting in there.
<!--I dunno how to make this work so I'll just put the name here-->
<input type="hidden" name="user" value="admin" />What do we have here? The username is passed along with the new password to the site. If no verification is done, it might be possible to edit the passwords of other users. But what user should we try? If we jump back to the main page, we’ll see that the whoever created this site goes by the name of “TheTallGuy”. So, we can open up TamperData and see if modifying the user field will allow us to change the password of this user.
Changing fields with TamperData
Once we submit the form, we get a notification that the password is changed. Skipping ahead to where we log into TheTallGuy’s account, we see the note he left for himself: ` IMPORTANT: Fix dl script (broken/data/download.php) ` That should be our next target. Access the file with no arguments gives us: ` FILE NOT FOUND: ` From this we can guess that the script probably wants a file parameter. But what file should we try to download? What about the download script itself?
#/broken/data/download.php?file=download.php
<?php
error_reporting(0);
#FIXME: People might be able to download this file!
function cleanit($v) {
$v=str_replace("", "", $v);
$o=$v;
do {
$v=preg_replace("|/\.*/|", "/", $v);
$v=preg_replace("|^/|", "", $v);
} while($o!=$v && $o=$v);
return $v;
}
$path=cleanit($_GET['file']);
if(!strlen($path) || !file_exists($path)) {
print 'FILE NOT FOUND: '.$path; exit;
} elseif(strpos($path,'protected')===0) {
print 'ACCESS DENIED: '.$path; exit;
}
readfile($path);
?>
If we try to access the directory that download.php is in, we see a sub directory called “protected”. However, nothing appears to be in this directory. If you’ve worked with Apache before, you should know about the .htaccess file. This file contains configuration data and is parsed by Apache when that directory is accessed.
Using protected/.htaccess won’t work thanks to the check with strpos(). If we look at the cleanit() function, we see that it doesn’t sanitize input correctly, and as a result allows one level of directory traversal in either direction. For example, passing a string like "../chuuuuuu.png", will download "chuuuuuu.png" from the parent directory. Using that information, we can direct the download script to get ./protected/.htaccess, which bypasses the strpos() check and gives us the following output:
<files XDONOTOPENX>
order allow,deny
deny from all
</files>
This file prevents access to XDONOTOPENX from the web. However, the download script has no such restriction. Downloading ./protected/XDONOTOPENX with the download script gives us the key.
Inchbinge was the latter of two web challenges I wrote for CSAW CTF. This challenge wasn’t particularly difficult. After getting past the login screen, what had to be done next was usually clear. One issue that some teams had was that they opened the .htaccess file with download.php but forgot to view the source. This confused some people as all they saw was:
order allow,deny deny from all
Nevertheless, most teams were able to complete this challenge and get the key.