/************** ...: SysCalls Monitor SCM :... ************** * * * RedKod Team visit us at : www.redkod.com #redkod@undernet * * * ****************************************************************************** * * * Ce code est soumis aux termes de la licence GPL, merci de les respecter. * * * * Author : ChiRon Release Date : 2002-07-19 * * Mail : Revision : 2002-07-24 * * Filename : scm.c Version : 0.2 * * * *****************************************************************************/ 1 - Intro - (vous pouvez zapper si vous etes presse... ;) Ce module permet d'enregistrer l'etat des syscalls de votre systeme pour en verifier l'integrite, et si besoin est, de les restaurer dans leur etat d'origine. Pour cela il enregistre les adresses des appels systeme de la syscall table ainsi que les quelques premiers bytes qui les composent. Cela vous permet donc de savoir si les syscalls de votre systeme ont ete rediriges (par redirection classique ou hijacking). Si par exemple votre systeme a ete rootkitte, vous pouvez, non seulement le savoir, mais en plus rendre le rootkit innoperant ! Vous pouvez utiliser le module en mode manuel et en mode monitoring. Le mode monitoring reside en memoire, il verifie constamment les syscalls. Au moidre doute, il restaure les appels systemes originaux. J'ai par exemple essayer d'installer le rootkit Adore. 1 a 2 secondes environ apres avoir lance le ./startadore, Adore etait totalement innoperant ! 2 - Infos - Le module fonctionne tres bien chez moi : Debian Woody 3.0 i386 avec un noyau 2.4.9. Si vous rencontrez des difficultes a le faire fonctionner, contactez-moi; il est possible que certaines specificites de la programmation kernel changent en fonction des architectures, et je n'ai eu l'occasion de tester le module que sur ma machine... Sachez toutefois que le module necessite un noyau de version 2.2.0 ou ulterieure pour fonctionner (enfin il fonctionne avec les 2.3.x et 2.4.x et fonctionne _theoriquement_ avec des 2.2.x). Le support des LKM doit etre egalement active. Si tel n'est pas le cas, lors de la compilation du noyau, editez les configs comme suit : Enable Loadable Module Support (CONFIG_MODULES) : Y Set version information on all modules symbols (CONFIG_MODVERSIONS) : Y Kernel module support (CONFIG_KMOD) : Y 3 - How to use - Compilation : gcc -c -O3 -Wall -I/lib/modules/`uname -r`/build/include/ scm.c Chargement : root# insmod scm.o [OPTIONS] Dechargement : root# rmmod scm Options: * action init : initialise la liste avec les syscalls originaux. verify-x : compare la liste des syscalls originaux avec les syscalls actuels, affiche le resultat sur _output_ monitor-x : compare la liste des syscalls originaux avec les syscalls actuels _check_ fois toutes les _delay_ secondes, affiche le resultat sur _output_ note : pour verify et monitor, x represente le comportement, il peut etre "passive", dans ce cas le module se contente d'afficher si des syscalls ont ete modifies, ou "active", ou en plus d'afficher, le module va remplacer par les syscalls originaux les syscalls alteres. * input system : se base sur le systeme pour extraire les informations concernant les syscalls (vous n'aurez que leurs numeros, pas leurs noms). Ce parametre est disponible pour toutes les actions. file:foo : prend les information a partir d'un fichier, ou 'foo' est le chemin, relatif ou absolu, qui permet d'acceder a ce fichier. L'action init prend en entree uniquement le fichier "unistd.h", que vous pouvez trouver dans "/usr/src/linux/include/asm/". Il en extraitra le nom et les numeros des appels systeme. Les actions verify et monitor ne prennent en entree que des fichiers generes par l'action init. * output none : aucune sortie screen : sortie sur le stdout (par defaut l'ecran) file:foo : sortie dans le fichier 'foo' both:foo : sortie a la fois sur le stdout et dans le fichier 'foo' le resultat sur screen. note : les _output_ file et both sont indisponibles pour l'action monitor; ceci est du au fait que d'une part il est quasi impossible de gerer des fichiers quand on reside dans la memoire du kernel et d'autre part que cela n'aurait pas de sens : si un intru a obtenu le root, il lui suffit de faire un rm et tous les logs contenus dans le fichier sont effaces. * delay : pour l'action monitor-x uniquement; indique en secondes le labs de temps separant deux verifications (par defaut il est a 10 secondes). * check : pour l'action monitor-x uniquement; indique le nombre de fois que la table des syscalls sera checkee par seconde lors d'une verification. (1 fois par seconde est la valeur par defaut; son augmentation n'a de relle importance que si le delay est inferieur ou egal a 1 seconde). 4 - Quelques exemples d'utilisation - Initialisation a partir du unistd.h et qui enregistre les informations des syscalls dans le fichier syscalls_list : insmod scm.o action=init input=file:/usr/src/linux/include/asm/unistd.h output=file:syscalls_list Verification, qui prend ses infos dans le fichier syscalls_list et enregistre toute alteration dans le fichier report : insmod scm.o action=verify-passive input=file:syscalls_list output=file:report Monitoring, qui affiche a l'ecran toute alteration des syscalls, et restaure les syscalls des que ceux-ci sont modifies : insmod scm.o action=monitor-active input=file:syscalls_list output=screen Monitoring, qui n'affiche rien. Il prend ses infos directement a partir du systeme et verifie toutes les 2 secondes (vous pouvez par exemple lancer le module de cette maniere au chargement de linux, il s'adaptera au systeme et veillera constamment) : insmod scm.o action=monitor-active input=system output=none delay=2 5 - Notes Le mode monitoring est bien pratique, n'oublier pas cependant de lancer regulierement le module en mode manuel avec comme _input_ non pas le mode system, mais un fichier dans lequel toutes les infos des syscalls ont ete enregistrees; on est jamais trop prudent. D'autre part, il arrive (c'est assez rare) que les adresses des syscalls changent. J'en ai ete temoin. Veillez donc a verifier de temps en temps si tel est le cas, comme apres une grosse mis a jour du systeme ou du kernel (ceci ne concerne que le cas ou vous verifiez les syscalls a partir d'un enregistrement dans un fichier, l'input system s'adapte au systeme courant). L'affichage ecran n'est possible que sous une console; X ne permet pas de percevoir les messages du kernel. Faites attention aux fichiers _input_ que vous utilisez, suivez bien les instructions donnees plus haut, ne vous trompez pas (sinon ca peut segfaulter). Je tiens a m'excuser aupres des tous premiers utilisateurs du module. En effet, la version 0.1 etait vilainement buggee et faisait segfaulter le kernel (ahaha... mdr, pardon les gars ;). Si votre materiel ou votre systeme a ete endommage, je m'engage a vous rembourser la somme exacte que j'ai touchee pour votre copie du programme. Greets to Redkod Team Members : NostroBO, R-e-D, AngelUS49, LiNX` !