Migrate to using mdbook

src/pentesting-ci-cd/gitea-security/README.md

@@ -0,0 +1,138 @@
+# Gitea Security
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## What is Gitea
+
+**Gitea** is a **self-hosted community managed lightweight code hosting** solution written in Go.
+
+![](<../../images/image (160).png>)
+
+### Basic Information
+
+{{#ref}}
+basic-gitea-information.md
+{{#endref}}
+
+## Lab
+
+To run a Gitea instance locally you can just run a docker container:
+
+```bash
+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
+```
+
+## Unauthenticated Enumeration
+
+- Public repos: [http://localhost:3000/explore/repos](http://localhost:3000/explore/repos)
+- Registered users: [http://localhost:3000/explore/users](http://localhost:3000/explore/users)
+- Registered Organizations: [http://localhost:3000/explore/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**.
+
+## Internal Exploitation
+
+For this scenario we are going to suppose that you have obtained some access to a github account.
+
+### With User Credentials/Web Cookie
+
+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]
+> 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.
+
+### With User SSH Key
+
+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:
+
+```bash
+# 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/config`** will give you info about key is related.
+
+#### GPG Keys
+
+As explained [**here**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-ci-cd/gitea-security/broken-reference/README.md) sometimes it's needed to sign the commits or you might get discovered.
+
+Check locally if the current user has any key with:
+
+```shell
+gpg --list-secret-keys --keyid-format=long
+```
+
+### With User Token
+
+For an introduction about [**User Tokens check the basic information**](basic-gitea-information.md#personal-access-tokens).
+
+A user token can be used **instead of a password** to **authenticate** against Gitea server [**via API**](https://try.gitea.io/api/swagger#/). it will has **complete access** over the user.
+
+### With Oauth Application
+
+For an introduction about [**Gitea Oauth Applications check the basic information**](./#with-oauth-application).
+
+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**.
+
+### Branch Protection Bypass
+
+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 Pus**h: 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.
+
+### Enumerate Webhooks
+
+**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**.
+
+## Post Exploitation
+
+### Inside the server
+
+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
+
+{{#include ../../banners/hacktricks-training.md}}