| Les buffers overflows 2/3 |
L'idée est donc sur le fond très simple, mais la programmation d'un exploit (un programme permettant d'exploiter une faille) n'est pas toujours aussi aisée, loin de là. La raison en est assez simple, les programmeurs se méfient et vérifient de plus en plus souvent les tailles des tampons de données (buffers) à traiter. De plus il est nécessaire d'avoir de bonnes connaissances en programmation, notamment en assembleur et aussi de maîtriser les débuggeurs pour pouvoir développer un exploit (aussi appelé « sploit » dans le milieu).
Une fois la faille repérée, il est courant d'envoyer un payload (une charge littéralement, disons ici une commande) ou un shellcode (une séquence qui permettra l'obtention d'une console de commande, un shell). A ce stade, le pirate dispose d'un accès au serveur lui permettant d'exécuter des commandes sur celui-ci avec la même identité que le programme fautif. Ensuite, il est courant de faire une escalade de privilège afin de monter en droit sur le système, pourquoi pas en utilisant un autre « overflow ». Il est nettement plus facile de lancer des exploits en « local » et ainsi de prendre le contrôle complet de la machine, avec le plus haut niveau de droits.
Un overflow peut être local (faire crasher un programme comme par exemple hh.exe dans le cas de la faille CHM) ou distant, comme dans le cas du ver Slammer ou des exploits contre IIS, Apache, ssh et autre.
|