web-dev-qa-db-fra.com

Contourner la commande / script spécifié dans / etc / passwd

Considérez la ligne suivante de /etc/passwd:

sadeq:x:1000:1000:Mohammad Sadeq Dousti,,,:/home/sadeq:/bin/custom-script.sh

La dernière partie, /bin/custom-script.sh, affiche la commande/le script à exécuter lorsque l'utilisateur se connecte au système. Actuellement, il s'agit d'un simple script Bash, qui présente à l'utilisateur un menu, limitant efficacement les commandes possibles qu'il peut exécuter.

Ou, je l'espère! Peut-être que les utilisateurs peuvent contourner custom-script.sh, et accédez directement à Bash. Ensuite, ils peuvent exécuter n'importe quelle commande dans leur contexte utilisateur.

Existe-t-il un moyen de contourner le script Bash ci-dessus et d'exécuter d'autres commandes?

Edit: Considérez le cas simple suivant comme custom-script.sh:

#!/bin/bash
echo What is your name?
read name
echo Hi $name
34
M.S. Dousti

Avec l'exemple de script que vous avez publié, l'utilisateur restreint peut par exemple en apprendre beaucoup sur le système, comme les noms d'autres utilisateurs et les programmes installés. Par exemple.

What is your name?
> /home/* 
Hi /home/foo /home/bar /home/sadeq

Le script que vous possédez peut être exploitable de manière similaire, peut-être au point où l'utilisateur peut obtenir un véritable accès Shell.

Vous pourriez probablement améliorer la situation en démarrant le menu de connexion dans un environnement en bac à sable: il ne sera pas nécessairement à 100% pare-balles, mais au moins le bac à sable comblera tout un tas de failles de sécurité que l'auteur du script a peut-être laissées.

8
Dmitry Grigoryev

Supposons qu'il existe une porte dérobée (probablement involontaire).

Le défaut /etc/passwd sur les postes de travail Sun du début des années 90 comprenait une entrée semblable à ceci:

games::0:0:games:/nopath:/bin/false

En d'autres termes, un compte nommé "jeux" sans mot de passe. Apparemment, le génie qui a proposé cette idée n'avait pas d'imagination et lui a attribué un uid et un gid de zéro (c'est-à-dire la racine et la roue). Généralement, c'était correct, car le répertoire personnel n'avait pas de sens et le Shell était réglé sur un programme qui se terminait toujours par un échec. En outre, les paramètres par défaut pour tout accès par réseau - telnet, rlogin, rcp, ftp - ont été définis pour empêcher l'accès par tout uid de zéro. Il y avait une entrée de mot de passe distincte pour root, avec un mot de passe défini correctement, un répertoire personnel et Shell.

Cela signifie que si vous essayez de vous connecter en tant que jeux, les événements suivants se produisent:

  • La connexion en tant que jeux sur la console réussirait dans un premier temps, mais engendrerait ensuite le /bin/false Shell, qui se fermerait immédiatement.
  • Utiliser telnet ou rlogin refuserait carrément la connexion. Même s'il avait réussi, le /bin/false Shell quitterait immédiatement.
  • FTP et scp n'utilisent pas de shells, mais ils ont été configurés pour refuser l'accès à uid zero, vous ne pouvez donc pas vous connecter de cette façon.
  • Une connexion GUI démarrerait les services GUI par défaut, y compris un gestionnaire de fenêtres, un client d'horloge et un terminal. Ce dernier quitterait immédiatement parce que son enfant Shell quitterait immédiatement. Vous obtiendrez donc un écran vide à l'exception d'une horloge. (Plus d'informations ci-dessous ...)
  • Si vous avez vraiment e pour vous connecter en tant que root, vous devrez soit le faire à partir de la console, soit d'abord rlogin/telnet en tant qu'un autre utilisateur sur cette machine, puis su root. L'une ou l'autre manière utilise l'entrée root passwd plutôt que l'entrée games passwd, et fonctionne ainsi comme root devrait fonctionner.

Le compte des jeux semblait donc toujours échouer, à moins que vous ne vous soyez connecté à l'interface graphique. Dans ce cas, la seule chose qui est apparue était l'horloge. Cependant, vous pouvez cliquer avec le bouton droit sur l'arrière-plan pour obtenir un menu racine, avec une liste de programmes fournis en usine que les utilisateurs devraient normalement personnaliser eux-mêmes. (La personnalisation du menu n'a pas fonctionné pour le compte de jeux; je ne me souviens pas exactement pourquoi.) Vous pouvez essayer d'afficher plus de fenêtres de terminal, ce qui échouerait tous. Il y avait un jeu de puzzle (qui a peut-être été le moteur du compte en premier lieu). Un autre choix était de se déconnecter. Et puis il y avait l'outil de débogage graphique, dbxtool.

dbxtool était une interface graphique avec le débogueur symbolique dbx, semblable au gdb d'aujourd'hui. Étant uid zéro, vous pouvez attacher et contrôler n'importe quel processus sur le système, bien que cela ne soit pas utile car les programmes fournis par Sun ont été compilés sans symboles. Vous pourriez lancer un shell, mais cela utiliserait votre variable d'environnement Shell, qui était /bin/false. Cependant, vous pouvez également modifier les variables environnementales! Cela signifie que vous pouvez obtenir un shell racine comme suit:

  1. Connectez-vous via l'interface graphique en tant que jeux, sans mot de passe.
  2. Cliquez avec le bouton droit pour afficher le menu racine.
  3. Démarrez un dbxtool.
  4. setenv Shell /bin/sh
  5. (Optionnel) setenv HOME /
  6. Démarrer un shell avec !
  7. Parce que le terminal n'est pas défini, faites stty sane

Voila, root shell sans mot de passe!

Par conséquent, ne supposez pas qu'un utilisateur ne peut pas s'échapper d'un shell non valide.

44
DrSheldon

Vous ne pouvez pas ignorer l'exécution du script. Ceci est votre shell de connexion, et sera démarré à chaque connexion. Et en tant que shell de connexion, vous vous déconnecterez à chaque fois qu'il se terminera. Mais vous pouvez utiliser des bizarreries, des bogues et des incohérences sur le shell de connexion pour vous échapper.

Une chose que vous pourriez faire est d'échapper à un Shell en utilisant n'importe quelle option du menu. Si le menu vous permet de démarrer vim, less, more ou d'autres commandes, vous pouvez théoriquement vous libérer. Si le sysadmin est expérimenté, ces commandes utiliseront leurs versions restreintes et ne fonctionneront pas.

27
ThoriumBR

Je me souviens d'un défi de wargame où il y avait un cas similaire - le Shell a souligné quelque chose qui a simplement imprimé une sortie en utilisant la commande more, puis a mis fin à la session. Cependant, puisque plus dispose d'un éditeur de texte intégré (dans ce cas particulier, c'était vi), il suffisait de redimensionner la fenêtre du terminal à partir de laquelle vous vous connectiez pour que plus soit activé, puis utilisez-le pour échapper au Shell.

Donc, la réponse dépend de ce que fait votre script. Consultez les pages man pour chacune des commandes que vous exécutez pour éviter une vulnérabilité.

15
Elhitch

TLDR: le script dont vous parlez est sécurisé!

Mais sachant qu'en production, vous pouvez utiliser des versions différentes, vous devez être conscient des concepts suivants:

1. Si la "lecture" est vulnérable à l'injection de commande. S'il est vulnérable, alors la valeur 'name' comme 'Bob; cat/etc/passwd ' pourrait retourner le contenu du fichier passwd et ' Bob &&/bin/bash -i ' pourrait donner une session bash interactive.

De telles questions ont déjà été posées, p. Ex. ici:

https://stackoverflow.com/questions/34640504/is-it-possible-to-perform-Shell-injection-through-a-read-and-or-to-break-out-of

La réponse dit "Non, pas vulnérable", à cause de:

"(..) les shells modernes analysent l'instruction avant toute substitution de variable, et ne sont donc pas affectés par cette attaque."

Ainsi, dans votre exemple, l'entrée utilisateur par "lecture" ne peut pas être contournée à partir du shell standard.

2. Où l'entrée est-elle analysée?

Votre script est sécurisé, car 'echo' ne fournit aucune technique d'échappement (du moins inconnue). Mais n'oubliez pas d'utiliser des binaires "dangereux" comme mentionné dans f.e. ici:

https://fireshellsecurity.team/restricted-linux-Shell-escaping-techniques/

Si les entrées utilisateur sont analysées par: man | less | more, awk, find, nmap, python | php | Perl, bash | sh lui-même, alors l'échappement est possible, ce qui permet un shell entièrement interactif (I 'ai juste testé avec moins, python et find).

Si vous mettez l'entrée uniquement en écho, comme dans votre exemple, alors vous êtes OK.

3. Si votre entrée est utilisée dans la commande Shell avec des astérisques (*), comme: tar * ou ls *

Je ne peux pas imaginer quand cela peut être utile dans votre scénario, mais il vaut toujours mieux le mentionner. Si c'est un cas, veuillez vous familiariser avec l'écriture suivante:

https://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt

Un tel comportement peut également conduire à échapper à votre script.

4
dtrizna