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 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)

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.