41. Les différents types d’attaques
La sécurité informatique et son pendant, le piratage, sont liés de manière très intime. Ce que fait l’un dicte l’existence de l’autre et inversement.
41.1. Les attaques locales
Les attaques locales peuvent être dûes à un logiciel défectueux ou une mauvaise configuration du système. Dans le premier cas, deux possibilités existent :
une faille logicielle existante mais non connue du grand public [1],
une faille logicielle existante connue du grand public [2].
Si [1] se produit, la seule solution est la veille passive sur l’exécution des processus de chaque utilisateur mais il s'agit d'un cas rare. C’est généralement [2] qui se présente, et qui, suite à une maintenance défectueuse permet à la personne mal intentionnée de faire ce qu’elle désire. Ainsi il est indispensable de faire un suivi quotidien des logiciels qui nécessitent une mise à jour, de vérifier que les processus en présence sont normaux et qu’aucune connexion inconnue ne perturbe la ligne.
Un exemple de maintenance minimale se présente comme suit :
$ ssh eof.eu.org -l jop $ sudo apt-get update $ sudo apt-get dist-upgrade -u $ sudo ps faux $ sudo netstat -tupanw $ sudo last $ sudo w
Si l'on explique ce qui ce passe :
connexion à l’hôte désiré
récupération de la liste des mises à jour en fonction du système
visualisation et installation des paquets à mettre à jour
surveillance des processus à un instant T, ordonnés en arbre
surveillance des connexions tcp et udp
visualisation des dernières connexions
liste des connectés au système à un instant T
41.1.1. Élévation des privilèges
Lorsqu’un système est compromis, le pirate va toujours chercher à obtenir des privilèges supérieurs. Ceci afin de se laisser libre accès aux ressources systèmes et réseaux. Pour ce faire, il va utiliser mille et un procédés. La finalité est toujours la même, à savoir devenir root.
41.1.1.1. Root : jamais !
On peut considérer comme dangereux de se connecter en tant que root. Dans ce cas, il faudra privilégier un utilisateur afin qu’il puisse exécuter les commandes usuelles d’administration. Pourquoi ne pas utiliser root ? Parce que le mot de passe pourrait être intercepté, parce que root peut modifier à loisir tout ce qui se trouve sur le système, y compris les logs. L’emploi de la commande sudo laisse des traces évidentes et elle est à loisir configurable, on peut donc s’appuyer dessus pour un exercice efficace.
Exercice : installez et configurez sudo pour qu’il ne vous autorise qu’à utiliser la commande iptables. Configurez-le d’abord pour qu’il vous demande votre mot de passe, puis qu’il ne vous le demande plus jamais. Présenter ensuite le contenu du fichier etc/sudoers :
Visualisation de l'état courant du fichier :
root@CP2L:~# cat /etc/sudoers # /etc/sudoers # # This file MUST be edited with the 'visudo' command as root. # # See the man page for details on how to write a sudoers file. # Defaults env_reset # Host alias specification # User alias specification # Cmnd alias specification # User privilege specification root ALL=(ALL) ALL # Allow members of group sudo to execute any command # (Note that later entries override this, so you might need to move # it further down) %sudo ALL=(ALL) ALL # #includedir /etc/sudoers.d
Faisons maintenant en sorte que seule la commande iptables soit autorisée :
root@CP2L:~# visudo root@CP2L:~# tail -n 10 /etc/sudoers root ALL=(ALL) ALL # Allow members of group sudo to execute any command # (Note that later entries override this, so you might need to move # it further down) %sudo ALL=(ALL) ALL # #includedir /etc/sudoers.d vanvincq ALL = !ALL, /sbin/iptables
Essayons maintenant de faire quelques commandes :
vanvincq@CP2L /media/Emulation/Master-2-ISIDIS/CPLL/JournalDeBord $ sudo ls [sudo] password for vanvincq: Sorry, user vanvincq is not allowed to execute '/bin/ls' as root on CP2L. vanvincq@CP2L /media/Emulation/Master-2-ISIDIS/CPLL/JournalDeBord $ sudo ps aux [sudo] password for vanvincq: Sorry, user vanvincq is not allowed to execute '/bin/ps aux' as root on CP2L.
Essayons avec iptables :
vanvincq@CP2L /media/Emulation/Master-2-ISIDIS/CPLL/JournalDeBord $ sudo iptables -L [sudo] password for vanvincq: Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
Ajoutons maintenant la possibilité de faire un sudo sans devoir imérativement renseigner le mot de passe :
root@CP2L:~# visudo root@CP2L:~# tail -n 10 /etc/sudoers root ALL=(ALL) ALL # Allow members of group sudo to execute any command # (Note that later entries override this, so you might need to move # it further down) %sudo ALL=(ALL) ALL # #includedir /etc/sudoers.d vanvincq ALL = NOPASSWD: !ALL, /sbin/iptables
Voilà, juste un dernier essai pour en être certain :
vanvincq@CP2L ~ $ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
Il est important, voire essentiel de ne jamais exécuter un processus inconnu en tant que root. C’est pour cela que la variable PATH de root ne contient pas le répertoire où vous vous trouvez comme chemin d’exécution. Prenons un petit exemple :
Un élève ambitieux construit un fichier qui ajoute un nom et un password avec les droits root puis qui exécute la commande ls. Que se passe-t’il si root l’exécute ? Le compte est ajouté et la commande ls s’exécute correctement. Nous venons de fournir à notre élève un compte avec le pouvoir de l’administrateur en une commande.
Selon l’environnement où vous vous trouvez, cherchez une réponse "adaptée". Il n’y a pas de solution parfaite toute faîte. Pour cela, il est nécessaire de bien connaître les besoins de vos utilisateurs et de leur faire c omprendre vos besoins en terme de sécurité. Des solutions comme rssh et/ou l’emprisonnement pourront être parfaite pour certains et non avenues pour d’autres.
Exercice : expliquez dans un texte d’une dizaine de lignes l’intérêt de rssh ainsi que ses contraintes.
rssh est un shell réduit qui s'utilise avec OpenSSH et qui fournit un accès limité à l'hôte l'utilisant. Ainsi, une fois configuré, rssh autorise l'utilisation d'une ou plusieurs de ces commandes : scp, sftp, cvs, rdist et rsync. Aucune autre commande ne sera autorisée. À l'instar d'un environnement "chrooté", rssh emprisonnera son utilisateur dans un espace réduit tout en limitant son domaine d'action. L'avantage est assurément lié à la sécurité que procure son utilisation. Néanmoins, paradoxalement, un bug a été découvert par John Barber; permettant à un utilisateur l'accès intégral au système, autrement dit de contourner l'environnement chrooté. Mais ce cas de figure n'était succeptible d'arriver qu'en cas d'absence de fichier de configuration (ou de configuration erronée). Désormais, il est obligatoire d'avoir un fichier de configuration valide. Dans le cas contraire, tous les accès utilisateurs seront vérouillés. Un autre bug découvert cette fois par Maarten van der Schrieck a une nouvelle fois fait apparaître une faille de sécurité. Mais rassurons nous, la dernière version de rssh corrige ces problème. En bref, même si un programme améliore la sécurité, il ne faut jamais se croire à l'abri.
Source : pizzashack.org
41.1.2. Mot de passe
L’obtention d’un mot de passe est une entrée directe sur votre serveur. Il ne faut donc pas hésiter à le changer régulièrement tout en prenant soin qu'il soit d'une certaine complexité. De même, si vous savez de manière sûre qu’un utilisateur loue/donne/vend son mot de passe, pensez à des sanctions sévères à son encontre.
41.1.3. Les rootkits
Les rootkits, ou boîtes à outils du parfait petit pirate, permettent à son possesseur de prendre le contrôle du système et de cacher son activité à l’administrateur, la plupart du temps en remplaçant les binaires communs, tels que ls, netstat, w, last, ps, top. Il peut de ce fait agir en toute impunité, sans ce soucier d’une éventuelle intervention du propriétaire. Le moyen le plus efficace pour se rendre compte de cette infraction est de surveiller les binaires essentiels de votre système par un hids.
Exercice : installez et configurez tripwire de manière sommaire. Remontez par mail l’inconvénient de ce genre de système ainsi que ses avantages.
Tripwire que l'on peut classer dans la catégorie des HIDS permet la détection d'intrusions sur un hôte. pour l'installation, je choisis la simplicité en utilisant apt-get. Lors de l'installation il sera demandé deux passphrases (le local passphrase pour sécuriser l'accès à la base de données et les rapports; et le site passphrase pour sécuriser le fichier de configuration).
Pour une première utilisation, il est nécessaire d'initialiser la base de données Tripwire. Pour cela il faut utiliser la commande tripwire.
vanvincq@CP2L ~/Bureau/CPLL/JournalDeBord $ sudo /usr/sbin/tripwire --init Please enter your local passphrase: Parsing policy file: /etc/tripwire/tw.pol Generating the database... *** Processing Unix File System *** ### Warning: File system error. ### Filename: /var/lib/tripwire/CP2L.twd ### Aucun fichier ou dossier de ce type ### Continuing... The object: "/lib/init/rw" is on a different file system...ignoring. ### Warning: File system error. ### Filename: /etc/rc.boot ### Aucun fichier ou dossier de ce type ### Continuing... ### Warning: File system error. ### Filename: /root/mail ### Aucun fichier ou dossier de ce type ### Continuing... ### Warning: File system error. ### Filename: /root/Mail ### Aucun fichier ou dossier de ce type [...] ### Continuing... ### Warning: File system error. ### Filename: /root/.addressbook.lu ### Aucun fichier ou dossier de ce type ### Continuing... ### Warning: File system error. ### Filename: /root/.Xresources ### Aucun fichier ou dossier de ce type ### Continuing... The object: "/dev/pts" is on a different file system...ignoring. The object: "/dev/shm" is on a different file system...ignoring. ### Warning: File system error. ### Filename: /proc/3479/fd/4 ### Aucun fichier ou dossier de ce type ### Continuing... ### Warning: File system error. ### Filename: /proc/3479/fdinfo/4 ### Aucun fichier ou dossier de ce type ### Continuing... ### Warning: File system error. ### Filename: /proc/3479/task/3479/fd/4 ### Aucun fichier ou dossier de ce type ### Continuing... ### Warning: File system error. ### Filename: /proc/3479/task/3479/fdinfo/4 ### Aucun fichier ou dossier de ce type ### Continuing... The object: "/proc/sys/fs/binfmt_misc" is on a different file system...ignoring. Wrote database file: /var/lib/tripwire/CP2L.twd The database was successfully generated.
Durant la phase d'initialisation, il se peut (ce qui est mon cas) de rencontrer des avertissements et autres messages d'erreurs. Il peut être adéquat de modifier le fichier de configuration (/etc/tripware/twpol.txt) et commenter ce qui n'est pas nécessaire. En effet, c'est dans ce fichier que l'on définit la "politique" de tripware, autrement dit on y définit ce qui doit être monitoré et de quelle mamnière.
Une fois le fichier modifié, il faut le signer :
vanvincq@CP2L ~ $ sudo /usr/sbin/twadmin --create-polfile -S /etc/tripwire/site.key /etc/tripwire/twpol.txt [sudo] password for vanvincq: Please enter your site passphrase: Wrote policy file: /etc/tripwire/tw.pol
À noter qu'à chaque fois que l'on modifie les fichiers /etc/tripwire/twcfg.txt ou /etc/tripwire/twpol.txt il faut reconstruire la base. Il est préférable de supprimer l'ancienne base préalablement (stocké dans /var/lib/tripwire/).
Vérification de l'intégrité de la base :
vanvincq@CP2L ~ $ sudo /usr/sbin/tripwire --check > ~/check_rapport.txt vanvincq@CP2L ~ $ head -n 20 check_rapport.txt Parsing policy file: /etc/tripwire/tw.pol *** Processing Unix File System *** Performing integrity check... The object: "/lib/init/rw" is on a different file system...ignoring. The object: "/dev/pts" is on a different file system...ignoring. The object: "/dev/shm" is on a different file system...ignoring. The object: "/proc/sys/fs/binfmt_misc" is on a different file system...ignoring. Wrote report file: /var/lib/tripwire/report/CP2L-20120418-200247.twr Open Source Tripwire(R) 2.4.1 Integrity Check Report Report generated by: root Report created on: Wed Apr 18 20:02:47 2012 Database last updated on: Never =============================================================================== Report Summary: ===============================================================================
Pour visualiser le contenu de la base de données :
vanvincq@CP2L ~ $ sudo /usr/sbin/twprint -m d
[...]
/etc/usb_modeswitch.d/12d1:1520
-rw-r--r-- root (0) 260 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/12d1:1521
-rw-r--r-- root (0) 260 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/12d1:1523
-rw-r--r-- root (0) 259 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/12d1:1553
-rw-r--r-- root (0) 260 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/12d1:1557
-rw-r--r-- root (0) 259 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/12d1:1c0b
-rw-r--r-- root (0) 260 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/1410:5010
-rw-r--r-- root (0) 285 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/1410:5020
-rw-r--r-- root (0) 253 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/1410:5030
-rw-r--r-- root (0) 260 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/1410:5031
-rw-r--r-- root (0) 265 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/1410:5041
-rw-r--r-- root (0) 303 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/148f:2578
-rw-r--r-- root (0) 305 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/16d8:6281
-rw-r--r-- root (0) 239 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/16d8:6803
-rw-r--r-- root (0) 250 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/16d8:6803:?
-rw-r--r-- root (0) 277 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/16d8:700a
-rw-r--r-- root (0) 238 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/16d8:f000
-rw-r--r-- root (0) 329 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/198f:bccd
-rw-r--r-- root (0) 282 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/19d2:0003
-rw-r--r-- root (0) 312 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/19d2:0026
-rw-r--r-- root (0) 274 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/19d2:0040
-rw-r--r-- root (0) 366 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/19d2:0053
-rw-r--r-- root (0) 365 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/19d2:0083
-rw-r--r-- root (0) 284 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/19d2:0101
-rw-r--r-- root (0) 287 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/19d2:0103
-rw-r--r-- root (0) 355 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/19d2:0115
-rw-r--r-- root (0) 274 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/19d2:1001
-rw-r--r-- root (0) 491 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/19d2:1007
-rw-r--r-- root (0) 287 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/19d2:1009
-rw-r--r-- root (0) 287 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/19d2:1013
-rw-r--r-- root (0) 491 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/19d2:2000
-rw-r--r-- root (0) 519 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/19d2:fff5
-rw-r--r-- root (0) 276 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/19d2:fff6
-rw-r--r-- root (0) 268 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/1a8d:1000
-rw-r--r-- root (0) 276 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/1a8d:1000:uPr=5G
-rw-r--r-- root (0) 383 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/1ab7:5700
-rw-r--r-- root (0) 264 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/1b7d:0700
-rw-r--r-- root (0) 308 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/1bbb:f000
-rw-r--r-- root (0) 280 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/1c9e:1001
-rw-r--r-- root (0) 270 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/1c9e:9200
-rw-r--r-- root (0) 291 Sun Feb 27 22:29:09 2011
/etc/usb_modeswitch.d/1c9e:9e00
-rw-r--r-- root (0) 234 Sun Feb 27 22:29:09 2011
[...]
Pour plus d'information, il peut être intéressant de jeter un oeil sur ces différents sites : [1][2].
Ainsi, Tripware peut s'avérer intéressant pour la surveillance d'un système ou de tout autre chose. Néanmoins, il ne faut jamais se reposer entièrement sur un outil pour assurer la sécurité d'un système.
41.2. Les attaques distantes
Si les attaques locales sont plus nombreuses elle n’en sont pas moins les plus dangereuses, puisque comme nous l’avons vu, elles restent dans un champ de personnes connues. Les attaques distantes, quant à elles, permettent à toute personne potentiellement raccordée à votre réseau de tenter sa chance, ce qui, dans le cas d’Internet peut devenir un réel problème.
41.2.1. Le problème de l’ARP
Exercice : reproduisez les exemples du site arp-sk et remontez vos impressions.
Arp-sk est un outil conçu pour manipuler les tables ARP de toute sorte d'équipement.
Récupération et installation de arp-sk :
vanvincq@CP2L ~/Documents/arp-sk-0.0.16 $ ./configure beginning autoconfiguration process for arp-sk-0.0.16... checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking whether make sets $(MAKE)... yes checking for working aclocal-1.4... missing checking for working autoconf... missing checking for working automake-1.4... missing checking for working autoheader... missing checking for working makeinfo... found checking for gcc... gcc checking for C compiler default output file name... a.out [...]
vanvincq@CP2L ~/Documents/arp-sk-0.0.16 $ make Making all in man make[1]: entrant dans le répertoire « /home/vanvincq/Documents/arp-sk-0.0.16/man » make[1]: Rien à faire pour « all ». make[1]: quittant le répertoire « /home/vanvincq/Documents/arp-sk-0.0.16/man » Making all in compat make[1]: entrant dans le répertoire « /home/vanvincq/Documents/arp-sk-0.0.16/compat » gcc -DHAVE_CONFIG_H -I. -I. -I../include -g -O2 -W -Wall -c getopt1.c gcc -DHAVE_CONFIG_H -I. -I. -I../include -g -O2 -W -Wall -c getopt.c gcc -DHAVE_CONFIG_H -I. -I. -I../include -g -O2 -W -Wall -c inet_aton.c gcc -DHAVE_CONFIG_H -I. -I. -I../include -g -O2 -W -Wall -c inet_ntop.c gcc -DHAVE_CONFIG_H -I. -I. -I../include -g -O2 -W -Wall -c strcasecmp.c gcc -DHAVE_CONFIG_H -I. -I. -I../include -g -O2 -W -Wall -c strerror.c gcc -DHAVE_CONFIG_H -I. -I. -I../include -g -O2 -W -Wall -c strlcat.c gcc -DHAVE_CONFIG_H -I. -I. -I../include -g -O2 -W -Wall -c strlcpy.c rm -f libcompat.a [...]
vanvincq@CP2L ~/Documents/arp-sk-0.0.16 $ sudo make install [sudo] password for vanvincq: Making install in man make[1]: entrant dans le répertoire « /home/vanvincq/Documents/arp-sk-0.0.16/man » make[2]: entrant dans le répertoire « /home/vanvincq/Documents/arp-sk-0.0.16/man » make[2]: Rien à faire pour « install-exec-am ». make install-man1 make[3]: entrant dans le répertoire « /home/vanvincq/Documents/arp-sk-0.0.16/man » /bin/bash ../mkinstalldirs /usr/local/man/man1 /usr/bin/install -c -m 644 ./arp-sk.1 /usr/local/man/man1/arp-sk.1 make[3]: quittant le répertoire « /home/vanvincq/Documents/arp-sk-0.0.16/man » make[2]: quittant le répertoire « /home/vanvincq/Documents/arp-sk-0.0.16/man » make[1]: quittant le répertoire « /home/vanvincq/Documents/arp-sk-0.0.16/man » Making install in compat [...]
vanvincq@CP2L ~/Documents $ sudo updatedb; locate arp-sk /usr/local/sbin/arp-sk /usr/local/share/man/man1/arp-sk.1
41.2.1.1. MAC spoofing
Cette technique consiste à changer l'adresse MAC d'une carte réseau d'un hôte sur un réseau.
41.2.1.2. ARP spoofing
Cette technique consite à envoyer sur le réseau un paquet ARP contenant de fausses informations. Le principal intérêt est de détourner le flux pour l'obliger à passer en un point spécifique.
41.2.2. MITM
Man In The Middle (MITM), que l’on peut traduire par l’homme au milieu est une attaque courante. C’est entre autre celle que nous venons de voir au niveau arp. Le pirate cherche à s’introduire entre vous et l’hôte que vous souhaitez contacter. Que cela soit sur une connexion sécurisée ou non, l’attaque reste possible. C’est pour cela qu’il faut absolument vous assurer de votre interlocuteur, d’autant plus lorsque vous vous trouvez sur une liaison possédant une couche ssl. Vérifiez toujours les certificats qui vous sont présentés et au moindre signe de modification intempestive, contactez l’administrateur distant pour vous assurer que celle-ci est normale.
41.2.3. DOS et DDOS
Le déni de service et son petit frère le déni de service distribué sont des moyens attrayant pour couper un utilisateur du reste du monde. Ainsi isolé, la victime est aveugle et sourde et reste à la merci du pirate. Pourquoi employer ce type d'attaque ?
il peut tout simplement permettre une demande de rançon pour que l’attaque s’arrête. C’est une chose courante pratiquée par la mafia.
Le pirate peut tout simplement vouloir usurper la place de l’hôte qu’il DOS sur le réseau,
le pirate peut vouloir attirer l’attention sur un endroit précis pendant qu’il attaque ailleurs.
La différence entre une attaque DOS et DDOS est que dans la deuxième situation, l'assaut provient non pas d'un hôte mais de plusieurs, souvent comptés en milliers. Que peut on faire dans ce cas ? Tout dépend des circonstances, mais il faut tout d’abord commencer par ne pas paniquer. Il faut étudier l’attaque et tenter de cibler un point commun à chacune, par exemple un paramètre qui serait identifiable dans chaque paquet incriminé. Par la suite, prenez des mesures sur votre firewall puis sur votre routeur et n’hésitez pas à contacter votre fournisseur d’accès.
Sachez qu’un deni de service peut se pratiquer très facilement sur un système en moins de treize caractères. Ne prenez donc pas ce problème à la légère et pensez le plus tôt possible à des solutions adéquates.
41.2.4. XSS
Le Cross Scripting Site est un procédé très répandu sur Internet qui consiste à utiliser des faiblesses de programmation des sites pour exécuter des commandes locales ou distantes. Cela est rendu possible par l’existence de langages tels que PHP.
En effet, que va t’il se passer si dans un formulaire, j’autorise l’upload d’un fichier php, sans prendre une quelconque protection ? Si la personne a directement accès à ce fichier par la suite, il peut programmer autant de choses qu’il désire, à commencer par un shell distant ou une discussion directe par sa page.
Même si ce problème semble bénin, on retrouve des milliers de sites affectés de la sorte. Quelle est la solution à adopter ? Il faut tout d’abord s’assurer que tous les champs d’upload ou de saisie sont vérifiés. Ne pas se baser sur les cookies comme unique moyen d’authentification et pour finir, avoir une configuration close du langage utilisé.
Qu’est ce que cela signifie dans les faits ? Tout simplement que si l’administrateur système ne travaille pas avec les équipes de développement des sites, ou s’il n’est pas suffisamment strict dans sa politique d’hébergement, il risque de gros ennuis par la suite.
Exercice : Créez une page web en php qui laisse en champ de saisie sans vérification et qui renvoie sur la même page le résultat. Insérez la chaîne suivante dans le champ de saisie et envoyez au traitement : <script>alert(’problème’);</script> Analysez le résultat. Si un problème en résulte, comme l’apparition d’un pop-up, réparez le problème. Expliquez vos résultats.
Voici le petit script (très simpliste) PHP chargé de démontrer la faille XSS. Les deux fichiers se nomment failleXSS.php et failleXSS2.php :
<?php
echo "<html>";
echo "<head></head>";
echo "<body>";
echo "<h2>Faille XSS :</h2>";
echo "<form method='post' action='failleXSS2.php'>";
echo "<table>";
echo "<tr>";
echo "<td>Nom :</td>";
echo "<td><input type='text' name='nom' value='' /></td>";
echo "<td><input type='submit' value='valider' /></td>";
echo "</tr>";
echo "</table>";
echo "</form>";
echo "</body>";
echo "</html>";
?>
<?php
echo "<html>";
echo "<head></head>";
echo "<body>";
echo "<h2>Faille XSS :</h2>";
echo "Bonjour ".$_POST['nom']." !";
echo "</body>";
echo "</html>";
?>
Voilà ce qu'on obtient basiquement :
On veut bien qu'il est très facile d'injecter du javascript dans la balise input. Procédons maintenant à une simple précaution en ajoutant un appel à la fonction htmlentities pour sécuriser le code :
<?php
echo "<html>";
echo "<head></head>";
echo "<body>";
echo "<h2>Faille XSS :</h2>";
echo "Bonjour ".htmlentities($_POST['nom'])." !";
echo "</body>";
echo "</html>";
?>
Réessayons le test :
Htmlentities offre une première ligne de protection mais cette fonction est loin d'être suffisante. Il y a d'autres failles exploitables comme par exemple le "SQL injection".
41.2.5. L’ingénierie sociale
Un des fléaux actuels se résume dans ces deux mots. Nul besoin de casser du code, de chercher des failles de sécurité. Pourquoi faire compliqué lorsque l’on peut faire simple ? En effet, vous voulez un accès, il suffit de le demander. Une procédure d’inscription en bonne et due forme et vous obtenez l’accès au graal.
La guerre électronique, comme on la nomme dans les hautes sphères se base sur le modèle de la communication. On vous montre ce que vous désirez voir et entendre, du moment que le résultat est assuré. Ainsi, une personne mal intentionnée pourra se faire passer pour un fournisseur afin de récupérer telle ou telle information. D’autres encore diront faire partie de la télémaintenance pour obtenir directement un mot de passe.
Intox ou info, toujours est-il que la chose marche et plutôt bien même.
Comment lutter contre cela ? Nous allons le voir dans le chapitre suivant, mais une des premières règles réside en quelques mots : ne jamais donner son mot de passe ! Vérifiez, autant que possible, la réalité de vos interlocuteurs. Les entreprises ont en général un site web avec un début d’organigramme ; les newsgroups sont le coeur même de fanatiques de la communication. Les pages personnelles ne manquent pas. N’hésitez pas à faire des recherches sur vos correspondants pendant qu’ils sont en ligne. Cela peut paraître incongru, mais cela vous vaudra une sécurité améliorée.
41.3. Sensibilisation
C’est le début même du plan de sécurisation de votre système d’information. Comme nous l’avons déjà vu, la sécurité totale de votre SI réside sur la résistance la plus forte de votre maillon le plus faible, qui en général se trouve être l’humain.
Organisez des séances de sensibilisation, sous forme de jeux par exemple ou de petits films. Il est nécessaire que chacun de vos collaborateurs soit informé des risques qu’il fait encourir à l’entreprise et au-delà au SI s’il s’avère être le maillon faible. Toujours en accord avec votre direction, n’hésitez pas à faire des rappels réguliers sur les mots de passe, en les accompagnant d’une liste de comptes défectueux. Restez toujours cordial, mais ferme quant à votre politique, à commencer par vous-même. Ce n’est pas parce que vous êtes l’administrateur que vous êtes au-dessus du lot. Appliquez d’abord vos règles et montrez-le, vous n’en serez que d’avantage pris au sérieux.
41.4. La charte de l’utilisation du système d’information
La charte est votre point d’entrée du droit dans votre SI. Toute personne n’ayant pas accepté la charte doit se voir interdire l’usage du SI. En effet, c’est elle qui définit les usages à l’intérieur du SI, ainsi que les limites. Toute infraction à celle-ci doit d’abord se voir doter d’un rappel, puis si l’infraction continue, d’une interdiction d’usage partiel ou total. Cette charte n’est pas posée une fois pour toute dans l’entreprise, elle doit être mûrement réfléchie et modifiable chaque année, en fonction des nouvelles technologies. Nous avons eu l’occasion de le voir par l’arrivée du p2p et des messageries instantanées. Si quelque chose n’est pas cité dans la charte, préférez que les utilisateurs viennent vous demander l’autorisation, plutôt qu’ils ne le fassent à votre insu. Créer un climat de confiance autour de ces règles de bonne conduite vous permettra de constituer une sécurité plus résistante.
41.5. L’historisation
Pour terminer ce panel sur les types d’attaques et les solutions inhérentes, revenons un peu sur le plan technique. Vos systèmes vont produire un historique d’utilisation, autant dans le bon usage que dans les erreurs qui sont commises sur votre SI. Il semble indispensable de centraliser ces informations et de les rendre non accessibles à l’extérieur de votre entreprise, ceci afin qu’en cas de compromission, le pirate ne puisse effacer ses traces.
Il est fort probable, en fonction de la quantité d’informations que vous récolterez, qu’un serveur doive être dédié à cette action. De même, si la génération de logs est forte, il serait stupide de vouloir suivre la totalité de ceux-ci. Préférez des remontées d’alertes ciblées.
En terme de cartographie du réseau, certains spécialistes en sécurité vont jusqu’à ne pas fournir d’adresse IP au serveur de log et connectent les serveurs en faisant des remontées directement par un hub avec ce dernier, puis envoient l’information. De ce fait, notre serveur récupère les informations sans avoir besoin d’une couche de niveau III. Cette méthode peut sembler radicale mais reste de fait absolument sécurisée. Dans des cas plus normaux, n’hésitez pas à utiliser le pare-feu afin qu’aucun trafic ne puisse sortir de votre machine et que seul les flux d’historique soient autorisés en entrée. Voilà qui compliquera bien l’affaire de notre pirate.