CVE-2023-44400

# 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.