Majoritairement, les fichiers peuvent être rangés en trois familles, comme vu dans la Part I.
Intéressons nous aux fichiers ne faisant pas partie de ces familles. Par la suite, j'appelerai fichier RFI un fichier utilisé par les pirates.
1/Obfuscation
Tout d'abord, certains pirates utilisent de l'obfuscation. Le principe en est simple, il suffit de coder en base64 un document, puis d'utiliser la commande eval(base64_decode ...).
Certains pirates préferent encoder un base64 un fichier gzippé qui sera donc évalué. Je ne comprends pas forcément cette manière de faire, puisqu'il ne s'agit nullement de pouvoir cacher ou chiffrer de l'information, mais seulement de la dissimuler.
Je suis tombé sur certains fichiers qui pouvaient être encodés jusqu'à 8 fois d'affilée en mélangeant du base64 et/ou du gzip à chaque tour.
Mis à part perturber des néophytes complets, la méthode n'a pas vraiment d'interêt, mais elle reste toutefois largement utilisée. Le nombre de messages sur des forums de néophytes demandant comment lire ces lignes est éclairant à ce principe.
Les fichiers obfusqués de cette manière sont le plus souvent des fichiers de découverte d'environnements.
2/Ajout de commandes obfusquées
Souvent ces fichiers RFI contiennent uniquement une partie obfusquée. Son déchiffrement montre souvent que ce contenu est une adresse email contenant dans son corps l'URL appelante, l'IP du serveur, etc.. Tout d'abord, on peut penser qu'il s'agit d'une méthode pratique pour récolter les serveurs vulnérables suite à scan.
Toutefois, je pense plutôt qu'il s'agit de pirates qui se piratent entre eux. Une fois un fichier RFI trouvé, il devient simple d'ajouter son adresse mail et d'attendre que le premier pirate utilise ce fichier. Je penche dans cette direction pour deux raisons: Seule cette partie est obfusquée, et souvent elle est placée dans des endroits qui se veulent discret, comme par exemple après l'ajout d'une cinquantaine de lignes vides en fin du fichier RFI. L'ouverture de ce fichier dans un éditeur de texte n'affiche pas ce morceau de code ajouté, se trouvant beaucoup plus bas. Ce n'est pas très bien caché, mais c'est au même niveau que de cacher des infos à l'aide de la base64.
3/ Fichiers bots
Les fichiers bots contiennent souvent le nom d'un canal IRC sur lequel ils se connectent. Pour information, voici le genre d'en-tête contenu dans ces fichiers:
###############################################
# [!] McN RFI Botz Modified by cuex [!] #
###############################################
');
######################################################
## Usage: ##
## perl feelscanz.pl
## Notes: ##
## + All Parameters are optional ##
## ##
## Features: ##
## + RFI Scanner ##
## + RFI Scan & Exploit (Exploit per engine) ##
## + Joomla RFI Scan & Exploit ##
## + Milw0rm Search ##
## + Google bypass (Using PHP) ##
## + Message Spy & Save ##
## + Auto Spreading ##
######################################################
On note que le canal et le serveur sont optionnels et peuvent être fournis sur la ligne de commande. Toutefois, on lit généralement:
##[ KONFIGURASI IRC ]##
my @servers = ("irc.openjoke.org"); #IRC Servers (Separated by coma)
my %bot = (
nick => "xxx[".int(rand(100))."]",
ident => "mcn".int(rand(100)),
chan => ["#megascan"], #Channels to join (Separated by coma)
server => $servers[rand(scalar(@servers))],
port => "6667"
);
Ce qui permet de savoir sur quel serveur la machine doit se connecter, quel sera son nick, etc. On trouve certaines configurations possédant des mots de passe, indiqués eux-aussi dans le fichier de conf.
L'accès à ces canaux est donc possible.
Et la connexion sur ces canaux est en fin de compte peu sources de renseignements.
Grosso modo, ces incursions sont de trois types:
-Arrivée sur un canal vide, sans absolument aucune personne, ni admin.
-Arrivée sur un canal et éjection quasi immédiate. L'admin lance une commande pour vérifier qu'il s'agit bien d'un bot (il est censé répondre aux commandes après tout). En cas de non réponse, éjection. Ce qui donne une impression de suivi de la part du botmaster de son réseau. Curieusement, ces canaux sont vides.
-Arrivée sur un canal parmi les autres bots et les admins. Le suivi des conversations des admins sur ce canal ou sur les autres canaux dont ils font partie ne fournit finalement que peu d'informations. Généralement, ils ne parlent pas anglais et les seuls URL qu'ils s'échangent sont des URL menant vers des films X (rapidshare, etc..). J'ai pu rester plusieurs heures sur différents canaux sans aucune action de la part du botmaster.
4/ Serveurs visés
La liste des fichiers visés par ces pirates est elle aussi relativement décevante. Au vu du code de ces RFI scanners, ce n'est pas étonnant, mais ils arrosent vraiment large puisque généralement tous les liens d'une page web sont testés. Il ne testent même pas si le fichier est un fichier php, ou s'il correspond réellement à un site vulnérable.
Les fichiers php visés ainsi que les variables correspondent à ce qui se trouve sur milw0rm (ce qui est loin d'être étonnant).
5/ Autres fichiers dignes d'interêt
J'ai trouvé également au cours de ces recherches un kit de phishing préparé. Il concernait la "Commonwealth Bank of Australia 2009", et comportait les fichiers suivants:
a.php, ago.php, complete.php, index.php, index2.php, mastercard.php, wps.html.
Le wps.html contenait le message de phishing classique:
"Dear Customer, With Maestro Card Number 560279XXXXXXXXX or MasterCard. You have been chosen by the Online Department to take part in our quick and easy survey" etc...
Avec un lien visible vers www3.netbank.commbank.com.au mais qui pointe réellement vers www.netbank.commbank-online.com/images/netbank/survey.html ...
Rien de bien neuf dans le phishing. Une recherche google montre que la banque australienne a été victime d'un phishing en mai 2009. Mon fichier récolté date de juin, je ne sais pas si c'est le même.
6/Et pour la suite?
En attendant un Remote File Inclusion - Part III, quelles sont les pistes à creuser?
-Ajouter à son tour son adresse mail dans les fichiers RFI afin de vérifier leur utilisation. Ceci est élégant, sans risque, mais n'est pas pleinement fonctionnel. Je pense que des configurations php peuvent être vulnérable alors que la configuration empêche l'envoi de mail.
-Réécrire un bot 'safe' qui n'effectue aucune action offensive, mais qui répond aux questions de statut. Ainsi, il est possible d'entrer sur un canal, et observer les commandes données par le botmaster. A ce sujet, et pour avoir vu le résultat sur les canaux dont je me faisais kicker, je pense que le recrutement des bots se fait en deux temps: Scan intensif, arrivée sur le canal. Selon l'état du bot, il doit être redirigé vers un canal secondaire. Ce canal secondaire pourrait être plus instructif que le premier.
-Trouver la primo-infection. Le RFI est basé sur un serveur qui contient un fichier offensif. Une fois un serveur vulnérable trouvé, il sera possible de lui faire héberger des fichiers RFI pour continuer l'infection. Mais quel a été le premier fichier? Je pense que l'état des serveurs hébérgeant ces fichiers RFI serait intéressante. Toutefois, certains de ces RFI doivent être directement hébérgés par le serveur appartenant au pirate.
-Télécharger des fichiers de logs des serveurs webs pour connaître la fréquence à laquelle ces fichiers sont appelés.
-Les bots connectés sur le chan IRC n'obéissent qu'aux ordres du botmaster. Je me demande à quel point il serait possible de faire une injection perl pour qu'il obéisse à un autre botmaster; genre utiliser comme nick: admin') #
-Envoyer un mail à une des adresses et se faire passer pour une machine vulnérable afin de voir la réaction de l'attaquant.
Bien entendu, ces options deviennent limites du point de vue éthique et posent des questions quant à leur mise en oeuvre. Pour l'instant, je n'ai pas mis en place ces otpions.
CONCLUSION/
Après m'être documenté sur les botnets, et plus particulièrement sur les bots perl, PHP et les RFI, je partage les conclusions de ces auteurs. Conclusions partagées par pas mal d'auteurs traitant de honeypots d'ailleurs.
Analyser ces botnets reste très intéressant mais les conclusions restent les mêmes: La majorité de ces fichiers que j'ai pu récupérer grâce à mon outil semblent être utilisés par du kiddie. Ceci est dû à la fois au type de faille employée (testable à grande échelle, scripts fournis prêts à l'emploi) mais peut-être aussi à leur manière de faire. Moins ils sont bons, plus ils arrosent large et plus j'ai de chance de les voir.
TRès intéressant ! Merci !
RépondreSupprimer