Summary

The article discusses the vulnerability CWE-620, "Unverified Password Change," and provides guidance on identifying, reporting, and addressing this security flaw within web applications, emphasizing the importance of multi-factor authentication in password change processes.

Abstract

The article "CVE Hunting Tips #001" by Joe Helle delves into the common security vulnerability known as CWE-620, which involves unverified password changes in web applications. The author explains the ease with which attackers can exploit this vulnerability when applications do not require current password verification or multi-factor authentication for password changes. The article provides practical advice on how to recognize this issue, demonstrating an example where a user's password can be changed without their knowledge or consent, leading to unauthorized access and disruption of user activities. Joe Helle also guides readers through the process of reporting such vulnerabilities using the Huntr.dev platform, detailing the steps from registering on the site to submitting a comprehensive report, including the identification of the vulnerability, severity assessment, and providing a proof of concept. The article underscores the significance of considering both user experience and potential attack vectors when developing applications, and it encourages ethical hackers to contribute to the security community by reporting vulnerabilities responsibly.

Opinions

The author, Joe Helle, emphasizes the importance of considering the attacker's perspective during web application pentesting to ensure robust security measures.
He suggests that critical access points in applications should always be protected by at least a second factor of authentication, and ideally, by multi-factor authentication.
The article conveys that the process of reporting vulnerabilities can be subjective, particularly in assessing severity, and that maintainers may adjust the reported severity.
Joe Helle expresses appreciation for the Huntr.dev platform and its goals, indicating his support for its effectiveness in the ethical hacking community, despite not being formally affiliated with the platform.
The author acknowledges the challenge of waiting for responses from maintainers due to varying response times, and advises to check the repository information on Huntr.dev for estimated response times before engaging deeply with a project.
He encourages readers to learn from his experiences and to actively participate in finding and reporting vulnerabilities, contributing to the overall security of web applications.

CVE Hunting Tips #001

Unverified Password Change

Introduction

In today’s article we’ll talk about a super easy to find vulnerability covered under CWE-620 — Unverified Password Change. At the end of the article, we’ll go through the Huntr.dev submission process and what to expect from submission to validation and beyond using one of my previously reported findings.

Users authenticate to applications multiple times a day. Oftentimes users will use a password that has meaning to them, such as a boyfriend or girlfriend, a pet, or something else. Sometimes applications require a password to be changed on a rotating bases, and users will move from Spring2022! to Summer2022! to Fall2022! and beyond. Other times the password could be completely irrelevant to them, and they are simply using a strong password.

Password Changes

No matter the purpose of a password change, it’s incredible common to need to do so. When we think about web application pentesting (which is how I’ll refer to bug hunting for the most part), we try to think from the perspective of an attacker. When we think about unauthenticated access, we’re considering how an attacker is trying to gain a foothold. When we think about authenticated access, we’re thinking about how the attacker got there, and what they can do.

So, what does an unverified password change look like?

Can you spot the issue here? As we think about web application security and the perspective of an attacker, we can clearly see the problem in this instance. Let’s theorize for a moment. Jane has stood up from their workstation in an office without logging out, and Bill Bad Guy in the next cubicle sees it. Bill jumps onto Jane’s computer, clicks the change password button, and changes the password without knowing Jane’s current one.

In this case, Bill Bad Guy was unchecked in changing the password because there was no second method of authenticating the person actually changing it. When Jane comes back, they can no longer access the web application, and Jane is unable to do their job duties.

What Should We Do?

As a developer, it’s vitally important to consider every action in an application not only from the user experience perspective, but the attacker’s as well. Critical access points in applications should always be protected by at least a second factor of authentication. In this case, the application should require the current password at a minimum. Ideally the application could require MFA authentication to the application, as well as an MFA token to modify those critical points.

We Found It, Let’s Report It

We’ll use a recent submission I put on Huntr.dev as an example. I’m going to blur out some of the details so that you all put the effort into finding some of these on your own.

First you’ll need to register on the website, which is pretty self-explanatory. Once you’ve logged in, click the Submit Report button at the top of page. After doing so, you’ll be met with something that looks like this.

The first item is to list the actual repository. Literally any repository on Github is eligible, so don’t feel like you have to chase big fish. Any fish work here.

Once you’ve listed the repository, you can list the Package Manager, if applicable. After that, list the Version Affected. This can usually be found on the repo itself, either in the tags, or in the releases section on the right of the Github repository.

Moving on, next you identify the name of the actual vulnerability. The platform utilizes the CWE system, and in this case it’s CWE-620. You can type in the beginning of the title of the CWE listing (Unverified Password Change in this case). It’s vitally important that you list the vulnerability name appropriately as it not only helps the maintainer, but also your platform rating.

Next is severity. This is a bit more of a subjective process, but you may need to do some research into the appropriateness of each rating. There are plenty of CVSS calculator guides online, including the one listed on the site itself. In this case, the attack can happen on a network, the complexity is low, some amount of privileges are required, the actual user does not have to interact with it, the scope does not change, Confidentiality is low, Integrity is high, and Availability is high. Again, these can be pretty subjective, so do your best, and don’t be surprised if a maintainer wants to reduce severity a bit.

Next is the Write-Up and Impact sections. These use Markdown, and if you’re anything like me, you don’t have experience with it. So, take your time to learn some of the basics and how to make your report stand out. Here you want to leave the description of the vulnerability so that the maintainer has a clear understanding of it and include a Proof of Concept of your exploitation. This can include some basic steps for exploitation (as is the case with password changes), or code blocks used for exploitation.

The Impact is where you explain why the vulnerability is of concern in the application.

Following impact is the Occurrences and References sections. The Occurrences section is undoubtedly the most difficult part of the process, as you need to search out the approximate location of the vulnerable code in the repository. I honestly do my best here, but I’m not a developer. If I don’t know exactly where it’s at, I say that in the description. References is your opportunity to list information for the maintainer to understand more about the vulnerability, if necessary.

Once you’re done with that you can preview the results at the bottom and click the submit button. The platform will notify the repository maintainer in 24 hours, and then the wait begins. You can see a verified report of mine for Unverified Password Changes here.

The Worst Part — Waiting

As many of the projects you’ll find or submit are maintained by small teams or individuals, it may take a bit to get a response back on your submission. These wait times can be wildly different, with some occurring in the same day, and some I’ve been at nearly 30 days on. The best thing you can do is to look at the repository information on Huntr.dev itself to see what those response times are. The scores vary from A+ to F and look something like the following, and I definitely recommend looking at these scores before deciding to jump in too deeply with projects.

Next Up

In the next article we’ll go over another recent finding of mine, a Text Input Denial of Service attack. Future articles won’t include the specifics on the Huntr.dev process, so make sure to check back in here if you need information on it in the future.

Joe Helle is a Red Team Lead, former mayor, and creator of Movement, Pivoting, and Persistence for Pentesters and Ethical Hackers course. Joe holds multiple web application CVEs. See what Joe is working on at https://www.themayor.tech.

I am not affiliated with, sponsored or paid by Huntr.dev. I simply appreciate the platform and its goals, and the success I’ve had on it so far.