SYN, SYN-ACK, ACK …

Steal This Blog

Mirror Exploit-db

décembre 19th, 2009 by Corbier

Il est parfois difficile de trouver l’information que l’on souhaite. C’est pourquoi j’ai mis en place un mirror du site http://www.exploit-db.com/

En effet, ils proposent un svn pour télécharger les mises à jours (beaucoup plus pratique que l’archive en passant)

The Exploit Database can now be downloaded via SVN. We figured it would be easier to download and track exploits this way, rather than re-downloading the whole archive. We will be adding the exploit-db archive as a package in BackTrack4, but for now you can:

root@bt4:# cd /pentest/exploits/
root@bt4:# svn co svn://devel.offensive-security.com/exploitdb

Le mirror est disponible ici

Filed under Non classé having No Comments »

DNS & co

décembre 7th, 2009 by Corbier

Le protocole DNS est la clé de voute d’internet. Ce protocole est utilisé partout à tous les instants.

Les derniers avis de sécurité du protocole DNS notifiait des problèmes de sécurité d’implémentation du Transaction ID. Il est possible sous certaine configuration de prédire le transaction ID.

Ce transaction ID est généré à chaque requête et ré-émis lors de la réponse.  Partant de ce principe il est possible de faire des statistiques sur la génération des transactions ID.

J’ai créé un outil en python permettant de faire de l’analyse sur ces fameux transaction ID.

L’idée est d’envoyer a un serveur DNS des requêtes aléatoire (par exemple: 345678865.mondomaine.fr)  sur un domaine sous votre contrôle afin d’étudier le champs Transaction ID.

J’ai donc fait de l’analyse sur 2000 requêtes vers un DNS  « Windows 2003 Serveur SP1″.  Il en résulte le résultat suivant :

Capture-2

On constate effectivement que la génération du transaction ID n’est pas si aléatoire que ca.

Le même test sur un DNS de chez google

Capture-3

La différence est assez flagrante. Ici la ramdomization est correct, il serait assez difficile de prédire le transaction ID.

Vous pouvez télécharger l’outil en python à l’adresse suivante  http://data.stealthisblog.fr/script/DnsStats.py

Cet outil sera modifié pour automatiser l’attaque en MITM sur le protocole DNS.

Filed under Non classé having No Comments »

VMware Server et Virtual Router Redundany Protocol (VRRP)

mars 3rd, 2009 by Corbier

Selon Wikipédia :

Virtual Router Redundancy Protocol (protocole de redondance de routeur virtuel, VRRP) est un protocole non propriétaire redondant décrit dans la RFC 3768 dont le but est d’augmenter la disponibilité de la passerelle par défaut servant les hôtes d’un même sous-réseau.

Le fonctionnement de VRRP est le suivant :

Chaque Routeur Virtuel utilise une adresse mac de l’IANA ces adresses mac sont réversées et vont de 00:00:5e:00:01:00 à 00:00:5e:00:01:ff (on peut donc avoir 256 routeurs virtuels par segment Ethernet)

Les routeurs communiquent entre eux via l’adresse multicast réservée 224.0.0.18 associé à la mac réservé 00:00:5e:00:01:02

Comme l’indique le paquet capturé suivant :

Frame 6 (70 bytes on wire, 70 bytes captured)
Ethernet II, Src: IETF-VRRP-virtual-router-VRID_02 (00:00:5e:00:01:02), Dst: IPv4mcast_00:00:12 (01:00:5e:00:00:12)
Internet Protocol, Src: 192.168.130.160 (192.168.130.160), Dst: 224.0.0.18 (224.0.0.18)
Virtual Router Redundancy Protocol

Afin d’utiliser une IP virtuelle associés a plusieurs routeurs nous utilisons le Common Address Redundancy Protocol ou CARP.

Selon wikipédia :

Common Address Redundancy Protocol ou CARP est un protocole permettant à un groupe d’hôtes sur un même segment réseau de partager une adresse IP.

Dans le cadre de préparation de labs, j’ai voulu émulé l’ensemble de via une solution freebsd (Pfsense) sous VMware Server. Cependant l’adresse virtuel CARP ne pouvait pas être utilisé. Les réponses ARP était bien présente mais le ping et tout les autres services était indisponible.

Le module kernel vmnet drop tout les paquets ethernet que ne sont pas à destination :

  • d’elle même
  • d’une addresse de broadcast FF:FF:FF:FF:FF:FF
  • d’une addresse de multicast

Cependant le bloc de IANA est manquant !!!Les packets sont donc droppés.

Afin de valider et corriger le module noyau, il faut éditer le driver.c contenu dans /usr/lib/vmware/modules/source

Le fichier qui nous intéresse est dans l’archive vmnet.tar. Il faut extraire cette archive.

tar xvf vmnet.tar

cd vmnet-only

Ensuite nous devons localiser la fonction VNetPacketMatch qui est responsable du matching de paquet.

*
*———————————————————————-
*
* VNetPacketMatch –
*
*      Determines whether the packet should be given to the interface.
*
* Results:
*      TRUE if the pasket is OK for this interface, FALSE otherwise.
*
* Side effects:
*      None.
*
*———————————————————————-
*/

Bool
VNetPacketMatch(const uint8   *destAddr, // IN: destination MAC
const uint8   *ifAddr,   // IN: MAC of interface
const uint8   *ladrf,    // IN: multicast filter
uint32   flags)          // IN: filter flags
{
/*
* Return TRUE if promiscuous requested, or unicast destined
* for interface, or broadcast (and broadcast requested), or
* if multicast (and all multicast, or this specific
* multicast MAC, was requested).
*/

return ((flags & IFF_PROMISC) || MAC_EQ(destAddr, ifAddr) ||
((flags & IFF_BROADCAST) && MAC_EQ(destAddr, broadcast)) ||
((destAddr[0] & 0×1) && (flags & IFF_ALLMULTI ||
(flags & IFF_MULTICAST &&
VNetMulticastFilter(destAddr, ladrf)))));
}

Il faut ajouter les lignes suivantes ajoutant le support des paquets de IANA :

((destAddr[0] == 0) && (destAddr[1] == 0) &&
(destAddr[2] == 0x5e) && (destAddr[3] == 0) &&
(destAddr[4] == 1))

Ce qui nous donne la fonction suivante :

return ((flags & IFF_PROMISC) || MAC_EQ(destAddr, ifAddr) ||
((flags & IFF_BROADCAST) && MAC_EQ(destAddr, broadcast)) ||
((destAddr[0] == 0) && (destAddr[1] == 0) &&
(destAddr[2] == 0x5e) && (destAddr[3] == 0) &&
(destAddr[4] == 1)) ||
((destAddr[0] & 0×1) && (flags & IFF_ALLMULTI ||
(flags & IFF_MULTICAST &&
VNetMulticastFilter(destAddr, ladrf)))));

Sauvegardez et recompilez le module :

make vmnet.ko

Il nous reste à copié le nouveau module au bon endroit

cp vmnet.ko  /lib/modules/`uname -r`/misc/vmnet.ko

/etc/init.d/vmware restart

Nous avons désormais un VMware Server fonctionnelle.

Nuit du Hack 2009

février 20th, 2009 by Corbier

La sécurité informatique et le hacking

Le développement des nouvelles technologies à donné naissance à un nouveau type de danger, aussi bien pour les entreprises que pour le consommateur final : le piratage des systèmes privés. Il s’agit dans la majorité des cas d’une intrusion sur le système même de la victime. Le pirate est alors en mesure d’utiliser l’ordinateur visé comme s’il en était propriétaire, mais sans en avoir les autorisations. Les conséquences peuvent être dramatiques aussi bien à une échelle commerciale qu’individuelle.

La sécurité informatique regroupe l’ensemble des techniques, compétences et méthodologies destinées à garantir l’intégrité des systèmes d’informations automatisés de tout type, et à les protéger contre cette menace de piratage.

Le Hacking peut se définir comme la passion de la recherche de jeunes esprits dynamiques, souvent amateurs, dans la recherche de bugs (cause de piratage) des programmes couramment utilisés, afin de trouver des solutions adaptées pour prévenir les utilisateurs de ces dangers. C’est aussi une volonté du partage de l’information avec le grand public, destinée à offrir à chacun la possibilité de comprendre, d’apprendre et de participer à son tour au développement de nouvelles technologies de sécurité.

Qu’est-ce que la Nuit du Hack?

Autour de conférences et de challenges informatiques, la Nuit du Hack a pour objectif de réunir passionnés et professionnels du monde de la sécurité informatique. Ils pourront découvrir les dernières avancées techniques dans ce domaine et évaluer leurs compétences.

A ne pas manquer, rendez vous a Paris le 13 juin. Au programmes conférences, challenges et autres joyeusetées.

Nous sommes actuellement a la recherche de conférenciers, si cela vous intéresse veuillez envoyer un mail indiquant le thème de celle ci et une explication de ce que vous allez aborder. Nous contacter.

Pour plus d’information rendez vous : http://www.nuitduhack.com

Les inscriptions seront bientôt ouvertes. Toute communauté du monde libre est également bienvenue. Le libre étant très proche de l’éthique que nous défendons de par son développement et sa rapidité d’évolution.

N’hésitez pas à venir nous voir sur le chan #hzv sur irc.worldnet.net.

Filed under Non classé having No Comments »

IP-FailOver Ovh Vmware Server

janvier 23rd, 2009 by Corbier

Lorsque l’on a un serveur dédié on peut être tenté de faire de la virtualisation sur son serveur. Plus OS, facilité des backups etc… Cependant, pour éviter que ce soit trop le bazar sur leur réseau, Ovh a limiter les mac adresse par rapport au port des commutateurs.

Il est donc impossible de communiquer avec un machine qui serait bridger sur l’interface de la machine hôte. Pour pallier à ça il est possible de mettre ses machines virtuelles en mode HostOnly. Il suffit ensuite d’activer le routage et le snat sur le linux .

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Mais cela pose problème si l’on souhaite utiliser des ip public. Il faut donc feinter.

Tout d’abord ovh propose d’utiliser des IpFailOver afin de faire « pointer » plusieurs ip public sur le même serveur. Comme les mac adresses sont bloquées par port, il faut utiliser le proxy_arp de linux afin de réussir cette configuration.

L’idée est donc d’utiliser des ips public que l’on a acheter à ovh pour des machines virtuelles. Il faut donc configurer une interface réseau vmware en hostonly. Dans ma configuration c’est vmnet1. Activons maintenant le proxy_arp sur l’interface vmware.

echo 1 > /proc/sys/net/ipv4/conf/vmnet1/proxy_arp

Je vous laisse consulter la page suivante pour avoir plus d’information sur le fonctionnement d’un proxy arp.

Ensuite il faut ajouter une route à destination de ip_suplémentaire pour que la machine hote puisse savoir à quel interface envoyer le paquet.

route add ip_supplémentaire dev vmnet1

Il ne vous reste plus qu’a configurer votre machine virtuelle avec l’adresse suplémentaire. Avec un masque de sous réseau 255.255.255.255 pour pouvoir communiquer avec les machines de votre subnet.

Cependant attention le trafic à destination de votre machine virtuel passe par la table filter-forward d’iptables il vous faut évidement configurer les protocoles que vous souhaiter router.

Filed under Non classé having No Comments »

« Previous Entries Next Entries »