mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-11 20:45:21 -08:00
Translated ['src/pentesting-ci-cd/cloudflare-security/cloudflare-domains
This commit is contained in:
Translator
@@ -56,9 +56,9 @@ Si encuentras un **volumen sin una instantánea** podrías: **Crear una instant
|
||||
aws-ebs-snapshot-dump.md
|
||||
{{#endref}}
|
||||
|
||||
### Exfiltración de Datos
|
||||
### Exfiltración de datos
|
||||
|
||||
#### Exfiltración por DNS
|
||||
#### Exfiltración DNS
|
||||
|
||||
Incluso si aseguras un EC2 para que no pueda salir tráfico, aún puede **exfiltrarse a través de DNS**.
|
||||
|
||||
@@ -72,20 +72,20 @@ Incluso si aseguras un EC2 para que no pueda salir tráfico, aún puede **exfilt
|
||||
|
||||
Un atacante podría llamar a los puntos finales de la API de una cuenta controlada por él. Cloudtrail registrará estas llamadas y el atacante podrá ver los datos exfiltrados en los registros de Cloudtrail.
|
||||
|
||||
### Grupo de Seguridad Abierto
|
||||
### Grupo de seguridad abierto
|
||||
|
||||
Podrías obtener acceso adicional a los servicios de red abriendo puertos así:
|
||||
```bash
|
||||
aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --port 80 --cidr 0.0.0.0/0
|
||||
# Or you could just open it to more specific ips or maybe th einternal network if you have already compromised an EC2 in the VPC
|
||||
```
|
||||
### Privesc a ECS
|
||||
### Privesc to ECS
|
||||
|
||||
Es posible ejecutar una instancia de EC2 y registrarla para ser utilizada para ejecutar instancias de ECS y luego robar los datos de las instancias de ECS.
|
||||
|
||||
Para [**más información consulta esto**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs).
|
||||
|
||||
### Eliminar registros de flujo de VPC
|
||||
### Remove VPC flow logs
|
||||
```bash
|
||||
aws ec2 delete-flow-logs --flow-log-ids <flow_log_ids> --region <region>
|
||||
```
|
||||
@@ -104,7 +104,7 @@ Además de la ejecución de comandos, SSM permite el túnel de tráfico, lo que
|
||||
```shell
|
||||
aws ssm start-session --target "$INSTANCE_ID"
|
||||
```
|
||||
3. Obtén las credenciales temporales de Bastion EC2 AWS con el script de [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf#abusing-ssrf-in-aws-ec2-environment)
|
||||
3. Obtén las credenciales temporales de Bastion EC2 AWS con el script de [Abusing SSRF in AWS EC2 environment](https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#abusing-ssrf-in-aws-ec2-environment)
|
||||
4. Transfiere las credenciales a tu propia máquina en el archivo `$HOME/.aws/credentials` como perfil `[bastion-ec2]`
|
||||
5. Inicia sesión en EKS como el Bastion EC2:
|
||||
```shell
|
||||
@@ -121,9 +121,9 @@ kubectl get pods --insecure-skip-tls-verify
|
||||
```
|
||||
Tenga en cuenta que las conexiones SSL fallarán a menos que establezca la bandera `--insecure-skip-tls-verify` (o su equivalente en las herramientas de auditoría de K8s). Dado que el tráfico se canaliza a través del túnel seguro de AWS SSM, está a salvo de cualquier tipo de ataques MitM.
|
||||
|
||||
Finalmente, esta técnica no es específica para atacar clústeres EKS privados. Puede establecer dominios y puertos arbitrarios para pivotar a cualquier otro servicio de AWS o a una aplicación personalizada.
|
||||
Finalmente, esta técnica no es específica para atacar clústeres privados de EKS. Puede establecer dominios y puertos arbitrarios para pivotar a cualquier otro servicio de AWS o a una aplicación personalizada.
|
||||
|
||||
### Compartir AMI
|
||||
### Share AMI
|
||||
```bash
|
||||
aws ec2 modify-image-attribute --image-id <image_ID> --launch-permission "Add=[{UserId=<recipient_account_ID>}]" --region <AWS_region>
|
||||
```
|
||||
@@ -139,7 +139,7 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
|
||||
|
||||
Una prueba de concepto similar a la demostración de Ransomware presentada en las notas de post-explotación de S3. KMS debería renombrarse a RMS por Ransomware Management Service debido a lo fácil que es usarlo para cifrar varios servicios de AWS.
|
||||
|
||||
Primero, desde una cuenta de AWS del 'atacante', crea una clave administrada por el cliente en KMS. Para este ejemplo, solo haremos que AWS administre los datos de la clave por mí, pero en un escenario realista, un actor malicioso retendría los datos de la clave fuera del control de AWS. Cambia la política de la clave para permitir que cualquier Principal de cuenta de AWS use la clave. Para esta política de clave, el nombre de la cuenta era 'AttackSim' y la regla de política que permite todo el acceso se llama 'Outside Encryption'
|
||||
Primero, desde una cuenta de AWS 'atacante', crea una clave administrada por el cliente en KMS. Para este ejemplo, solo haremos que AWS administre los datos de la clave por mí, pero en un escenario realista, un actor malicioso retendría los datos de la clave fuera del control de AWS. Cambia la política de la clave para permitir que cualquier Principal de cuenta de AWS use la clave. Para esta política de clave, el nombre de la cuenta era 'AttackSim' y la regla de política que permite todo el acceso se llama 'Outside Encryption'.
|
||||
```
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
@@ -239,7 +239,7 @@ La regla de la política de clave necesita que se habiliten lo siguiente para pe
|
||||
- `kms:GenerateDataKeyWithoutPlainText`
|
||||
- `kms:ReEncrypt`
|
||||
|
||||
Ahora con la clave accesible públicamente para usar. Podemos utilizar una cuenta de 'víctima' que tenga algunas instancias EC2 activas con volúmenes EBS no cifrados adjuntos. Los volúmenes EBS de esta cuenta de 'víctima' son nuestro objetivo para el cifrado, este ataque se realiza bajo la suposición de una violación de una cuenta de AWS de alto privilegio.
|
||||
Ahora, con la clave accesible públicamente para usar. Podemos utilizar una cuenta de 'víctima' que tenga algunas instancias EC2 activas con volúmenes EBS sin cifrar adjuntos. Los volúmenes EBS de esta cuenta de 'víctima' son nuestro objetivo para el cifrado, este ataque se realiza bajo la suposición de una violación de una cuenta de AWS de alto privilegio.
|
||||
|
||||
 
|
||||
|
||||
@@ -249,7 +249,7 @@ Esto resulta en que solo queden volúmenes EBS cifrados disponibles en la cuenta
|
||||
|
||||
|
||||
|
||||
También vale la pena mencionar que el script detuvo las instancias EC2 para separar y eliminar los volúmenes EBS originales. Los volúmenes originales no cifrados ya no están.
|
||||
También vale la pena mencionar que el script detuvo las instancias EC2 para separar y eliminar los volúmenes EBS originales. Los volúmenes originales sin cifrar ya no están.
|
||||
|
||||
|
||||
|
||||
@@ -324,7 +324,7 @@ A continuación, regrese a la política de clave en la cuenta del 'atacante' y e
|
||||
]
|
||||
}
|
||||
```
|
||||
Espera un momento para que la nueva política de claves se propague. Luego regresa a la cuenta de 'víctima' e intenta adjuntar uno de los volúmenes EBS recién cifrados. Descubrirás que puedes adjuntar el volumen.
|
||||
Espera un momento para que la nueva política de claves se propague. Luego regresa a la cuenta de 'víctima' e intenta adjuntar uno de los nuevos volúmenes EBS cifrados. Verás que puedes adjuntar el volumen.
|
||||
|
||||
 
|
||||
|
||||
@@ -332,7 +332,7 @@ Pero cuando intentes reiniciar la instancia EC2 con el volumen EBS cifrado, simp
|
||||
|
||||
 
|
||||
|
||||
Este es el script de python utilizado. Toma credenciales de AWS para una cuenta de 'víctima' y un valor ARN de AWS disponible públicamente para la clave que se utilizará para el cifrado. El script hará copias cifradas de TODOS los volúmenes EBS disponibles adjuntos a TODAS las instancias EC2 en la cuenta de AWS objetivo, luego detendrá cada instancia EC2, separará los volúmenes EBS originales, los eliminará y finalmente eliminará todos los snapshots utilizados durante el proceso. Esto dejará solo volúmenes EBS cifrados en la cuenta de 'víctima' objetivo. SOLO UTILIZA ESTE SCRIPT EN UN ENTORNO DE PRUEBA, ES DESTRUCTIVO Y ELIMINARÁ TODOS LOS VOLUMENES EBS ORIGINALES. Puedes recuperarlos usando la clave KMS utilizada y restaurarlos a su estado original a través de snapshots, pero solo quiero hacerte consciente de que esto es una prueba de concepto de ransomware al final del día.
|
||||
Este es el script de python utilizado. Toma credenciales de AWS para una cuenta de 'víctima' y un valor ARN de AWS disponible públicamente para la clave que se utilizará para el cifrado. El script hará copias cifradas de TODOS los volúmenes EBS disponibles adjuntos a TODAS las instancias EC2 en la cuenta de AWS objetivo, luego detendrá cada instancia EC2, desacoplará los volúmenes EBS originales, los eliminará y finalmente eliminará todos los snapshots utilizados durante el proceso. Esto dejará solo volúmenes EBS cifrados en la cuenta de 'víctima' objetivo. SOLO UTILIZA ESTE SCRIPT EN UN ENTORNO DE PRUEBA, ES DESTRUCTIVO Y ELIMINARÁ TODOS LOS VOLUMENES EBS ORIGINALES. Puedes recuperarlos usando la clave KMS utilizada y restaurarlos a su estado original a través de snapshots, pero solo quiero hacerte consciente de que esto es una prueba de concepto de ransomware al final del día.
|
||||
```
|
||||
import boto3
|
||||
import argparse
|
||||
|
||||
@@ -49,7 +49,7 @@ aws ecr get-download-url-for-layer \
|
||||
Después de descargar las imágenes, debes **verificarlas en busca de información sensible**:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics
|
||||
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/basic-forensic-methodology/docker-forensics.html
|
||||
{{#endref}}
|
||||
|
||||
### `ecr:PutLifecyclePolicy` | `ecr:DeleteRepository` | `ecr-public:DeleteRepository` | `ecr:BatchDeleteImage` | `ecr-public:BatchDeleteImage`
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## ECS
|
||||
|
||||
Para más información, consulta:
|
||||
Para más información consulta:
|
||||
|
||||
{{#ref}}
|
||||
../aws-services/aws-ecs-enum.md
|
||||
@@ -12,11 +12,11 @@ Para más información, consulta:
|
||||
|
||||
### Roles IAM de Host
|
||||
|
||||
En ECS, un **rol IAM puede ser asignado a la tarea** que se ejecuta dentro del contenedor. **Si** la tarea se ejecuta dentro de una **instancia EC2**, la **instancia EC2** tendrá un **rol IAM** diferente adjunto.\
|
||||
Lo que significa que si logras **comprometer** una instancia ECS, potencialmente puedes **obtener el rol IAM asociado al ECR y a la instancia EC2**. Para más información sobre cómo obtener esas credenciales, consulta:
|
||||
En ECS, un **rol IAM puede ser asignado a la tarea** que se ejecuta dentro del contenedor. **Si** la tarea se ejecuta dentro de una **instancia EC2**, la **instancia EC2** tendrá **otro rol IAM** adjunto.\
|
||||
Lo que significa que si logras **comprometer** una instancia ECS, puedes potencialmente **obtener el rol IAM asociado al ECR y a la instancia EC2**. Para más información sobre cómo obtener esas credenciales consulta:
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf
|
||||
https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html
|
||||
{{#endref}}
|
||||
|
||||
> [!CAUTION]
|
||||
@@ -28,12 +28,12 @@ Además, EC2 utiliza docker para ejecutar tareas de ECS, así que si puedes esca
|
||||
|
||||
#### Haciendo que los contenedores se ejecuten en el host actual
|
||||
|
||||
Además, el **rol de la instancia EC2** generalmente tendrá suficientes **permisos** para **actualizar el estado de la instancia del contenedor** de las instancias EC2 que se utilizan como nodos dentro del clúster. Un atacante podría modificar el **estado de una instancia a DRAINING**, luego ECS **eliminará todas las tareas de ella** y las que se están ejecutando como **REPLICA** se **ejecutarán en una instancia diferente,** potencialmente dentro de la **instancia del atacante**, para que pueda **robar sus roles IAM** y potencial información sensible desde dentro del contenedor.
|
||||
Además, el **rol de la instancia EC2** generalmente tendrá suficientes **permisos** para **actualizar el estado de la instancia de contenedor** de las instancias EC2 que se utilizan como nodos dentro del clúster. Un atacante podría modificar el **estado de una instancia a DRAINING**, luego ECS **eliminará todas las tareas de ella** y las que se están ejecutando como **REPLICA** serán **ejecutadas en una instancia diferente,** potencialmente dentro de la **instancia del atacante** para que pueda **robar sus roles IAM** y potencial información sensible desde dentro del contenedor.
|
||||
```bash
|
||||
aws ecs update-container-instances-state \
|
||||
--cluster <cluster> --status DRAINING --container-instances <container-instance-id>
|
||||
```
|
||||
La misma técnica se puede realizar **dando de baja la instancia EC2 del clúster**. Esto es potencialmente menos sigiloso, pero **forzará a que las tareas se ejecuten en otras instancias:**
|
||||
La misma técnica se puede realizar **deregistrando la instancia EC2 del clúster**. Esto es potencialmente menos sigiloso, pero **forzará a que las tareas se ejecuten en otras instancias:**
|
||||
```bash
|
||||
aws ecs deregister-container-instance \
|
||||
--cluster <cluster> --container-instance <container-instance-id> --force
|
||||
|
||||
Reference in New Issue
Block a user