[Blink - partie 5] Scanner de vulnérabilités et conclusions du dossier

Par Redaction, secuobs.com
Le 06/09/2006

---

Résumé : Avec un scanner de vulnérabilités interne qui permet d’effectuer des tests intrusifs locaux (uniquement), Blink est une solution à la fois professionnelle et accessible qui propose un niveau de sécurité relativement élevé. - Lire l'article



Le scanner de vulnérabilités locales provient du scanner eEye Retina. Il permet d’effectuer des tests intrusifs locaux. Des rapports et « fixes » sont proposés pour les faiblesses ou failles recensées.

Dans ce mode de fonctionnement, aucune comparaison ne pourrait être faite avec Nessus ( lien ), le très populaire scanner de la société Tenable Network Security sur lequel est notamment basé le service Exoscan de Secuobs.

Leurs approches sont relativement différentes : ce « Retina light » est orienté « utilisateur », tandis que Nessus (bien que proposant des local checks qui peuvent s’approcher des fonctionnalités présentées) a une vocation bien plus technique, permettant d’être un meilleur candidat pour les approches de pen-tests (tests d’intrusion) : il fournit de nombreuses fonctionnalités techniques avancées et des rapports plus détaillés de ce point de vue.



Figure 35 : Interface des scans locaux


Les rapports générés sont visuellement très soignés et peuvent être lus par des utilisateurs non avertis. La base de vulnérabilités est synchronisée régulièrement. Plusieurs logiciels tiers sont également recensés (Winzip, Winamp, etc.).

Les vulnérabilités propres à l’OS sont bien évidemment toutes présentes dans le rapport. Les défauts de configuration apparaissent également, tels que les comptes non utilisés, comportant des mots de passe faibles ou trop peu fréquemment renouvelés, les renforcements tels que les limitations sur les mots de passe erronés.

En suivant point par point les recommandations fournies par le rapport, il est possible de ;

- Désactiver la plupart des services Windows par défaut et non utilisés ;
- Désactiver les null sessions ;
- Désactiver les caches locaux des mots de passe de domaine ;
- Désactiver les accès anonymes à la base de registre ;
- Etc.

Ces « alertes », une fois corrigées, peuvent être vérifiées à l’aide d’un nouveau scan sur la même machine. Il est possible, à tout moment, de consulter le rapport du dernier scan effectué.



Figure 36 : Rapport de vulnérabilités locales (1)



Figure 37 : Rapport de vulnérabilités locales (2)


Blink est une solution à la fois professionnelle et accessible qui propose un niveau de sécurité relativement élevé. Attention cependant à ne pas tomber dans le stéréotype classique : Blink ne saurait en aucun cas remplacer des solutions complémentaires classiques et les précautions indispensables (y compris humaines…).

Nous avons réellement apprécié le produit Blink et ses nombreuses fonctionnalités, mais il existera toujours des moyens de contournements, particulièrement sur des schémas d’attaques ciblées et motivées.

Lors des tests menés sur Blink, nous avons utilisé une backdoor s'exécutant sous forme de thread injecté dans le(s) processus navigateur(s) via l'outil WiShMaster de Benjamin Caillat (dossier prochainement disponible sur Secuobs).

Le principe consiste à lancer une instance « cachée » du navigateur par défaut (la plupart du temps autorisée à sortir à destination du port TCP/80) et d’y injecter un thread contenant le payload. Il s’agit dans notre exemple d’un payload en connect back :

- Un serveur écoute sur le port 80 et se met en attente de la connexion du payload distant ;
- Une fois la connexion initiée, un shell est exécuté côté client.

Pour résumer, l’idée est donc de leurrer Blink en injectant dans un processus autorisé un payload du type connect back sur le port 80 permettant de lancer sur la machine distante un shell. Le choix se tourne vers le navigateur Internet par défaut… Que ferait-on sans Web…

Avec le module « Firewall applicatif » activé ainsi que le « firewall système », l’IPS désactivé, ainsi que la protection applicative désactivée, l’attaque est concluante et le shell s’exécute normalement sur la machine distante :



Figure 38 : Récupération d'un shell MS à l'aide d'un payload de connect back sur le port 80


En revanche, l’alerte est effectivement remontée quand l’IPS est activé car le flux sortant sur le port TCP/80 n’est pas du trafic HTTP. Cette protection se contournera donc simplement en encapsulant le flux sortant en HTTP (voire HTTPS).

L’IPS détecte en effet une communication qui ne semble pas être de type Web à destination du port 80 d’un serveur :



Figure 39 : Blocage du flux (trafic non HTTP vers TCP/80)


En revanche, la protection applicative bloquera l’exécution détectant l’appel système LoadLibraryA :



Figure 40 : Blocage de l'appel système LoadLibraryA


Blink s’est montré fiable et complet lors de nos tests, mais il est nécessaire de rappeler, encore une fois, que la sécurité doit faire partie d’un contexte, et qu’un élément seul ne saurait garantir une « sécurité à 100% » comme le laissent entendre certains discours Marketing.


Autres ressources dans ce dossier :

[Blink - partie 1] Présentation, installation et mises à jour - lien
[Blink - partie 2] Configuration du filtrage réseau & du filtrage applicatif - lien
[Blink - partie 3] Protection contre le phising & Système de Détection d'intrusion - lien
[Blink - partie 4] Protection applicative, anti-spyware & journalisation - lien