Vulnerability

[atthacks]

Hey @mprahl

Hope you are well. First of all, I want to say I really like this application. Some really good work 👍

I believe I have found a vulnerability in this application.

I have tried connecting with you on LinkedIn - please reach out to me on there to discuss.

I can see from other comments that ADReset is not actively maintained and you have developed a version 2. So I understand you may not implement a fix for this. If you're happy for me to publish the findings publicly now then I'm happy to do so?

If I don't hear back from you in 1 week, I'll proceed to publish the findings as I'll assume its something that you don't want to invest anymore time in. This should hopefully then give others who have implemented this application to start working on a fix themselves if they wish to do so.

Thanks

[mprahl]

@atthacks this project is not maintained, however, if the issue is severe and is an easy fix, I may attempt to fix it.

[atthacks]

@mprahl no problem. I suspected this may have been the case. I'll finish putting together the writeup and post it on here hopefully later today.

[atthacks]

ADReset Escalation of privileges

I have noticed a really simple way of escalating privileges while using ADReset. I first noticed this after I implemented this awesome application on a purposely vulnerable VM which I am currently working on. However, in my case the privilege escalation method was not intended to be this route and found it while testing my machine. I thought the findings should be shared to allow real life use cases to remediate appropriately.

Just for clarity, I tested ADReset on a Windows Server 2019 machine. Most of the screenshots below are taken from Kali while testing.

High level steps: • Using PowerShell, run a command to get the guid of the user you want to takeover • Log into MySQL which has the adreset database • Insert a row into emailreset and browse to reset page • Change password

Elevation of privileges is accomplished through abusing the permissions granted to the adresetuser user in the MySQL backend which then allows you to do a password reset on any AD user account. So, in order for this to work you will need to know what these credentials are or a MySQL user with insert access to one of the tables (emailreset). In my instance the file containing the credentials is located at c:\inetpub\adreset\resources\core\init.php. Additionally, it's worth noting that the account you want to take over does NOT need to be registered for password resets.

Many users within a business may have the appropriate permissions, either through misconfiguration or by design with users such as Developers and DBA's.

First, we need to get the guid of the user we wish to conduct the password reset on. We can get this with the PowerShell command below. I have created a user jane_admin specifically for this demonstration.

powershell { (get-aduser -identity jane_admin).ObjectGUID }

Next we need to log into mysql then go into the adreset database.

Even though I do not have the email reset feature enabled - we still need to add an entry to the emailreset table.

Looking at the columns of the table.

Excluding id we have three fields to supply. userguid we have from the PowerShell command ran earlier, code can be anything we want and createtime should be set to NOW().

INSERT INTO emailreset (userguid, code, createtime) VALUES ('971660b2-341e-4b2a-8169-99764935c1e6', 'blahblahblah', NOW())

Now just navigate to the reset page http://Your-IP-Address/newpw.php?idq=blahblahblah.

The user jane_admin does not have any secret questions set up and does not have email reset functionality enabled. However we are now prompted to supply a new password for her account.

Notice the idq value will be the same as what we inserted for code into the emailreset table earlier.

I typed a new password and clicked Set Password and had a success message.

So in a nutshell to wrap up - if you have enough rights in MySQL (either adresetuser or another account), then you can very easily reset any users password regardless if they have set themselves up for password reset or not.

As this project is no longer maintained, hopefully it will help highlight the issue to users and help them either mitiage, risk accept or implement a fix themselves. Alternatively I see that @mprahl now has a version 2 located here https://github.com/mprahl/ADReset2 which you may want to consider and an option.

[mprahl]

@atthacks this seems like an already understood risk that if you give an application rights to external systems that you should guard where it stores those credentials. Therefore, this is not really a vulnerability considering you need write access to the MySQL database. The vulnerability you point out is actually in the configuration of the database.

Sure, the application could make it harder for an attacker by verifying that the user has email resets enabled but if you have write access, you can just enable this in the database. The application could sign all configuration entries, secret questions, and one time codes for email resets. This would mean the attacker would have to both get access to the local application configuration and the database. In my opinion, ADReset would more likely be compromised by someone getting access to the local configuration which gives them the encryption key and database service account. So you still have a single point of failure.

If you'd like to open a ticket requesting the functionality I described above, please feel free. Additionally, you can file a PR that adds a warning in the documentation that if the database is compromised that ADReset is also compromised. Since I don't think this is a vulnerability in the application, I will close this issue.

Thanks for reporting your concern!