This is the final part of the series. In the first two posts, an SSRF, LQL query injection leads to an arbitrary file deletion. This leads to a complete authentication bypass by racing a file for auth. In part 3, we finish off the chain.
The endpoint CoreModGeneral contains a arbitrary file read vulnerability. A URL can be passed in but does not validate the URI type. This means an attacker can pass in the file:// scheme and retrieve arbitrary files from the system.
CheckMk has two types of users: normal and automation. The automation user is pre-configured with a random secret, which is stored in plaintext via the file automation.secret. By using the arbitrary file read from above, we can escalate privileges to read the credentials and login as this user.
In terms out that the automation user is quite restricted so we want to be a normal user. How does it know the difference between an automation and a regular user? By checking for the existence of the automation.secret file! So, once we read the file, we can use a previous vulnerability to delete the file, making us appear as a regular user. Now we are a normal user!
For the seamless authentication for Nagvis to take place, dynamic PHP code is generated. In particular, user information is put into a string in real PHP code. Single quotes within this data are escaped by prepending a backslash. However, if the data contains a backslash itself, we can escape the attempted escaped single quote. For instance, the input A\' would become A\\' instead of A\\\', allowing us to escape the context.
The bug above gives us an authenticated code injection vulnerability. From a single SSRF to authentication to code execution is pretty amazing. This is probably the most amount of bugs I've ever seen chained together. More interestingly, some of these quirks weren't bugs - the functionality, such as the file deletion in this step, was just an implementation quirk. Awesome write up!