CVE-2023-44400: Uptime Kuma has Persistentent User Sessions

First published: Mon Oct 09 2023(Updated: )

# Summary Attackers with access to a users' device can gain persistent account access. This is caused by missing verification of Session Tokens after password changes and/or elapsed inactivity-periods. # Details `uptime-kuma` sets JWT tokens for users after successful authentication. These tokens have the following design flaws: - After successful login, a JWT token and it is stored in `sessionStorage` or `localStorage`. Which of the two is decided based on the `Remember Me` button. The users' token is valid without any time limitation, even after long periods of inactivity. This increases the risk of session hijacking if, for example, a user forgets to log off and leaves the PC. - sessions are only deleted on the client side after a user loggs out, meaning a local attacker could reuse said token with deep system access over the browser - If a user changes a password - any previously logged in clients are not logged out - previously issued tokens remained valid forever These flaws allow user cookies to remain valid even after changing passwords or being inactive, posing a high security risk. # POC ### Password resets not deactivating cookies - Log in. - Note the user cookie. - Change your password. - Attempt to log in again with the same cookie. - The cookie remains valid despite the password change. ### Inactivity not deactivating sessions In testing, even after a period of over a day of inactivity, the session was still valid # Impact Another person with local access to the device could take over the session permanently, even after hours of previous inactivity or a password change. Such activity would not be obvious to the user (see https://github.com/louislam/uptime-kuma/issues/3481 if you want to help with this). With this gained account access, an attacker can cause: ## confidentially loss - monitors (including private ones not shared on public status pages) - notification providers - settings like `api-keys` (only used for accessing `/metrics`) - settings like secrets like the `Steam API Key` - maintenance periods ## availability loss - by creating a lot of monitors and setting the retention policy very high leading to degraded database performance or out of storage - by creating a lot of `HTTP(s) - Browser Engine (Chrome/Chromium) (Beta)` leading to RAM exhaustion ## integrity loss - by the attacker deleting a monitor - by the attacker deleting a monitor's history - by the atacker changing the meaning of a monitor (changing where it points) ## scope creep If operated in some restricted network, access to monitors may provide the ability to change the scope of the attack to a different piece of infrastructure, for example via SQL commands to a database server. We have not classified this as `changed scope` because credentials stored in the application for accessing other systems are existing valid paths across the trust boundary, and the user should be aware of that.

Credit: security-advisories@github.com security-advisories@github.com security-advisories@github.com

Never miss a vulnerability like this again

Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.

Read MoreStart Free Trial

• collector/github-advisory-latest
• alias/GHSA-g9v2-wqcj-j99g
• alias/CVE-2023-44400
• collector/github-advisory
• agent/type
• agent/softwarecombine
• collector/mitre-cve
• source/MITRE
• agent/remedy
• agent/weakness
• agent/references
• agent/title
• agent/author
• agent/severity
• agent/last-modified-date
• agent/description
• agent/first-publish-date
• agent/event
• agent/trending
• agent/source
• agent/tags
• collector/nvd-index
• agent/software-canonical-lookup-request
• collector/nvd-cve
• collector/nvd-api
• package-manager/npm
• vendor/uptime.kuma
• canonical/uptime kuma