Glassfish brute force login

Product Line: Eclipse GlassFish

• Vulnerable Version: 7.0.15

• Summary: In Eclipse GlassFish version 7.0.15 is possible to perform Login Brute Force attacks. This vulnerability arises when the product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame, making it more susceptible to brute force attacks.

• Prerequisites: No special configurations are required.

Step-by-step instructions and PoC

A remote unauthenticated user can perform Login Brute Force attacks. Successfully exploitation of this vulnerability can allow the administration access to an attacker.

Affected Endpoints • URL: – https://[IP]:[PORT]/j_security_check – https:// [IP]:[PORT]/management/domain • HTTP Parameter: – j_password – Header Authorization

Below there is the evidence with the vulnerability details and the payloads used. As shown in the figure below, an attacker can perform 50 failed login attempts and can login successfully at the 51st to the web application. This behavior occurs because the product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame.

(image)

In the similar way it is possible to perform the same attack’s type, described previously, in the management REST interface, as shown below:

(image)

Security Impact

An attacker can exploit this vulnerability to obtain the administration access within the Administration Console or Management REST Interface. Remediation Steps It is suggested to temporarily disable the account after a certain number of failed attempts. This will prevent attackers from continuing to try to brute-force their way in once they have reached a certain threshold. The account can be automatically re-enabled after a period of time, or the user can be required to contact customer support to have it reset

assigned to @redteamtim, @hsawamura, @smillidge, and @dmisingname3q2

Dear Glassfish team, please have a look at this one @hsawamura @smillidge @dmisingname3q2

Reported: July 15th, 2024

Hi @hsawamura, @smillidge, @dmisingname3q2, we would like to know whether you have any update about this vulnerability. We would like to know whether you can require the reservation of the CVE ID for it. Thank you for cooperation and Best Regards.

Hi team and @mrybczyn, considering the mix-up created through the issue #232 (closed) about the CVE and since you are a CNA, therefore you are responsible for reservation request of CVE IDs and their management, may you keep us up to date regarding this issue please? May you reserve the CVE ID for it and trasmit it to us, please? Thank you and kind regards

Eclipse GlassFish typically requests CVE assignment upon the release of a version containing the fix. As an open-source project with publicly available source code, anyone can contribute fixes and improvements. We welcome your contributions for a swift resolution.

Hi team and @mrybczyn, According to your handbook about the CVEs management (https://www.eclipse.org/projects/handbook/#vulnerability-cve) the procedure is different: The first point of paragraph "General Case" (https://www.eclipse.org/projects/handbook/#general-case), that is called "Request the number", and we quote it "When you know that there is a security issue (the fix is not yet needed at this point), go to the CVE Request form and fill it. Make sure to keep the issue confidential for now. If you want to make the issue visible to multiple project members, add them as assignees when creating the ticket (it will be hard later on)." So you may proceed to require the CVE before you fix the flaws. Then, when the patch is ready, you can publish the CVE, as reported in your handbook in the point "Ask for publication of the issue".

So at this point may you reserve the CVE, please?

According to your handbook about the CVEs management (https://www.eclipse.org/projects/handbook/#vulnerability-cve) the procedure is different:

Yes, unfortunately, the current approach we're taking is different from what's outlined in the handbook. The handbook provides examples of "General case," as the heading says, and not all projects follow them.

We will address all reported issues, including this one, one by one. Is there a specific reason why you need to reserve a CVE ID urgently?

We need to reserve the CVE IDs because of our security internal policies. For this reason we'll appreciate so much whether you may do it. Thank you and kind regards

I understand that there's an agreement we assign a CVE to this issue. We will create an appropriate ticket in a moment.As usual, please use it in a confidential discussion only and only in a discussion about this particular issue: when we publish a CVE, we also make related issues non-confidential and it might be complicated if there are references to other, unpublished CVEs.

Please have a look in https://gitlab.eclipse.org/security/cve-assignement/-/issues/33 if the information is correct as it is. We can update it until the publication date.

@hsawamura, @smillidge, @dmisingname3q2, and @redteamtim please let me clarify the reservation process. The Project (or the researcher) can request a reservation at any point. A fix is not needed. We have projects with different practices.

What is important is to start writing the CVE entry early enough so that everyone agrees on the formulation before publication and do not need to rush just before.

The reservation process is very fast from our side (the EF) and if there's no need for a CVE early, we can reserve it at the last moment. It also limits the risk of an early leak. However, the timeline depends on the needs of everyone.

added vulnerabilityconfirmed label

@hsawamura, @smillidge, @dmisingname3q2 any update on when you expect the fix?

added cvereserved statusawaiting_release labels

Hi team, we would like to know if you have a release date for this vulnerability. Thank you and regards

Gentle ping @hsawamura @smillidge @dmisingname3q2. The researcher would like to have an update on their report. It has been already almost 4 months since they reported it. Thanks!

assigned to @atijmse7y

assigned to @omihalyi

assigned to @avpinchuk

assigned to @pygieo

assigned to @kaido207

@atijmse7y @omihalyi @avpinchuk @pygieo @kaido207, please have a look if you can assist in resolving this issue. Please note that this is a GitLab confidential issue and you need to be logged in to see it. Otherwise you will get a 404.

As shown in the figure below ... Below there is the evidence with the vulnerability details and the payloads used.

I cannot see that.

(image) (image)

I see nothing there.

Hi team, we would like to know if you have any news for this vulnerability. Thank you and regards

Hi team, we would like to know if you have any news for this vulnerability. Thank you and regards

Hi @mrybczyn @mbarbero, could you help us to known if you have a release date for this vulnerability? Thank you and regards

Hi team, we would like to know if you have a release date for this vulnerability. Thank you and regards

Hi , we would like to know if you have any news about the release date for the fix. Thank you and best regards.

Greetings @redteamtim , many thanks for reporting!
We're making this issue public since it has passed number of days expected for responsible vulnerability disclosure.
The mitigation on this issue is expected to happen in the future.
Currently the Glassfish committers have a considerable workload on their hands and since this vulnerability involves brute forcing authentication and GlassFish is not a web server, it has been considered there are greater risks coming from a malicious actor.

made the issue visible to everyone

Hi @tiagolucas, thanks for your feedback. We would like to know when you will publish the CVE on MITRE about this issue, since you have published it here. Thank you and regards

Hi @tiagolucas, we would like to know if you could publish the CVE on MITRE, since you have published it here. Thank you and regards.