Uptime Kuma Authenticated remote code execution via TailscalePing

Summary

### Summary The `runTailscalePing` method of the `TailscalePing` class injects the `hostname` parameter inside a shell command, leading to a command injection and the possibility to run arbitrary commands on the server. ### Details When adding a new monitor on Uptime Kuma, we can select the "Tailscale Ping" type. Then we can add a hostname and insert a command injection payload into it. The front-end application requires that the field follow a specific pattern, this validation only happens on the front-end and can be removed by removing the attribute `pattern` on the `input` element. https://github.com/louislam/uptime-kuma/blob/dc4242019331e65a79ac16deef97510144e01b12/server/monitor-types/tailscale-ping.js#L40-L46 We can finally add the new monitor and observe that our command is being executed. **NOTE:** When using Uptime Kuma inside a container, the "TailScale Ping" type is not visible. We can fake this information by intercepting WebSocket messages and set the `isContainer` option to `false`. ### PoC * Authenticate. * Create a new monitor. * Select the TailScale Ping type (if not visible, see the note in the details section). * Insert the command injection payload inside the `hostname` field. (for example `$(id >&2)`) * Remove the `pattern` requirement on the field. * Save and start the monitor. ### Impact An authenticated user can execute arbitrary command on the server running Uptime Kuma. ### Remediation There are other command execution in the codebase, they use a method `spawn` from the `child_process` module which does not interpret the command as a shell command, the same thing should be done here. **NOTE:** The Tailscale CLI seems to support the `--` sequence. It should be used between the `ping` subcommand and the `hostname` argument to avoid argument injection.