En fait, ça crée un nouveau fichier nommé ls avec comme contenu l'unique ligne de code entre guillemets, du coup, quand on appellera la commande ls, ça aura pour seul effet d'afficher le contenu du fichier cat /challenge/binary/binary1/.passwd. Pourquoi on fait ça ? Je ne le sais pas, ça ne semble pas permettre une élévation de droits en soi. Peut-être que ça sert à contourner une limitation autre, mais dans ce cas autant appeler directement cat. Quoi qu'il en soit, ça ne change pas ma conclusion : n'exécute pas ces commandes (ou dans une machine virtuelle jetable :P).
(je voulais éditer mon commentaire mais pas eu le temps, d'où l'auto-réponse)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
Je vais faire court : n'exécute pas ces commandes, ça pue le soft malveillant.
rm –rf ./ls
Ça supprime le fichier ls dans le répertoire courant. Si tu te trouves dans /bin, ls est un binaire essentiel, que tu appelles dans tous les cas où tu veux lister les fichiers d'un répertoire (y compris dans un paquet de scripts shell que tu n'as pas écrits toi-même). Si tu n'es pas dans /bin, ça ne trouvera pas le fichier et ça te retournera une erreur.
On lit le fichier /challenge/binary/binary1/.passwd et on colle son contenu dans un nouveau fichier appelé ls, qui se situe précisément à l'endroit où a été supprimé le fichier ls précédent. Pourquoi on fait ça ? En effet, on pourrait tout à fait, en théorie, modifier le fichier sans le supprimer avant. Sauf que c'est une modification du fichier et qu'on n'a pas les droits pour ce faire sans être root. Alors que si on supprime un fichier appartenant à root, rm affichera simplement une demande de confirmation, qu'on force via l'utilisation de -f à la ligne précédente. Ainsi, on a remplacé un binaire très fréquemment utilisé, protégé par le système de droits, par notre binaire à nous, en contournant le système de droits.
chmod+x ./ls
On a notre binaire, mais il n'est pas exécutable. Qu'à celà ne tienne ! On le rend exécutable. Comme on a créé le binaire nous-même, on en est propriétaire : on peut modifier les droits dessus. Tout le monde peut donc désormais exécuter le binaire pourri qu'on a collé sur notre disque, et pire : tout le monde l'appellera de fait quand il croira appeler la commande ls, commande innocente s'il en est.
cd ~
pwd
On retourne dans notre dossier /home. On ne remonte pas d'un cran : on va dans le répertoire personnel de l'utilisateur courant. pwd sert à vérifier qu'on est dans le /home de l'utilisateur courant, si on en doutait.
./binary1
On exécute binary1. Rien que cette ligne devrait te mettre la puce à l'oreille : tu es en présence d'un programme exécutable, dont tu ne sais rien. Cette ligne l'exécute, tout simplement. Ce que fait binary1 ? Je n'en sais strictement rien, c'est un binaire. Mais je n'irais pas le tester.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: N'exécute pas ces commandes
Posté par Liorel . En réponse au message questions sur differentes commandes. Évalué à 3.
Je me suis planté dans l'interprétation de la ligne
En fait, ça crée un nouveau fichier nommé
lsavec comme contenu l'unique ligne de code entre guillemets, du coup, quand on appellera la commandels, ça aura pour seul effet d'afficher le contenu du fichiercat /challenge/binary/binary1/.passwd. Pourquoi on fait ça ? Je ne le sais pas, ça ne semble pas permettre une élévation de droits en soi. Peut-être que ça sert à contourner une limitation autre, mais dans ce cas autant appeler directementcat. Quoi qu'il en soit, ça ne change pas ma conclusion : n'exécute pas ces commandes (ou dans une machine virtuelle jetable :P).(je voulais éditer mon commentaire mais pas eu le temps, d'où l'auto-réponse)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # N'exécute pas ces commandes
Posté par Liorel . En réponse au message questions sur differentes commandes. Évalué à 5.
Je vais faire court : n'exécute pas ces commandes, ça pue le soft malveillant.
Ça supprime le fichier
lsdans le répertoire courant. Si tu te trouves dans/bin,lsest un binaire essentiel, que tu appelles dans tous les cas où tu veux lister les fichiers d'un répertoire (y compris dans un paquet de scripts shell que tu n'as pas écrits toi-même). Si tu n'es pas dans/bin, ça ne trouvera pas le fichier et ça te retournera une erreur.On lit le fichier
/challenge/binary/binary1/.passwdet on colle son contenu dans un nouveau fichier appeléls, qui se situe précisément à l'endroit où a été supprimé le fichierlsprécédent. Pourquoi on fait ça ? En effet, on pourrait tout à fait, en théorie, modifier le fichier sans le supprimer avant. Sauf que c'est une modification du fichier et qu'on n'a pas les droits pour ce faire sans être root. Alors que si on supprime un fichier appartenant à root,rmaffichera simplement une demande de confirmation, qu'on force via l'utilisation de -f à la ligne précédente. Ainsi, on a remplacé un binaire très fréquemment utilisé, protégé par le système de droits, par notre binaire à nous, en contournant le système de droits.On a notre binaire, mais il n'est pas exécutable. Qu'à celà ne tienne ! On le rend exécutable. Comme on a créé le binaire nous-même, on en est propriétaire : on peut modifier les droits dessus. Tout le monde peut donc désormais exécuter le binaire pourri qu'on a collé sur notre disque, et pire : tout le monde l'appellera de fait quand il croira appeler la commande
ls, commande innocente s'il en est.On retourne dans notre dossier /home. On ne remonte pas d'un cran : on va dans le répertoire personnel de l'utilisateur courant.
pwdsert à vérifier qu'on est dans le /home de l'utilisateur courant, si on en doutait.On exécute
binary1. Rien que cette ligne devrait te mettre la puce à l'oreille : tu es en présence d'un programme exécutable, dont tu ne sais rien. Cette ligne l'exécute, tout simplement. Ce que faitbinary1? Je n'en sais strictement rien, c'est un binaire. Mais je n'irais pas le tester.Ça, ce sont les sources. Le mouton que tu veux est dedans.