ATUTOR SWU CODE
we have the next important lines of code, as we see there, first checks if the POST parameter is set, if we look back at figure 2 we can see that it is, then stores the values from the parameters “form_login_hidden” and “form_login” at the variables $this_password and $this_login and finally sets the variable $used_cookie to falseĪfter the code showed in figure 5, the app uses $addslashes() on both variables ($this_password and $this_login) but as we saw in the previous post this does not do anything.įinally we can see the next important piece of code in the image from below. are not that important to exploit the vulnerability, so let’s just jump to the next important piece of code, see figure 5.įigure 5.
This means that if we change the request and add that parameter we can set it to whatever we want. If we look back at the login request from Figure 2. microtime(TRUE)) īasically is checking if the post parameter “token” is set and if it is, then does: $_SESSION = $_POST Code from login_Īt figure 4 we have the first lines of code from login_ and the first three lines are very important to exploit this authentication bypass there’s not too many things there but we can see that is including two files, and login_, since we are trying to understand how the login proccess works, let’s go and take a look at the login_functions file.įigure 4. Below we have a picture of the contents of login.php fileĪs we see in figure 3. Now that we know how the login request looks, we can start reading the source code to see how the login process works.
ATUTOR SWU PASSWORD
Note that the form_password_hidden is not a plaintext password (i used te credentials test:test), so we should take a look about how that hash is generated. Form_login_action=true&form_course_id=0&form_password_hidden=ef54344395c598213ae8345db480c6916a25c75a&p=&form_login=test&form_password=&submit=Loginįrom those parameters three of them look interesting, those are “form_password_hidden”, “form_login” and “form_password”
0 kommentar(er)
