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]

300 Gigabits par seconde, c'est beaucoup pour un DDOS?

Vous n'avez pas du y échapper dans les news, CloudFlare indique qu'une attaque en DDOS a dépassé les 300Gbit/s. Certains sites reprennent l'information en expliquant qu'internet était au bord de la rupture, accusant durement ce pic d'activité à 300Gb/s. Je ne suis pas vraiment d'accord sur le fait qu'Internet était au bord de la catastrophe.

Je trouve intéressant de replacer ces chiffres dans le contexte.
300Gb/s, pour un particulier comme moi, c'est juste énorme. J'ai une connexion ADSL 20Mbit/s. L'attaque est 15000 fois supérieure à mes capacités d'absorption. Je peux acheter un serveur chez un hébergeur avec une carte réseau Gigabit. C'est mieux, mais une attaque de cette ampleur est encore 300 fois supérieur a ce ce que je peux encaisser. Je peux multiplier mes serveurs, mais mon hébergeur peut-il traiter 300Gbps?

Intéressons-nous aux hébergeurs. Si je lis les plaquettes d'OVH, je vois qu'il permet d'échanger 500Gbps. OVH est donc capable d'absorber ces 300Gbps, même si je pense que le reste du réseau OVH risque de le sentir.
Et pour les autres hébergeurs, c'est encore plus gros. Si je prends de-cix, on a un graphe qui montre que 2.5Tb/s sont routés sans problème. Pour eux, une attaque qui transite à 300Gbps, l'impact est quasi-nul. Et pour CloudFlare, qui explique avoir décentralisé ses serveurs et multiplié les points d'accès au plus près des Tier-1, alors 300Gbps est raisonnable.

Moralité, l'Internet ne va pas s'écrouler car un DDOS à 300Gbps a lieu.
Si vous êtes la cible, cela ressemble à un ouragan. Si vous êtes internet, alors c'est une légère brise.

TCP/IP security is boring : Second strike

Il y a trois ans j'écrivais une article intitulé "TCP/IP security is boring".
Résumé rapide: En juin 2010, pendant le SSTIC, Harald Welte indiquait avoir quitté le monde de la sécurité TCP/IP en tant qu'auteur iptables car "TCP/IP security is boring" afin d'écrire OsmocomBB. En 2010, je remarquais que la sécurité TCP/IP était vraiment la portion congrue de la sécurité.
Si on regarde le programme du SSTIC 2013, rien sur le réseau. 2012, une conf réseau sur le suivi malveillant de connexions (intéressante mais limité au premier "HOP" du firewall) et une conf sur l'analyse de protocoles (netzob). 2011, pas grand chose non plus.

RSA 2013 vient de terminer, et Adi Shamir (le 'S' de RSA) conclut qu'aujourd'hui la cryptographie ne protège plus, ou tout du moins que son importance est faible. La raison: à quoi cela sert de chiffrer lorsque l'attaquant est administrateur de vos machines, qu'il a accès à la version en clair des documents ainsi qu'à la clé de déchiffrement? La question est bien réelle.
Je vais faire une analogie. Lorsque l'on veut traverser facilement une chaine de montagnes, on regarde le col le plus bas afin de minimiser les efforts. Les attaques informatiques sont basées sur la même idée. A quoi bon casser du RSA (AES, etc..) alors qu'on peut aller chercher le document en clair? Et aujourd'hui ou sont les cols les plus bas? Il existe quelques marronniers comme le pdf, flash et depuis peu Java. Mais il y en a un autre qu'on oublie et qui perdure depuis longtemps: où est la sécurité du réseau? On trouve toujours une petite ligne dans les compte-rendus d'APT indiquant que les auteurs ont fait un effort pour contourner l'antivirus, mais on entend même pas parler du réseau, sous-entendu qu'il est évident de pouvoir piloter à distance des machines dans des réseaux (soit-disant) protégés(!).

Si je lis l'Edito de MISC 66 (mais je n'ai pas encore lu le dossier sur le BYOD) on peut trouver ces lignes qui suivent la prise de conscience des éditeurs de logiciels qui sécurisent de plus en plus leurs développements: "(...)Cette réflexion et les changements du monde de l'édition logicielle ne pourraient-ils se produire pour l'architecture des réseaux ? Ça passe par un changement de mentalité, par imaginer de nouvelles approches. Et les gens qui sont la tête dans le guidon n'ont pas forcément le temps de s'en préoccuper, quand il faut déjà faire marcher le réseau pour que le PDG puisse consulter ses mails depuis n'importe où.(...)En attendant, côté réseau, la réponse est toujours la même : empiler des équipements. Et les équipes ne changent pas plus, toujours en sous-effectif, avec de plus en plus de missions à remplir avec de moins en moins de moyens. Et bizarrement, les effets sont toujours les mêmes : les attaques passent."

Pour connaître un peu le monde du firewall, je confirme bien cette vision. J'ai vu quantité de configurations de firewall en mode masquerading: on masque le réseau privé en sortie, et on NAT les 3-4 ports vers les serveurs de la DMZ. Sécurité: néant. Et lorsque la sécurité bloque une fonctionnalité, le choix porte immédiatement sur le rétablissement de la fonctionnalité au détriment de la sécurité. A croire qu'un firewall, c'est comme un antivirus sur un windows. Il faut en mettre un pour se conformer aux "bonnes practices", mais on sait tous que ça ne sert à rien, et que c'est agaçant donc on désactive un maximum de fonctionnalités à commencer par les alertes. Un autre exemple: actuellement, on entend beaucoup parler du firewall PaloAlto. Très beau, très fonctionnel, plein de trucs qui permettent un management du réseau efficace comme bloquer twitter, ou réserver 20% de la BP à facebook et qui pond des rapports très élégants. La sécurité? Quelle sécurité? Checkpoint résume bien son état: il n'y en pas. C'est un outil de management de réseau, mais il est pris comme un outil de sécurité (on appelle ça un Firewall Next-Gen!), et les APT continueront de passer..

Que faire? Le firewall bien géré, administré par des gars compétents, avec des logs surveillés serait la solution? C'est sans doute un premier pas. Il reste le BYOD, la dépérimétrisation, et les réseaux qui "bavent" à l'extérieur comme le Wifi et la 3G/4G. Pour le wifi, ça s'arrange, mais pour l'iPad branché sur le PC de bureau pour le recharger, quel équipement installer? Mettre un osmocomBB et forcer les connexions vers lui pour filtrer tout ça?
Une autre solution serait-elle de mettre QubesOS partout et considérer le réseau 'broken beyond fixing'? Ou encore, laisser le réseau à une équipe de management de réseau, et ne faire que du network/analysis forensics? Puisque les machines seront attaquées et qu'on sait qu'on ne l'empêchera pas, autant le prendre en compte, mais se doter d'une analyse pour être capable de remonter très vite à l'infection initiale. J'aime bien les idées de Damballa à ce sujet. Une autre manière de voir le réseau afin de détecter des menaces.

Pour terminer sur une note un peu plus concrète, vous l'aurez compris le programme du SSTIC est paru. Je ne sais toujours pas si je pourrais y aller cette année (pour un premier problème simple: je n'ai pas de carte bleue pour acheter le billet), mais beaucoup de conférences m'intéressent à commencer par celle sur l'USB (j'ai une note en préparation depuis au moins 18 mois là dessus). Le challenge SSTIC 2013 ne devrait pas tarder non plus, j'ai cru entendre qu'il serait à base de sécurisation de wiki, de gif animés et de bières ;)