WebGoat - Primera parte

Durante esta semana hemos estado trabajando intensamente con la aplicación web WebGoat para conocer y estudiar las 10 vulnerabilidades web más explotadas en Internet. WebGoat ha sido actualizado recientemente según OWASP Top 10 donde se han implementado las 10 vulnerabilidades más conocidas, explotadas y peligrosas de estos últimos años. Por tanto, en este articulo, y en el siguiente, mostraremos un video de cómo podemos explotar cada una de las 10 vulnerabilidades de OWASP Top 10 con la finalidad de aprender, estudiarlas, y luego poder probarlas en proyectos de pentesting.

 

Admin lost password: En este ejemplo veremos los peligros de permitir que los usuarios recuperen sus contraseñas de administrador en una aplicación web. Este problema se debe a que el sistema no impone medidas adecuadas para proteger la recuperación de contraseñas de la cuenta de administrador, lo que permite que un atacante pueda acceder a la cuenta de administrador y obtener acceso no autorizado a la aplicación y a los datos que maneja.

Authentication Bypass: En este ejemplo veremos como un atacante puede sortear la autenticación y obtener acceso no autorizado a los recursos protegidos. Esto puede ocurrir debido a una variedad de factores, como la falta de validación de entrada adecuada, la gestión incorrecta de sesiones y cookies, o la implementación débil de políticas de autenticación y autorización.

 

Bypass front-end restrictions: En este ejemplo veremos una situación en la que las restricciones de seguridad impuestas por el front-end de una aplicación web pueden ser fácilmente eludidas por un atacante. El front-end de una aplicación web se refiere a la parte visible e interactiva de la aplicación que los usuarios interactúan directamente con ella. En muchos casos, el front-end se utiliza para imponer restricciones de seguridad, como limitar las opciones disponibles en un menú o evitar que los usuarios accedan a ciertas funciones o datos.

 

HTML tampering: En este ejemplo veremos una situación en la que un atacante puede modificar el código HTML de una página web, lo que podría permitirle realizar diversas actividades maliciosas. Un atacante podría, por ejemplo, cambiar el valor de un campo oculto en un formulario web para enviar información falsa al servidor. También podría modificar la apariencia de una página web para engañar a los usuarios y obtener información confidencial. Además, un atacante podría utilizar HTML tampering para insertar código malicioso en una página web, como un script que envía información a un servidor controlado por el atacante.

 

Espero que os haya gustado.

Autor : Miguel Sánchez Suárez

F5XC - AntiBot avancé

J'ai déjà écrit plusieurs fois sur F5XC – Bot Defense, F5 ASM – Bot Defense et F5 BIG-IP ASM – Bot Protection mais cette fois je veux écrire sur l'intégration de F5XC Bot Defense et BIG-IP où il faudra configurer une iApp, ou un profil Bot Defense, pour relier nos équipements BIG-IP à la technologie AntiBot hébergée dans les services cloud F5. Pour réaliser l'intégration de BIG-IP avec F5XC Bot Defense, il sera nécessaire d'insérer un code JavaScript dans nos services Web.

Où peut-on insérer le code JavaScript pour pouvoir consommer la protection Bot Defense ? Le tableau suivant montre clairement où le code JavaScript peut être inséré. Je vais principalement écrire aujourd'hui comment le faire depuis un BIG-IP, c'est-à-dire depuis n'importe quel BIG-IP, et pas seulement depuis F5 AWAF ou les nouvelles versions de BIG-IP. Cependant, il peut également être inséré à partir d'autres points tels que F5XC WAAP ou depuis NGINX, Salesforce Commerce, Cloudflare, Adobe Commerce et AWS CloudFront. Il existe donc des connecteurs pour pouvoir intégrer la technologie AntiBot de F5 dans toutes ces plateformes.

 

F5XC Bot Defense - Connecteurs

Si nous avons travaillé avec F5XC ou Shape, nous savons que nous devons insérer un code JavaScript. Traditionnellement, nous avons fait l'insertion de ce JavaScript à travers une iApp développée par F5 où un ensemble de paramètres doit être configuré, le plus important étant : l'endroit où nous voulons injecter le JavaScript, quels domaines nous allons protéger et quel type d'action est ce que nous allons faire une fois que nous détectons que la demande, ou la tentative d'accès, provient d'un bot ou d'un utilisateur humain. Nous devrons également indiquer dans l'iApp à quel serveur virtuel nous voulons appliquer la protection AntiBot. Nous allons également avoir un identifiant d'application qui est utilisé pour établir un lien avec le service F5XC.

 

F5XC Bot Defense iApp

Le déploiement et la configuration de l'iApp Bot Defense étaient requis dans les versions antérieures à 17.1. Cependant, actuellement les nouvelles versions intègrent déjà un connecteur natif pour relier nos équipements BIG-IP avec F5XC. Par conséquent, à partir de la version 17.1, le module natif remplit les fonctions de l'iApp Bot Defense où vous pouvez configurer des profils spécifiques avec les données d'identification de l'application, les domaines à protéger et les actions à effectuer. Ces profils F5XC Bot Defense seront attribués ultérieurement aux serveurs virtuels.

 

F5 BIG-IP - Distributed Cloud Services

Le code JavaScript actuellement inséré est composé de deux codes JavaScript, alors que dans les versions précédentes, il s'agissait de trois codes JavaScript. Ce JavaScript a un code complexe pour empêcher l'ingénierie inverse. Dans les versions actuelles, un code JavaScript appelle l'autre code JavaScript. Les codes JavaScript sont insérés par défaut dans toutes les pages Web car c'est le plus simple et c'est pratique, mais vous pouvez également spécifier où nous voulons l'insérer si nous pensons qu'il n'est pas nécessaire de l'insérer dans toutes les pages. Normalement, bien que nous insérions le code JavaScript dans toutes les pages, nous n'en protégerons que certaines, comme les pages de connexion ou de création d'utilisateur. Dans l'image suivante, nous pouvons voir que l'insertion a été faite après la balise <head>.

 

JavaScript

Enfin, F5XC Bot Defense est un produit qui est servi à partir du cloud F5. Par conséquent, tous les panneaux de contrôle d'où nous allons voir les attaques sont dans F5XC, toute la télémétrie collectée est envoyée à F5XC et c'est là que nous devons nous connecter pour la voir. L'ensemble du service Bot Defense est basé sur le cloud F5XC. Bot Defense est un outil qui demande peu de gestion. Une fois que nous l'avons lié aux services que nous voulons protéger, nous n'avons rien à faire car Bot Defense est chargé d'identifier ce qui est bon et ce qui est mauvais.

Comment votre entreprise détecte-t-elle les bots ?

Fortinet ZTA

Récemment, j'ai écrit sur ZTNA, l'architecture ZTNA et la configuration ZTNA. Cependant, il ne faut pas confondre ZTNA avec ZTA. ZTA gère l'accès aux ressources internes, c'est-à-dire l'accès au réseau via la couche d'accès, comme un réseau filaire ou un réseau sans fil. Comme ZTNA, ZTA a une architecture Zero Trust. Premièrement, il va identifier et découvrir tout ce qui se trouve sur le réseau, c'est-à-dire qu'il saura quels utilisateurs sont connectés. Par la suite, la connectivité sera fournie en fonction de l'utilisateur, du type d'appareil et de la posture de sécurité de l'équipement, et les appareils qui ne respectent pas la posture de sécurité ou qui ne sont tout simplement pas enregistrés seront également isolés. Enfin, tout type de faille de sécurité sera identifié et une réaction automatique sera effectuée, isolant les appareils pour minimiser l'impact.

Grâce à Security Fabric, il sera possible d'effectuer des contrôles de risques continus sur les appareils pour vérifier s'ils sont toujours conformes à la politique de sécurité. ZTA peut être intégré à FortiClient, qui peut déjà effectuer des contrôles de sécurité s'il appartient à une architecture ZTNA, ou il peut également être intégré à des tiers, tels que le logiciel EDR, qui peuvent signaler ou donner de la visibilité à tout événement de sécurité en cours, effectué au sein de l'appareil.

 

Dans une architecture ZTA, deux validations sont effectuées. La première est une validation de pré-connexion dans laquelle l'utilisateur est vérifié, quel type d'appareil se connecte, quelle application, à quelle heure de la journée et où la connexion a lieu. Ces informations sont vérifiées par rapport à la politique de conformité du réseau pour automatiser l'accès via SDN en fonction du degré de confiance dans cet appareil.

Validation avant connexion

Une fois l'appareil connecté au réseau, une gestion des risques post-connexion est effectuée pour analyser en continu tous les appareils. Le but est de répondre immédiatement aux événements de sécurité qui peuvent être signalés par tout équipement connecté au réseau.

 

Évaluation des risques après connexion

Par exemple, lorsqu'un appareil compromis est connecté au réseau et établit des connexions avec un serveur Command & Control, l'appel sera bloqué par tout élément de sécurité tel que FortiGate. Le pare-feu informera FortiNAC et FortiNAC isolera automatiquement l'appareil compromis pour l'empêcher d'être une menace pour l'organisation. De cette manière, le temps nécessaire pour contenir la menace est considérablement réduit.

 

Réponse aux incidents

Enfin, la capacité de l'appareil à s'intégrer à l'ensemble de l'architecture ZTA lui permet de s'adapter dynamiquement aux circonstances de chacune des connexions. Par exemple, un utilisateur qui appartient à un certain groupe peut changer de groupe et obtiendra dynamiquement les autorisations du nouveau groupe sur le réseau.

 

Segmentation basée sur le groupe

Envisagez-vous de déployer ZTNA ou ZTA ?

Fortinet ZTNA - Configuration

Réaliser une configuration ZTNA dans Fortinet est très simple. Il s'agit d'une configuration très similaire à la configuration d'une publication de service avec des VIP dans FortiGate. Nous allons devoir publier différents serveurs ZTNA sur une ou plusieurs adresses IP, généralement des adresses IP publiques, via une configuration qui se trouve toujours dans la section Policy & Objects → ZTNA et qui sera disponible sur les appareils disposant d'une version de FortiOS 7.0 ou supérieur.

 

Serveurs ZTNA

Lorsque nous configurons un serveur ZTNA, nous devrons faire une association du serveur ZTNA avec les serveurs où se trouve l'application dans le réseau de l'entreprise. Vous pouvez également définir différents certificats SSL pour les services qui sont présentés au client. Vous pouvez également définir quels serveurs réels seront actifs et lesquels ne le seront pas, c'est-à-dire que vous pouvez configurer un équilibrage des serveurs en haute disponibilité active/passive des services ZTNA.

 

ZTNA - Mappage de serveur

Généralement, il y a une question qui est posée de manière récurrente : est-ce qu'une adresse IP publique est nécessaire pour chaque service que nous voulons "publier" via ZTNA ? La réponse est très simple. Non. Avec une seule adresse IP publique, nous pouvons configurer une multitude de services ZTNA. La différenciation peut être effectuée sur la base de l'en-tête Host du protocole HTTP, bien que le service puisse également être différencié via l'URL. Cependant, lorsque nous avons plusieurs services ZTNA avec des noms de domaine différents, il est important que la résolution DNS se fasse toujours sur le même VIP. Par conséquent, FortiGate redirigera les demandes de différents services ZTNA vers les serveurs d'applications réels correspondants. De même, différents ports TCP peuvent être utilisés pour différencier les services ZTNA.

 

Deux services mais une adresse IP unique

Une fois les services ZTNA sont configurés, il est nécessaire de définir les règles ou politiques ZTNA. Dans les règles, nous définirons qui et dans quelles conditions peuvent accéder aux services, c'est-à-dire que les règles ZTNA définissent l'autorisation et le respect de la posture de sécurité. Par conséquent, lorsque l'équipement est autorisé et que l'utilisateur est authentifié, et respecte également les mesures de sécurité, il pourra accéder aux ressources qui ont été définies dans la règle ZTNA.

 

Règle ZTNA

Oserez-vous faire une configuration ZTNA ?