mardi 30 avril 2013

Conférences, Livre Blanc, et autre info

Quelques petites infos disparates réunies dans le même post de Blog:

1/Conférences
J'ai le plaisir d'aller assister au Training Corelan D'HackInParis les 17-18-19 juin prochain.
Par ailleurs, je retourne aux RMLL2013 en tant que speaker pour parler du chiffrement de disque sous linux dans une conférence intitulée "Myths and reality".

2/Le livre blanc et la fameuse menace "cyber"
Le livre blanc de la défense et sécurité nationale est publié. Une recherche textuelle montre que le mot "cyber" apparaît 38 fois.
Morceaux choisis:

"Les opérations ciblées conduites par les forces spéciales et les frappes à distance, le cas échéant cybernétiques, pourraient devenir plus fréquentes, compte tenu de leur souplesse d’emploi dans un contexte où les interventions classiques continueront d’être politiquement plus difficiles et parfois moins efficaces." Un goût de stuxnet?

"Le cyberespace est donc désormais un champ de confrontation à part entière". Les 5 champs d'actions référencés sont terre-air-mer-espace (hors atmosphère)-cyberespace

"Les cyberattaques, parce qu’elles n’ont pas, jusqu’à présent, causé la mort d’hommes, n’ont pas dans l’opinion l’impact d’actes terroristes."


"L’importance nouvelle de la cybermenace implique de développer l’activité de renseignement dans ce domaine et les capacités techniques correspondantes. Cet effort a pour objet de nous permettre d’identifier l’origine des attaques, d’évaluer les capacités offensives des adversaires potentiels et de pouvoir ainsi les contrer. Les capacités d’identification et d’action offensive sont essentielles pour une riposte éventuelle et proportionnée à l’attaque." Première fois qu'on entend parler de lutte offensive.

Et enfin, page 105, après avoir beaucoup parlé de cyberdéfense:
"La lutte contre la cybermenace" : (...) "Au sein de cette doctrine nationale, la capacité informatique offensive, associée à une capacité de renseignement, concourt de façon significative à la posture de cybersécurité. Elle contribue à la caractérisation de la menace et à l’identification de son origine. Elle permet en outre d’anticiper certaines attaques et de configurer les moyens de défense en conséquence. La capacité informatique offensive enrichit la palette des options possibles à la disposition de l’État. Elle comporte différents stades, plus ou moins réversibles et plus ou moins discrets, proportionnés à l’ampleur et à la gravité des attaques." : C'est timoré: plus ou moins réversible, plus ou moins discret, ca reste une "option". On est quand même loin du discours guerrier américain qui dit "on est capable de trouver les auteurs des attaques, et on est capable de leur faire beaucoup de mal". Cf un ancien article de blog.

3/ autre info
Arkoon vient de se faire racheter par Cassidian.

lundi 22 avril 2013

Bonjour, ton site semble avoir un problème

"Bonjour, je crois que votre site web à un problème." Régulièrement, j'envoie ce genre de mail à des webmasters pour leur signaler un dysfonctionnement en donnant un maximum d’éléments pour les aider à corriger leur problème.
Malheureusement, les administrateurs ne donnent souvent pas suite car de leur point de vue, leur site fonctionne très bien.

J'ai donc pensé faire un petit récapitulatif ici des points importants à considérer lorsqu'on nous soumet une compromission de site web. Je ne vais pas parler des buts des pirates, qui peuvent être multiples et variés, depuis le message à faire passer jusqu'au commerce (vraisemblablement lucratif) des faux antivirus ou des botnets. Je vais présenter six types de compromissions.
  • Le defacing
  • l'ajout de sites webs
  • l'ajout de pages webs ou répertoires
  • l'ajout de javascript dans les pages webs
  • la redirection par .htaccess
  • et l'ajout de modules apache.
1/ Le defacing n'a absolument rien de furtif, son but en est même l'opposé. Que ce soit pour la glorification personnelle du pirate ou pour la diffusion d'un slogan (généralement politique et souvent opposé à celui du site piraté), il faut que cela se voie. L'administrateur s'en rend généralement très vite compte.

2/ Dans certains cas, le pirate ne cherche pas à utiliser le site pour profiter de sa popularité, mais préfère utiliser ses ressources (disque, réseau). Il va alors ajouter des sites webs en vhosts. De manière intéressante, j'ai pu observer plusieurs noms connus accolés à un nom quelconque, comme par exemple picasa.com.randomname.tld ou facebook.com.anotherrandomname.tld. L'administrateur devra donc consulter le contenu des fichiers de configuration d'apache et vérifier qu'aucun vhost n'est ajouté.

3/ L'ajout de page et de répertoire est à peine moins furtif qu'un defacing mais laisse le site d'origine fonctionner normalement. Pour s'en rendre compte, l'administrateur peut lire ses logs d'accès, consulter le contenu du site, et/ou demander à google l'état de son site (via une recherche site:www.site.tld ou cache:www.site.tld).
J'ai démontré un PoC d'une attaque similaire en utilisant directement la base de données. Un site de forum permettait aux utilisateurs d'enregistrer un avatar et une signature ce qui est courant. Ce qui était faible, c'est qu'il n'y avait aucune restrictions, ni de création de compte (automatisation possible), ni d'accès (par le referer par exemple), ni de taille ou de format de fichiers. Dès lors, il devenait simple de remplir la BdD de toutes les données souhaitées et d'utiliser la bande passante et le stockage de ce site à des fins malveillantes. Curieusement, j'ai rarement vu des attaques de ce genre "IRL", mais une surveillance du contenu et de l'usage de sa base de données n'est pas à exclure.

4/ Pour être encore un peu plus furtif, le pirate peut simplement ajouter un petit javascript dans certaines pages du site. Le site fonctionne toujours, et une vérification rapide du contenu du site ne montre rien d'évident. Il faut donc comparer le site avec une version saine. Et là, le fait de disposer de deux versions du site web (une préprod et une en prod par exemple) peut aider. Une autre méthode consiste à lire le code source des pages webs envoyées par le serveur pour trouver le code malveillant.
Cet ajout de code peut également être effectué à l'aide de la variable php auto_append_file qui comme son nom l'indique ajoute automatiquement à toutes les pages la valeur considérée.

5/ Pour ajouter en discrétion, le pirate peut choisir de modifier le .htaccess du site web et de ne rediriger que quelques clients (selon l'IP source, le navigateur ou le referer utilisé) vers une page malveillante. Généralement, le pirate ne redirige que des clients provenant d'un moteur de recherche. Ainsi, les habitués du site (admin, utilisateurs) ne constatent aucune modification et accèdent au site par l'utilisation d'un lien en favori ou en tapant l'URL directement dans la barre d'adresse.
Les redirections peuvent également choisir de renvoyer vers le site d'origine les machines sans intérêt (déjà passées par là, ou non vulnérables pour l'attaque considérée). Un utilisateur ira donc sur le site via une recherche google, se fera infecter et n'accédera pas au site. La seconde fois qu'il cliquera sur le site, il y accédera normalement.
L'administrateur devra donc accéder à son site de diverses manières pour vérifier l'état de son site.

6/ Le niveau le plus élevé de discrétion et de furtivité que j'ai pu voir a été fait en ajoutant des modules apaches. Chercher darkleech pour plus d'infos là dessus.
Ce module permet au pirate d'ajouter dynamiquement le code offensif aux pages web souhaitées . De plus, le module fait attention à ne jamais renvoyer deux fois le code offensif à la même IP source dans un certain intervalle de temps. Il surveille également les connexions IP au serveur web. Si une IP est connectée en ssh, alors aucun contenu malicieux ne lui sera renvoyé. Si root est loggé, si tcpdump est lancé, ou si des programmes comme rkhunter ou équivalent tournent le module n'a aucune activité.
C'est ingénieux: en cas de compromission, alors l'admin va toujours se connecter en ssh pour étudier la situation, et le module va faire le mort empêchant ainsi sa détection. Si l'admin recharge plusieurs fois la page ou scanne son serveur, il ne verra absolument rien d'anormal.

Conclusion/
Pour pouvoir nettoyer son site, il faut s'assurer de pouvoir s'y connecter. Dans certaines situations les pirates changent les mots de passe. Il faut donc toujours connaître plusieurs moyens d'accès: mot de passe du CMS, mot de passe ftp pour uploader les pages, mot de passe ssh, accès physique à la machine, redirection du DNS vers une autre IP, etc...
Une fois que le code offensif a été corrigé, il reste le plus gros du travail, c'est à dire à trouver comment le pirate est rentré la première fois, sinon il reviendra et vous serez condamné a recevoir un autre email vous prévenant que votre site "a sans doute un problème". Et pour ça, il n'existe pas de solution magique, lire les logs, mettre à jour, tracer les accès, mieux blinder le site, etc...

[update 25/04: quelques cleanup et typos]