Connect the dots #16: « Protection des applications web »

Mais que veut dire « Tout est contrôlé » ?

1. Chaque utilisateur doit être identifié
2. Chaque accès doit être validé
3. Chaque composant doit être vérifié

 Pour cela nous mettons en œuvre quatre principes: 

1. Le « zéro surface d’attaque« . Nous avons vu des exemples dans les articles précédents. Le but est d’empêcher l’attaquant d’accéder à l’intérieur de notre système d’informations par une compromission initiale, due à la faiblesse exposée d’un de nos postes de travail externes (en télétravail), composant réseau ou serveur.

2. Nous avons également vu dans le cadre du renforcement de la sécurité du télétravail (article #15 de la série connect the dots) que les accès distants devaient être éliminés au profit d’un « proxy filtrant »: « Zéro accès distant », notamment les dispositifs de VPN et les RDP. Cela évitera qu’en cas de piratage d’un poste de travail distant, celui-ci ne serve de « Cheval de Troie » en accédant directement à toutes les ressources qui sont attribuées à cet utilisateur, à travers ses habilitations réseau et systèmes.

3. Nous verrons dans un prochain article qu’une architecture redondante, notamment pour éviter les ruptures et les indisponibilités du service est fondamentale dans notre stratégie. Pour cela nous allons éliminer les SPOF (Single Point Of Failure), c’est à dire que nous allons doubler ou tripler (voire plus) tous les composants qui risquent de lâcher ou qui risquent d’être « inondés » par une attaque en déni de service. Ceci sera également vrai côté télétravailleur où nous allons doubler la manière de se connecter à internet avec un routeur de secours.

4. Parallèlement à tout cela, nous devons renforcer, puis supprimer les « crédentités ouvre tout », c’est-à-dire les combinaisons de login-mot de passe qui donnent accès à l’ensemble des applications et des systèmes pour un utilisateur donné. En rendant « granulaire » l’accès aux applicatifs, on se retrouve devant deux problèmes: La multiplication des login-mots de passe pour un utilisateur, ce qui va entraîner une expérience utilisateur (UX) assez mauvaise. Imaginez que vous ayez à vous identifier cinquante fois par jour à votre système ?! Que se passera-t-il ? Comme tout le monde, vous allez mettre le même mot de passe partout et si possible le plus court et simple à retenir possible. L’autre problème induit est la faiblesse d’une application web ou du serveur qui la supporte, ce qui permettra à l’attaquant de récupérer le mot de passe de l’utilisateur ou d’exploiter une vulnérabilité de ce serveur. 

Nous allons donc nous intéresser ici à la solidité des services web, car ils sont la clef de voute de notre nouvelle stratégie « zéro trust ». Comme pour la « zéro surface d’attaque », nous allons utiliser un outil pour analyser notre site web:

(c) Purplemet.com

(c) Purplemet.com

On voit que notre score médiocre est dû à deux causes: La présence d’une console WordPress visible et accessible depuis Internet, ainsi que qu’un plugin « Lodash » vulnérable par 3 CVE récentes (Common Vulnerability and Exposure):

(Source Clubic.com)

Donc, le premier élément à corriger est la console WordPress accessible depuis internet. C’est très souvent le cas, puisque beaucoup de développements web sont sous-traités à des agences ou des éditeurs qui ont besoin d’accéder à leur CMS (Content Management System), un logiciel qui leur permet de gérer le contenu du site de manière simple avec des modèles et des feuilles de style. Suivons les recommandations de notre outil de diagnostic:

(c) Purplemet.com

Pour cela nous allons tout d’abord « cacher » la console d’administration de manière à éviter que les bots des attaquants ne repèrent son existence. Il existe de nombreux plug-ins référencés par WordPress pour cela:

(source WordPress.com) 

Nous pouvons également restreindre les adresses IP qui accèdent à cette console et limiter le nombre de tentatives de connexion pour empêcher les bots de faire une attaque par brute force, en essayant des millions de mots de passe. On peut également tracer toute modification pour savoir s’il s’agit d’une modification d’un des développeurs depuis son domicile ou bien d’une véritable attaque:

Ici, on a mis en place une adresse fixe avec un reverse proxy sur l’adresse IP de l’admin et également, on a changé son nom, pour ne pas utiliser le compte générique « Admin » et, enfin, on trace tous les changements par l’envoi automatisé d’un e-mail au gestionnaire du site.

Le résultat immédiat est une amélioration de notre score de sécurité:

(c) Purplemet.com

Nous allons maintenant nous intéresser au plugin Lodash qui est vulnérable:

(c) Purplemet.com

Comme souvent, il s’agit d’un problème de patches non appliqués. Autrement dit, une version plus récente du plugin résout les vulnérabilités existantes. Nous sommes en version 4.17.19. La base du NIST nous indique pour l’une des CVE quelles versions de Lodash sont concernées:

(Source nvd.nist.com)

Cette vulnérabilité concerne les versions antérieures à la 4.17.20, donc la notre: 4.17.19. Allons sur le site de Lodash pour voir s’il existe une version plus récente du plugin:

(Source Lodash repository)

En effet, depuis deux mois, la version 4.17.21 de cette librairie Javascript est sortie, et elle corrige les trois vulnérabilités listées par le NIST. « Yapuka » changer le module Lodash par celui-ci ! Attention: Est-ce que ce module fait partie de WordPress auquel cas, est-ce que WordPress continuera à fonctionner avec cette modification de librairie ? Nous n’en savons rien. Il est donc important d’identifier, module par module, lesquels sont utilisés et lesquels ont des dépendances. Cette cartographie des modules vous permettra d’effectuer des mises à jour correctes et d’éviter les crash. Ceci dit, j’ai remarqué que, souvent, les développeurs mettent tous les modules disponibles avec la théorie du « on ne sait jamais, on pourrait en avoir besoin ». Et comme on empile les objets inutiles dans notre cave ou notre garage jusqu’à ce qu’il soit plein, les développeurs ont tendance à empiler les technologies, « au cas où »… Le problème est qu’un attaquant pourrait utiliser n’importe quel plugin vulnérable pour pirater le site, même s’il n’est pas actif ! Voici un exemple avec un site web dont je m’occupe:

Pas moins de douze technologies sont utilisées ici, dont trois librairies Javascript vulnérables:

(c) Purplemet.com

Après avoir contacté les développeurs, ils ont analysé quels modules sont vraiment utilisés et ont supprimé les autres. Ils ont également mis à jour les modules utilisés. Voici le résultat:

(c) Purplemet.com

Plus aucune vulnérabilité n’est présente sur le site, et celui-ci passe du score de « D » (médiocre)  à « A » (le meilleur possible).

(c) Purplemet.com

A noter que le site avait une bonne note jusqu’à la semaine 10, puis certains modules étaient redevenus vulnérables, la correction étant intervenue en semaine 11. Il faut donc suivre chaque site web journalièrement. L’intérêt principal d’un outil de diagnostic par rapport à un pentest (test d’intrusion), ponctuel, est une vision « cinéma » dynamique, au lieu d’une « photo » statique à un instant donné. Au passage, cela permet également, si on effectue une vérification journalière, de se rendre compte si le site est « down ».

Au final on disposera d’un outil de supervision de la sécurité de nos applications web, voici un exemple depuis www.purplemet.com :

(c) Purplemet.com