Security issue - Pagekit's request password feature allows user acc enumeration #935
Comments
|
Whilst a valid point, to be fair Pagekit isn't the only CMS with such
security issue. Do you have any code to submit that can address this issue?
…On Wed, Sep 18, 2019, 6:14 PM Steve ***@***.***> wrote:
Problem
Hi,
When a user is requesting to reset his password using a valid email
account, Pagekit gives the following response.
[image: image]
<https://user-images.githubusercontent.com/53895017/65129478-ef9df200-da2d-11e9-95f6-c2b25c15e322.png>
However, when an invalid em upail account is submitted, Pagekit notifies
user that the particular email account cannot be found.
[image: image]
<https://user-images.githubusercontent.com/53895017/65129529-10664780-da2e-11e9-83c9-b4bf32a2fd46.png>
Leveraging on this, the attacker can use a list of emails to enumerate the
valid user accounts based on the response of the server.
Recommendation: It is recommended to give generic responses when user
inputs his email address for recovery e.g. "If this email exists, you will
receive an email with the reset instructions." in order to prevent user
account enumeration.
OWASP ref:
https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002)
Technical Details
- Pagekit version: 1.0.17
- Webserver: Apache/2.4.39
- Database: MySQL
- PHP Version: 7.2.21
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#935?email_source=notifications&email_token=ADCGLCNPXCVW5RBDNZVZZWDQKHPQDA5CNFSM4IX3BRMKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HMCBQBQ>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADCGLCPEDY2OEAHDXKV65VTQKHPQDANCNFSM4IX3BRMA>
.
|
|
Hi terfex, Thank you for the quick response. I am not sure where the exact code is located, but you could just change the error message for the "Forgotten Password" function so that it does not indicate if the submitted email is valid or not. Regards, |
|
It might not be sufficient to use a generic message. A 'kiddie script' isn't going to read whatever is rendered in the message anyway, and may keep trying no matter what is displayed. It might be a better option to cause a timeout of 5/10/15 minutes after X number of failed attempts from the same IP. It shouldn't matter if the function is for logging in, confirming user registrations, or retrieving/resetting passwords... it's better to limit credential related functionality from abuse. At some point it becomes obvious that the real mission isn't to reset someone's password, but to figure out what user name/email can be used for a brute-force login attempt, or even to initiate a DoS attack on the site. |
|
Another solution could be to implement a honeypot with a blank field or a
reCaptcha.
Whilst changing a message may not be sufficient, it certainly help give
less clues away. Even if obscurity is not security.
…On Tue, Nov 12, 2019, 8:41 PM humantex ***@***.***> wrote:
It might not be sufficient to use a generic message. A 'kiddie script'
isn't going to read whatever is rendered in the message anyway, and may
keep trying no matter what is displayed. It might be a better option to
cause a timeout of 5/10/15 minutes after X number of failed attempts from
the same IP. It shouldn't matter if the function is for logging in,
confirming user registrations, or retrieving/resetting passwords... it's
better to limit credential related functionality from abuse.
At some point it becomes obvious that the real mission isn't to reset
someone's password, but to figure out what user name/email can be used for
a brute-force login attempt, or even to initiate a DoS attack on the site.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#935?email_source=notifications&email_token=ADCGLCMMWY5BJEVQF3CTQFTQTJ23NA5CNFSM4IX3BRMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDZUOKI#issuecomment-552814377>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADCGLCKXA67YY2MIXGWZIBDQTJ23NANCNFSM4IX3BRMA>
.
|
|
These sound like reasonable options too. Anything to address the original issue and adds another dimension onto it at the same time is a win-win. As for obscurity not being security... This is exactly the direction things are headed: https://www.techradar.com/news/businesses-are-replacing-vpns-with-zero-trust-network-access |
Bug BountyWe have opened up a bounty for this issue on our bug bounty platform. Want to solve this vulnerability and get rewarded 💰? Go to https://huntr.dev/ We will submit a pull request directly to your repository with the fix as soon as possible. Want to learn more? Go to https://github.com/418sec/huntr 📚 Automatically generated by @huntr-helper... |
|
@huntr-helper ... Perhaps you (or your bot), might like to include a link to said bounty when these comments are inserted into issue queues. After browsing what seems to be your GitHub bounty board, I see no listing that's obvious for this issue. Without some real clarity, this looks like no more than an advertisement from a bot. |
|
@humantex - thanks for your feedback! This is definitely a great idea and we will track this as an issue on our backlog. We were slightly delayed from the comment being made to the bounty being published on our platform. Thanks! 🍰 Edit: Please reference the URL - https://www.huntr.dev/app/bounties/open/1-packagist-pagekit. |
|
🛠️ A fix has been provided for this issue. Please reference: 418sec#1 🔥 This fix has been provided through the https://huntr.dev/ bug bounty platform. |
|
@huntr-helper ... I can appreciate the effort to address this issue, but maybe I'm missing something. The fix you've selected proposes modifying the response provided by Pagekit's code by changing a text string - not by altering the behavior of the code that produces the underlying problem itself. The 'new' response might be meaningful to legitimate users, but it utterly misses the point where malicious scripts are hammering a vulnerability in order to gain credential confirmations for further exploits. Script kiddies will unleash their attacks and not care one iota about what Pagekit's on-screen textual response will be. Their script will keep running for 'X' iterations, or 'X' amount of time, and as long as it receives any response, it will continue until 'X' happens - OR - it succeeds. If some bad actor decides that this might also be a great way to launch a DoS attack on a Pagekit or other similarly affected sites, it offers no way to disconnect the core code from providing further responses. An attack script doesn't 'read' the response this fix will give, and it just keeps going until stopped. Nothing is changed by rewording the text. This proposal might satisfy one aspect of the issue, but IMHO, it does little to fix the deeper security problem. It doesn't create a timeout from a requesting IP to continue without further requests, nor does it create a cookie to set a flag for a reset request and/or a number of tries to block more requests, and/or send an admin notification after X tries to alert the site owner there's user abuse, and/or there's a potential attack under way. The abuse potential remains, no matter what the on-screen textual response is to the request. In any event, there's also the question of how any proposed bounty fix would make it into a Pagekit update when there's no apparent involvement of Pagekit's authors and its developer - i.e., YOOTheme. Have they been involved in the bounty process in some way to facilitate any fix getting merged into Pagekit's code? They haven't responded to the initial 11 month old report made in September of 2019 by @cobbler987, and not every Pagekit user is capable of making their own code changes -and- when we/they do, they would be overwritten for any future updates provided by and with YOOTheme's approved code. At that moment - it's all rendered useless. |
|
Fully agree to @humantex. Here a "solution" got accepted by @JamieSlome that does not solve the issue at all. You are redirected to a different page based on the result which gives a possibility to enumerate. It is unlikely that this will ever make it to pagekit and the whole process is a little bit intransparent. The fix done in biskuit [1] solves the issue in most cases, but is still not complete. It is still possible to enumerate blocked accounts and any account in case sending the reset email fails. So, even there more work needs to be done ... |
Problem
Hi,
When a user is requesting to reset his password using a valid email account, Pagekit gives the following response.
However, when an invalid email account is submitted, Pagekit notifies user that the particular email account cannot be found.
Leveraging on this, the attacker can use a list of emails to enumerate the valid user accounts based on the response of the server.
Recommendation: It is recommended to give generic responses when user inputs his email address for recovery e.g. "If this email exists, you will receive an email with the reset instructions." in order to prevent user account enumeration.
OWASP ref: https://www.owasp.org/index.php/Testing_for_User_Enumeration_and_Guessable_User_Account_(OWASP-AT-002)
Technical Details
The text was updated successfully, but these errors were encountered: