Fuite d'informations par un CRM (Cross Site Scripting / XSS)

J'ai découvert hier une faille dans un logiciel de CRM (Customer Relation Ship Management) basée sur du Cross Site Scripting (XSS ou CSS).
Pour des infos sur le CRM, je vous invite à lire le billet de Lionel ICI.

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.
Le CRM qui m'intéresse aujourd'hui est celui de TechExcel.
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>.
Ce 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) 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 quelques heures, 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 dout 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, vérifiez que votre outil de CRM 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 !