Gitea Security
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Gitea is a self-hosted community managed lightweight code hosting solution written in Go.
To run a Gitea instance locally you can just run a docker container:
Connect to port 3000 to access the web page.
You could also run it with kubernetes:
Public repos: http://localhost:3000/explore/repos
Registered users: http://localhost:3000/explore/users
Registered Organizations: http://localhost:3000/explore/organizations
Note that by default Gitea allows new users to register. This won't give specially interesting access to the new users over other organizations/users repos, but a logged in user might be able to visualize more repos or organizations.
For this scenario we are going to suppose that you have obtained some access to a github account.
If you somehow already have credentials for a user inside an organization (or you stole a session cookie) you can just login and check which which permissions you have over which repos, in which teams you are, list other users, and how are the repos protected.
Note that 2FA may be used so you will only be able to access this information if you can also pass that check.
Note that if you manage to steal the i_like_gitea cookie (currently configured with SameSite: Lax) you can completely impersonate the user without needing credentials or 2FA.
Gitea allows users to set SSH keys that will be used as authentication method to deploy code on their behalf (no 2FA is applied).
With this key you can perform changes in repositories where the user has some privileges, however you can not use it to access gitea api to enumerate the environment. However, you can enumerate local settings to get information about the repos and user you have access to:
If the user has configured its username as his gitea username you can access the public keys he has set in his account in https://github.com/<gitea_username>.keys, you could check this to confirm the private key you found can be used.
SSH keys can also be set in repositories as deploy keys. Anyone with access to this key will be able to launch projects from a repository. Usually in a server with different deploy keys the local file ~/.ssh/config will give you info about key is related.
As explained here sometimes it's needed to sign the commits or you might get discovered.
Check locally if the current user has any key with:
For an introduction about User Tokens check the basic information.
A user token can be used instead of a password to authenticate against Gitea server via API. it will has complete access over the user.
For an introduction about Gitea Oauth Applications check the basic information.
An attacker might create a malicious Oauth Application to access privileged data/actions of the users that accepts them probably as part of a phishing campaign.
As explained in the basic information, the application will have full access over the user account.
In Github we have github actions which by default get a token with write access over the repo that can be used to bypass branch protections. In this case that doesn't exist, so the bypasses are more limited. But lets take a look to what can be done:
Enable Push: If anyone with write access can push to the branch, just push to it.
Whitelist Restricted Push: The same way, if you are part of this list push to the branch.
Enable Merge Whitelist: If there is a merge whitelist, you need to be inside of it
Require approvals is bigger than 0: Then... you need to compromise another user
Restrict approvals to whitelisted: If only whitelisted users can approve... you need to compromise another user that is inside that list
Dismiss stale approvals: If approvals are not removed with new commits, you could hijack an already approved PR to inject your code and merge the PR.
Note that if you are an org/repo admin you can bypass the protections.
Webhooks are able to send specific gitea information to some places. You might be able to exploit that communication. However, usually a secret you can not retrieve is set in the webhook that will prevent external users that know the URL of the webhook but not the secret to exploit that webhook. But in some occasions, people instead of setting the secret in its place, they set it in the URL as a parameter, so checking the URLs could allow you to find secrets and other places you could exploit further.
Webhooks can be set at repo and at org level.
If somehow you managed to get inside the server where gitea is running you should search for the gitea configuration file. By default it's located in /data/gitea/conf/app.ini
In this file you can find keys and passwords.
In the gitea path (by default: /data/gitea) you can find also interesting information like:
The sqlite DB: If gitea is not using an external db it will use a sqlite db
The sessions inside the sessions folder: Running cat sessions/*/*/* you can see the usernames of the logged users (gitea could also save the sessions inside the DB).
The jwt private key inside the jwt folder
More sensitive information could be found in this folder
If you are inside the server you can also use the gitea binary to access/modify information:
gitea dump will dump gitea and generate a .zip file
gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET will generate a token of the indicated type (persistence)
gitea admin user change-password --username admin --password newpassword Change the password
gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token Create new admin user and get an access token
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
