As usual I'm a little behind on the blogging. The results from the first round of codegate are up, you can see them at http://hacking.beist.org/. On of the CLGT members posted a post event summary from his perspective at http://vnsecurity.net/Members/lamer/archive/2009/03/11/codegate2009/
I noticed that I got blog hits from people looking for clues or solutions through google et al. I didn't get a team and had several other commitments, so I thought I would post the only challenge I got around to solving...#8. Solution after the break.
I noticed that I got blog hits from people looking for clues or solutions through google et al. I didn't get a team and had several other commitments, so I thought I would post the only challenge I got around to solving...#8. Solution after the break.
Codegate 2009 Challenge 8 was a web based challenge. I am writing the solution from memory a few days later so there might be some inconsistencies.
Visiting the challenge url presented a admin access denied for ip xxx.xxx.xxx.xxx style error message. A quick look at the html source revealed a clue;
Viewing the file index.php.bak revealed php code similar to this:
So the answer was obfuscated in the source, otherwise it would have been too easy. Still it wasn't too hard. It's a variation of the many $_REQUEST vulnerabilities. the two extracts will globalize the variables and since there is no namespace you can overwrite $_SERVER variables by supplying a variable with the same name in your cookie. However there are some str replace rules to "prevent" such activity. However they suffer from matching inaccuracies.
So we fire up tamper data in firefox, refresh the page and add the following cookie to the request;
The str replace will match and transform the value as follows:
12 will match and remove 12 letting the leading 1 and trailing 2 form a new 12 -> 1277..00..00..1 and so it goes. 7. -> 127.00..00..1. 0. -> 127.0.0.1. Game over! This reveals the answer. It was something like:
Visiting the challenge url presented a admin access denied for ip xxx.xxx.xxx.xxx style error message. A quick look at the html source revealed a clue;
<!--
Source: index.php.bak
-->
Viewing the file index.php.bak revealed php code similar to this:
<?php
$answer="#######';
extract($_SERVER); extract($_COOKIE);
$ip=$REMOTE_ADDR;
if (isset($_COOKIE[REMOTE_ADDR]) {
$ip=str_replace("12","",$ip);
$ip=str_replace("7.","",$ip);
$ip=str_replace("0.","",$ip);
}
if ($ip == "127.0.0.1) {
print "Hello admin, the answer is: $answer";
} else {
print "Access denied for ip: $ip";
}
?>So the answer was obfuscated in the source, otherwise it would have been too easy. Still it wasn't too hard. It's a variation of the many $_REQUEST vulnerabilities. the two extracts will globalize the variables and since there is no namespace you can overwrite $_SERVER variables by supplying a variable with the same name in your cookie. However there are some str replace rules to "prevent" such activity. However they suffer from matching inaccuracies.
So we fire up tamper data in firefox, refresh the page and add the following cookie to the request;
COOKIE=REMOTE_ADDR=112277..00..00..1The str replace will match and transform the value as follows:
12 will match and remove 12 letting the leading 1 and trailing 2 form a new 12 -> 1277..00..00..1 and so it goes. 7. -> 127.00..00..1. 0. -> 127.0.0.1. Game over! This reveals the answer. It was something like:
ohnoes~danger!zombies ahead!!!
