_ _____________________ _
-*4*- `^°*;:,.> Web Scanning <.,:;*°^`
_____________________________/¯¯¯¯¯¯ ¯¯¯¯¯\_____________________________
¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸
Contexte : scan d'un serveur web
Technique : on the rocks
-L'encodage Hexa
----------------
La methode la plus basique pour paumer un admin dans ses logs lors d'un
passage au crible de son serveur pour des vulnerabilites connues est de
deguiser l'url des requetes en remplacant les lettres par leurs valeurs
hexadecimales ASCII.
Les investigations etant souvent basee sur des recherches texte il est
tres facile de semer le trouble en encodant le tout.
Par exemple le test pour la vulnerabilite MDAC sur IIS laisse les
traces suivantes :
06:45:25 10.0.2.79 GET /msadc/ 302
Du coté du pingouin qui envoie la requete, ca peut ressembler a ca :
[root@localhost /root]# nc -n 10.0.2.55 80
GET /msadc HTTP/1.0
Ceci produit donc le resultat suscité.
En substituant les lettres par leur valeur ASCII en hexa, la chaine
"msadc" devient alors 6D 73 61 64 63. L'ascii encoding en hexa n'est
pas toujours efficace, nous allons voir pourquoi...
La requete suivante est donc forgée :
[root@localhost]# nc -n 10.0.2.55 80
GET /%6D%73%61%64%63 HTTP/1.0
Ha bin merde sur IIS ca change rien, m'enfin c pas grave vu que la
faille mdac est quand meme assez vieille. Aucune importance, car
meme si l'encodage hexa n'aide pas beaucoup sur un serveur microdob,
il va etre tres efficace sur un serveur apache (par exemple pour
verifier une toute aussi vieille faille qu'est celle du dossier test-cgi.
Ca ressemblerait a peu pres a ca sans encodage :
[root@localhost]# nc -n 10.0.0.2 80
HEAD /cgi-bin/test-cgi HTTP/1.0
Et pour ajouter un flou artistique dans les logs du serveur :
[root@localhost]# nc -n 10.0.0.2 80
HEAD /%63%67%69-bin/test-%63%67%69 HTTP/1.0
Un coup d'oeil au log d'acces nous montre ceci dans le premier cas :
10.10.10.10 - - [18/Oct/2000:08:22:47 -0700] "HEAD /cgi-bin/test-cgi
HTTP/1.0" 200 0
Et dans le deuxieme cas (partiellement hex-encodé) :
10.10.10.10 - - [18/Oct/2000:08:23:47 -0700] "HEAD
/%63%67%69-bin/test-%63%67%69 HTTP/1.0" 200 0
A noter que dans les deux cas la reponse est 200 (commande executee
avec succes), sauf que dans le deuxieme le fichier de log est rempli
avec les valeurs telles qu'elles ont été envoyées en hexa, rendant
ainsi toute recherche textuelle inutile en cas de recherche exacte (la
methode la plus greppée par les admins.
Malheureusement de plus en plus de systemes permettent d'ajouter des
filtres a la recherche et notemment le decodage hexa des valeurs
trouvees avant comparaison.
Voici un petit utilitaire en php qui fait double emploi, dans un premier
temps il permet de convertir une adresse ip de type xxx.xxx.xxx.xxx en
adresse numerique decimale (et vice-versa), mais il permet aussi
d'encoder en hexa n'importe quelle chaine dans le but de tester si le
log du serveur web prend effectivement la chaine exacte ou la chaine
encodee envoyee dans la requete.
");
echo ("Devient $hide\n ");
echo ("try it http://$hide\n ");
}
if($unhide=="") $unhide=$hide;
if($unhide!="") {
$one =$unhide/16777216%256;
$two =$unhide/65536%256;
$three =$unhide/256%256;
$four =($unhide-1)%256+257;
echo "Unhide : $one . $two . $three . $four\n ";
}
}
?>
-Le Serveur Proxy
-------------------
Concevoir l'approche d'un serveur est aussi important que de dissimuler les
traces une fois l'approche etablie. Quand l'adresse IP originale est masquee
par un moyen ou par un autre, la situation est telle que toute attaque
dirigee vers le serveur web sera loggée avec l'adresse du masque plutot que
celle dont les attaques sont originaires.
Les proxies sont en general utilisés pour rediriger différents protocoles
au travers d'un seul point d'acces. Au niveau pratique, tous les utilisateurs
sont forcés d'utiliser un meme proxy pour acceder a l'internet, laissant ainsi
la possibilité aux admins d'ajouter des limites et restrictions en entree et
en sortie. Le proxy relaye toutes les demandes des utilisateurs vers les serveur
concernés qui enregistrent non pas leur adresse mais celle de la machine ou
se trouve ce proxy. Evidemment le proxy lui meme possede un fichier de log
avec le detail des connexions, cela peut representer une securité autant qu'une
crainet pour les petits malins qui veulent se planquer derriere...
Il se peut parfois que certains proxies "orphelins" soient abandonnés sur le
reseau, ils vont alors rejoindre le rang des proxies-pour-tous (ay qu'est ce
que c'est que cette secte ? ) Proxys-4-All -> http://www.proxys4all.com/ avec
une liste de serveurs mal configurés (ou trop bien configurés, ca dépend de quel
coté on se place hehehe).
L'utilisation d'un tel proxy appliquée a l'exemple donné plus haut donne des
resultats differents sur les logs, voici une connexion normale :
Pingouin :
[root@10.1.1.1 /]# nc -v 10.8.8.8 80
HEAD / HTTP/1.0
Fichier Log sur la machine ciblée
10.1.1.1 - - [18/Oct/2000:03:31:58 -0700] "HEAD / HTTP/1.0" 200 0
Voici la meme connexion etablie au travers d'un proxy
In the following attack/log file combination, we see the attacker achieve
the same goal, except that the attacker uses a proxy server.
Pingouin :
[root@10.1.1.1 /]# nc -v 216.234.161.83 80
HEAD http://10.8.8.8/ HTTP/1.0
Fichier Log sur la machine ciblée
216.234.161.83 - - [18/Oct/2000:03:39:29 -0700] "HEAD / HTTP/1.1" 200 0
Le proxy utilisé ici est 216.234.161.83 => proxy.proxyspace.com et c'est
bien cette adresse qui apparait au lieu de celle du pingouin (10.1.1.1).
La seule facon pour l'admin du serveur web de tracker l'adresse originale
est de faire cooperer l'admin qui s'occupe du proxy qui a relayé la requete,
car la plupart des serveurs proxies ont un fichier log TRES detaillé.
Pour contourner cette lacune, la ruse consiste a utiliser un second, voire
un troisieme proxy qu'on met en chaine (si possible un proxy situé dans un
autre pays ou appartenant a des sociétés concurrentes.
Retrouver la trace de l'ip originale devient alors une veritable chasse au
tresor et reclame des capacités plus politiques et strategiques que
techniques.
Le chainage des proxies est une technique testée et approuvée par de grandes
marques de hackers, il existe meme des programmes pour script-kiddies qui
font ca automatiquement :
SocksChain pour Windows. -> http://www.ufasoft.com/socks/
-Le SSL
------
Une information interessante est que les serveurs equipes d'un module SSL
actif ne sont PAS monitorés par des programmes de detection d'intrusion, car
fondamentalement ils ne peuvent pas (le premier S dans SSL deviendrait
nul et non avenu). Voila pourquoi les intrusions sont toujours plus rapides
et plus "securisees" sur le port 443 (HTTPS) que sur le 80 (HTTP). Inutile
de preciser quelle est la route qui est la plus souvent utilisée par un
attaquant qui veut rester invisible. La methode dite du "mec au milieu"
est plus que jamais appliquable (voir hackoff precedent pour description de
cette methode).
Traduit et complété a partir d'un document original trouvé sur le web.