On a tenté de nous hacker 0bin

This entry was posted in Administration System and tagged 0bin bash meta python security zerobin on by

En me baladant dans l’arbo de 0bin.net pour retirer un dox qu’on m’avait signalé je suis tombé sur un dossier au nom bizarre :

# ls -l
total 4
4 drwxr-xr-x 7 root root 4096 sept. 24  2014 --

Hum, voilà qui n’est pas pratique à analyser depuis le bash. Et pourquoi j’ai ce dossier-là d’ailleurs ?

Regardons ce qu’il y a dedans :

# python -c "import os; os.rename('--', "strange_dir")"
# ls strange_dir/
3Q  Dk  k5  Oh  -u

Oh, y a un dossier nommé “-u”…

A ce stade-là, j’ai juste supprimé le truc.

Et j’ai réalisé : on crée les dossiers de l’arbo en fonction du nom du paste, qui est une clé générée côté client, et donc fournie par un code JavaScript non trusté.

Du coup l’attaqueur nous a sans doute passé une commande bash comme nom de fichier. J’imagine, espérant qu’on fabriquait le fichier avec une exécution shell. Comme on utilise le module os pour le faire, je pense que ça n’a eu aucun impact.

J’espère :)

8 thoughts on “On a tenté de nous hacker 0bin”

  • Fred

    Non, aucun impact. A condition bien entendu que la commande “os” pour fabriquer le fichier ne soit pas “os.system()” ;)

    Sinon analyser un fichier/dossier nommé “–” depuis le bash ne pose aucun souci: suffit de rajouter “–” entre la commande et le nom du fichier

    Exemple: ls -l — “–”

    Le premier “–” indique au bash que ce qui suit n’est plus de l’option et qu’il doit alors le gérer comme un argument normal.

  • foxmask

    et eviter que le process qui a demarré 0bin ne soit pas owné by root

  • thican

    Hum, voilà qui n’est pas pratique à analyser depuis le bash.

    Pourtant, si, il est très facile de lire un fichier ou dossier de ce type, que ce soit Bash ou tout autre programme :

    – soit utiliser le chemin complet,

    – ou le chemin relatif en rajoutant “./” (ce qui donne ls ./–, pareil pour les jokers, ls ./*)

    my_2_cts

  • John

    Comment faites-vous pour la création du dossier ?

    makedirs() ? subprocess() avec shell=True ? os.system() ? os.popen() ?

    Si c’est makedirs vous ne craignez rien (amha) par contre si l’une des 3 suivantes vous pouvez continuer votre analyse, ça sent le pwnage.

  • Sam Post author

    Zerobin est owné par zerobin et non root:

     # ps aux | grep zerobin
root      4967  0.0  0.0  11292   972 pts/0    S+   07:46   0:00 grep --color=auto zerobin
zerobin  18993  0.0  0.6 895720 19436 ?        Sl   Oct20   8:42 python /home/zerobin/zerobin.py --settings-file /home/zerobin/zerobin/settings.py

    Et on crée le chemin avec os.makedirs, os.mkdir and open: https://github.com/sametmax/0bin/blob/master/zerobin/paste.py#L143

    . D’ailleurs ça me fait remarqué qu’on a une optimisation inutile dans cette partie du code qu’on devrait virer.

    Normalement on est bon, mais il y a peut être eu d’autres essais qu’on a pas vu ^^

  • Dominique

    Merci pour le lien John… c’est vachement intéressant comme contenu.

    Je pense que je vais essayer le soir à la maison

    Dominique

  • windows_user

    J’ai vu que ca à été corrigé depuis, que tu gènère l’uuid coté serveur et non plus coté client. En revanche, à l’époque, os.mkdirs ne sécurisait pas tout, voici un exmple avec le code actuel, même si le kwarg uuid est présent sans être utilisé:

     
p = Paste(uuid="yoyo/../../../views/ya", content="code")  # écrit un fichier dans views, et peut probablement écraser le html présent si au lieu de mettre "ya" on met base.tpl...
    p.save()

    Il va sans dire que ca peut aussi marche pour n’importe quel fichier de n’importe quelle dir qui se trouve en static.

Comments are closed.

Des questions Python sans rapport avec l'article ? Posez-les sur IndexError.