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
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.
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}
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.
Graylog2 before 0.92 allows remote attackers to bypass LDAP authentication via crafted wildcards.
In Graylog before 2.4.6, XSS was possible in typeahead components, related to components/common/TypeAheadInput.jsx and components/search/QueryInput.ts.
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.
End of life: 11/30/2022, Latest version: 4.2.13
End of life: 11/30/2022, Latest version: 4.2.13
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: 10/13/2021, Latest version: 4.0.17
End of life: 10/13/2021, Latest version: 4.0.17
End of life: 4/12/2022, Latest version: 3.3.17
End of life: 4/12/2022, Latest version: 3.3.17
End of life: 5/20/2020, Latest version: 3.2.6
End of life: 5/20/2020, Latest version: 3.2.6
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: 3/1/2019, Latest version: 2.4.7
End of life: 3/1/2019, Latest version: 2.4.7
End of life: 12/22/2017, Latest version: 2.3.2
End of life: 12/22/2017, Latest version: 2.3.2
End of life: 7/26/2017, Latest version: 2.2.3
End of life: 7/26/2017, Latest version: 2.2.3
End of life: 2/9/2017, Latest version: 2.1.3
End of life: 2/9/2017, Latest version: 2.1.3
End of life: 6/4/2015, Latest version: 1.0.2