5 ms·

Unless I'm reading this wrong, wouldn't it require someone generating a new password, then never changing it to something else?

by mkr-hn 12y ago

davio 12y ago
I think that's typical. Not sure if this is the case, but I think the danger would be if you are able to use a "forgot password" link to enable the token.
- tankenmate 12y ago
  Indeed, create a new throw away account; find out where in the PRNG table the password came from for this throw away account. Use that information to guess the next "Reset password" password then use that to hijack the target account.
dspillett 12y ago
It says there is no exploit as yet, but I imagine one would revolve around a malicious user with an account on that instance (either because they should have or because they've gained one via another exploit) using the reset feature to repeatedly reset their own account. If they are able to gain kowledge of the RNG's internal state by using information gleaned from many runs of this process, they can then use the feature against another account and guess the reset token that gets generated, allowing them to gain control of the account without needing to receive the password reset email (which will still go to the right user at that stage). How practical such an attack would be is debatable, but it is certainly possible and perhaps someone more skilled at being a malicious user than I am can thing of something "better".
rossriley 12y ago
I only had a quick look at the affected code but it seems an attack would take the following format. 1: Craft a request to trigger a password reset for the admin account. 2: Then predict the token that would be generated and use this to access the reset and change the password. This would be feasible because the token is predictable if you know the mt seed which is the only random number used in the token generation. Whilst this is not completely straightforward, anyone with access to the machine (including on the same shared host) could easily find out the seed, and of course there are plenty of other vectors for machines leaking this information.
sarciszewski 12y ago
Well, let's assume I can wave a magic wand and predict the next PRNG output. These are the hypothetical next steps to abuse this capability: 1. Create password resets for a non-admin user account whose inbox I can read. 2. Predict the next token that will be issued. 3. Request a password reset for the blog owner. 4. Use predicted token to change the admin password. The solution is to use a true CSPRNG with access to high-quality entropy (i.e. /dev/urandom) rather than relying on a userspace RNG based on mt_rand(), uniqid(), and fast cryptographic hash functions. The lion's share of criticism I've received is that the userspace CSPRNG is good enough to stop this attack. I subscribe to the "use urandom" school of thought that even the most paranoid yet well-informed crypto experts subscribe to. The rest of the criticism I've received was in the realm of "why bother, just SQLi one of the horribly written WordPress plugins they'll inevitably install?"

Unless I'm reading this wrong, wouldn't it require someone generating a new password, then never changing it to something else?

by mkr-hn 12y ago

Unless I'm reading this wrong, wouldn't it require someone generating a new password, then never changing it to something else?

davio 12y ago

I think that's typical. Not sure if this is the case, but I think the danger would be if you are able to use a "forgot password" link to enable the token.

tankenmate 12y ago
Indeed, create a new throw away account; find out where in the PRNG table the password came from for this throw away account. Use that information to guess the next "Reset password" password then use that to hijack the target account.

dspillett 12y ago

It says there is no exploit as yet, but I imagine one would revolve around a malicious user with an account on that instance (either because they should have or because they've gained one via another exploit) using the reset feature to repeatedly reset their own account. If they are able to gain kowledge of the RNG's internal state by using information gleaned from many runs of this process, they can then use the feature against another account and guess the reset token that gets generated, allowing them to gain control of the account without needing to receive the password reset email (which will still go to the right user at that stage). How practical such an attack would be is debatable, but it is certainly possible and perhaps someone more skilled at being a malicious user than I am can thing of something "better".

rossriley 12y ago

I only had a quick look at the affected code but it seems an attack would take the following format. 1: Craft a request to trigger a password reset for the admin account. 2: Then predict the token that would be generated and use this to access the reset and change the password. This would be feasible because the token is predictable if you know the mt seed which is the only random number used in the token generation. Whilst this is not completely straightforward, anyone with access to the machine (including on the same shared host) could easily find out the seed, and of course there are plenty of other vectors for machines leaking this information.

sarciszewski 12y ago

Well, let's assume I can wave a magic wand and predict the next PRNG output. These are the hypothetical next steps to abuse this capability: 1. Create password resets for a non-admin user account whose inbox I can read. 2. Predict the next token that will be issued. 3. Request a password reset for the blog owner. 4. Use predicted token to change the admin password. The solution is to use a true CSPRNG with access to high-quality entropy (i.e. /dev/urandom) rather than relying on a userspace RNG based on mt_rand(), uniqid(), and fast cryptographic hash functions. The lion's share of criticism I've received is that the userspace CSPRNG is good enough to stop this attack. I subscribe to the "use urandom" school of thought that even the most paranoid yet well-informed crypto experts subscribe to. The rest of the criticism I've received was in the realm of "why bother, just SQLi one of the horribly written WordPress plugins they'll inevitably install?"