Pwned by abandonware
Table of Contents
1. Introduction
Conférence faite par des employés de Synacktiv. La conférence se veut un premier pas dans la sécurisation Linux via le prisme d'un émulateur (DOSBox) qui a besoin d'autorisations tout en les régulant pour ne pas se faire poutrer par un exécutable malveillant.
2. Contexte
DOSBox est un émulateur de système DOS. Une fois lancé, il peut monter en lecture et écriture le disque de l'hôte. Wine est un émulateur plus générique pour Windows, qui va monter automatiquement le dossier home de l'utilisateur.
Est-il possible, ayant accès aux fichiers de l'utilisateur, de lui péter son système en backdoorant un exéctuable ou un script ?
2.1. Avec un script .bat
Il n'est pas possible d'exécuter un script .bat avec DOSBox qui
écrit un programme malveillant sur l'hôte pour plusieurs raisons :
- le nom des fichiers est en majuscules (avec une commande de type
echo coucou > test) - le retour à la ligne est celui de Windows (
\r\n) et ne sera pas compris par Linux si on cherche à exécuter le fichier ensuite - les fichiers ont un nom d'une taille maximum de 8 caractères
L'idée serait donc d'écrire un programme en C pour pouvoir écrire ce fichier.
2.2. Détection de l'environnement
Il est possible de détecter DOSBox grâce à la commande ver. Il est
indiqué la version de DOS ainsi que DOSBox. Il est aussi possible de
le détecter avec un script BAT : on essaie de monter D dans
~. Windows refusera mais c'est possible sur Linux.
Il est plus compliqué de détecter Wine, mais son nom peut être
retrouvé dans le fichier ntdll.dll.
2.3. Comment se protéger
Plusieurs options :
- avoir confiance en l'éditeur et dans le distributeur : un vieux logiciel a pu être repacké et tous les distributeurs ne font pas de check de sécurité
- lire le code source, mais le binaire peut différer et c'est très chronophage et nécessite des compétences en RE et/ou en développement
Ou alors, on liste ce que l'on souhaite éviter : l'accès aux fichiers et à Internet.
Il est possible de faire ça avec une sandbox :
- Docker, dur à utiliser avec une interface graphique
- une VM, mais il n'y a pas plus d'intérêt à utiliser DOSBox
- utiliser une technologie qui s'appuie sur les namespaces (FireJail, BubbleWrap, Flatpack…)
On va se concentrer sur un mécanisme générique : les Linux Security Module, et plus particulièrement sur SELinux et AppArmor, les plus connus. Il existe d'autres solutions, souvent complémentaire, comme Yama ou Lockdown.
3. SELinux
Cette solution a été développé en 2001 par la NSA, mais Linus n'était pas chaud pour l'ajouter à Linux.
Son principe est de mettre un label à chaque processus et fichier afin
de limiter les accès à des bulles. Cela nécessite cependant un système
de fichier compatible. Il est possible de voir ce label avec l'option
-Z dans ls et ps.
Par exemple (et par défaut), un processus avec le label ssh ne peut
pas lire un fichier avec le label http. Et ce même s'il est exécuté
en root.
Ce n'est cependant pas le cas, SELinux est configuré pour pouvoir laisser un minimum de liberté aux utilisateurs. Beaucoup de choses sont "cachées", mais configurables.
2 astuces :
- ne jamais mettre la valeur
setenforceà 0, cela désactive SELinux - la copie de fichier ne va pas forcément garder le label. Il faut
utiliser
restoreconpour le restaurer
Google utilise cette solution pour Android (depuis la 5.0) et les distributions basées Fedora ont une préconfiguration dédiée.
SELinux rend la rétroingénierie et le pentest très difficile. Il apporte une bonne protection. Cependant, il n'est pas bien supporté par Ubuntu ou Debian.
4. AppArmor
AppArmor a quelques différences avec SELinux :
- il est plus simple et utilisé par défaut sur Debian
- n'a pas de label par fichier, seuls les processus en ont un
- le profil est lié à un chemin, on perd la configuration, ou profile, si on déplace le binaire
Un fichier de configuration va contenir des listes d'actions. Il existe 2 modes qui vont définir ce que l'on fait lorsqu'un programme voudra en exécuter une :
complain- reporte l'action dans le journal
enforce- bloque l'action sans la reporter
Lorsqu'un programme appelle un autre programme, on effectue une transition.
Ubuntu contient le profile AppArmor de quelques applications, mais la majorité n'en a pas.
4.1. Comment faire un profile
L'outil officiel pour écrire des profiles ne marche pas très bien et est en retard sur certaines fonctionnalités. Il est mieux d'écrire à la main la configuration.
La méthode Synacktiv pour écrire rapidement un profile fonctionnel :
- écrire un profile simple très restrictif en mode enfore
- essayer de lancer l'application (elle va sûrement crasher parce qu'elle n'a pas assez de droits)
- vérifier la dernière action qu'elle a souhaité faire
- l'ajouter dans le profile
- retourner au 2.
Il est possible d'inclure d'autres fichiers dans les profiles,
plusieurs fichiers d'abstraction contenant des règles pour des
programmes C ou des programmes ayant besoin du son se trouvent dans
/etc/apparmor.d.
4.2. Quelques astuces
Le profile private-file-strict permet de bloquer toutes les actions
sur les fichiers.
Il est possible de mettre le flag U pour définir des changements
de profiles lors des transitions. Il faut cependant éviter, cela
autorise le programme à faire ce qu'il veut.
La règle deny va être prioritaire sur une même rège qui autoriserait
une action et ne laisse pas de trace dans le journal. Cela permet
d'éviter le spam d'informations alors que l'on sait que le programme
fonctionne sans avoir accès à cette règle. Une règle deny ne
laisserait pas de trace même avec un profile complain.
5. Durcir Wine sans AppArmor
Pour pouvoir durcir Wine sans utiliser AppArmor, il est possible de :
- avoir un utilisateur à part sans droit, certains fichiers systèmes peuvent cependant rester accessible
- utiliser la sandbox de Wine, mais elle reste très vulnérable et facilement contournable
6. Conclusion
- il ne faut pas lancer n'importe quoi sur sa machine
- il faut durcir son système
- il faut comprendre comment ce durcicement fonctionne pour pouvoir l'appliquer au mieux