DIGITEMIS découvre une vulnérabilité au sein d’un produit StormShield [CVE-2020-11711]

DIGITEMIS a découvert une vulnérabilité produit StormShield [CVE-2020-11711]. Stormshield Network Security (SNS) est une solution de protection des réseaux (pare-feu). Le produit SNS a également été certifié sur les critères communs EAL4+ fin 2016. La dernière génération (v4) du produit SNS est disponible depuis fin 2019.

stormshield vulnérabilité CVE-2020-8430

Découverte et Exploitation

L’équipe test d’intrusion de DIGITEMIS a découvert une vulnérabilité produit StormShield [CVE-2020-11711] au sein des produits SNS 3.6 à 3.10 et 4.0.0 à 4.0.4.
Un attaquant disposant d’un accès administrateur sur le SNS peut forger une clause de non-responsabilité malveillante. Il en résulte une exécution de code JavaScript persistante sans interaction utilisateur sur l’interface d’authentification du panel d’administration.

Par ce biais, il pourra maintenir son accès sur le panel d’administration du SNS. Il est également possible de dérober des identifiants du portail VPN SSL si l’administrateur a enregistré ses derniers dans le navigateur pour se reconnecter plus rapidement.

Cette vulnérabilité à été référencée CVE-2020-11711 par le MITRE.

Correctifs

L’éditeur a publié un correctif sur les versions 3.7.13, 3.11.0 et 4.1.1. Il est donc recommandé de mettre à jour ces systèmes. Le bulletin de sécurité édité par DIGITEMIS peut être téléchargé ci-dessous :

https://www.digitemis.com/wp-content/uploads/2020/11/20201026_CGA_StormShield_SNS_Build_3.8.0_StoredXSS_v1.0_article_Romain.pdf

Je partage

Derniers articles

Analyse des Métriques XSS : comprendre l’Impact des injections de code côté client

Lors des tests d’intrusion, l’injection de code côté client est généralement plus aisée à découvrir qu’une injection côté serveur. Le nombre de paramètres dynamiques transitant du back au front, la difficulté d’échapper correctement à l’entrée et à la sortie et la multitude d’encodage liés à l’affichage peuvent être des vrais casse-têtes pour qui souhaite faire la chasse à la XSS. Le JavaScript malveillant semble ainsi avoir de beaux jours devant lui. Cependant, il n’est pas rare qu’à l’issu de l’audit, la criticité d’une telle injection découle directement de la configuration des cookies présents sur l’application. En effet, l’absence de l’attribut HttpOnly majore irrémédiablement les risques liés à ce type d’attaque. Néanmoins, cela signifie-t-il que la présence de cet attribut doive absolument amenuiser la criticité d’une injection ?

Lire l'article

Angular, N’Tier et HttpOnly

Avec l’apparition au cours de la décennie 2010 des environnements de travail Javascript de plus en plus puissants, l’architecture N’Tiers, si elle était déjà une norme dans le contexte d’application d’entreprises au cours des années 2000, a pu voir son modèle s’étendre à de nombreuses solutions Web. Ce modèle repose sur l’utilisation de technologies exécutées par le navigateur. Or, il arrive parfois que cette couche doive gérer une partie de l’authentification de l’utilisateur, pourtant une recommandation courante sur l’authentification est qu’elle ne doit jamais être côté client. Aussi, les cookies devraient toujours posséder l’attribut HttpOnly, empêchant leur lecture par une couche Javascript et ce afin d’empêcher tout vol de session lors d’une attaque de type XSS. Pourtant, cet attribut empêche littéralement l’application front-end de travailler avec ces éléments. Comment gérer au mieux ces questions sur ce type de déploiement ?

Lire l'article