Response to CVE-2023-26756

from the Revive Adserver project team

Our response to the CVE-2023-26756 report.

Date: April 22, 2024

Introduction

CVE-2023-26756 has been recently filed against the Revive Adserver project. The action was taken without first contacting us, and it did not follow the security process that is thoroughly documented on our website. The project team has been given no notice before or after the disclosure. Our team has been made aware of this report by a community member via a GitHub issue. All of this resulted in an inability for us to produce an appropriate statement beforehand, so this blog post can be considered as our response to it.

Not a vulnerability in Revive Adserver

The project team rejects this disclosure assertion of a vulnerability in Revive Adserver v5.4.1, and in fact of any later version.

Firstly, the proof of concept of the new report is essentially a duplicate of the existing HackerOne report #961115, which we received back in 2016, and which ultimately resulted in the release of Revive Adserver 3.2.3 on March 2nd, 2016, containing the fix to CVE-2016-9124, properly disclosed in our security advisory REVIVE-SA-2016-001.

Quoting that advisory:

An account lockdown feature was considered, but rejected to avoid introducing service disruptions to regular users during such attacks. A random delay has instead been introduced as a counter-measure in case of password failures, along with a system to discourage parallel brute forcing. These systems will effectively allow the valid users to log in to the adserver, even while an attack is in progress.

Going into more detail, we introduced a random delay of 1-5 seconds in the response in case of failed authentication, which by itself should slow down any brute forcing attempt. On top of that, while an authentication is being processed, any other concurrent attempt is being applied a 4 times longer delay than the above before even checking the credentials, resulting in much higher response delays for each attempt when trying to massively brute force a system.

In our opinion this could be considered a rate limiting mechanism, whereas CVE-2023-26756 mentions “Lack of rate limiting” as one of the reasons to claim the software is vulnerable. This part of the counter measure against brute force attempts had thus been in place for over 7 years at the time CVE-2023-26756 was published.

Secondly, CVE-2023-26756 claims the system allows weak passwords, whereas the release of Revive Adserver 5.4.0 on April 14, 2022, brought a default password length requirement of at least 12 characters and the usage of the zxcvbn library to give a visual hint of the actual password strength. Ultimately it is the user who is responsible if they decide to use a weak password, or if they’re not guarding their password closely.

Thirdly, looking into the PoC image in CVE-2023-26756, we can see an apparently non-weak 12-character alphanumeric password being found at the 212th brute force request, from what seems to be a specifically crafted dictionary. We consider that to be an unrealistic scenario.

In conclusion

We are of the opinion that it is reasonable to reject the vulnerability assertion, since we are convinced our application offers sufficiently powerful tools against brute force attacks.

Future improvements

Just like any responsible open source project, we take security of the application extremely seriously. We are considering implementing changes to make brute force attacks even harder than they are now, and are also considering forms of account lockdowns, or implementing multi-factor authentication.

Please follow responsible disclosure procedures

Over the years, we’ve been diligently dealt with any security vulnerability that has been reported to us through our documented process and our HackerOne disclosure program.

We take security very seriously and we firmly believe that responsible disclosure benefits everybody that is involved in the process.