Cracker une flash (obtenir le code) Il peux être très utile d'obtenir la source d'une flash pour récupérer un script ou même un mot de passe. Imaginons que sr un site, une flash te demande un mot de passe pour entrer. Voici comment obtenir le mot de passe : Clique droit à côté de la flash, clique sur Afficher la source. Cherche un code qui ressemble à ça dans la source : Ici, on voit que la flash s'appelle flash.swf Maintenant, tu dois trouver la flash dans tes temporary internet files (Fichiers temporaire d'internet, en gros, tout les fichiers des sites internet que tu a visité sont stoqués là). Pour cela, clique sur le bouton Démarrer, puis Rechercher fichier ou dossier. et cherche flash.swf dans ton disque dur. Une fois la flash trouvée, copie la sur ton Bureau (par exemple). Ensuite, télécharge le logiciel ASV (active script viewer). Avec ce logiciel, tu ouvres la flash, et là, tu as accès à tout le code, et donc le mot de passe ! Comment éviter cette faille : Le seul moyen d'éviter cette faille est de protéger la page par un mot depasse php, et non flash

Passer un code Allopass Tout d'abord, sache qu'on ne peut pas toujours passer un code Allopass. Un code Allopass sert à faire payer les visiteurs qui veulent accéder à certains fichiers ou pages d'un site. La technique consiste à trouver directement le fichier recherché sans payer. On peux déjà commencer par chercher quelques url manuellement : par exemple si on veut télécharger un logiciel : http://sitevictime.com/appz/ ou http://sitevictime.com/logiciels/ ou http://sitevictime.com/prog/ .... Si tu ne trouve pas avec cette technique, fait un scann du site avec le logiciel IntelliTamper pour trouver les fichiers voulus. Voilà PS : Allez voir http://staracademy-interdit.com et http://www.colocs-interdit.com ils sont faciles à pirater (indice : "videos")

Les failles cookies Certain site ont un système de connexion à l'admin ou à l'espace membre pas du tout sécurisé. C'est le cas d'une ancienne version PhpMyAnnu par exemple. Presque tous les système de connexion sécurisée fonctionnent avec des cookies, tu peux d'ailleur tester ce tuto sur Loadation et sur le challenge de Loadation. (il n'y a pas de faille dans le système de Loadation , mais il y en a une dans le challenge) Nous allons ici essayer de hacker un espace membre (c'est pareil pour les administrations). Inscris toi tout d'abord à cet espace membre, connecte toi, et tappe dans la barre d'adresse : javascript:alert(document.cookie), et appuie sur Enter. C'est une commande javascript qui t'affichera dans un message alert tout les cookies du site. - Si tu obtiens un message du genre login=ton_login;passw=ton_mot_de_passe, c'est que le système est sécurisé. - Si tu obtiens un message du genre login=ton_login, alors une a trouvé une grosse faille ! login correspond ici au nom de la variable cookie, cette variable ne s'appelle pas forcément login. Pourquoi ? Parce que le script de connexion vérifie uniquement que le cookie de login existe, et non pas si un cookie contenant le mot de passe existe. Tu peux alors te connecter sous le nom de n'importe quel membre ou admin. Pour celà, tu doit modifier le cookie. C'est très simple : Il suffit d'aller sur une page du site en question, et de taper dans l'url : javascript:document.cookie="login=le_login_qu_on_veut_utiliser;";, une page blanche aparaitra, avec écrit le contenu que tu as ajouté au cookie. Retourne sur le site, tu sera alors connecter sous le nom que tu auras indiqué ! Essayons maintenant de hacker une admin d'un site où seul un mot de passe est demandé. (Ps : cette technique ne fonctionne pas toujours). Tapons un mot de passe au hasard, qui sera bien sûr faux. Regardons maintenant les cookies : tape javascript:alert(document.cookie) dans la barre d'adresse. S'il apparait un message du genre logadmin=false ou logadmin=0 ou logadmin=non (ou quelque chose du genre), tu as une bonne chance logadmin correspond ici au nom de la variable cookie, cette variable ne s'appelle pas forcément logadmin. Tape ceci dans la barre d'adresse : javascript:document.cookie="logadmin=1";. (mets 1 si logadmin est égal à 0, true si c'est false, oui si c'est non, ...etc) Retourne maintenant à la page d'admin, et tu sera connecté ! Si tu n'es pas connecté, mets un mot de passe au hasard, et tu sera normalement connecter. Bien sûr, si tu trouves une telle faille sur un site, préviens immédiatement le webmaster Pour éviter la faille : Pour éviter la faille, il suffit de ne pas enregistrer et vérifier uniquement un cookie contenant le login, mais il faut aussi utiliser un cookie contenant le mot de passe.

Domain Name Server (DNS) Domain Name Server (DNS) by Morth 1) explication la première question qui doit venir est « qu'es ce que le DNS ? », c'est très simple, tout d'abord DNS veut dire « Domain Name Server », si on prend la traduction française ça donne du « Serveur de Nom de Domaine ». Ah, très bien, on a donc un serveur, une machine qui fourni un service donc à des clients. Quel service fourni ce serveur ? Pas grand chose en fait, il met juste à disposition une base de donnée à des routines clientes telles que dig, host, nslookup ... A quoi ça sert ? En fait cela sert à établir une correspondance entre des adresses logiques internet dite IP et une représentation plus facile a retenir, un nom de domaine. Par exemple, lorsque vous tappez http://www.google.fr dans votre navigateur, votre navigateur doit deja savoir à quelle machine correspond ce nom de domaine, à quel IP il doit s'adresser. Il va donc utiliser les dns pour avoir la correspondance ip – nom de domaine. 2) mise en oeuvre Il existe deux methodes pour « faire de la résolution de dns » (oui, un nom de domaine c'est comme une équation, ça se résoud ^^). La première consiste à consulter un fichier que l'on aurrait sur notre machine. > cat /etc/hosts 127.0.0.1 localhost 192.168.0.13 routeur.local 192.168.0.15 morth.local mais on a aussi une liste de serveur interrogeables : >cat resolv.conf search maison.local nameserver 192.168.0.13 nous devons donc choisir entre ces deux methodes, ceci est decrit dans le fichier de configuration nsswitch.conf >cat nsswitch.conf passwd: compact group: compact shadow compact hosts files dns networks files protocol db files rpc db files services db files en y regardant de plus près on voit donc que sur ce réseau, la résolution de dns se fait d'abord en consultant mon fichier hosts, puis, s'il ne trouve pas, utilise le service de dns interrogeant 192.168.0.13. si on avait pas ajouté dns derrière files, il y aurrait eu de grande chances que je ne puisse pas resoudre des nom de domaine sur l'internet (puisque je me suis pas amusé à rentrer les milliers de sites web dans ce fichier hosts ) il existe des commandes permettant d'interroger les dns, nous avons par exemple nslookup qui est très complet sur windaube et host, perso je préfère host alors je l'utiliserais dans ce tuto. On veut savoit quelle est l'ip qui correspond au routeur de ce réseau : > host routeur.local maison.local A 192.168.0.13 Les dns sont structuré en arbre, c'est à dire que chaque domaine peut etre lui même racine d'un domaine.Le séparateur est le « . » ainsi analysons www.google.fr on a donc le domaine [fr] géré par l'AFNIC en france. Puis le domaine [google] géré par google Corporation (on peut savoir qui gère un nom de domaine en interrogeant une base de donée mondiale appellée whois à www.whois.net) Puis la machine [www] qui appartient à google. Ainsi ftp.google.fr et www.google.fr peuvent très bien etre des machines différentes, d'ip différentes comme une même machine avec deux « alias » pour une même ip. (le meilleur moyen de le savoir étant d'utiliser host ou ping). Alors cela veut dire que le serveur de dns que j'interroge connait l'ensemble du web Et bien non, et c'est là la force comme la faiblesse de dns, il est réparti ! C'est à dire qu'un serveur ne dispose que d'une partie de l'information, s'il n'a pas la réponse à la question qu'on lui pose, il demande à un autre serveur. « qui est google.fr ? » ---- « je sais, c'est X.X.X.X » « qui est google.de ? » <--- « je ne sais pas, je à ns.google.fr »<------- « je sais moi ! Y.Y.Y.Y » ainsi même s'il faut remonter jusqu'au serveur maitre de l'AFNIC, on finira forcément par trouver de qui il s'agit. Vous comprennez alors maintenant pourquoi, lorsque vous achetez un nom de domaine, on vous dit qu'il y a 24h d'attente de « propagation des dns », il faut attendre que de serveur maitre à serveur esclave, l'information circule. Chaque serveur possède les données sur la zone surlaquelle il fait autorité, par exemple sur le réseau décrit plus haut, le serveur 192.168.2.13 connait la correspondance IP / nom de toutes les machines située sur ce sous réseau. Poussons un peu plus loins l'analyse. Si vous connaissez un minimum IP, vous savez qu'il existe des réseau et des sous-réseau. Réseau local 192.168.0.0 sous réseau maison 192.168.0.0 sous réseau jeux 192.168.1.0 ben avec dns c'est pareil réseau local local maison maison.local jeux jeux.local 3) dns forgery aussi appelé dns spoofing le dns forgery, est une attaque basée sur la très faible identification des paquets d'interrogation dns. Regardont d'un peu plus près ce qu'il se passe lors de cette interrogation d'une serveur dns. Le client envoie un paquet contenant un identifiant ID IP source 192.168.0.15 Ip serveur 192.168.0.13 ID 40 Nom à résoudre Google.fr Et le serveur réponds par le même identifiant et l'ip : IP source 192.168.0.13 Ip client 192.168.0.15 ID 40 Nom à résoudre X.X.X.X On comprend dès lors qu'il suffit de connaître cet identifiant ID, pour detourner les paquets ! Facile lorsque le client emmet sa requete, on écoute sur le réseau, on capte un ID. Il suffira de répondre plus vite que le serveur de dns avec le même ID pour faire croire au client que google.fr (par exemple) est 192.168.0.8 (nous), ainsi il enverra ses paquets HTTPS, FTP, POP3, SMTP ... à nous ! On enregistre tout ce qu'on reçoit et on le pousse à s'identifier pour recuperer le mot de passe Il faut donc ecouter ce qui passe sur le réseau et qui est à destination du serveur ns.serveur.ext sur le port 53. 4) Dns cache poisonning Cette necessite d'avoir un serveur de dns publique sous le coude. Reprennons donc notre shéma de résolution. Si un serveur n'a pas l'information demandée dans son fichier il demande au serveur ayant autorité. Mais pour eviter que ces informations soient tout le temps redemandée, les serveurs de dns possèdent un cache qui stoque les données déjà résolues. Ainsi on va, avec notre serveur de dns bourrer le serveur cible. Prennons un nom de domaine, morth.com on va corrompre un peu ns.morth.com pour lui faire envoyer enormément de donnée lors des résolutions de dns. Mettons que notre machine d'ecoute soit ecoute.morth.com d'ip 157.34.21.33 On va faire en sorte que lorsque notre serveur de dns réponds à une demande de résolution d'un autre serveur, il lui envoie des tas de fausses résolutions genre : google.fr A 157.34.21.33 free.fr A 157.34.21.33 yahoo.com A 157.34.21.33 loadation.com A 157.34.21.33 Ainsi on va faire en sorte que le serveur cible nous demande une résolution de nom de domaine en lui envoyant par exemple une résolution de « toto.morth.com », ne connaissant pas morth.com le serveur cible va donc relayer la demande à ns.morth.com Notre serveur va donc lui renvoyer des tas d'info falsifiée renvoyant sur 157.34.21.33. Le serveur cible met tout ça dans son cache, et croit ainsi connaître les adresses de free.fr, google.fr ... Je vous laisse imaginer les applications (et dieu sait si elles sont puissantes !!!)