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:
docker run -p 3000:3000 gitea/gitea
Connect to port 3000 to access the web page.
You could also run it with kubernetes:
helm repo add gitea-charts https://dl.gitea.io/charts/
helm install gitea gitea-charts/gitea
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_giteacookie (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:
# Go to the the repository folder
# Get repo config and current user name and email
git config --list
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/configwill give you info about key is related.
Check locally if the current user has any key with:
gpg --list-secret-keys --keyid-format=long
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
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
giteabinary to access/modify information:
gitea dumpwill dump gitea and generate a .zip file
gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRETwill generate a token of the indicated type (persistence)
gitea admin user change-password --username admin --password newpasswordChange the password