21 avr. 2008

DDOS sur CNN

Un groupe de pirates chinois souhaiteraient attaquer le site de CNN. L'appel du groupe "Revenge of the flame" est actuellement relayé par un nombre croissant de sites chinois. L'objectif étant de saturer le serveur (DDOS attack)




emblème du groupe Revenge of the Flame

Au 17 avril 2008, le site (en) http://www.thedarkvisitor.com publiait les informations suivantes :

1. Début de l'attaque le 19 Avril 2008 à 8h00
2. Attaque ciblée sur www.cnn.com
3. Attaque de type DDOS, prolongée sur trois heures
4. Appel à contribution de botnets (réseaux de machines infectées, à disposition des pirates) afin de mener à bien l'attaque.

L'annonce étant publique, le site www.cnn.com a mis en place des mesures anti SYN flood. Cette protection aurait permis de faire échouer une première tentative, mais aurait également perturbé fortement les tentatives de connection "normales" en provenance d'Asie

ATLANTA, Georgia (CNN) — CNN was targeted Thursday by attempts to interrupt its news Web site, resulting in countermeasures that caused the service to be slow or unavailable to some users in limited areas of Asia.

Les pirates ont alors reporté leur attaqee à une date "ultérieure non précisée publiquement", en attendant la désactivation des règles anti SYN flood sur le site. En attendant le groupe continue de recruter, et apparemment sans problèmes.


Voici le premier message public du groupe à la population chinoise (Version anglaise et traduction francaise après) :

Statement from Revenge of the Flame:

In just three short days, our organization, the Revenge of the Flame, has grown large. First, I want to thank everyone for their strong sense of nationalistic responsibility. However, maybe we were too impetuous. We love our country! We will resist all anti-Chinese influences! However, we must choose the right way to come to the defense of our country, families and ourselves!!! After some core internal discussions, we have decided to temporarily cancel the 19th attack plan! The Revenge of the Flame organization still exists! Later we can be a computer discussion organization, we will study together for the day our country needs us! Our government and military will all mobilize! At that time, we will let those so-called foreign net-forces see! No matter where, China will never lose to them! We also have our net-forces! Perhaps at that time, our Revenge of the Flame will be the main strength! We all love our country! But, we must use sensible methods to defend our honor!

ATTENTION: Our original plan for 19 April has been canceled because too many people are aware of it and the situation is chaotic. At an unspecified date in the near future, we will launch the attack. We ask that everyone remain ready. I will repeat it again. At an unspecified date in the near future, we will launch the attack. We are only at present cancelling the attack. We could send out a notice on the day of the attack and have it completed in one day. The attack hasn’t been cancelled; it will be carried out on an unspecified day in the near future. I think everyone understands what we mean.

We hope that even more people with the Chinese national blood will join our actions. Only in unity is there strength. We are not individuals, we are a collective, and we are Chinese.

Source américaine : 17 avril / 18 avril

Et la traduction FR:

En seulement 3 courts jours, notre organisation, la Revanche de la Flame, a grossit énormément. Tout d’abords, j’aimerai remercier chacun d’entre vous pour votre “sens responsable nationaliste”. Cependant, nous étions sans doute trop impétueux. Nous aimons notre pays ! Nous allons resister à toutes les influences anti-chinoises. Cependant, nous devons choisir la bonne voie pour défendre notre pays, nos familles et nous-même ! Après quelques discussion internes, nous avons décidés d’annuler temporairement l’attaque du 19. L’organisation de La Revanche de la Flamme existe toujours ! Plus tard nous pourrons être une organisation de discussion virtuel, nous étudierons ensemble pour le jour où notre pays aura besoin de nous. Notre gouvernement et nos armées se mobiliseront tous ! A ce moment la, nous laisserons les sus-nommées “force du net étrangère” voir (comprendre) ! N’importe ou, la Chine ne perdra jamais contre eux. Nous avons, nous-aussi nos force du net ! Peut-être ace moment, notre Revanche de la Flamme sera la plus grand force ! Nous aimons tous notre pays ! Mais nous devons user de méthode plus sensibles pour défendre notre honneur.

ATTENTION : Notre plan de départ du 19 avril a été annulé parce que trop de monde était au courant et la situation était chaotic. A une date non spécifiée dans un futur proche, nous lanceront l’attaque. Nous demandons à chacun de rester prêt. Ca va recommencer. A une date non spécifiée dans un futur proche, nous lanceront l’attaque. Nous annulons présentement l’attaque. Nous pourrons envoyer une note sur la date de l’attaque et nous serrons prêt dans la journée. L’attaque n’a pas été annulée; elle sera relancé dans un futur proche. Je pense que chacun comprend ce que nous voulons dire.

Nous espérons qu’encore plus de chinois de sang nous rejoindront. C’est seulement dans l’unité que nous aurons la force. Nous ne sommes pas des individualités, nous somme une communauté, nous sommes chinois.

(traduction www.leblogdantoine.com)

18 avr. 2008

Google XSS

La méthode alert() de javascript a un usage quasi-réservé au debug de scripts. Néanmoins, elle est de loin la plus appelée dans les proofs of concepts de failles XSS.

Tellement que celà en devient un Google dork. Il est possible de trouver une quantité impressionnante de pages vulnérables (non 0day du coup) via une recherche du genre :

inurl:<script>alert('XSS')</script>


Avec même des petites perles :

http://www.sic.gov.lv/?gi=%3CSCRIPT%3Ealert(String.fromCharCode(88,83,83))%3C/SCRIPT%3E


Petite dérive hors sujet : étant donné que l'on parle de la méthode alert(), jetez donc un oeil à l'article "snippets of defense Pt. I" de .mario (GnuCitize, PHP IDS, mailgun..."

Toujours partant du fait qu'alert() est très souvent utilisée pour prouver une faille XSS, l'idée est de réécrire le méthode, afin de logger ses appels.
Le code est sur le lien ci-dessus. Assez sympathique et belle utilisation des possibilités de JavaScript concernant les pointeurs de fonction.

6 avr. 2008

Effectuer des requêtes RARP sous Linux

Pour mémoire, le protocole RARP, définit par la RFC 903 permet à une machine de connaitre l'adresse IP d'une machine (par exemple elle même) à partir de son adresse matérielle (ou adresse MAC).

Si des requêtes ARP peuvent être forgées à partir de l'outil ARPING, il n'existait pas à ma connaissance d'outil similaire pour les systèmes Gnu/Linux.
C'est chose faite avec RARPING, le logiciel est écrit en C, sans dépendance particulière (système Gnu/Linux, un compilateur C digne de ce nom et c'est tout...). Le projet est hébergé sur Google Code, vous pouvez récupérer le code soit par svn :

svn co http://rarping.googlecode.com/svn/trunk/ rarping-read-only

Soit via votre browser à la homepage du projet : http://code.google.com/p/rarping

J'ai plusieurs idées pour améliorer rarping. Il devrait donc encore évoluer de façon importante. Notamment quant à la possibilité pour l'utilisateur de définir le timeout, et l'usurpation d'adresses IP et MAC dans les requêtes. D'autres petites choses comme un meilleur contrôle des sorties (niveau de verbosité, logs...)

Les commentaires sont de type Doxygen et relativement abondants.
Ils suffisent je pense à comprendre le fonctionnement du programme.

L'utilisation requiert la CAP_NET_RAW (cf. man capabilities) pour être utilisé du fait qu'il ouvre une socket de types SOCK_RAW (envoi de données brutes sur le réseau), donc sur la majorité des machines, il faudra être root.
La ligne de commande est relativement simple et classique :


root@debianne:# ./rarping -h
RARPING (null) on (null)
Usage : ./rarping [-h] [-c count] [-I interface] request_MAC_address
-h : print this screen and exit
-V : print version and exit
-c count : send [count] request(s) and exit
-I interface : network device to use
request_MAC_address : hardware address we request associated IP address
For example : ./rarping -I eth0 00:03:13:37:be:ef


root@debianne:# ./rarping -c 1 -I eth0 00:16:32:2e:15:b6
RARPING 00:16:32:2e:15:b6 on wlan0
Reply received from 192.168.1.14 (00:11:d9:6a:51:c4) : 00:16:32:2e:15:b6 has 192.168.1.13
Sent 1 request(s)
Received 1 response(s)



Si vous trouvez des bugs, avez des idées pour améliorer le programme, des questions ou n'importe quoi qui concerne de près ou de loin rarping n'hésitez pas à m'en faire part!

25 mars 2008

Bluetooth Hacking -- II --

Ok, ok, c'est vrai j'avais promis de releaser ici mes codes relatifs à la sécurité Bluetooth. Le manque de temps m'a empêché de mener à bien et surtout en temps voulu mon code. J'ai bien commencé un RFComm Packet Injector (un truc pas encore implémenté dans Bluediving ) mais ai donc dû le mettre de côté.

Pour me faire pardonner, voici une petite liste de liens bien plus intéressant que le programme qui aurait dû être ici :

Présentations des principales attaques connues
La même à la sauce Kaspersky Labs
Guide d'introduction à la programmation Bluetooth

En enfin une vidéo de ces messieurs du Chaos Computer Club. Intéressant de voir comment il martyrisent le protocole dont la sécurité est vantée par tous les industriels (même ceux hors du consortium Bluetooth!). Bon en même temps c'est vrai que les mecs du CCC sont doués à vous faire flipper d'utiliser une cafetière tellement elle est insecure à leur yeux...



Dossier Bluetooth : -- Partie 1 (technologie) -- Partie 2 (sécurité) --
N'hésitez pas à consulter les autres vidéos du CCC!

http://chaosradio.ccc.de

6 mars 2008

Macro mouchard

Petit post au milieu d'une période bien chargée! Simplement pour partager une macro extrêmement utile. Elle permet de savoir avec précision où l'on se trouve dans le code, et l'état de errno. Peut donc raccourcir grandement une phase de Debug...

#define MOUCHARD (fprintf( stderr, "Mouchard !!!\n
\tFile : %s\n
\tFunction : %s\n
\tLine : %d\n
\terrno : %m (%d)\n", __FILE__, __FUNCTION__,
__LINE__, errno ))


(Découpée ici sur plusieurs lignes pour d'évidentes raison de mise en page)

En espérant qu'elle vous sera aussi utile qu'à moi!
Ce morceau de code est sous Licence Gnu/GPL, from "Bioul", d'après une idée de Vincent, un de ses amis de promo (de source sure!)

9 févr. 2008

Confiance

Etrange surprise que je viens d'avoir ce soir. En me rendant ici même, mon antivirus (Kaspersky pour ne pas le nommer) m'affiche ceci:



D'abord quelque peu inquiet, j'ai réalisé que toutes les url *.blogspot.com généraient une telle alerte (normalement des alertes critiques!)

Ceci est dut au fait que Blogspot, première plateforme de blog, google powered, est jugée "digne de confiance" par les internautes.. Or, blogspot offre aux auteurs des blogs le contrôle du code html généré. Très pratique lorsque l'on veut procéder à quelques ajouts, mais certains y auront vu la possibilité de placer cà et là quelques scripts malveillants. Javascripts notamment.

Certains blogs de blogspot doivent donc être (ou avoir été) utilisés comme tête de pont pour mener des attaques... D'autant plus que la plateforme est gratuite et l'inscription simple et rapide.

Les malwares javascripts et flash sont très en vogue actuellement. Couvrant de la tentative d'exploitation de failles 0day sophistiquée au phishing plus "commun".

Je ne suis pas en mesure d'expliquer pourquoi blogspot est donc "banni" par Kaspersky pour cause de phishing, et pas autre chose. Aucune information sur le site de Kaspersky Labs.

Troublant également: le fait que des outils évolués comme le sont ceux cités ici se contentent aveuglément de prohiber (car vu le message affiché on est plus proche de l'interdiction que du conseil, est-ce plus mal?) l'accès à toute URL en *.blogspot.com
Preuve:


Je ne sais pas encore comment réagir à cela... Une précaution est de mettre le nom de domaine en noscript dans votre navigateur.

25 janv. 2008

Vous êtes bien au 72.14.207.191 et autres joies du DNS

Premier post de l'année 2008, je sais, le précédent remonte à un moment maintenant... J'en profite donc pour attaquer d'autant plus vite le sujet (merveilleuse introduction, vous admettrez!)

La mode les travaux du GnuCitizen de ces derniers jours sont tournés autour d' attaques au niveau de protocoles réseaux au sens strict, plus que web apps comme auparavant. Les deux ne sont pas complètement distincts non plus mais cela est une autre histoire (intéressante). Après quelques frappantes recherches concernant l'UPnP, voilà au tour du DNS de passer entre leurs neurones affutés. </éloges>

Le sujet me passionnant, à mon tour de m'essayer à la chose, sans aucune prétention de rivaliser.

Le protocole DNS (Domain Name Service) est, pour mémoire, ce protocole qui permet de transformer "hatch-the-hitch.blogspot.com" en "72.14.207.191". En effet vos applications n'ont strictement rien à faire de l'url, et votre mémoire de l'adresse ip (à moins d'une pulsion de consulter mon site sur un réseau aux DNS en panne mais bon là c'est pas pareil!). Cette résolution de noms se fait en envoyant une requête à un serveur, lequel transmet à d'autres serveurs DNS etc... jusqu'à l'obtention de l'adresse ou d'une erreur. Dans les deux cas la réponse remonte ensuite au client.

Ensuite il y a le mauvais élève, mDNS, pour multicast DNS, ou les requêts sont envoyées en broadcast 255.255.255.255, et répond qui veux (oui, le méchant pirate au fond de la salle, tu veux répondre?). Les produits Apple ou la Xbox360 utiliseraient ce protocole.

Un autre point notable est que ces communications se font via des paquets UDP, forgeables sans problèmes aucun par un utilisateur. Par contre les serveurs sont sur les ports 53, il faut donc être root pour les binder. Cela ne constitue pas un obstacle majeur étant donné, je le répète que n'importe quel utilisateur d'une machine connectée au réseau pourra forger des fausses réponses.

Forger des réponses DNS? Rien ne protège le client? Serions-nous alors face à un protocole infernal, pure invention du malin, voir d'un hippie? Non quand même pas. Lors d'une requête, la demande d'informations est "signée" d'un octet aléatoire. La réponse reprend le même octet. Bon, il s'entend qu'un bête sniffer permet de bypasser la chose. Ensuite un petit DOS sur le "vrai" serveur DNS et vous voila le roi du monde, un peu!

Le contrôle du traffic DNS d'un réseau se révèle quasiment synonyme du contrôle du réseau. En effet, il permet d'attaquer sur tous les fronts. Phishing, modification à la volée de pages web, à l'aide d'un serveur distant, Mitm attacks, dénis de service... je m'arrête là!

Les serveurs DNS sont donc des organes à protéger. Il existe différentes solutions pour cela. La plus "pratique" est l'utilisation d'IDS tels que SNORT. Ces logiciels peuvent détecter une attaque autour du protocole DNS. Charge à l'administrateur de prendre les mesures adaptées.
Une autre peut être la mise en place d'une architecture dnssec qui permet en autre d'éliminer les risques de DNS cache poisoning.