Aujourd’hui, de plus en plus de services et de réseaux sociaux misent sur les API pour permettre aux utilisateurs une réelle appropriation de leur service et ainsi, récolter un maximum de membres. Le piratage de Twitter n’est en aucun cas lié au « tout-API », mais aux vulnérabilités du could-computing et surtout à la capacité des administrateurs de Twitter de faire confiance à un système vulnérable en soi. D’ailleurs, je ne comprend pas encore pourquoi ils laissent aux yeux de Google (un de leurs concurents) par l’intermédiaire de GoogleDocs des documents confidentiels et extrêmement préjudiciables pour leur entreprise…

Cependant, ce piratage amène à s’intéresser aux services professionnels et amateurs développés en parallèle des sites web 2.0 grâce aux différentes API mises à disposition par les développeurs. Ces derniers présentent de nombreuses vulnérabilités, pas uniquement liées aux vulnérabilités lambda du type XSS permettant le vol de compte des membres. Elles peuvent se transformer être de véritables risques, tant pour les utilisateurs, que pour d’autres sites Internet pouvant par l’intermédiaire du piratage de ces services subir de véritables DDos ou être le relai d’attaques plus pointues.

1. Vulnérabilités

Bref, voilà ce que l’on peut dire sur les types d’attaques dont peuvent être victimes les différents services et ce que cela peut engendrer pour les victimes :

• Vol de session permettant, selon le type de configuration du service, de poster certaines informations à la place de l’internaute. Et peut-être, de pouvoir de fil en aiguille s’identifier totalement sur le site source produisant l’API à la place de l’internaute.

• Attaque MIM, récupération des identifiants. Une large partie des services utilisant les API de certains réseaux sociaux demandent à l’internaute de s’identifier sur leur site – pour pouvoir, par exemple, poster un message à la place de l’internaute automatiquement -. Cependant, ces identifications sur certains services (une majorité) n’utilisent pas un protocole sécurisé -SSL- pour transmettre les identifiants du client vers leur serveur, permettant ainsi l’interception de ces derniers dans un réseau local. Ainsi, cela permet de contourner pour un pirate le https mis en place par certains réseaux sociaux pendant l’identification de leur membre.

• Vulnérabilités lambda des services web Entre SQLi, XXS, CSRF, failles « d’upload », includes locales, injections dans des fichiers etc. Nous pouvons trouver de tout sur les services rattachés aux APIs de certains réseaux sociaux. Ceci permettant de faire un peu ce que l’on veut (ouverture d’un shell, mise en place d’une backdoor sur les différents serveurs, piratage des bases de données etc.). Cependant, les pirates auront – je pense – une attention toute particulière pour backdoorer les mécanismes d’identification des membres afin de récupérer les identifiants de ces derniers. Ils attaqueront – suivant leurs envies – ensuite les sessions des membres sur le réseau social promulguant les API, mais également testeront les mots de passes récoltés sur différents sites où les membres se sont sans doute inscrits ainsi que sur les webmails. D’autres s’amuseront peut-être avec la récupération des identifiants à inonder les services de micro-blogging de messages…

• Hijacking des URLs Cette vulnérabilité pèse surtout sur les shorteners d’URL du type bit.ly ou tinyurl.com. Imaginez ce que peut ressentir un site internet étant pointé par des millions d’URLs potentiellement cliquables plusieurs fois par des utilisateurs. Le problème est à relever et la sécurité des shorteners d’URL est aujourd’hui un point critique auquel il faut faire très attention. D’ailleurs, ce problème est déjà arrivé au service Cligs, re-dirigeant deux millions d’URL vers un seul site… qui n’a pas tardé à tomber. Voir un article à ce sujet ici ou là.

2. Contre-mesures

Les contre-mesures à appliquer sont assez simples pour les utilisateurs de réseaux sociaux, utilisez au minimum des services bâtis sur les API de certains services web, surtout quand ces derniers demandent une identification n’étant pas sécurisée. Il faut aussi essayer de deviner quels services sont susceptibles de garder dans leurs bases de données vos mots de passes en clair (cela est déductible assez facilement, si vous vous inscrivez à un service qui agit régulièrement sur votre Twitter sans votre intervention (transposition de flux RSS etc.)).

Pour ce qui est des développeurs de services reposant sur des API, engager un hacker/pirate/spécialiste (rayez la mention inutile) reste la meilleure solution afin de tester les différentes vulnérabilités qui peuvent siéger dans le système. Après libre à eux de le faire ou non, cependant la qualité de service risque à tout moment de passer à la trappe si des audits de sécurité ne sont pas faits régulièrement sur les différentes sphères du système d’information régissant le webservice. (acteurs, physique, application).

3. Conclusion

Tout comme les plugins pour les CMS, les services utilisant des API de certains sites communautaires répandent leurs vulnérabilités au grès de leurs créations augmentant ainsi les risques de rendre tout un système vulnérable. Cependant, ces vulnérabilités (et c’est là toute la chose) ne se concentrent pas au seul site internet du service utilisant l’API d’un énième site communautaire, mais peuvent être utilisés contre les utilisateurs des sites communautaires et contre d’autres sites internet.

Je pense que Twitter – même si la sécurité n’est pas leur fort – (ou d’autres sites communautaires) devraient avoir le droit de jeter un coup d’oeil sur les sources des scripts et des serveurs sur lesquels reposent les services utilisant leur API. C’est tout de même les utilisateurs du site internet diffusant les API les premiers attaqués. Bref, j’espère que cette petite parenthèse vous à un peu informé sur les risques du « tout-API » même si je n’ai pas énuméré l’intégralité des failles (ce qui est en soit impossible). Je prédis cependant une hausse significative des piratages de comptes utilisateurs par l’intermédiaire de ces services dans les prochains mois. D’ici là, prenez garde à vous ! NIARK :D

Bref, donc tout d’abord, quel matériel choisir ?

Là, question coût, nous n’allons pas acheter quelque chose de très puissant, car il sera principalement réalisé afin de permettre le téléchargement de fichiers (après vous voyez pour la légalité), la mise en place d’un serveur web voire mail si vous le souhaitez. Donc pour faire « bien » à pas cher, vous avez deux choix :

1. Le choix Système-D : Allez acheter sur un site ex : leboncoin.fr un netbook avec un écran cassé, on en trouve de très bons à pas cher 50 à 80 euros avec 1go de Ram, 900hz, entre 4 et 16go de disque dur etc. Ceci est bien car les personnes vendant ce matériel ne savent pas que ce qui compte dans une grande partie des cas, ce n’est pas l’écran, mais bien l’intérieur de la bête.

2. Le choix résonné : Si vous avez un peu d’argent devant vous (environ 200 euros) vous pouvez vous prendre un petit soekris histoire d’être sûr d’avoir du bon matos. Il n’est pas bruyant et consomme rien. Cependant ceux qui sont allergiques aux lignes de commande vont vivre quelques heures de configuration fastidieuses. Ce choix est résonné par rapport à la consommation d’énergie si votre bébé va tourner 7j/7.

Maintenant que vous avez le matériel, où l’installer ? Là vous avez plusieurs possibilités et tout dépend là aussi de la chaleur qu’il dégage. J’ai fait des tests dans plusieurs endroits aussi atypiques les uns que les autres et ce qui en ressort c’est qu’un petit serveur comme vous allez faire n’a pas besoin d’une chambre froide afin de fonctionner non-stop. Cependant, j’ai testé la méthode dans le frigo et cela s’avère un assez bonne alternative :) (si vous n’avez pas de légumes/fruits/etc dedans).

Et le web fut !

Pour ce qui est de la connectivité, oubliez le WIFI et préférez le filaire cela permettra d’avoir moins de problèmes de paramétrage au cas où le serveur redémarre ou si le wifi merdoy. Une chose est sûre, les câbles, malgré ce que l’on en dit, ont encore de beaux jours devant eux ! Le raccordement à la box fait, sécurisez cette dernière, mettez un mot de passe d’accès si cela n’est pas déjà fait. Activez l’IP forwarding vers l’adresse IP statique de votre serveur en question à partir de la console d’administration. Pourquoi mettre un mot de passe ? Tout simplement pour éviter les attaques CSRF, mais aussi (et surtout) éviter que l’on ait accès à son administration si votre serveur est éteint.

Ceci fait, tous les flux entrants par le(s) port(s) que vous avez désignés vont être aiguillés vers votre serveur (Cool, non ? Non ? Bon d’accord…) Maintenant vous n’avez plus qu’à installer votre petite solution LAMP sur votre serveur et les différents services que vous voulez. N’oubliez pas d’activer les virtual hosts sur Apache si vous avez fait pointer des noms de domaines sur votre BOX.

La sécurité avant tout !

Passons maintenant à la sécurité du serveur, car il faut bien le dire, un serveur non implanté dans une DMZ présente un vrai risque pour la sécurité du réseau et la confidentialité des informations transférées sur ce dernier. Donc il faut absolument le sécuriser de toutes parts. Tout d’abord, contre le fingerprinting actif et passif. Il faut pour cela changer le TTL de Linux pour faire croire aux différents scanners que c’est Windows qui est sur la machine (on on change le TTL de 64 en 128) (les scanners ne se basent pas que sur le ttl pour déduire les version des Os, mais c’est une méthode, et autant la brouiller), on change aussi les différents bandeaux des différentes applications telles que SSH, Apache et autres trucs comme cela. Moins l’attaquant en sait sur le système visé depuis l’extérieur mieux c’est pour vos fesses ! (d’ailleurs documentez-vous sur ce petit soft bien sympa : IP personnality, même s’il est pour les 2.4, la doc est assez sympa histoire de voir comment cela fonctionne…). Il y a aussi ce petit lien avec quelques logiciels du même type.

Ceci fait, il nous faut changer quelques configurations par défaut, tout d’abord, SSH. On enlève la possibilité de login en Root à distance sur le système, on change le port par défaut du service histoire de ne pas être attaqué par des Boots où des SK. Ensuite on va configurer un petit utilitaire afin de détecter la moindre tentative manquée de connexion à différents services, cet utilitaire est connu et bien sympa. Surtout si on le couple à un service d’envoi d’SMS pour avec un temps de réponse post-attaque rapide. Son nom : fail2ban. Et oui, on ne change pas une équipe qui gagne ! Bon pour la documentation direction ICI où tout y est très bien expliqué. Amusez-vous avec IP tables afin de dropper les paquets qui sont méchant, pour cela, il existe des tonnes de ressources sur Internet donc je vous fait confiance.

Vous pouvez aussi envisager une solution de port knocking afin de gérer les ports dynamiquement, cette solution permet beaucoup de choses, et surtout réduit considérablement les logs de tentatives d’attaques :)

Il faut aussi créer un utilisateur dans un espace confiné, afin d’emprisonner le pirate dès l’obtention d’un shell d’attaque sur un processus utilisé par cet utilisateur. La technique s’appelle le chroot et est difficile à mettre en place si on ne l’a pas fait trente six mille fois sur différents logiciels (moi aussi j’ai encore du mal à chrooter). Au programme, récupération des librairies utiles au logiciel, création de l’espace restreint dans un répertoire à la racine et emprisonnement des processus. Vous pouvez le faire, ou pas. Si vous ne voulez pas passer par cette tâche longue et fastidieuse, vous pouvez désactiver pour les utilisateurs autres que le root les programmes utiles au pirate en tant d’attaque tels que wget, gcc, python, cURL, vim, nano, pico etc. afin qu’il ait beaucoup de mal à devenir root sur votre machine (chmod 700). On peut aussi, afin qu’il ne s’amuse pas à essayer d’entrevoir la topologie de notre réseau chmoder les ifconfig, ping etc. Vous pouvez aussi vous amuser avec le petit tool de la NSA dénommé SElinux perrmettant de mettre des droits pour des processus à des fichiers pécis, et cela, un Linux standard ne le fait pas ! :D Cela devient très vite utile en cas d’attaque. Voir plus d’infos ici ou sur Google ;)

Enfin, pour la configuration du serveur (apache, php etc.) désactivez tout ce qui peut permettre l’identification là aussi des versions utilisés, donc direction tout d’abord httpd.conf et désactivez les signatures du serveur. Vérifiez que la valeur expose_php dans le php.ini est à off, si elle ne l’est pas, mettez-là ! En ce qui concerne aussi le php.ini, mettez le safe_mod sur on, les magic_quotes aussi, modifier l’open base dir et mettez allow_url_fopen sur Off. Désactivez de plus certaines fonctions qui sont pas très très sympa… Ne laissez jamais MySQL s’exécuter avec l’utilisateur root de ce dernier, créez des utilisateurs avec des droits restreint afin de ne pas aller vers la catastrophe. Par ailleurs, mettez en place un petit IDS codé en PHP sur votre site dynamique afin de voir s’il est la cible d’attaques… (voir PHPIDS, même si à ma grande surprise, il ne contre pas certaines attaques que mon IDS php à moi détecte… :D)

Et maintenant ?

Et bien, si vous avez tout fait et que vous arrivez encore à lire ces lignes, je dois dire bravo ! Il ne vous reste plus qu’à veiller sur les mises à jour de votre système, de créer un Cron qui exportera vos logs (mysql/apache/acces/ssh) toutes les semaines vers une adresse mail mise en place pour l’occasion afin d’entrevoir des tentatives d’attaque qui seraient passées entre les mailles du filet. On peut aussi s’amuser à envoyer des mails ou des SMS, mais ceci est une autre histoire. Veillez à faire un rkhunter avec Cron quelques fois afin de voir s’il n’y a pas de rootkits sur le système et… voilà !

Désolé si cet article manque de références ou n’est pas complet, j’ai écrit cela – un peu – à l’arrache aujourd’hui et je ne vais pas aller chercher des références si j’en n’ai pas pris pour le réaliser. La prochaine fois, j’essayerai de faire quelque chose de plus « pro ».