Outil Securite

Lors des campagnes de sensibilisation, NES Conseil est souvent confronté à la mise en place de démonstrations d’attaques WiFi pour que les utilisateurs prennent la mesure des dangers qui peuvent les affecter lors de l’utilisation de réseaux WiFi inconnus / publics / malveillants.

J’ai donc décidé d’assembler une plateforme modulaire qui tiens dans une mallette et qui soit évolutive pour pouvoir réaliser des attaques WiFi, simplement en alimentant la mallette. Je vais vous détailler la conception du Mineur sans fil qui est présenté lors de la conférence Secu’RT du 1er Mars 2018 à l’IUT de Montbéliard.

Attardons nous quelques instants sur la vulnérabilité majeure découverte dans OpenSSL et qui occupe massivement le devant de la scène de la sécurité informatique depuis le début de la semaine. OpenSSL est une bibliothèque logicielle sur laquelle sont basés nombre de composants serveurs utilisant des communications sécurisées, c'est pourquoi toute faiblesse ou vulnérabilité trouvée sur celle-ci est lourd de conséquences... Découverte par Neel Mehta de Google Security et datée du 07 Apr 2014, cette vulnérabilité est estampillée CVE-2014-0160 et porte le nom de Heartbleed bug vulnerability.

heartbleed

Les travaux présentés ici décrivent l'analyse d'une application .NET éditeur rencontrée dans le cadre de nos tests d'intrusion. Toutes les informations permettant d'identifier ce dernier ont été supprimées.

Sommaire

  1. Analyse en boîte noire
  2. Rappel sur l'environnement d'exécution .NET
  3. Analyse en boîte blanche
  4. Extraction des clés
  5. Conclusion

Voilà pas mal de temps déjà (2008-2009) que l'on est au courant du faible niveau de sécurité de la téléphonie DECT, principale norme utilisée dans la téléphonie fixe. Où en est la sécurité 5 ans après ...? Pour rappel, DECT (Digital Enhanced Cordless Telephone: Téléphone sans-fil numérique amélioré) est une norme de téléphonie sans-fil numérique destinée aux particuliers comme aux entreprises. Opérant sur la gamme de fréquence 1 880 à 1 900 MHz (micro-ondes) sp_dect

Après une longue période de vacances, voici un nouvel article sur notre blog.

Cela fait un moment que l’on n’a pas parlé de Reverse Engineering sur le blog, il est temps d’y remédier.

Aujourd’hui nous allons nous intéresser aux applications Windev que nous avons découvertes lors d’un audit. WinDev est un langage de développement développé par PcSoft, société Française.

L'objet de cet article concerne plus précisément l’outil WDModfic.exe qui a pour objectif de modifier les fichiers d'analyse d'une application WinDev et qui est embarqué avec toute application WinDev.

Il est important de savoir que WinDev utilise 2 grands types de fichiers :

  • Un fichier d'analyse permettant de décrire la structure des fichiers de données
  • Les fichiers de données eux-mêmes

Le but de ce Reverse est d’arriver à prendre la main sur les fichiers de données de l'application protégés par une couche de chiffrement supplémentaire basée sur un mot de passe paramétré directement dans WinDev. Ce mot de passe est souvent identique à celui configuré sur le fichier d'analyse de l'application WinDev (en tout cas dans les applications WinDev que l'on a audité)

Le processus d'attaque est le suivant :

  1. Téléchargement de l'outil wdmodfic.exe
  2. Reverse Engineering de ce dernier
  3. Découverte de la vulnérabilité
  4. Extraction du mot de passe embarqué dans l'outil wdmodfic.exe
  5. Récupération des données contenues dans les fichiers de données dans le cas ou le mot de passe du fichier d'analyse est le même que celui du fichier de données

Ceci permet donc via un utilitaire WinDev disponible librement de prendre le contrôle de n'importe quelle application développée sous WinDev.

Attention ceci n'est valable que pour la version 16 de WinDev (qui est plutôt récente et datant de Juin 2011). Nous n'avons pas réalisé le test sur WinDev 17

Dans notre article précédent (https://www.nes.fr/securitylab/?p=487), nous avons vu comment créer un web shell PHP quasi-indétectable au niveau des logs des requêtes Apache en utilisant les fonctionnalités du mod_rewrite.

Nous allons reprendre ce web shell et lui ajouter un peu de d’obfuscation pour qu’il devienne encore moins traçable, à savoir : - Encodage en base64 des requêtes - Padding du payload : ajout de caractères ne servant à rien dans les requêtes afin d’empêcher le décodage automatique des payloads base64 par les WAF (Web Application Firewall) - Envoi de contenu de taille variable en retour, afin de ne pas alerter les WAF avec une page de 0 octet) - Manipulation des lettres dans les noms des fonctions PHP à base de str_replace : afin d’empêcher la détection de fonctions PHP (exemple : exec, base64_decode, base64_encode…) - Changement de la page requêtée à chaque envoi de commande afin qu’il n’y ait pas plusieurs requêtes sur la même page qui se suivent dans les logs

Lors d’un test d’intrusion web, il arrive de découvrir une vulnérabilité d’upload de fichiers permettant d’envoyer des fichiers PHP.

Afin d’exploiter cette vulnérabilité, on envoie un Web Shell PHP classique ou un peu plus évolué (c99, c100, r57, 12309…) permettant d’exécuter des commandes à distance sur le serveur attaqué.

Malheureusement ce type d'attaque est souvent très peu discrète et un admin système consciencieux peut vite repérer le webshell.

Nous allons ici vous expliquer une méthode pour rendre cette attaque quasi-indétectable