How I Discovered a Password Vulnerability

Password security is an increasingly important topic as passwords are often used throughout the average person’s daily life. With so much sensitive information being stored online, it’s now more important than ever to protect your accounts with strong and secure passwords. When using online services, you want to believe your user input and your data in motion and at rest if safe and confidential.

I want to believe this myself, and I did for quite some time until I started studying cybersecurity and even more so when it became a reality for me as I took these steps to discover how a service used nationwide in my company was letting us all down, exposing our passwords:

From the index of hxxps[://]Company.domain.com/ , click the Use Your Allowance Here button.

Doing so sparks a new HTTP request to grab hxxps[://]Company[.]domain[.]com/NetData/Company/Logon[.]d2w/report? followed by a unique session ID in the URL. From this page, click the Log-in hyperlink under Account which keeps the URL the same hxxps[://]Company[.]domain[.]com/NetData/Company/Logon[.]d2w/report?

Click Forget your ID/Password? Click Here. to request hxxps[://]Company[.]domain[.]com/NetData/NetKommerce/ForgetPasswordv2[.]d2w/input? (a session ID will automatically populate in the URL - the server will serve a blank page without it)

Type in a few random letters in the password field and then press the Email My User ID/New Password button.

The next page will prompt Please try again Once you click the again hyperlink, a new path is served hxxps[://]Company[.]domain[.]com/NetData/Company/ForgetPassword[.]d2w/input?

The biggest flaw is the ForgetPassword[.]d2w script in the /NetData/Company path which instructs the server to output 3 database values to the email linked to a valid domain account a user registers.

The email content I received when replicating the issue is as follows:

User ID : jacvb
Email : jacvb@company.com
Password : 700MOULMEIN709

This email shows my password in plaintext, meaning it was never hashed in the database to begin with. This was shocking to me as I was well aware the implications of this — if that database is dumped, all the employees at my company who used this third-party apparel site could fall victim to an account takeover. The biggest insecurity here was due to the fact that most users re-use passwords. A privileged user at the company could easily have their work email or workstation compromised, leading to calamity.

I knew the database needed some form of hashing enabled and the Company/ForgetPassword[.]d2w file should be deleted. Knowing this was third party site, I took it upon myself to Google Dork key phrases containing the online store only to find my company was not the only one affected by this bad practice the Third-Party company and web-developers were using. Each client seemed to have the same source code in their personalized sites, meaning the same steps could be taken to find out if their passwords were hashed, and they weren’t.

I reached out to the company responsible for creating the sites only to never receive word back. My hope was to inform them about the security flaw and to not only secure thousands of users’ information, but mine as well.

Luckily the security team at my company was very receptive of this as I escalated it to them but since none of us had remote server access to this site, the issue could not be resolved on our end which lead to more escalation and security meetings to evaluate the risk.

The issue has now been resolved and the service and data was migrated to a new server with new source code. Whether or not this means the data is now secure, there is only one way to find out..