Escalation via sudo mosh-server

Mosh (mobile shell) is an SSH alternative built for unstable connections: it keeps the session alive even if the IP changes or the network drops. Internally it's two pieces: mosh-server, launched on the remote end and printing a one-time MOSH_KEY to stdout, and mosh-client, which connects to that UDP port using the key.

The abuse. If sudo -l shows a user can run mosh-server as root:

(ALL) NOPASSWD: /usr/bin/mosh-server

then the server starts with root privileges, and the interactive session connecting to it inherits that context. No injection trick is needed: mosh's own design opens a shell, and here that shell is root's.

Steps.

sudo mosh-server new -p 6010          # port in the 6000-6100 range mosh reserves
# output: MOSH CONNECT 6010 <MOSH_KEY>
MOSH_KEY=<MOSH_KEY> mosh-client 127.0.0.1 6010

The first command returns the key; the second connects locally to that port and opens a terminal as root. The MOSH_KEY is one-time and changes on every start, so you must copy it from the server's output.

Why it happens. mosh-server isn't meant to run as root via sudo; it isn't an obvious LOLBIN (it's not vim or find), but it opens an interactive session, and that's enough. It's the same principle as any GTFOBins entry: a sudo-allowed binary that, directly or indirectly, grants access to a shell.

How to detect it. The signature is a sudo mosh-server in /var/log/auth.log (an unusual binary for sudo), followed by a mosh-server process running as root that opens a UDP listener in the 6000-6100 range with a root interactive shell hanging off it (auditd/Sysmon for Linux over execve with ppid=mosh-server). The local mosh-client connection to that port closes the chain. A root mosh-server with no matching user session is the tell.

Defence. Don't grant mosh-server (or any binary that opens interactive sessions) via sudo with NOPASSWD. If mosh is needed, run it under the user's own account, never as root. Related to SUID abuse and to checking GTFOBins before widening a sudoers rule.