Contexte
Nous apprenons dans l’énoncé de ce chall que des logs suspicieux ont étés trouvés récemment, mais que ceux-ci ont disparus la minute après leur découverte.
Investigations
Le dossier /var/log ne contient rien d’intéressant, la récupération de données potentiellement supprimées est inutile dans ce chall.
Nous cherchons à retrouver les derniers éléments système de la machine, pour cela nous utilisons strace, un outil de débogage et de diagnostic qui trace les appels systèmes.
Le nom strace est dérivé de system call trace system call trace, ce qui signifie qu’il permet de tracer et d’analyser les appels système effectués par un programme.
En utilisant strace avec la commande ls, nous pouvons voir les appels système spécifiques utilisés par ls pour accéder aux fichiers.
Le résultat de l’exécution de strace ls affiche la liste détaillée des appels système effectués par ls ainsi que les arguments et les valeurs de retour correspondantes pour chaque appel système.
En analysant les appels systèmes, nous repérons un nom suspicieux:
listxattr est une fonction qui permet de lister les extended attributes associés à un fichier.
Dans notre cas, le chemin du fichier sur lequel l’appel système listxattr est effecuté est /var/log/hide_access_log.log, et l’extented attribut user.EVIL_ATTACKER_ATTR.
J’ai essayé en vain de récupérer le fichier de log avec getxattr, qui récupère le contenu de l’attribut étendu identifié par le nom et associé au chemin donné dans le système de fichiers.
En essayant d’afficher le droit du fichier, nous nous rendons compte d’une incompréhension:
Le fichier de log est bel et bien présent sur le système, mais n’est pas affichable.
Lorsque nous essayons d’afficher les détails du fichier, nous avons comme réponse ses droits, ainsi qu’un message répondant que celui-ci n’existe pas.
En guise de comparaison, le fichier pwnii n’existe pas sur le système, nous n’avons donc aucune information sur celui-ci.
Nous tentons d’afficher le fichier de log avec d’autre binaires que cat, avec par exemple less, tac, head, tail..
Aucun d’entre eus ne l’affiche, sauf more.
Flag: Hero{y0u_just_f1nd_4_r00tk1t_!!}
PoC | Rootkit super stylé
Le PoC fournit dans le fichier de log nous permet de comprendre ce qu’il s’est passé.
Ce rootkit modifie LD_PRELOAD, une variable d’environnement permettant
de spécifier une bibliothèque partagée qui sera chargée au démarrage d’un programme.
Pour faire cela, il utilise les extended attributes (xattr) qui sont des fonctionnalités permettant d’ajouter des informations supplémentaires à des fichiers ou des répertoires. Ils ne modifient pas la structure ou les attributs de base du fichier.
Afin de comprendre en détail cet incroyable rootkit, je vous recommande de lire de code source de celui-ci.
Nous affichons le contenu du fichier avec more car celui-ci utilise ioctl, un system call uilisé pour effectuer des opérations de contrôle sur des périphériques et des descripteurs de fichiers.
Cf: https://github.com/util-linux/util-linux/blob/master/text-utils/more.c
En analysant le rootkit, nous nous rendons compte que ioctl n’est pas hook, voilà pourquoi nous pouvons l’appeler ;)
Merci à @Worty pour ce chall.