Not properly invalidated session vulnerability in Graylog Web Interface, version 2.2.3, due to incorrect management of session invalidation after new logins. The application generates a new 'sessionId' each time a user authenticates, but does not invalidate previously issued session identifiers, which remain valid even after multiple consecutive logins by the same user. As a result, a stolen or leaked 'sessionId' can continue to be used to authenticate valid requests. Exploiting this vulnerability would allow an attacker with access to the web service/API network (port 9000 or HTTP/S endpoint of the server) to reuse an old session token to gain unauthorized access to the application, interact with the API/web, and compromise the integrity of the affected account.

A Session ID leak in the audit log in Graylog before 4.1.2 allows attackers to escalate privileges (to the access level of the leaked session ID).

A Session ID leak in the DEBUG log file in Graylog before 4.1.2 allows attackers to escalate privileges (to the access level of the leaked session ID).

Summary

Arbitrary classes can be loaded and instantiated using a HTTP PUT request to the /api/system/clusterconfig/ endpoint.

Details

Graylog's cluster config system uses fully qualified class names as config keys. To validate the existence of the requested class before using them, Graylog loads the class using the class loader.

https://github.com/Graylog2/graylog2-server/blob/e458db8bf4f789d4d19f1b37f0263f910c8d036c/graylog2-server/src/main/java/org/graylog2/rest/resources/system/ClusterConfigResource.java#L208-L214

PoC A request of the following form will output the content of the /etc/passwd file:

curl -u admin:<admin-password> -X PUT http://localhost:9000/api/system/clusterconfig/java.io.File \ -H "Content-Type: application/json" \ -H "X-Requested-By: poc" \ -d '"/etc/passwd"'

To perform the request, authorization is required. Only users posessing the clusterconfigentry:create and clusterconfigentry:edit permissions are allowed to do so. These permissions are usually only granted to Admin users.

Impact

If a user with the appropriate permissions performs the request, arbitrary classes with 1-arg String constructors can be instantiated.

This will execute arbitrary code that is run during class instantiation.

In the specific use case of java.io.File, the behaviour of the internal web-server stack will lead to information exposure by including the entire file content in the response to the REST request.

Credits

Analysis provided by Fabian Yamaguchi - Whirly Labs (Pty) Ltd

Impact

Graylog users can gain elevated privileges by creating and using API tokens for the local Administrator or any other user for whom the malicious user knows the ID.

For the attack to succeed, the attacker needs a user account in Graylog. They can then proceed to issue hand-crafted requests to the Graylog REST API and exploit a weak permission check for token creation.

Workarounds

In Graylog version 6.2.0 and above, regular users can be restricted from creating API tokens. The respective configuration can be found in System > Configuration > Users > "Allow users to create personal access tokens". This option should be Disabled, so that only administrators are allowed to create tokens.

Recommended Actions

After upgrading Graylog from a vulnerable version to a patched version, administrators are advised to perform the following steps to ensure the integrity of their system:

Review API tokens An overview of all existing API tokens is available at System > Users and Teams > Token Management. Please review this list carefully and ensure each token is there for a reason.

Check Audit Log (Graylog Enterprise only) Graylog Enterprise provides an audit log that can be used to review which API tokens were created when the system was vulnerable. Please search the Audit Log for action:create token and match the Actor with the user for whom the token was created. In most cases this should be the same user, but there might be legitimate reasons for users to be allowed to create tokens for other users. If in doubt, please review the user's actual permissions.

Review API token creation requests Graylog Open does not provide audit logging, but many setups contain infrastructure components, like reverse proxies, in front of the Graylog REST API. These components often provide HTTP access logs. Please check the access logs to detect malicious token creations by reviewing all API token requests to the /api/users/{userid}/tokens/{tokenname} endpoint ({userid} and {tokenname} may be arbitrary strings).

Graylog before 3.3.3 lacks SSL Certificate Validation for LDAP servers. It allows use of an external user/group database stored in LDAP. The connection configuration allows the usage of unencrypted, SSL- or TLS-secured connections. Unfortunately, the Graylog client code (in all versions that support LDAP) does not implement proper certificate validation (regardless of whether the "Allow self-signed certificates" option is used). Therefore, any attacker with the ability to intercept network traffic between a Graylog server and an LDAP server is able to redirect traffic to a different LDAP server (unnoticed by the Graylog server due to the lack of certificate validation), effectively bypassing Graylog's authentication mechanism.

Impact It is possible to obtain user session cookies by submitting an HTML form as part of an Event Definition Remediation Step field. For this attack to succeed, the attacker needs a user account with permissions to create event definitions, while the user must have permissions to view alerts. Additionally, an active Input must be present on the Graylog server that is capable of receiving form data (e.g. a HTTP input, TCP raw or syslog etc).

Patches

Workarounds None, as long as the relatively rare prerequisites are met.

Analysis provided by Fabian Yamaguchi - Whirly Labs (Pty) Ltd

Impact

A security issue has been identified in Graylog affecting the parsing of syslog messages that use a key-value format, such as those generated by Fortigate devices.

The vulnerability allows attackers to overwrite individual message fields, or to produce invalid messages which Graylog will discard. This effectively enables log evasion techniques to obscure malicious activity.

Patches

The issue has been fixed in the following Graylog versions: 6.3.12, 7.0.7, 7.1.2. Users should upgrade to one of these versions or above to remediate the vulnerability.

Graylog Cloud has already been patched.

Workarounds

There are no feasible workarounds for this issue. Upgrading to a patched version is recommended.

To find potentially discarded messages due to parsing errors, customers of Graylog Enterprise or Security can check the Indexing and Processing Failures Index[^1].

Credits

Thanks to Jose Luis González, from Fundación Sarenet, with additional analysis by Borja Marcos from Sarenet.

[^1]: https://go2docs.graylog.org/current/gettinginlogdata/indexerandprocessingfailures.html

Impact

The reporting functionality in Graylog allows the creation and scheduling of reports which contain dashboard widgets displaying individual log messages or metrics aggregated from fields of multiple log messages. This functionality, as included in Graylog 6.1.0 & 6.1.1, is vulnerable to information leakage triggered by multiple concurrent report rendering requests from authorized users.

When multiple report renderings are requested at the same start time, the headless browser instance used to render the PDF will be reused. Depending on the timing, either a check for the browser instance "freshness" hits, resulting in an error instead of the report being returned, or one of the concurrent report rendering requests "wins" and this report is returned for all report rendering requests that do not return an error. This might lead to one user getting the report of a different user, potentially leaking indexed log messages or aggregated data that this user normally has no access to.

Patches This problem is fixed in Graylog 6.1.2.

Workarounds There is no known workaround besides disabling the reporting functionality.

References

Improper Access Control (IDOR) in the Graylog API, version 2.2.3, which occurs when modifying the user ID in the URL. An authenticated user can access other user's profiles without proper authorization checks. Exploiting this vulnerability allows valid users of the system to be listed and sensitive third-party information to be accessed, such as names, email addresses, internal identifiers, and last activity. The endpoint 'http://<IP>:12900/users/<myuser>' does not implement object-level authorization validations.

Impact Starting with 6.1, HTTP Inputs can be configured to check if a specified header is present and has a specified value to authenticate HTTP-based ingestion. Unfortunately, even though in cases of a missing header or a wrong value the correct HTTP response (401) is returned, the message will be ingested nonetheless.

Patches

Workarounds Disabling http-based inputs and allow only authenticated pull-based inputs.

Analysis provided by Fabian Yamaguchi - Whirly Labs (Pty) Ltd

Reflected Cross-Site Scripting (XSS) vulnerability in the Graylog Web Interface console, version 2.2.3, caused by a lack of proper sanitization and escaping in HTML output. Several endpoints include segments of the URL directly in the response without applying output encoding, allowing an attacker to inject and execute arbitrary JavaScript code when a user visits a specially crafted URL. Exploitation of this vulnerability may allow script execution in the victim's browser and limited manipulation of the affected user's session context, through the  '/system/pipelines/' endpoint.

Reflected Cross-Site Scripting (XSS) vulnerability in the Graylog Web Interface console, version 2.2.3, caused by a lack of proper sanitization and escaping in HTML output. Several endpoints include segments of the URL directly in the response without applying output encoding, allowing an attacker to inject and execute arbitrary JavaScript code when a user visits a specially crafted URL. Exploitation of this vulnerability may allow script execution in the victim's browser and limited manipulation of the affected user's session context, through the  '/system/indexsets/' endpoint.

Reflected Cross-Site Scripting (XSS) vulnerability in the Graylog Web Interface console, version 2.2.3, caused by a lack of proper sanitization and escaping in HTML output. Several endpoints include segments of the URL directly in the response without applying output encoding, allowing an attacker to inject and execute arbitrary JavaScript code when a user visits a specially crafted URL. Exploitation of this vulnerability may allow script execution in the victim's browser and limited manipulation of the affected user's session context, through the  '/

alerts

/' endpoint.

Reflected Cross-Site Scripting (XSS) vulnerability in the Graylog Web Interface console, version 2.2.3, caused by a lack of proper sanitization and escaping in HTML output. Several endpoints include segments of the URL directly in the response without applying output encoding, allowing an attacker to inject and execute arbitrary JavaScript code when a user visits a specially crafted URL. Exploitation of this vulnerability may allow script execution in the victim's browser and limited manipulation of the affected user's session context, through the  '/system/nodes/' endpoint.

Reflected Cross-Site Scripting (XSS) vulnerability in the Graylog Web Interface console, version 2.2.3, caused by a lack of proper sanitization and escaping in HTML output. Several endpoints include segments of the URL directly in the response without applying output encoding, allowing an attacker to inject and execute arbitrary JavaScript code when a user visits a specially crafted URL. Exploitation of this vulnerability may allow script execution in the victim's browser and limited manipulation of the affected user's session context, through the '/system/authentication/users/edit/' endpoint.

Graylog before v2.4.4 has an XSS security issue with unescaped text in dashboard names, related to components/dashboard/Dashboard.jsx, components/dashboard/EditDashboardModal.jsx, and pages/ShowDashboardPage.jsx.

Graylog before v2.4.4 has an XSS security issue with unescaped text in notifications, related to toastr and util/UserNotification.js.

In Graylog before 2.4.6, XSS was possible in typeahead components, related to components/common/TypeAheadInput.jsx and components/search/QueryInput.ts.

Impact Reauthenticating with an existing session cookie would re-use that session id, even if for different user credentials. In this case, the pre-existing session could be used to gain elevated access to an existing Graylog login session, provided the malicious user could successfully inject their session cookie into someone else's browser.

The complexity of such an attack is high, because it requires presenting a spoofed login screen and injection of a session cookie into an existing browser, potentially through an XSS attack. No such attack has been discovered.

Patches Graylog 5.1.11 and 5.2.4, and any versions of the 6.0 development branch contain patches to not re-use sessions under any circumstances, making this type of attack impossible.

Workarounds Using short session expiration and explicit log outs of unused sessions can help limiting the attack vector. Unpatched this vulnerability exists, but is relatively hard to exploit. A proxy could be leveraged to clear the authentication cookie for the Graylog server URL for the /api/system/sessions endpoint, as that is the only one vulnerable.

Analysis provided by Fabian Yamaguchi - Whirly Labs (Pty) Ltd

Summary Graylog utilises only one single source port for DNS queries.

Details Graylog seems to bind a single socket for outgoing DNS queries. That socket is bound to a random port number which is not changed again. This goes against recommended practice since 2008, when Dan Kaminsky discovered how easy is to carry out DNS cache poisoning attacks. In order to prevent cache poisoning with spoofed DNS responses, it is necessary to maximise the uncertainty in the choice of a source port for a DNS query.

PoC

The attached figure shows the source ports distribution difference between Graylog configured to use a data adapter based on DNS queries and ISC Bind. The source port distribution of the DNS queries sent from Graylog to a recursive DNS name server running Bind (CLIENTQUERY) are depicted in purple, while the queries sent from the recursive DNS server to the authoritatives (RESOLVERQUERY) are plotted in green color. As it can be observed, in contrast to ISC Bind which presents a heterogeneous usage of source port, Graylog utilises a single source port.

!image

Impact Although unlikely in many setups, an external attacker could inject forged DNS responses into a Graylog's lookup table cache. In order to prevent this, it is at least recommendable to distribute the DNS queries through a pool of distinct sockets, each of them with a random source port and renew them periodically.

(Credit to Iratxe Niño from Fundación Sarenet and Borja Marcos from Sarenet)

A partial path traversal vulnerability exists in Graylog's Support Bundle feature. The vulnerability is caused by incorrect user input validation in an HTTP API resource.

Thanks to weiweiwei9811 for reporting this vulnerability and providing detailed information.

Impact

Graylog's Support Bundle feature allows an attacker with valid Admin role credentials to download or delete files in sibling directories of the support bundle directory.

The default datadir in operating system packages (DEB, RPM) is set to /var/lib/graylog-server. The data directory for the Support Bundle feature is always <datadir>/support-bundle.

Due to the partial path traversal vulnerability, an attacker with valid Admin role credentials can read or delete files in directories that start with a /var/lib/graylog-server/support-bundle directory name.

The vulnerability would allow the download or deletion of files in the following example directories.

- /var/lib/graylog-server/support-bundle-test - /var/lib/graylog-server/support-bundlesdirectory

For the Graylog and Graylog Enterprise Docker images, the datadir is set to /usr/share/graylog/data by default.

Patches

The vulnerability is fixed in Graylog version 5.1.3 and later.

Workarounds

Block all HTTP requests to the following HTTP API endpoints by using a reverse proxy server in front of Graylog.

- GET /api/system/debug/support/bundle/download/{filename} - DELETE /api/system/debug/support/bundle/{filename}

Summary

In a multi-node Graylog cluster, after a user has explicitly logged out, a user session may still be used for API requests until it has reached its original expiry time.

Details

Each node maintains an in-memory cache of user sessions. Upon a cache-miss, the session is loaded from the database. After that, the node operates solely on the cached session. Modifications to sessions will update the cached version as well as the session persisted in the database. However, each node maintains their isolated version of the session.

When the user logs out, the session is removed from the node-local cache and deleted from the database. The other nodes will however still use the cached session.

These nodes will only fail to accept the session id if they intent to update the session in the database. They will then notice that the session is gone. This is true for most API requests originating from user interaction with the Graylog UI because these will lead to an update of the session's "last access" timestamp.

If the session update is however prevented by setting the X-Graylog-No-Session-Extension:true header in the request, the node will consider the (cached) session valid until the session is expired according to its timeout setting.

PoC In a 2-node setup, with both nodes behind a load balancer:

1. Log in 1. Extract the session ID from the cookie 1. Log out and close the browser 1. Perform the following API request repeatedly with curl (with <session-id> replaced with the session id from step 2 and <lb-host> replaced with the hostname of your load balancer): curl -I -H X-Graylog-No-Session-Extension:true https://<session-id>:session@<lb-host>/api/system/cluster/nodes 1. Notice that the request is sometimes rejected, but sometimes succeeds

Impact

No session identifiers are leaked.

After a user has logged out, the UI shows the login screen again, which gives the user the impression that their session is not valid anymore. However, if the session becomes compromised later, it can still be used to perform API requests against the Graylog cluster. The time frame for this is limited to the configured session lifetime, starting from the time when the user logged out.

End of life: 2/11/2019, Latest version: 2.5.2

End of life: 2/11/2019, Latest version: 2.5.2

End of life: 6/4/2015, Latest version: 1.0.2

End of life: 6/4/2015, Latest version: 1.0.2

End of life: 5/17/2022, Latest version: 4.1.14

End of life: 5/17/2022, Latest version: 4.1.14

End of life: 3/1/2019, Latest version: 2.4.7