2.2.3. Les Attaques
Applicatives
Les attaques applicatives se basent sur des failles dans les
programmes utilisés, ou encore des erreurs de configuration. Toutefois,
comme précédemment, il est possible de classifier ces attaques
selon leur provenance.
i. Les problèmes de configuration
Il est très rare que les administrateurs réseaux
configurent correctement un programme. En général, ils se
contentent d'utiliser les configurations par défaut. Celles-ci sont
souvent non sécurisées afin de faciliter l'exploitation du
logiciel (ex : login/mdp par défaut d'un serveur de base de
données). De plus, des erreurs peuvent apparaître lors de la
configuration d'un logiciel. Une mauvaise configuration d'un serveur peut
entraîner l'accès à des fichiers importants, ou mettant en
jeu l'intégrité du système d'exploitation. C'est pourquoi
il est important de bien lire les documentations fournies par les
développeurs afin de ne pas créer de failles.
ii. Les bugs
Liés à un problème dans le code source,
ils peuvent amener à l'exploitation de failles. Il n'est pas rare de
voir l'exploitation d'une machine suite à une simple erreur de
programmation. On ne peut toutefois rien faire contre ce type de
problèmes, si ce n'est attendre un correctif de la part du
développeur.
iii. Les buffers overflows
Les buffers overflows, ou dépassement de la pile, sont
une catégorie de bug particulière. Issus d'une erreur de
programmation, ils permettent l'exploitation d'un shellcode3 à distance.
Ce shellcode permettra à une personne mal intentionnée
d'exécuter des commandes sur le système distant, pouvant aller
jusqu'à sa destruction. L'erreur de programmation est souvent la
même : la taille d'une entrée n'est pas vérifiée et
l'entée est directement copiée dans un buffer dont la taille est
inférieure à la taille de l'entrée. On se retrouve donc en
situation de débordement, et l'exploitant peut ainsi accéder
à la mémoire.
iv. Les scripts
Principalement web (ex : Perl, PHP, ASP), ils
s'exécutent sur un serveur et renvoie un résultat au client.
Cependant, lorsqu'ils sont dynamiques (i.e. qu'ils utilisent des entrées
saisies par un utilisateur), des failles peuvent apparaître si les
entrées ne sont pas correctement contrôlées. L'exemple
classique est l'exploitation de fichier à distance, tel que l'affichage
du fichier mot de passe du système en remontant l'arborescence depuis le
répertoire web.
v. Les injections SQL
Tout comme les attaques de scripts, les injections SQL
profitent de paramètres d'entrée non vérifiés.
Comme leur nom l'indique, le but des injections SQL est d'injecter du code SQL
dans une requête de base de données. Ainsi, il est possible de
récupérer des informations se trouvant dans la base (exemple :
des mots de passe) ou encore de détruire des données.
vi. Man in the middle
Moins connue, mais tout aussi efficace, cette attaque permet
de détourner le trafic entre deux stations. Imaginons un client C
communiquant avec un serveur S. Un pirate peut détourner le trafic du
client en faisant passer les requêtes de C vers S par sa machine P, puis
transmettre les requêtes de P vers S. Et inversement pour les
réponses de S vers C. Totalement transparente pour le client, la machine
P joue le rôle de proxy. Il accédera ainsi à toutes les
communications et pourra en obtenir les informations sans que l'utilisateur
s'en rende compte.
| 
