Iyas

Encore un coup de Str0x0 l'blaireau

Tout à fait d'accord avec toi

Le contenu est déjà plus que validé depuis longtemps en fait Le seul problème c'est qu'il faut être très technique. Surtout dans tout ce qui est language C, Assembleur, fonctionnement de la stack linux, de la heap, du kernel etc.. Mais il me parait clair que c'est sur ce site que l'on retrouve le meilleur de la "scene black hate". Et puis bon ca change des pauvres attaques WEB façon PHP INCLUDE / INJECTION SQL utilisées par les KIDDIES C'est dans ce EZINE qui l'on retrouve les articles qui ont permis de mettre au point les nouvelles techniques d'intrusions tel que les buffers overflows, l'exploitation des chunks dans malloc, les bugs de format, ..., ...). On y retrouve même le célèbre article d'Aleph1 "Smash the Stack" qui était le premier vrai article expliquant comment profiter des buffers overflows: http://www.phrack.org/issues.html?id=14&issue=49 Donc personnellement je n'ai aucun doute sur le contenu de ce EZINE en général. Après y'a surement des articles moins interessants que d'autres mais bon...

Oui mais si tu dois developper un site à objectif commercial autant le developper bien nan ? C'est la faute des developpeurs si les sites sont vulnérables... Bon parfois c'est l'admin qui fait mal son boulot...Mais pour ce qui est des sites web...C'est une toute autre histoire.

Salam, Bon voici pour moi ce que j'appelle de LA SECURITE http://www.phrack.com/ Bon à première vue le site fait un peu WARLORDZ sur les bords ... Mais le contenu est vraiment interessant. Il y'a je crois quelque chose comme 65 EZINEs sortis comprenant chacun une dizaine d'articles parfois très techniques. Alors si vous vous ennuyez allez faire un peu de E LECTURE

Oui certes mais ces gens la ont autre chose à faire que d'aller modifier des pages web sur des sites commerciaux ... Aujourd'hui les gens confondent Hacker et on va dire Cracker mais si le mot ne convient pas tout à fait. Globalement HACKER pour moi est la personne qui va découvrir une vulnérabilité, développer le concept permettant de pénéter un systeme..Et je ne parle pas ici d'un pauvre PHP include ou d'une injection SQL comme on en voit beaucoup de nos jours. Le CRACKER lui va utiliser le concept mis à disposition pour entrer sur un système...Moi j'apelle ca aussi un KIDDIES Enfin bon... Pour ton info voici le site qui pour moi est la référence dans le domaine: http://www.phrack.com/ Effectivement tu en trouveras d'autres. Mais les ges qui vont écrire dans ce EZINE restent pour la plus part anonymes Tu as je crois quelque chose comme 65 numéros avec des articles très très interressants et parfois très techniques. Moi perso c'est ca que j'appelle de la Sécurité Pas des gamins de 15 ans qui vont aller changer la page web d'un site commercial pour ensuite aller se la raconter sur les forums

Meilleurs hackers au monde ? Ah bon ? Tu l'as tiens d'où cette info ? Non parce que la j'ai un leger doute...

Salam, Personnellement je trouve qu'il y'a déjà beaucoup de portails web traitant des problèmes de sécurité... Je sais pas ce que tu entends par "s'il s'occupe plutôt de tout ce qui est sécurité informatique en Algérie" mais je dirais qu'il faudrait dans un premier temps, que ce "CERT" sensibilise les hébergeurs et les sociétés aux problèmes de la sécurité informatique. Il faudrait ensuite qu'ils puissent répondre aux sociétés ou autre qui viendraient demander des avis/conseils dans le domaine de la sécurité informatique, et ce qu'ils soient d'ordre techniques et ou organisationels. Si c'est juste centraliser les informations des autres sites qui traitent déjà de la sécurité informatique j'ai envie dire ok... mais ca ne fera pas forcément avancer les choses... Et puis si c'est un CERT dans ce cas pourquoi ne pas avoir pris CERT.dz ? Computer Emergency Response Team ca sonne vachement mieux nan ? Mais encore faut il que ce soit le but recherché... Quoi qu'il en soit le concept est bon si derrière il y'a du répondant. Petite question comme ca, y'a t il des cabinets de consultants en sécurité informatique en DZ ? Par ce que si ce n'est pas le cas il y'a peut être un marcher à prendre ++

Et juste pour info, si Samir demande ces informations, c'est parce que nous regardons en ce moment même la possibilité de mettre en place un service d'hébergement mutualisé sécurisé en insistant fortement sur cette particularité. Et en effet si on se lance sur cette idée c'est qu'on à les compétences pour maintenir le système...Sinon en effet ca n'aurait pas trop d'intérêts... Voilà donc on est à l'écoute et toutes les idées sont les bienvenues

Oui enfin en même temps c'est un peu logique ce que tu dis la nan ? Tu voudrais dire qu'il faut être admin sys pour faire du hosting ? Maitriser les services Web (apache), DNS (bind), Mail (Postfix, sendmail, ...), etc.., etc.. Bon les mailing list dans la sécu j'ai envie de te dire c'est bien mais tu peux t'en passer si t'es suffisament fort en système. Car quand la vulnérabilité devient publique il est généralement trop tard...Mais bon j'suis dak faut toujours garder un oeuil dessus. Quoi qu'il en soit, à mon avis, la plus grosse crainte que peut avoir un hébergeur c'est PHP et ses codes pourris La plupart des sites ownés aujourd'hui c'est via PHP ou via des vulnérabilités liées aux sites. C'est rarement par des services vulnérables ou alors dans ce cas faut changer d'hébergeur...

Mac OS X rulez !

Salam, Alors t'as vu la différence ? Toi l'adresse linux-gate.so.1 => (0xffffe000) ne change jamais alors que moi elle change en permance... Conlusion sur ton système tu peux bypasser cette protection... Moi pour ma part c'est un peu plus compliqué que prévu. Essaie de suivre la procédure de contournement et vois si tu peux l'appliquer à newbie2.c. Perso je ne crois pas mais je me trompe peut être. Cette solution doit fonctionner uniquement lorsque tu inctercèptes l'execution d'un programme en modifiant l'adresse de retour. Enfin il faut vérifier. Si t'as le temps pour jeter un coup d'oeuil... Moi de mon coté je vais essayer de trouver un système identique au tiens.. A suivre donc...

Salam, Le programme adéquat permettant de tester la sécurité d'un serveur: http://www.nessus.org Cet outil est gratuit, tourne sous Windows / Linux / Mac OS X. A mon avis tout comme snort il n'y a pas plus efficace dans le monde des logiciels libres. Il vous suffit de vous enregistrer sur le site pour recevoir un code de validation. Amusez vous bien

ButterflyOfFire, Juste une petite remarque, ton firewall ici ne sert pas à grand chose étant donné que tu fais de la NAT N pour 1. Tu pourrais donc très bien t'en passer. A moins que tu n'ais également des risques de sécu sur ton LAN interne Sinon si tu veux t'amuser essaye d'installer SNORT (http://www.snort.org). C'est à mon avis le meilleur programme de détection d'intrusions dans le monde des logiciels libres. Ce programme est présent dans la distribution Ubuntu. aptitude install snort et c'est parti Salam

Bon ben rien de bien méchant j'ai envie de dire Mis à part le manuel d'apache (http://82.67.69.135/manual/) Ca fait un peu débutant Mais bon en même temps on s'en tape ca sert a rien...Enfin ce n'est pas exploitable... Et puis t'as laissé un "backup file" (http://82.67.69.135/test/h.php~). Du coup on peut voir le source de http://82.67.69.135/test/h.php mais bon pareil ca ne sert pas à grand chose... Et les autres services sont firewallés donc bon... Ah oui t'as caché la version d'apache avec : ServerSignature off ServerTokens Prod Ou alors un truc du genre Mais sur la page d'accueil du site t'indiques les versions PHP et APACHE que tu utilises donc bon j'ai envie de dire que ca ne sert a rien Conlusion, ca semble sécure ... ++

Bon alors après analyse il semblerait que dans les exemples ci dessus l'adresse de la lib-gate.so.1 récuperée via ldd ne soit pas random.. Ben super mais chez moi ce n'est pas l'cas.. cb@www:~$ ldd yo linux-gate.so.1 => (0xb7fe0000) libc.so.6 => /lib/libc.so.6 (0xb7ea5000) /lib/ld-linux.so.2 (0xb7fe1000) cb@www:~$ ldd yo linux-gate.so.1 => (0xb7fb8000) libc.so.6 => /lib/libc.so.6 (0xb7e7d000) /lib/ld-linux.so.2 (0xb7fb9000) Amine, pourrais tu s'il te plait vérifier chez toi voir si tu as le même comportement ? Parce que la ca complique légèrement les choses

Un autre exemple de contournement de la lib-gate et en PERL cette fois

Comme je disais plus haut c'est compliqué tout ca. Mais sache un truc, c'est qu'aujourd'hui tous les pays ne possèdent pas une législation permettant de se retourner contre les pirates. Il suffit de prendre exemple sur la Roumanie Et puis il y'a "pirate et pirate"... Dans le sens ou un vrai pirate s'il s'introduit sur ton système, ce dernier ne viendra pas modifier ta page web ou autre... Il restera sur ton système et essaiera de récupérer d'éventuelles informations qui lui seront utiles par la suite. En gros si le mec est bon tu ne sauras jamais qu'il est entré sur ton serveur surtout si ce dernier est mal administré. Et puis y'a les KIDDIZ. Et la comment te protéger d'eux, si l'hébergeur et les développeurs web ne sont pas sensibilisés à la sécurité ? Tu sais que le risque existe...Qu'il y'a des règles à respecter...Donc ben mets tout ce que tu peux en place pour limiter les risques et puis c'est tout. Si il y'a des enjeux financiers, prends une assurance, si c'est une société prends une personne compétente qui saura mettre en place une politique de sécurité adaptée à l'activité de ta boite etc.. etc... En gros pour terminer la sécurité passe avant tout par la sensibilisation des administrateurs, développeurs etc.. etc.. A partir du moment ou tu es conscient des risques à toi de les évaluer et de faire le nécessaire pour limiter les dégâts. Bon j' arrête la parce que on peut aller super loin dans ce vaste sujet

Salam, Tiens l'article qui décrit comment contourner la lib en question : http://milw0rm.org/papers/55 Il faudrait voir si du coup cette si solution est applicable au programme newbie2.c. Notons que dans l'article nous somme en présence d'une exploitation réelle d'un buffer overflow, avec positionnement d'un shellcode dans la stack et modification de l'adresse de retour du programme. On va peut être un peu vite en besogne la ... L'idée était d'y aller progressivement afin de ne pas passer les étapes trop rapidement mais la je crois que c'est loupé

Amine, Bon j'ai compris d'ou ca vient cette histoire de randomization des adresses... Donc voici le test que j'ai effectué sous Ubuntu: cb@www:~$ ./yo AAAAAAAAAA Addresse de buf: 0xbfff0a0c cb@www:~$ ./yo AAAAAAAAAA Addresse de buf: 0xbfa3945c cb@www:~$ ./yo AAAAAAAAAA Addresse de buf: 0xbfb61d8c Et voilà ce que je vois lorsque je regarde à quelles libs est linké le programme: cb@www:~$ ldd ./yo linux-gate.so.1 => (0xb7f13000) libc.so.6 => /lib/libc.so.6 (0xb7dd8000) /lib/ld-linux.so.2 (0xb7f14000) Et la réponse se trouve dans la lib linux-gate.so.1 C'est elle qui fait en sorte que la stack de ton programme soit random... Du coup j'ai vérifié, même les adresses de l'environnement sont random... Donc faut trouver un contourmement ce qui est tout à fait faisable mais peut être pas dans l'exercice proposé. Sinon faut compiler sans cette lib afin de pouvoir faire l'exercice dans une configuration standard. Voilà en gros pourquoi ton adresse de buffer change à chaque fois..

Hahah oué excellent désolé d'avoir douté de tes compétences Bon alors logiquement le seul truc qui que je connais qui permette de faire ca c'est PAX avec son "randam address spaces". Ensuite ca fait un petit moment que j'ai pas mis les mains dans le Kernel de linux alors il se peut qu'ils aient ajouté ca par défaut. Et ce n'est pas un mal Alors il reste une solution qui peut fonctionner c'est l'environnement Tu exportes dans ton shell une variable genre CHECK qui contient le 0xdeadbeaf et toujours grace à gdb tu regardes si celle ci est modifiée à chaque execution. Pour info l'environnement se trouve toute à la fin de la mémoire du programme. Pour la retrouver plus facilement tu fais un truc du genre: export CHECK=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Et ensuite tu fais pointer le pointeur dans cet env pour tomber sur 0xdeadbeaf. J'essaierai de faire les tests sur un lnx dès que possible histoire de voir si j'ai le même comportement.

Comment fais tu pour afficher l'adresse de buf ? Car je pense que tu te plantes Voici une petite démonstration effectuée sous MAC OS X Intel avec gdb qui te pourveras bien que l'adresse de buf ne change pas. Pour faciliter la démonstration j'ai compilé le programme avec l'option -ggdb. Donc on commence par compiler le programme: cb:~ cb$ gcc -ggdb -o newbie2 newbie2.c cb:~ cb$ On utilise ensuite gdb: cb:~ cb$ gdb ./newbie2 NU gdb 6.3.50-20050815 (Apple version gdb-768) (Tue Oct 2 04:07:49 UTC 2007) This GDB was configured as "i386-apple-darwin"...Reading symbols for shared libraries ... done (gdb) On ajoute un break dans main lors de l'execution afin de permettre l'execution pas à pas du programme: (gdb) break main Breakpoint 1 at 0x1faf: file newbie2.c, line 10. (gdb) On lance suite le programme avec comme argument "AAAABBBB". Notons ici que A en hexa = 0x41 et B = 0x42 (gdb) run AAAABBBB Starting program: /Users/cbailleux/newbie2 AAAABBBB Reading symbols for shared libraries ++. done Breakpoint 1, main (argc=2, argv=0xbffff7bc) at newbie2.c:10 10 if (argc (gdb) On execute le programme "step by step" afin d'arriver jusqu'a la fonction strcpy: (gdb) step 13 strcpy(buf,argv[1]); (gdb) step 15 if (*check==0xdeadbeaf) (gdb) On affiche l'adresse de buf: (gdb) printf "%p\n", buf 0xbffff774 (gdb) On vérifie que c'est bien l'adresse de buf en vérifiant le contenu de cette adresse. On devrait ici trouver 0x41414141: (gdb) x 0xbffff774 0xbffff774: 0x41414141 (gdb) Donc ici l'adresse de buf est bien 0xbffff774. Je refais donc une deuxième exécution pour vérifier si on garde la même adresse: (gdb) run AAAABBBB Starting program: /Users/cbailleux/newbie2 AAAABBBB Reading symbols for shared libraries ++. done Breakpoint 1, main (argc=2, argv=0xbffff7bc) at newbie2.c:10 10 if (argc (gdb) printf "%p\n", buf 0xbffff774 (gdb) Voilà l'adresse reste la même Donc Amine je pense que tu te plantes quelque part... Certes je ne suis pas sous Linux mais bon le comportement est identique surtout sur une architecture INTEL... La je t'ai maché une partie du boulot donc à toi de faire le reste

Salam, Et bien c'est assez compliqué. L'hébergeur doit s'assurer de fournir des services Internet à jour. A partir de cet instant, si l'hébergeur est sérieux il doit agir en temps et en heure dès qu'une mise à jour sécurité et disponible pour corriger une éventuelle faille de sécurité. Il peut également mettre en place toutes les sécurités systèmes disponibles permettant de bloquer des attaques type "buffer overflow, heap overflow, format bug". Si ces conditions sont respectées, les risques de sécurité vont venir ensuite des développeurs. Si ces derniers développent du PHP non sécurisé, la responsabilité sera du coté du client. En effet l'hébergeur n'est pas responsable du code PHP que tu vas utiliser. Surtout si ce dernier compromet la sécurité de l'hébergement. Par contre c'est à lui de s'assurer, si ton site se fait pirater, qu'en aucun cas le pirate ne pourra modifier les sites des autres clients. Mais sache que tu es seul responsable de ton site et de ses failles de sécurité. Il y'a aujourd'hui plusieurs outils disponibles sur le net pour tester la sécurité d'un serveur et la sécurité d'un site web. Le plus connu et gratuit pour tester la sécurité d'un serveur est NESSUS (http://www.nessus.org). Pour ensuite tester ton site web, l'outil le plus puissant que je connaisse et utilisé par beaucoup de newbie est "Acunetix". Malheureusement ce programme est payant. Cependant si tu débrouilles bien tu devrais pouvoir le récupérer sur des sites P2P. Ca ne sera peut être pas la dernière version mais bon ca sera déjà un bon début Voilà

Si normalement, l'adresse de buf reste la même à chaque execution. Deux solution pour récuperer l'adresses de buf: 1 - Tu modifies le prog newbie2.c et tu fais affichier l'adresse de buf 2 - Tu utilises gdb

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