Tout d'abord une rapide présentation de ce qu'est le cross site scripting auquel je ferrai référence dans ce billet par XSS :

  • Le XSS c'est le fait d'injecter du code HTML ou javascript non prévu dans une page envoyée par un serveur.
  • Le code est exécuté dans le contexte de sécurité du document envoyé, et l'HTML est interprété.


Une attaque de site XSS nécessite donc trois protagonistes :

  • L'attaquant
  • Un serveur (une application vulnérable)
  • Une victime


Il existe 2 méthodes pour injecter du code :

  1. Le code est stocké par le serveur
  2. Le code est injecté par les paramètres fournis à l'URL

Un CRM, permet à une entreprise (généralement éditeur de logiciels) de fournir une interface de communication via Internet à ses clients pour les demandes d'assistance, le signalement de bugs, et de communiquer avec les équipes de support/développement de l'entreprise fournissant le service.

Chaque utilisateur enregistré dans le CRM est associé à un ou plusieurs projets, lui permettant ainsi de suivre l'évolution des incidents saisis pour les projets dans lesquels il est impliqué. Généralement les personnels des équipes de support ont accès à l'ensemble des projets.

Ma société achète donc un logiciel fourni par la société Acme. Acme fournit à une liste d'utilisateurs restreints un accès au CRM avec une authentification basée sur leur adresse email. Lorsque je me connecte avec mon compte, je n'ai accès qu'à la liste des incidents de ma société ouverts chez Acme.
Pour saisir un nouvel incident, je dispose d'une page web divisée en deux parties : les headers me permettant de définir un degré de sévérité et une priorité pour mon incident. La deuxième partie, est en fait une zone de saisie, comme on en trouve sur tous les forums et blogs pour laisser des commentaires. C'est cette deuxième partie qui retient mon attention, en effet, lorsque dans cette partie je saisie du texte entre des balises HTML, alors l'HTML est interprété.
Par exemple, si je veux insister sur un mot en particulier, et donc le faire apparaître en gras, je saisis : <B>un mot</B>.

Si après enregistrement de l'incident le mot apparaît en gras alors, le comportement du CRM est anormal, les balises HTML ne devraient pas être interprétées.

Vous allez me dire : je peux mettre des mots en gras ... la belle histoire !

Si on regarde la brève description d'une attaque de type XSS ci-dessus, on voit qu'au lieu de mettre de l'HTML je peux mettre du javascript.

Imaginons alors le scénario suivant :

Je me connecte avec mon utilisateur habituel, et j'ouvre un nouvel incident, dans la partie commentaire, au lieu de saisir du texte, je mets un script malveillant, qui me permet par exemple de voler le login et mot de passe de toute personne lisant cet incident (voir mon Proof Of Concept sur Firefox 2.0.5/6 par exemple) et qui envoie par un moyen ou un autre ces identifiants sur un email crée pour cela. Ou à défaut, je peux aussi voler les cookies d'authentification.
Je n'ai plus qu'à attendre, et lorsque un membre de l'équipe support lira mon incident, je recevrai son login et son mot de passe, me donnant ainsi accès en lecture/écriture à l'ensemble des événements saisis dans le CRM (y compris les incidents ouverts par les concurrents de ma société utilisant le même logiciel de Acme).
A partir de là, je peux donc saisir un commentaire bidon dans un des incidents d'un concurrent, afin de récupérer son login et son mot de passe sur le CRM, et une fois effectué, je n'ai plus qu'à faire quelques recherches et, pariant sur le fait que notre utilisateur concurrent utilise le même mot de passe sur le CRM que pour son email, je peux lire les emails de mon concurrent !

Pire : imaginons que ce ne soit pas l'équipe de support ou de dev qui lise mon premier incident, mais l'administrateur du CRM, je n'ai plus qu'à me connecter sur l'interface d'administration du CRM, me créer un utilisateur avec des droits d'administrateur sur tous les projets, effacer les traces de mon attaque initiale en XSS, et je me connecte paisiblement tous les jours pour surveiller les incidents de mes concurrents.
Ensuite, je suis presque certain que le mot de passe administrateur du CRM est identique au mot de passe administrateur ou root du serveur hébergeant le CRM, et que pour des besoins de support, ce serveur héberge sans nul doute un serveur FTP et accepte peut être même les connexions SSH.
... ect.

La suite n'a pour limite que votre imagination et/où vos besoins en terme d'espionnage industriel.
Je vous rassure tout de suite, cette plateforme de blogs n'est pas vulnérable aux attaques en XSS (si si j'ai essayé le premier jour).

Afin de se prémunir de ce genre de désagrément, si vous hébergez dans votre entreprise un outil de CRM, vérifiez qu'il n'interprète pas les balises HTML, faites le test tout simplement.
Si vous êtes client d'un CRM vérifiez que vous ne loguez pas des incidents sur une plateforme vulnérable et si c'est le cas, exigez de votre fournisseur qu'il corrige cette vulnérabilité dans les meilleurs délais.

Have fun !



+-+-+-+-+-+-+-

DISCLAIMER :

Je garanti que je n'ai pas exploité cette faille pour le compte d'aucune entreprise en vue d'une action d'espionnage industriel. Je garanti aussi le caractère non intrusif du proof of concept mis en place sur un CRM . J'ai immédiatement prévenu de cette faille les autorités des entreprises inpactées.

+-+-+-+-+-+-+-

Classe : Input Validation Error

Remote : Yes

Local : No

Published : 02/08/2007 4:37 PM

Updated : 03/08/2007 8:54 AM

Credit : Bertrand Arquilliere is credited with the discovery of this vulnerability.

Vulnerable : CRM from Acme

Not Vulnerable :

+-+-+-+-+-+-+-

Description :

Le CRM de Acme ne sanytize pas correctement les données envoyés par les utilisateurs connectés au CRM, permettant l'injection de code malveillant ou de code HTML lors de la saisie d'un incident. L'attaque permet alors de voler les éléments d'authentification basés sur des cookies, et à partir de là lancer d'autres attaques

+-+-+-+-+-+-+-

Exploit :

Un utilisateur authentifié peut saisir un incident contenant du code malveillant dans le CRM en utilisant son navigateur.

Proof of Concept :

  • Inclure dans une zone de saisie le code suivant : <script>alert("This CRM is vulnerable to XSS attacks")</script>
  • Enregistrer l'incident et l'afficher.

Autre voie d'exploitation :

  • Dans le champ "search" saisir le même texte que ci-dessus : <script>alert("This CRM is vulnerable to XSS attacks")</script>
  • Cliquer sur le bouton Search

+-+-+-+-+-+-+-

Solution :

Je ne suis pas au courant d'un patch fourni par l'éditeur.

+-+-+-+-+-+-+-

Reference :

None

+-+-+-+-+-+-+-

EDITEà 16h15 : Je viens de prévenir l'éditeur du logiciel et lui ai annoncé que je ne rendrais publique cette faille que dans un mois, soit le 03 septembre 2007. j'ai donc supprimé de ce billet toute référence à l'éditeur concerné, remplaçant son nom par Acme.
Je ne manquerai pas de vous tenir informé des réponses/réactions de cet éditeur.