- Accueil
- Tous les articles
- Par catégorie
- Les plus récents
- Hacking 101
- Blog
- Vers le vrai hacking
- Sources exemples
L'exploitation de programmes
| Les permissions sur les fichiers >> |
I°) L'exploitation de programmes : illustrations et techniques généralisées
Illustrations
L'exploitation des programmes est un pilier du hacking. Les programmes sont juste un ensemble complexe de règles suivant un certain ordre d'éxécution qui au final dit à l'ordinateur ce qu'il doit faire. Exploiter un programme est simplement une façon intelligente de faire faire à l'ordinateur ce que vous voulez qu'il fasse, même si le programme qui est en train de fonctionner a été conçu pour l'empêcher. Parce qu'un programme ne peut que faire ce pourquoi il a été conçu, les failles de sécurité sont en fait des défauts ou des négligences dans la conception du programme ou de l'environnement dans lequel le programme tourne. Bien sûr, cela demande un esprit créatif pour trouver ces failles et écrire des programmes qui les exploitent. Certaines de ces failles sont le résultat d'erreurs de programmation plutôt évidentes, mais il y a des erreurs beaucoup moins évidentes qui ont donné lieu à des techniques d'exploitations beaucoup plus complexes qui peuvent être appliquées à différents programmes.
Un programme peut seulement éxécuter à la lettre ce pourquoi il a été programmé. Malheureusement, ce qui est écrit ne coïncide pas toujours avec ce que le programmeur voulait que le programme fasse. Ce principe est illustré avec une histoire célèbre :
Les programmeurs sont humains, et il peut arriver que ce qu'ils écrivent ne soit pas exactement ce à quoi ils pensaient. Par exemple, une erreur commune en programmation est appellée une erreur off-by-one, qui arrivent quand le programmeur a mal compté de une seule itération. Cela arrive beaucoup plus souvent qu'on peut le croire, et peut être illustré par la question : "Si on construit une clôture de 100 mètres, avec des poteaux espacés de 10 mètres chacun, de combien a-t-on besoin de poteaux ?". La réponse évidente est 10 poteaux, qui bien sûr est inexacte puisqu'il en faudra 11. D'ailleurs, ce type d'erreur est appellé communément les fencepost errors (erreurs piquets de clotûre) et arrive quand le programmeur compte un nombre d'objets et non l'espace entre ceux-ci. Un autre example est quand un programmeur essaye une gamme de nombres ou d'objets à traiter (de l'objet N à l'objet M). Si N = 5 et M = 17, combien d'objets y a-t-il à traiter ? La réponse évidente est M - N = 12. En fait, il y a M - N + 1 objets à traiter, soit 13 objets. Tout ceci peut ne pas paraître intuitif, car ça ne l'est pas, et c'est exactement ainsi que ces erreurs arrivent.
A priori, ces erreurs paraissent bénignes et c'est pourquoi les testeurs ne s'en rendent pas compte durant les test d'éxécutions (ces erreurs ont assez rarement un impact sur le déroulement du programme). Ainsi, on a l'exemple d'un programme très sécurisé connu, OpenSSH, (Open Secure SHell) : il y a avait une erreur off-by-one dans le code de l'allocation des channels qui a été abondamment exploitée. En fait, il y avait dans le code la ligne suivante :
if (id < 0 || id > channels_alloc) {
Qui aurait du être :
if (id < 0 || id >= channels_alloc) {
En français, la première ligne serait "Si id est plus petit que 0 ou plus grand que le nombre de channels alloués, alors.." tandis que la deuxième ligne se lit "Si id est plus petit que 0 ou qu'il est plus grand ou égal au nombre de channels alloués, alors..".
Cette simple erreur off-by-one a permit des exploitations du programme où des utilisateurs normaux authentifiés pouvaient gagner les droits administrateurs (soit les plein pouvoirs) sur le système.
Un dernier exemple que nous ne développerons pas est le fait d'oublier d'adapter des nouvelles fonctionnalités et de vérifier qu'elles ne laissent pas des nouvelles failles de sécurité (on peut citer l'implémentation de l'Unicode dans le serveur web IIS de Microsoft).
Techniques généralisées
Ces types d'erreurs peuvent paraître dures à voir pour l'instant mais sont totalement évidentes pour des programmeurs ayant du recul. Par contre, il y a des erreurs communes qui deviennent rapidement beaucoup moins évidentes car elles sont rarement apparentes. Ces erreurs se retrouvant dans beaucoup d'endroits différents, des techniques d'exploitation généralisées se sont mises en place.
Les deux exploitations généralisées les plus communes sont les buffer-overflow et les exploits type format strings que nous expliquerons en détail un peu plus loin dans cette section. Dans ces deux techniques, le but final est de faire tourner un bout de code malveillant qui aura été injecté dans la mémoire de plusieurs façons. Ceci est connu en tant qu'éxécution de code arbitraire, car le hacker peut demander de faire au programme à peu près tout ce qu'il veut.
Mais ce qui fait que ces exploits sont intéressants sont les différents hacks intelligents qui se sont adaptés pour réussir des résultats finaux impressionants. Comprendre ces techniques est bien plus puissant que le résultat final d'un seul exploit isolé, comme elles peuvent être appliquées et étendues pour créer une avalanche d'effets différents. Ceci dit, un pré-requis pour comprendre ces techniques est une connaissance un peu plus en profondeur des permissions sur les fichiers, de la mémoire, de l'allocation de mémoire et du language assembleur.
Illustrations
L'exploitation des programmes est un pilier du hacking. Les programmes sont juste un ensemble complexe de règles suivant un certain ordre d'éxécution qui au final dit à l'ordinateur ce qu'il doit faire. Exploiter un programme est simplement une façon intelligente de faire faire à l'ordinateur ce que vous voulez qu'il fasse, même si le programme qui est en train de fonctionner a été conçu pour l'empêcher. Parce qu'un programme ne peut que faire ce pourquoi il a été conçu, les failles de sécurité sont en fait des défauts ou des négligences dans la conception du programme ou de l'environnement dans lequel le programme tourne. Bien sûr, cela demande un esprit créatif pour trouver ces failles et écrire des programmes qui les exploitent. Certaines de ces failles sont le résultat d'erreurs de programmation plutôt évidentes, mais il y a des erreurs beaucoup moins évidentes qui ont donné lieu à des techniques d'exploitations beaucoup plus complexes qui peuvent être appliquées à différents programmes.
Un programme peut seulement éxécuter à la lettre ce pourquoi il a été programmé. Malheureusement, ce qui est écrit ne coïncide pas toujours avec ce que le programmeur voulait que le programme fasse. Ce principe est illustré avec une histoire célèbre :
- Un homme marchant dans les bois trouve une lampe magique sur le sol. Instinctivement, il prend la lampe et en frotte le
côté avec sa manche et un génie en sort. Le génié remercie l'homme de l'avoir libéré et lui promet d'exaucer trois voeux
de son choix. L'homme extasié sait immédiatement ce qu'il va demander.
"Premièrement," dit l'homme, "Je veux un milliard d'euros."
Le génie fait claquer ses doigts et une malette pleine de billets apparaît dans un léger courant d'air.
L'homme s'empresse de continuer, "Ensuite, je veux une Ferrari."
Le génie fait claquer ses doigts et une Ferrari apparaît dans un nuage de fumée.
L'homme ajoute, "Et enfin, je veux que les femmes ne puissent me résister."
Le génie claque dans ses doigts et l'homme se transforme en une boite de chocolats.
Les programmeurs sont humains, et il peut arriver que ce qu'ils écrivent ne soit pas exactement ce à quoi ils pensaient. Par exemple, une erreur commune en programmation est appellée une erreur off-by-one, qui arrivent quand le programmeur a mal compté de une seule itération. Cela arrive beaucoup plus souvent qu'on peut le croire, et peut être illustré par la question : "Si on construit une clôture de 100 mètres, avec des poteaux espacés de 10 mètres chacun, de combien a-t-on besoin de poteaux ?". La réponse évidente est 10 poteaux, qui bien sûr est inexacte puisqu'il en faudra 11. D'ailleurs, ce type d'erreur est appellé communément les fencepost errors (erreurs piquets de clotûre) et arrive quand le programmeur compte un nombre d'objets et non l'espace entre ceux-ci. Un autre example est quand un programmeur essaye une gamme de nombres ou d'objets à traiter (de l'objet N à l'objet M). Si N = 5 et M = 17, combien d'objets y a-t-il à traiter ? La réponse évidente est M - N = 12. En fait, il y a M - N + 1 objets à traiter, soit 13 objets. Tout ceci peut ne pas paraître intuitif, car ça ne l'est pas, et c'est exactement ainsi que ces erreurs arrivent.
A priori, ces erreurs paraissent bénignes et c'est pourquoi les testeurs ne s'en rendent pas compte durant les test d'éxécutions (ces erreurs ont assez rarement un impact sur le déroulement du programme). Ainsi, on a l'exemple d'un programme très sécurisé connu, OpenSSH, (Open Secure SHell) : il y a avait une erreur off-by-one dans le code de l'allocation des channels qui a été abondamment exploitée. En fait, il y avait dans le code la ligne suivante :
if (id < 0 || id > channels_alloc) {
Qui aurait du être :
if (id < 0 || id >= channels_alloc) {
En français, la première ligne serait "Si id est plus petit que 0 ou plus grand que le nombre de channels alloués, alors.." tandis que la deuxième ligne se lit "Si id est plus petit que 0 ou qu'il est plus grand ou égal au nombre de channels alloués, alors..".
Cette simple erreur off-by-one a permit des exploitations du programme où des utilisateurs normaux authentifiés pouvaient gagner les droits administrateurs (soit les plein pouvoirs) sur le système.
Un dernier exemple que nous ne développerons pas est le fait d'oublier d'adapter des nouvelles fonctionnalités et de vérifier qu'elles ne laissent pas des nouvelles failles de sécurité (on peut citer l'implémentation de l'Unicode dans le serveur web IIS de Microsoft).
Techniques généralisées
Ces types d'erreurs peuvent paraître dures à voir pour l'instant mais sont totalement évidentes pour des programmeurs ayant du recul. Par contre, il y a des erreurs communes qui deviennent rapidement beaucoup moins évidentes car elles sont rarement apparentes. Ces erreurs se retrouvant dans beaucoup d'endroits différents, des techniques d'exploitation généralisées se sont mises en place.
Les deux exploitations généralisées les plus communes sont les buffer-overflow et les exploits type format strings que nous expliquerons en détail un peu plus loin dans cette section. Dans ces deux techniques, le but final est de faire tourner un bout de code malveillant qui aura été injecté dans la mémoire de plusieurs façons. Ceci est connu en tant qu'éxécution de code arbitraire, car le hacker peut demander de faire au programme à peu près tout ce qu'il veut.
Mais ce qui fait que ces exploits sont intéressants sont les différents hacks intelligents qui se sont adaptés pour réussir des résultats finaux impressionants. Comprendre ces techniques est bien plus puissant que le résultat final d'un seul exploit isolé, comme elles peuvent être appliquées et étendues pour créer une avalanche d'effets différents. Ceci dit, un pré-requis pour comprendre ces techniques est une connaissance un peu plus en profondeur des permissions sur les fichiers, de la mémoire, de l'allocation de mémoire et du language assembleur.
| Les permissions sur les fichiers >> |
37 Commentaires
Afficher tous
| FrizN | 16/07/13 08:26 |
| Oui oui, comme je l'ai dit à de multiples reprises, les articles d'introduction viennent en partie de ce livre, très bon pédagogiquement, cité dans la page introductive à ces articles ("Exploitation Native" dans le menu). |
|
| Anonyme | 16/07/13 01:31 |
| @Gangagan: Par contre, au niveau du hacking sur console, je te conseilles la OUYA, comme ça, pas de problème avec la license, et j'imagine que les autres hackers ne tarderont pas à partager leurs connaissances sur le sujet... et une communauté où apprendre et partager, c'est toujours pratique et valorisant (quoique moins "underground" :P) |
|
| Anonyme | 16/07/13 01:24 |
| Je ne sais pas si c'est une coincidence (cela m'étonnerait), mais je crois qu'il serait préférable d'ajouter un petit "Inspiré par « Hacking, the Art of Exploitation »" à la fin de cet article. Sinon, le reste du cours, comme tout ce qui l'a précédé, reste sans contexte parmis les meilleurs tutoriels de hacking existant (et probablement le meilleur cours francophone.) |
|
| Ganjaman | 09/07/13 12:21 |
| D'accord merci pour tes conseils man =D J'vais faire comme tu m'a dit mais si jamais j'ai des questions (c'est quasiment sûr que j'en aurais ^^), je peux toujours les poster en commentaire ? |
|
Commentaires désactivés.
Apprendre la base du hacking - Liens sécurité informatique/hacking - Contact
Copyright © Bases-Hacking 2007-2014. All rights reserved.
Copyright © Bases-Hacking 2007-2014. All rights reserved.