[SECURITY STANDARD] Episode 2: are you compliant to ... ISO 27002

Après avoir vu la norme ISO 27001, je vous propose un aperçu de la norme ISO 27002. Elles sont toutes les deux liées, même si, cette dernière n'est pas obligatoire. Cependant, elle représente une aide précieuse à l'implémentation d'un SMSI.

Ce qu'est la norme ISO 27002 ...

Il s'agit d'un code de bonnes pratiques contenant les mesures de sécurité qui peuvent aider à respecter les exigences de la norme ISO 27001. Les chapitres les plus importants sont les chapitres 5 à 15. Chacun aborde un thème de la sécurité de l'information qui sont présentés dans le schéma ci-dessous. En réalité, ils sont généralement liés entre eux et il est souvent difficile de les traiter sans s'appuyer sur d'autres mais l'ensemble de la norme présente ainsi des sujets complémentaires entre eux et complets dans sa globalité.


Liens entre les normes ISO 27001 et ISO 27002

Tout d'abord, il faut savoir que les thèmes de la norme ISO 27002 sont déjà repris dans l'annexe A de la première norme que nous avons étudiée. Cette annexe représente donc le lien entre les deux normes.

Ensuite, certaines clauses de la normes ISO 27001 correspondent aux thèmes de la norme ISO 27002. Pour être plus précis, prenons l'exemple suivant : la norme ISO 27001 demande d' "identifier rapidement les failles et les incidents de sécurité" (clause 4.2.3.a).2)). L'implémenteur du SMSI pourra s'appuyer sur le thème n°13 de la norme ISO 27002 (ou le point A.13 de l'ISO 27001) qui traite justement de la gestion de la sécurité.

En fait, cela va plus loin que ça. Rappelons que la norme ISO 27001 demande à ce que l'on crée une déclaration d'applicabilité (Dda ou SoA en anglais). Dans cette déclaration, l'implémenteur doit reprendre l'ensemble de l'annexe A et donc finalement l'ensemble des thèmes de la normes ISO 27002. Là, il doit dire quelles sont les mesures de sécurité qu'il souhaite mettre en place ou pas. Pour celles qu'il décide de ne pas considérer, il devra justifier une telle exclusion. La norme ISO 27002 apparaît alors comme quasiment indispensable pour aider l'implémenteur.


Exemple

Pour bien comprendre, voici un extrait de l'annexe A de la norme ISO 27001 :

On y trouve le thème, un objectif et les mesures associées. Dans la norme ISO 27002, nous retrouvons le même thème mais avec des précisions, ou plutôt des préconisation de mise en œuvre, pour appliquer les mesures de sécurité. De nouveau, en voici un extrait :

5.1.1 Document de politique de sécurité de l'information

Mesure : Il convient ... soit approuvé par la direction, puis publié et diffusé ...

Préconisations de mise en œuvre : il convient ...
a) une définition de la sécurité de l'information, les objectifs généraux recherchés et le domaine d'application retenu, ainsi que l'importance de la sécurité en tant que mécanisme nécessaire au partage de l'information ... ;
b) ...

Conclusion

Pour résumer, la norme ISO 27002 est d'une grande aide pour l'implémentation des mesures de sécurité - même si elle n'a aucun caractère obligatoire - à travers certaines clauses de la norme ISO 27001 et pour la déclaration d'applicabilité. Cependant, elle ne couvre pas tout, loin de là. Par exemple, l'implémentation globale du SMSI sera couverte par la norme ISO 27003 que nous verrons dans le prochain billet.

[SECURITY STANDARD] Episode 1: are you compliant to ... ISO 27001?

Des normes internationales ont été rédigées concernant la sécurité des systèmes d'information. Elles sont de plus en plus utilisées et elles servent notamment de référentiel pour les entreprises. Leur étude nous apporte un nouveau point de vue sur la SSI qu'il est important de connaître. Il n'est pas toujours facile de prendre le temps de les lire et les étudier alors je vous propose un aperçu de chacune d'entre elles.

Ce qu'on va voir ...

La norme centrale est la norme ISO 27001. C'est elle qui peut donner lieu à une certification et c'est d'ailleurs l'objet de notre premier épisode. Cependant, nous allons vite nous apercevoir qu'elle est liée à d'autres normes de la SSI que le schéma ci-dessous représente. D'où la nécessité des autres épisodes.


Ce qu'est la norme 27001 ...

Tout d'abord, il s'agit d'une norme d'exigences. C'est à dire que pour obtenir la certification en question, il est nécessaire que l'entreprise réponde à ces exigences. Plus précisément, la norme est découpée en 8 chapitres ou "clauses". Seules les clauses 4 à 8 sont vraiment importantes et sont à tenir compte pour la mise en place d'un SMSI (ou Système de Management de la Sécurité de l'Information) et obtenir la certification. Nous reviendrons sur ces clauses juste après.

Avant, il nous faut tenir compte d'une notion essentielle pour le SMSI : la modèle PDCA (Plan / Do / Check / Act). Réussir l'implémentation de son SMSI revient à respecter ce modèle. scrupuleusement Il ne s'agira donc pas uniquement de mettre en place une gestion d'incidents par exemple mais aussi de documenter le sujet, écrire les procédure associées, en contrôler les résultats et l'efficacité et corriger les défauts relevés.


Le modèle PDCA ...

Il est donc important de se focaliser sur ce modèle considéré comme une roue vertueuse, utilisée en mode fractale, c'est à dire pour chaque action. La norme ne demande pas finalement d'avoir un niveau de sécurité élevé mais de faire fonctionner un SMSI en respectant les 4 phases du PDCA tel que :

• Plan : définition de la politique du SMSI et du périmètre de celui-ci, appréciation du risque, traitement du risque, mesures de sécurité sélectionné (déclaration d'applicabilité ou dda).
• Do : plan de traitement des risques, déployer des mesures de sécurité, gérer le SMSI au quotidien, détection rapide aux incidents.
• Check : audits internes, contrôles internes, revues.
• Act : actions correctives, actions préventives, actions d'amélioration.

Les clauses de la norme ...

Nous présentons ici les 5 clauses qu'il est important de connaître. Vous remarquerez certainement un parallélisme avec le modèle présenté ci-dessus. Ce n'est pas un hasard.

• Clause 4 : SMSI. Cette clause fournit des indications importantes pour la mise en place du SMSI. Notamment, les exigences regroupées dans les articles 4.21, 4.2.2, 4.2.3 et 4.2.4 correspondent respectivement au Plan, Do, Check et Act. Malgré l'importance de cette clause, elle ne fait que 5 pages, nous devrons donc nous appuyer sur d'autres normes pour nous aider à obtenir un SMSI conforme à la norme (cf. premier schéma).
• Clause 5 : cette clause souligne la nécessite de l'implication de la direction dans le projet de déploiement du SMSI. En effet, il n'est pas envisageable qu'un SMSI puisse fonctionner correctement sans l'approbation et l'appui de la direction.
• Clause 6 : elle est relative aux audits internes. Il est demandé à ce que le SMSI soit contrôlé de manière régulière (check) selon un programme d'audit précis.
• Clause 7 : elle concerne la revue de direction du SMSI. A travers des comité de direction et de pilotage de la sécurité, le SMSI devra être revu régulièrement, notamment en s'appuyant sur les résultats des audits internes (clause précédente) mais pas seulement. Par exemple, les différents enregistrements et les indicateurs mis en place pourront servir aux décisions de la direction.
• Clause 8 : Cette clause aborde l'amélioration du SMSI (Act). Il s'agit de mettre en place les actions correctives et préventives relevées lors des actions de contrôles et approuvées afin d'améliorer le SMSI.

Pour aller plus loin ...

En premier lieu, je vous proposerai dès que possible un aperçu des autres normes dans ce blog. Ensuite, la meilleure façon d'appréhender un SMSI est de se documenter ou de suivre une formation sur le sujet. En termes de littératures, LA référence est le livre d'Alexandre Fernandez-Toro que je trouve très bien fait et que je recommande sans modération à qui veut en savoir plus.

[SCADA] SCADA Security ... or not

J'ai eu l'occasion dernièrement de travailler sur des environnements SCADA : ça change ! Mais en quoi ? Comment aborder ces bêtes là ? Quelles sont les failles les plus récurrentes ? Et déjà, est-ce que c'est sécurisé ? Petit point sur mes premiers retours d'expérience.

Ce qu'on en dit sur le Net

On trouve des articles sur le Net depuis quelques années maintenant mais plutôt sur des sites et blogs outre atlantiques et peu en France. Pourtant, il existe des acteurs majeurs dans notre pays.

Ayant eu l'occasion de travailler sur le sujet, on se rend compte que le pentest d'un SCADA ne s'aborde pas de la même manière qu'une application WEB classique par exemple. Pourquoi ? Parce que dans le cas d'un SCADA, c'est la disponibilité qui est requis en premier lieu et non la confidentialité de nos chères applications bancaires ou commerciales.

Une fois que nous avons compris cela, nous comprenons mieux les failles trouvées car on souhaite avant tout que ça fonctionne et que ce soit performant d'où l'attaquant a toutes les chances de se retrouver face à :

• des systèmes non patchés depuis des mois (... des années) ;
• des accès sans mot de passe ;
• des fichiers texte ou autre contenant les identifiants ;
• des communications non chiffrées ;
• etc.

Bref, il semblerait que le pentest d'un SCADA consiste tout simplement à sortir sa panoplie du hacker de base, c'est à dire :

• MBSA ou autre scanner ;
• nmap ;
• wireshark ;
• le moteur de recherche du système d'exploitation ;
• et arme ultime, la touche entrée une fois sur le champ "password" ;
• etc.
  

Et ce qui se passe dans la vraie vie

Bon, soyons honnête, je n'ai pas eu l'opportunité de faire 50.000 tests sur les environnements SCADA mais voilà ce que je peux dire de ce que j'ai pu voir. Avant, pour cadrer le sujet, il faut savoir que les applications étaient installées sur des serveurs Windows et qu'il faut donc ajouter à sa méthodologie celle d'un test d'une application lourde. Alors quand les attaques précédemment citées ne fonctionnent pas, nous ajoutons à notre panoplie des décompileurs et des debuggers (je m'arrêterais là, je ne suis pas un "pure reverser" ;)).

Le premier pentest s'est passé comme on le racontait sur Internet : c'est à dire qu'il n'y avait pas de sécu. Enfin, j'exagère, il y avait un mot de passe. Mais il était teeeeeeeeeeeeellement compliqué, que j'ai eu besoin d'aide ...

... Alors j'ai regardé l'aide où il était écrit :

The default user name is "guest". The default password is "0".

Alors si maintenant on nous donne la solution, qu'allons nous devenir ;)

Bon, ça c'est fait. En même temps, vous allez me dire, ça ne concernait que le mot de passe d'un compte "invité" donc c'est pas très grave ... sauf que ! En fait, on avait octroyé les privilèges les plus forts à ce compte ...

Autre point rencontré, un serveur où il manquait une soixantaine de patches Windows ... Quand on parle de virus et de vers, je confirme donc que les SCADAs sont eux aussi concernés ! Et les dégâts, prometteurs :/

Ce n'est cependant pas toujours si simple et j'ai effectivement rencontré un cas où les mots de passe étaient forts, les flux chiffrés et les mots de passe étaient sécurisés de manière sécurisée. Donc, la sécurité sur un SCADA, c'est envisageable ! Sauf que ... un décompileur (spécifique) était présent sur le serveur et il était donc possible de se créer un compte et de se donner les privilèges les plus élevés au passage ... BINGO !


Des outils de tous les jours, pour des tests SCADAS

Ce n'est pas forcément connu mais des outils que nous utilisons tous les jours prennent en compte les SCADAS. Et je ne peux que citer le célèbre NESSUS qui propose une famille de plugins nommé SCADA avec à ce jour 42 plugins sur le sujet.


Metasploit propose lui aussi un exploit tout fait pour certains SCADAs.



Bref, les moyens existent pour contrôler la sécurité (et inversement pour la contourner) d'un SCADA mais déjà que nous devons nous battre parfois pour expliquer les bienfaits de la sécurité, ici, on craint que le test en soit provoque déjà une perturbation et nous devons reconnaître que l'impact financier est ici direct. Mais que ce passera-t-il le jour où un réseau SCADA sera infecté ? Qu'un réseau SCADA sera pris pour cible (et même pas forcément par un attaquant aguerri !).

Alors que nous parlons de guerre numérique et que les énergies (que contrôlent les SCADAs) représentent le point névralgique des guerres, le risque est bien réel et important. On voit déjà ce que peut provoquer une pénurie d'énergie tel que le pétrole pendant quelques jours ;)

[HITB COnference] Day 2

La première journée était riche en vulnérabilités et exploitations. Après avoir visité un peu Amsterdam (non non, je ne faisais pas partie du groupe parti pour la zone rouge) avec notamment la visite de la maison d'Anne Frank (tout de suite, c'est moins sexy ;). Je n'ai pas assisté au deuxième keynote mais voici la suite des conférences que j'ai suivi.

Conf 1 - SAProuter, An Internet Window to your SAP platform - Mariano Numez di Croce

Fidèle à mon aventure sur SAP, voici la dernière conférence sur le sujet. Cette conférence se concentre sur le composant SAP Router et était très pratique puisqu'après une présentation de SAP, une démonstration de l'attaque par étape nous a été présentée. Pour ceux qui ne connaitrait pas bien SAP, je vous renvoie vers le résumé de la formation qui a eu lieu les deux premiers jours du HITB (résumé 1 et résumé 2).

Il faut rappeler avant tout que le SAP Router a pour rôle de filtrer les requêtes (couches 3 et 4), de tracer les connexions, d'appliquer une sécurité sur les flux (avec une clé partagée) et de sécuriser les flux (avec SNC).

Pour le filtrage des requêtes, une table permet de définir les flux autorisés, interdits et limités (ie, seuls les flux ayant pour protocole SAP sont autorisés). Première faille potentielle : les administrateurs, dans la vraie-vie, finissent souvent leur configuration par un "j'autorise tout". En effet, sur la base d'une liste blanche, les administrateurs n'ont pas toujours le courage d'entrer tous les accès et sachant qu'il faut que ça marche à tout prix ...

La démonstration a été réalisée à l'aide de l'outil BIZPLOIT (dont le speaker est le principal développeur). L'attaque se déroule en plusieurs étapes :

• phase de découverte : on recherche le port utilisé par le SAP Router. Par défaut, le port TCP/3299 mais nous vérifions à l'aide du module "discover" ;
• phase de découverte interne : le plugins saprouter spy nous permet de connaître les ports ouverts sur la machine comme si nous y étions ! Intéressant ;
• l'attaque consiste a utilisé le SAP Router en tant que proxy. Nous trouverons cette fois des infos sur la solution SAP (ex : version) ;
• Puis, on utilise le plugin de bruteforce pour trouver des comptes valides (e.g. mots de passe par défaut ou triviaux) ;
• On utilisera l'exploit saprouterAgent pour obtenir une connexion sur le SAP Router ;
• Enfin, c'est grâce à l'outil tsocks que notre trafic sera redirigé vers le proxy mis en place et que nous pourrons attaquer le système SAP comme de l'intérieur.

Une démonstration convaincante qui montrer les risques d'une mauvaise sécurisation de sa plateforme SAP. Les solutions de correction existent cependant :

• l'application des patches (pas toujours évidente malheureusement) ;
• l'application de la sécurité sur les connexions (nombre de connexion maximum, chiffrement, etc.) ;
• la politique de mot de passe pour les clients ;
• la généralisation des messages erreurs pour éviter l'affichage d'information technique.

Conf 2 - Firefox 4 and Opportunities for security research - Chris HOFMANN

Je ne m'étendrais pas sur cette conf qui n'avait pas tout l'intérêt attendu. L'idée est de lancer un "Bug Bounty Program". plus précisément, il s'agit de récompenser les personnes qui découvrent des bugs sur la prochaine version de Firefox (Firefox 4 donc). Cela existe déjà en réalité mais l'accent est mis sur le sujet pour motiver les chercheurs potentiels en leur octroyant une prime plus importante (3.000$). Cependant, le bug doit remplir plusieurs conditions comme conduire à un exploit distant. Problème : les marchés noirs offriront toujours plus. Néanmoins, souhaiteriez vous fournir des armes à des black hats, même pour de l'argent ?

Finalement, Mozilla estime que s'il ne paye pas pour la recherche des bugs maintenant, ils paieront plus cher d'une manière ou une autre la découverte des bugs. Ceci est vrai pour tout logiciel mais rarement considéré ... Dans le même temps, Mozilla a pour objectif d'assurer la sécurité de ses utilisateurs. De plus, la fondation en question veut se donner les moyens de faire face aux bugs :

• en assumant les bugs potentiels ;
• en motivant les chercheurs à trouver ces bugs ;
• en les corrigeant rapidement.

Il s'agit d'un réel défi car Firefox 4 bénéficiera de nouvelles fonctionnalité (tels qu'un parser HTML 5) qui pourront aussi représenter de nouveaux vecteurs d'attaque ...


Conf 3 - XProbe-NG, Building Efficient Network Discovery Tools - Fyodor YAROCHKIN

Il existe déjà beaucoup d'outil de découverte. Alors pourquoi un nouveau ? Celui proposé par Fyodor, déjà existant (Xprobe), est de tenir compte de la vraie-vie, des attaques qui ont lieu sur le Net. Ce tool de fingerpringting a aussi pour but d'étendre son action à la couche applicative pour combiner la collecte d'information aux couches réseaux et applicatives. Enfin, cette nouvelle version a pour vocation d'enrichir la version précédente à l'aide de scripts et de données échangées.

Plusieurs défis sont alors engagés pour réussir ce pari. Notamment, il faut :

• limiter le temps de traitement des couches réseaux, la couche applicative étant gourmande en interprétation ;
• être suffisamment rapide pour analyser les flux en temps réel (ou presque), ce qui pourra se faire avec un nouveau moteur.

L'outil, écrit en Python, utilise le principe de scoring et de prioroté pour traiter les informations les plus importantes en premier lieu. Ensuite, une autre solution consiste à ne lancer les modules d'analyse que quand ils sont nécessaires.

Au final, XProbe-NG va réaliser différents tests applicatifs comme analyser les séparateurs de répertoire, les fichiers spéciaux dans les répertoires, la sensibilité de la casse, etc ... pour différencier un Linux d'un Windows.

D'autres améliorations sont prévues pour permettre à cet outil de se démarquer. Une première version sera disponible la semaine prochaine à cette adresse.


Conf 4 - Top 10 Web 2.0 Attacks and exploits - Shreeraj SHAH

Lors de cette conférence, le speaker a pris en compte le Top 10 des vulnérabilités liées au WEB 2.0 en se basant sur l'OWASP. Voici le classement :

• 1) DOM Based XSS (Ajax) ;
• 2) SQL Injections (SOAP / XML) ;
• 3) Blind SQL over JSON/AMF ;
• 4) XPATH Injection ;
• 5) Business logic bypass ;
• 6) Decompilation Attack (ex : SWF) ;
• 7) WSDL ;
• 8) XSS with Flash ;
• 9) CSRF with XML ;
• 10) Widget / Marshup.

Une description et une démonstration a été réalisée pour chacune de ces attaques. Tout expliquer demanderait donc un billet à lui tout seul (au moins) mais cette présentation intéressante appelle notamment à la veille que nous devons réaliser en tant que pentesters sur ces nouvelles attaques. En effet, de nombreux sites sont touchées par ce type de vulnérabilités encore mal connues des développeurs.


Conf 5 - The travelling Hacksmith 2009/2010 - Saumil SHAH

Une présentation particulière qui ne manquait pas d'intérêt et qui en a fait rire plus d'un : il ne devait pas y avoir d'opérateur wifi ni d'agent d'opérateur de voyage dans la salle ...
Je m'explique ! Le speaker nous raconte qu'il voyage beaucoup et que tout se paye et souvent cher comme les connexions WiFi dans les chambres d'hôtel.

A travers les différents voyages et hôtels visités, Saumil nous montre comment il a réussit à obtenir un accès Internet gratuit ou moins cher. De la modification du numéro de chambre dans la requête au contrôle de la passerelle en passant par les injections SQL, aucun accès ne lui a résisté ;)

Ensuite, il s'attaque aux billets d'avion dans le but d'être surclassé. Il réussit à plusieurs reprise en modifiant son numéro de place dans le choix des places au check-in sur Internet.

Enfin, sur un site de réservation d'hôtel que je ne dois pas citer et que je ne ferais donc pas, il est possible de réserver et d'annuler sans payer de frais : sauf que l'annulation se fait sur le jour précédent de l'arrivée ! A voir si ça marche toujours ?


Et c'est la fin de cette conférence ! Ces 4 jours auront passé bien vite mais il est temps de sortir de Hackerland et de retrouver son chez-soi : enfin, si le Thalys arrive, déjà 30 minutes de retard ...

[HITB Conference] Day 1

Un petit retour sur cette première journée de conférence au HITB d'Amsterdam où l'ambiance est très bonne, l'hôtel cool (sauf pour y dormir apparemment ?) et les HITB girls sont ... sociables ! D'ailleurs, à quand les SSTIC girls ?

Keynotes - Dr Anton CHUVAKIN - Security Chasm

Cette conférence me rappelle un talk donné par Nicolas RUFF l'année dernière au SSTIC. En effet, une idée dans tout ça est de montrer l'échec de la sécurité depuis les années 90.

Tout d'abord, on a traversé plusieurs période de la sécurité en déplaçant le problème finalement à chaque fois. Tout d'abord, la sécurité était portée sur les ordinateurs, puis sur les réseaux, puis sur la prévention, puis sur la conformité et les normes, etc ...
En parallèle, nous avons voulu couvrir les risques locaux dans un premier temps puis les menaces extérieures (avec le pare-feu à tout va) puis la détection des attaques (mode des IDS/IPS) puis, plus récemment, le cybercrime et pour en arriver maintenant à la période des clouds.

Le problème, selon le conférencier, le manque de cohérence dans tout ça. Il y a d'une part ceux qui conseille de faire de la sécu et fournissent les recommandations alors qu'ils ne touchent pas au matériel (l'auditeur ne maitrise n'a jamais administré d'IPS qu'il va conseiller de configurer de telle ou telle manière par exemple pour mieux protéger le réseau) et d'autre part, nous avons les personnes qui appliquent la sécurité parce qu'il le faut bien ou parce qu'on leur demande, pas par conscience des risques.

Alors pour résoudre cela, plusieurs lignes de conduite nous sont fournis. A titre d'exemple, les normes peuvent être bénéfiques mais seulement pour mettre encadrer la mise en place de la sécurité dans un SI, pas pour avoir l'étiquette "compliant" notamment.

En fait, selon l'orateur, si une entreprise n'est pas en mesure d'assurer sa sécurité en 2020, elle mourra car un attaquant aura d'ici là toutes les armes lui permettant de mettre fin au business d'une entreprise.


Conf 1 - John 'Kanen' Flowers - Introducing Kane |Box

L'orateur part du principe que la sécurité ne fonctionne pas pour diverses raisons : elle coûte chère, les outils sont souvent contournés et cassés et les façons de penser et de "faire de la sécurité" n'ont pas évoluées depuis des années. A l'inverse, les outils de hacking sont souvent libres et les compétences des attaquants ne cessent d'évoluer.

Et c'est là que l'orateur à la bonne idée : proposer une solution de sécurité qui n'est pas seulement un nouveau logiciel mais un boitier "clé en main". Pour avoir travailler dans la sécurité, vous allez me dire que ça existe déjà : de nombreux éditeurs en proposent ... oui mais à quel prix ? A 475$ vous en connaissez combien ? En effet, c'est le prix de base d'un boitier Kane|Box. Et même, pour ceux qui ont l'âme d'un bricoleur, le code est libre et il ne vous reste plus qu'à monter le boitier.

L'auteur n'était donc pas là pour vendre sa marchandise mais pour fournir une solution complète et tout à fait abordable ; ce qui résout les problèmes actuelles pour implémenter la sécurité.

Et que permet de faire cette solution ? C'est une virtual box rassemble les caractéristiques suivantes :

• un module d'exploitation (sniffer + analyseur de paquets + crackers de mots de passe + scripts d'exploitation) ;
• un module de détection (pour la détection d'attaque réseau) ;
• un pare-feu (permettant d'inspecter les paquets et de les bloquer) ;
• un routeur (pouvant bénéficier de règles de filtrage) ;
• un mode host-based (pour collaborer avec les anti-virus et les pare-feu des machines).

L'idée est bonne et il serait intéressant de voir ce que cela pourrait donner en pratique.
En attendant, je vous invite à voir la page du produit pour plus d'info.


Conf 2 - Alexander POLYAKOV - Attacking SAP Users with SAPSPLOIT

Je continue mon aventure sur la sécurité de SAP (cf. traning1 et training2). Ici, l'orateur part du principe que le système SAP est correctement sécurisé et que les vecteurs d'attaque sur le système (OS, DB, appli, services additionnels) ne sont pas exploitables depuis notre point d'attaque. Ce qui, pour une version récente de la plateforme serait envisageable. Du moins, admettons.
Alors, le vecteur d'attaque sera l'utilisateur. En effet, c'est lui qui aura les permissions appropriées pour ce connecter au serveur SAP et une fois son poste de travail compromis, nous aurons la possibilité de nous attaquer au cœur de notre cible. De plus, les utilisateurs sont nombreux donc plus de chance de succès.

L'utilisateur se connecte au serveur SAP via le client SAPGUI. Premier point : les flux ne sont pas toujours chiffrés et seulement compressé au mieux (XOR avec une clé connue, base64, ...).
Deuxième point : SAPGUI est vulnérable à un certain nombre d'attaques :

• a) SAPGUI utilise des activeX et alors, les vulnérabilités concernant ce dernier sont aussi valables pour notre cible (ex : des buffer overflows sont réalisables). Aussi, les activeX permettent des intéractions avec les fichiers enregistrés sur le serveur : et si on changeait la configuration du serveur pour supprimer des protections ? Enfin, il est possible d'exécuter des commandes système ou de déployer un cheval de Troyes.
• b) Une fois le client compromis, il est possible de retrouver des données intéressantes sur la machine de la victime. Par défaut, nous les retrouverons dans le répertoire c:\windows\sap.
• c) D'autres attaques souvent prometteuses peuvent être menées sur le client : XSS (stored XSS notamment dans une fonction d'upload), phishing, XSRF, etc ...
• d) Il est même possible d'obtenir un shell en uploadant une page HTML dans une fonction d'upload du client.

Afin d'empêcher ce type d'attaque, voici quelques recommandations fournies par Alexander :

• Effectuer les mises à jour nécessaires : les dernières versions sont bien mieux protégées ;
• Tester la force des mots de passe des clients et appliquer un seuil d'échec pour la tentative de connexion ;
• Quelques configurations au niveau de la clé de registre permettent de mieux sécuriser le client ;
• Attention, à minuit, une option permet de délocker tous les utilisateurs ! A supprimer.

Des infos supplémentaires peuvent être trouvées ici.


Conf 3 - Laurent OUDOT - Web in the Middle - Attacking Client

La première conférence de l'après-midi nous parlait d'attaque de type MiTM que nous connaissons tous mais d'un type plus particulier qu'on appellera WiTM. En fait, il s'agit ici d'opérer sur des réseaux publics et si pensez réseaux Wi-Fi ... vous pensez juste !
En face, nous avons tous les appareils mobiles capables de se connecter via le Wi-Fi. En particulier, nous avons les smartphones et tout objet qui se croque ( [Début private joke] Oui Fred, j'ai décidé de reprendre le concours d'hier [Fin private joke] ;)).

J'ai retenu deux idées principales pendant la conférence :

• Lors d'une communication dite sécurisée via SSL, toutes les requêtes ne sont pas toujours envoyées de manière sécurisée. En effet, de la page de login à la déconnexion de l'utilisateur, nous pouvons retrouver des requêtes HTTP. Cela peut concerner notamment les pages de déconnexion ;
• Nous pouvons modifier le user-agent dans nos requêtes et voir le comportement du site WEB qui peut être différent pour certains.

A partir de ces deux idées, cela a donné naissance à des 0days que nous a présentés le speaker. Les références associées sont les suivantes :

• CVE-2010-1752 qui concerne l'iPhone ;
• CVE-2010-0028 qui concerne le navigateur du HTC (Opera) ;
• CVE-2010-0027 qui concerne les blackberry (vulnérabilité dans le "hotspot browser") ;

La démonstration réalisée en live concernait une dernière vulnérabilité touchant cette fois l'iPad. Une vulnérabilité dans son navigateur (Safari) permet de le crasher pour l'instant et peut être plus plus tard.

Il y a certainement eu un très gros travail derrière tout ça pour trouver et exploiter les vulnérabilités. Malheureusement, aucune explication n'a été fournie sur celles-ci. Aucun point technique n'a été abordé non plus. Même si cela se comprend vis à vis des constructeurs, cela a enlevé du piquant à la présentation.


Conf 4 - Niels TEUSINK - Owned Live on Stage: Hacking Wireless Presenters

Pour le coup, la présentation qui a suivi a été très explicite dans son explication et sa démonstration ! De plus, il s'agit là d'un sujet tout à fait original : le hacking à travers les périphériques sans fil !

A priori, tout périphérique sans fil pourrait nous servir entrer en ligne de mire. Tout d'abord, nous connectons via USB un périphérique sans fil (un appareil Logitech R-R0001 pour la présentation) sur deux PCs différents. Un des PC représente la machine de l'attaquant et l'autre, celui de la cible. Et vous avez bien compris, nous allons tenter de faire communiquer les appareils sans fil entre eux pour compromettre la machine cible !

Je vous passe les détails techniques de ces attaques physiques : il ne s'agit tout simplement de mon domaine et ne suis pas en mesure de vous apprendre quelque chose à ce sujet. Cependant, la technique d'attaque consiste dans un premier temps à sniffer via le BUS avec le matériel adéquat. De l'autre côté, le speaker choisit un appareil sans fil un peu différent. Pour résumer, le but va être de trouver le bon canal de communication qui nous permettra de communiquer entre les deux appareils. Une fois le canal trouvé, les appareils sont "liés" et là, le speaker nous montre ce qu'il est possible de faire : un connect-back sur du VNC sur la machine cible. Je peux juste vous confirmer que ça a bien marché pendant la démonstration ! C'est assez terrifiant non ? Et là, ce n'est pas une souris sans fil que vous tenez sous la main ? ...

Aujourd'hui, la sécurité n'existe pas pour les périphériques en question : il est donc important de créer un protocole sécurisé et d'utiliser une cryptographie fiable afin d'éviter des attaques de ce type.


Conf 5 - Tamas RUDNAI - Fireshark

Le speaker nous présente ici un plugin de Firefox. Un de plus ! Mais particulier celui-ci puisqu'il permet de cartographier les sites infectés par les malwares. Pour cela, le plugin visite les pages web et collecte les informations dont il a besoin (code source, redirections, screenshots, etc.).
Un autre but est de désobfusquer le code, ce qui permettra d'étudier les malwares rencontrés sur les sites.

L'outil peut fonctionner selon deux modes :

• le Network mode : ou mode automatique ;
• le Single-user mode : l'utilisateur choisit les sites qu'il souhaite inspecter ;

La dernière fonctionnalité qui n'a pas été évoquée est le post-processing. Le but est de pouvoir analyser un malware à partir des preuves collectées précédemment.

Étant donné que les malwares sont de plus en plus nombreux, ce plugin a tout à fait sa place au sein des outils d'un chercheur. En effet, outre le rôle de prévention (en évitant ainsi de visiter des sites contaminés), l'analyse des malwares permet de mieux comprendre les nouvelles attaques et d'en trouver les contre-mesures.


Fin de cette première journée. La suite dans le billet suivant.

[HITB Conference] SAP Hacking - Overview 2/2

Deuxième et dernier jour de training sur la sécurité de SAP. Beaucoup de choses mais ça reste tout à fait intéressant. On continue notre tour d'horizon !

La sécurité de l'authentification

Sur les systèmes SAP, il est possible de se connecter de plusieurs manières différentes. En particulier, il est possible de se connecter :

• via un login/mot de passe (classique) ;
• SNC (Secure Nework Communication) permet de se connecter à l'aide d'une librairie extérieure (ex : NTLM) ;
• via un certificat ;
• par ticket (dans le cadre d'une authent' par SSO notamment ;
• PAS (Pluggable Authentication Service) : utilisation d'une autre base d'authent' (ex : LDAP) ;

Bon, on conviendra que ce n'est pas le choix qui manquent. Après, ils ne sont pas tous égaux en termes de fiabilité...


La sécurité des utilisateurs

Tout d'abord, il existe plusieurs types d'utilisateur. Le type attribué dépendra de la connexion et du niveau de sécurité attendu. Par exemple, le type Dialog permet un accès direct au système SAP. Ce qui n'est pas le cas pour le type system mais ce dernier impose un mot de passe qui n'expire pas.
Une fois n'est pas coutume, il existe pas mal de comptes par défaut sur un système SAP. Évidemment, il est recommandé de verrouiller les comptes en question ou du moins, d'en changer les mots de passe.
Le compte privilégié est SAP*. Tiens, il me semble qu'on avait vu que ce compte avait un mot de passe par défaut trivial ... De plus, ce compte ne peut pas être supprimé ! Il existe cependant des moyens de sécuriser de tels accès.


La politique de mots de passe

L'encodage des mots de passe a évolué au fur et à mesure des versions de SAP. Aujourd'hui, les plus complexes sont hashés avec SHA1 et bénéficient d'un sel aléatoire. Les précédents sont cassables avec john patché. Ensuite, tous les paramètres classiques et attendus existent (blocage du compte, historique des mots de passe, expiration, etc.).


Les autorisations

Un utilisateur loggé ne peut pas (toujours) faire tout ce qu'il veut. il est soumis à des autorisations. Des contrôles sont donc effectués avant qu'un utilisateur ne puissent réaliser une transaction (au sens SAP) par exemple. Un utilisateur ayant le profile SAP_ALL est le plus intéressant pour un attaquant ; en effet, il permet de réaliser toute action.


La sécurité des communications

Un attaquant peut s'amuser à interagir avec les protocoles utilisés par SAP pour obtenir des informations sur le système ou exploiter des vulnérabilités. il s'agit notamment de :

• RFC : permet de lancer des fonctions sur les serveurs distants ;
• Commandes externes : une transaction de SAP permet d'interpréter des commandes système (sur le système d'exploitation).

La sécurité des environnements

Dans SAP, nous retrouvons trois instances primaires :

• environnement de développement (DEV) ;
• environnement de qualification (QAS) ;
• environnement de production (PRD).

Quand bien même il s'agit d'instances distinctes, elles sont reliées à une même base (common transport directory).
Il est possible de cloissoner les droits entre ces environnements et au sein de la base. Ainsi, un développeur ne pourra pas porter atteinte à l'intégrité des données de production par exemple. La configuration se fait via une transaction de SAP.


La sécurité du langage de programmation (ABAP)

Un module mal codé pourra permettre de lancer des attaques critiques. En l'occurrence, elles peuvent permettre de contourner les restrictions de droits appliqués à un utilisateur. Ce langage peut aussi permettre de lancer des commandes SQL et ainsi récupérer des données (contournement des contrôles d'autorisation (voir plus haut)).


Quelques portes cachées vers le graal

Il existe plusieurs points d'entrée qu'un attaquant se fera un plaisir d'utiliser pour atteindre sa cible. Il s'agit de service qui, une fois activé, offre une interface Web qui sera plus ou moins bien protégée ... (qui a dit que ça pourrait être accessible depuis Internet ??? ;)
Il pourra notamment compromettre l'application via les interfaces d'administration souvent mal protégée (d'après quelques recherches sur google ...).

• http://serveur:port/chemin_vers_WGate/service/!?variable
• http://serveur/scripts/wgate/webgui!?~client=000
• http://serveur:port/chemin_vers_WGate/admin/!

Conclusion

Voilà, c'est terminé pour la formation. Je n'ai pas été exhaustif mais je pense avoir fourni un bon aperçu. Ici, nous avons surtout vu les différents points de sécurité à aborder pour la sécurisation d'un système SAP ... ou les vecteurs d'attaque pour un attaquant.
Nous ne serons pas sans reparler de SAP car deux confs sont prévus sur le sujet. Aussi, j'espère trouver l'occasion de vous faire un retour d'expérience sur un audit afin d'illustrer cette théorie par la pratique :)

[HITB Conference] SAP Hacking - Overview 1/2

Après le SSTIC, on enchaîne avec le HITB à Amsterdam et cette fois, je vais essayer de tenir le rythme pendant les quatre jours pour mettre à jour mon blog quotidiennement. Inscrit à la formation SAP Security, je vais en profiter pour vous donner un aperçu ces deux premiers jours. Plus tard, il me restera à vous donner un exemple pratique ;)

A quoi ressemble la bête ?

SAP, c'est un ERP utilisé par pas mal d'entreprise car en gros, ça permet de gérer sa production de bout en bout. Par contre, c'est lourd à mettre en place et la sécurité est rarement la priorité des intégrateurs. Rien de nouveau, c'est souvent comme ça. Mais ça veut juste dire aussi qu'il y a moyen de s'amuser ;

Alors plutôt que de vous faire un cours sur SAP (d'ailleurs, je ne suis pas expert !), je vous donne les éléments principaux à prendre en compte pour sa sécurité.

• Le cœur est représenté par le système SAP contenant notamment la base de données (ex : Oracle) ;
• Dans cette base de données, se trouvent généralement des choses très intéressantes :p ;
• Pour se connecter à la plateforme SAP, on bind avec des clients, à considérer en tant que passerelle en fait. Concrètement, on peut utiliser comme interface de connexion SAPGUI et s'attaquer à ces clients. Vous allez chercher cette outil et vous allez vous rendre compte qu'il est payant. Et comme il ne vous viendrait pas à l'idée d'utiliser une version crackée, il existe en fait une version JAVA gratuite ici ;
• Il est possible de se connecter depuis l'extérieur au clients SAP. Dans ce cas, une ou deux couches s'interposent : le SAP Router et le Webdispather. Nous reparlerons de ces deux éléments plus loin ;
• SAP, c'est quand même bien complexe et quand ça marche, c'est déjà bien. C'est pour ça que la sécurité est souvent laissée de côté ...
  

Malgré tout cela, je ne voudrais pas que vous soyez perdu. Je penserai donc à ajouter un schéma.


La sécurité de SAP (depuis l'externe généralement)

Comme promis, nous allons parler de deux composants clés qui permettent d'apporter la sécurité à l'architecture SAP. Ces composants sont utilisés pour les connexions venant de réseaux qui ne sont pas de confiance généralement (ex : Internet).

Le SAP Router

Pour commencer, le SAP Router. On le retrouvera généralement sur le port TCP/3219. Il permet notamment de filtrer les IPs autorisées à communiquer avec les clients SAP. 3 niveaux de permission sont possibles :

• D pour deny ;
• P pour permit ;
• et S pour ne permettre que les flux SAP (ce qui est contournable ...) ;

Par défaut, ce composant fonctionne par liste blanche, ce qui est un bon point ... sauf si l'administrateur finit par mettre une règle équivalente à "permit any any" parce qu'il n'a pas le courage d'écrire toutes les autorisations et encore une fois, il faut que ça marche avant tout !
Pour chaque règle, nous pourrons associer à l'IP (ou plage d'adresse IP) autorisée un mot de passe (clé partagée). Pour être plus clair, voici un exemple de fichier de règles :

S 192.168.1.* SAPROUTER * motdepasse
D * * * *

Autre lacune du SAP Router, ces mots de passe sont visibles en clair dans le fichier de configuration. Dans le cas où le SAP router est bien configuré, il faudrait prendre la main sur la machine d'un utilisateur ayant la bonne adresse IP. Ensuite, comment obtenir un compte ? C'est en clair dans les profiles de l'utilisateur ...

Le Webdispatcher

Cette fois, nous nous attaquons à la couche applicative. A l'instar du SAP Router, le Webdispatcher va fonctionner à partir d'une liste blanche mais concerne les URLs autorisées cette fois (et non plus les IPs / services).
Il existe un compte par défaut qu'il peut être intéressant de connaître : icmadm. Mais le mot de passe est généré aléatoirement. On peut toujours essayer de trouver le mot de passe : l'interface d'administration se trouve à l'adresse suivante :

http://host:port/sap/wdisp/admin/default.html

Le Webdispatcher peut avoir d'autres fonctions comme la répartition de charge (load balancing) et le chiffrement des communications (de bout en bout ou non selon que l'on souhaite analyser les flux par exemple).

Pour terminer, voici un exemple de fichier de configuration (on retrouve les P et D pour respectivement Permit et Deny) :

P /sap/authorized.cgi
D *.php
D *

La sécurité de SAP en général

Instances SAP

Pour attaquer les instances SAP, nous aurons besoin de deux éléments :

• l'ID de l'instance (SAPID) ;
• un compte (login / mot de passe).

Concernant le premier élément, il est généralement le même que l'instance de la base de données. Si nous trouvions ce dernier, nous aurions de grandes chances d'avoir l'élément recherché.
Quant aux comptes, il en existe par défaut. En effet, à part les 3 clients SAP créés par défaut, les autres qui seront générés auront pour couple login / mot de passe :

SAP* / PASS

Les autres composants

L'architecture SAP dispose d'une base de données et d'un système d'exploitation au moins sur lequel repose la base de données. Plusieurs solutions peuvent être mises en place : Oracle, Informix par exemple côté base de données. Linux et Windows côté OS. Ces éléments clés au sein de l'architecture devront eux aussi être sécurisés.
Il y aurait beaucoup à dire et il ne s'agit pas d'éléments spécifiques à proprement parlé. Nous ne détaillerons donc pas ces points mais il est important de noter qu'ils doivent être traités afin de ne pas constituer les maillons faibles de l'architecture mise en place.


Petite conclusion

Nous avons commencer à aborder la sécurité de SAP tout en voyant des pistes potentielles d'attaques durant nos explications.
Pour faciliter la tâche d'un auditeur (ou d'un attaquant ...), il existe des plateformes d'audit tels que BIZSPLOIT dont je ne manquerai pas de vous parler et SAPSPLOIT sur lequel je reviendrai aussi puisqu'une conf y sera dédiée.

[ARJEL] Sécurité et jeux en ligne

Depuis peu, les jeux de pari en ligne sont autorisés sur la toile en France, à l'exception des jeux de poker qui le seront très prochainement. Un enjeux évident de sécurité entre en considération. Quand on annonce 2 milliards de chiffre d'affaire sur ce marché, il y a de quoi attirer des joueurs honnêtes ... et d'autres moins honnêtes.

L'ARJEL, qu'est ce que c'est ?

L'ARJEL, c'est l' "Autorité de Régulation des Jeux En ligne". Elle a pour rôle de s'assurer notamment que les jeux proposés en ligne se déroulent selon des règles bien précises en termes de législation outre les règles mêmes du jeu. Cette autorité a largement considéré la sécurité dans son cahier des charges. Un opérateur ne pourra légalement proposé ses jeux en ligne que si et seulement s'il est en accord avec ce cahier des charges. Nous allons montrer quelques points de sécurité à respecter dans ce cadre de jeux en ligne.

L'ARJEL, concrètement, ça donne quoi ?

Pour connaître exactement les exigences requises par l'autorité, le lecteur pourra se documenter en lisant le cahier des charges établi, téléchargeable ici.

S'il y a bien un principe à retenir, c'est la traçabilité. En l'occurrence, les opérations de jeu doivent être tracées. Il doit être possible de retrouver les actions d'un joueur à travers les logs. Mieux, les traces doivent être archivés de manière sécurisées afin de s'assurer de l'intégrité des logs. Plus précisément, les traces doivent être :

• horodatées ;
• chaînées ;
• scéllées ;
• à la disposition de l'ARJEL.

Au total, les traces doivent être conservées pendant 5 ans.

Un deuxième principe à mettre en place est la confidentialité des données. Pour cela, il est demandé à ce que les communications soient chiffrées. De plus, les moyens cryptographiques mis en place doivent suivre les bonnes pratiques. Notamment, le niveau de sécurité doit être suffisant pour les points suivants :

• le générateur de nombres pseudo-aléatoires ;
• l'algorithme de hashage ;
• les algorithmes à base de clés symétriques ou asymétriques employés.

L'ARJEL tient compte aussi de l'architecture de la plateforme de jeux en ligne. Tout d'abord, plusieurs composants sont définis : un frontal (en lien direct avec l'utilisateur), la plateforme de jeux (partie applicative pure), la plateforme de l'ARJEL avec un lien entre l'opérateur et l'autorité : cette dernière doit en effet pouvoir récupérer des données à tout moment à des fins de contrôle. Ensuite, des équipements de sécurité sont attendus comme des équipements de filtrage. Concernant les systèmes eux-mêmes, il est attendu qu'ils soient sécurisés (mise à jour, pas de mot de passe par défaut, durcissement système, etc.).

Concernant les contrôles justement, des audits périodiques et/ou à la demande devront être réalisés. Ces audits devront s'assurer de la sécurité du logiciel de jeu et du respect des règles. L'audit technique sera étendu à l'audit de code pour vérifier en profondeur la sécurité du logiciel.
Le contrôle pourra être fait ponctuellement par l'ARJEL en accédant au coffre-fort de l'opérateur où seront archivés les traces des opérations de jeu. L'autorité devra donc y avoir un accès.
Ensuite, des moyens de supervision doivent être mis en place. Pour terminer, l'identité du joueur doit être considérée afin de pouvoir l'identifier justement et s'assurer qu'il n'est pas interdit de jeu.

Pour obtenir l'agrément, des critères rigoureux doivent être respectés tels que :

• une certification CSPN ou mieux pour le coffre fort ;
• une authentification forte doit être nécessaire pour se connecter au coffre fort (avec une gestion de droits d'accès selon 4 profils définis) ;
• un reverse-proxy applicatif ou une solution similaire doit être déployée en frontal ;
• l'horloge utilisée doit être considérée comme fiable, c'est à dire à + ou - 1 seconde de l'UTC ;
• une architecture en haute disponibilité doit être mis en place.

L'ARJEL va encore plus loin en termes de sécurité dans le sens où elle va au-delà de la sécurité technique. D'une part, la sécurité organisationnelle est prise en compte avec par exemple :

• la gestion des incidents ;
• le plan de sauvegarde ;
• l'organisation (humaine, implémentation géographique, politique de sécurité, etc.)
• etc.

D'autre part, la sécurité physique :

• contrôle d'accès physique ;
• gestion du personnel ;
• etc.

Pour conclure ...

Il faut dire ce qui est, l'ARJEL a voulu faire les choses bien et les gens qui s'y sont penchés y connaissent vraiment quelque chose (qui a dit que ce n'était pas toujours le cas ??? ;)
Outre des exigences, elles sont réalistes. Pour preuves, des pistes d'implémentation sont fournies (ex : process de traçabilité).
Aussi, l'autorité a tenu compte de a sécurité selon les différents axes : techniques organisationnel et physique.
Le cahier des charges n'est pas encore terminé mais à ce jour, il fournit déjà toutes les chances que les jeux se déroulent avec les mêmes chances pour tous :)

[SSTIC 2010] Day 3

Une troisième journée qui finit en beauté cette édition 2010 !

Matinée

Trusted Computing : limitations actuelles et perspectives

Euh ... ça avait l'air intéressant ... ;)


JBOSS AS : Exploitation et sécurisation

Voilà un sujet qui m'intéresse beaucoup pour plusieurs raisons :

• ça parle de pentest et ça, je kiffe ! ;)
• on rencontre souvent ce genre de plateforme durant les audits ;
• j'avais abordé ce sujet dans un MISC avec un collègue : ravi de voir les nouveautés.

Après avoir rappelé les travaux déjà réalisés sur le sujet (par la RedTeam notamment), l'orateur a abordé la sécurité des nouvelles versions, ie JBOSS 5 et 6. En résumé, c'est mieux mais il reste toujours des failles exploitables ! En effet, la sécurité n'est pas appliquée par défaut ou alors mal (on se souvient de la sécurité des interfaces d'administration sur les requêtes GET et POST uniquement ...). La sécurisation est possible mais malheureusement, rarement prise en compte dans les entreprises, en démontrent les cas rencontrés lors des audits.


Audit d'application .NET complexes / Nicolas Ruff

Le retour de Nicolas ! Autant sa conf de l'année dernière avait pour but d'apporter une ouverture d'esprit sur la SSI en admettant ses échecs et d'aborder avant tout une reflexion, autant ici, c'est un sujet technique qui nous a été présenté. La démonstration a été réalisée avec une aisance déconcertante.
Le code .Net est passé au peigne fin et l'exemple d'une application Microsoft fait mouche : on bypass le formulaire de licence d'un produit de karaoké.
Seul regret, nous n'avons pas eu l'occasion de découvrir les talents de chanteur de Nicolas ! ;)


MLState, langage OPA / Mathieu Bodet

Disons que cette conférence m'a permis de comparer mon N900 avec le futur iPhone 4 de mon voisin ...
En fait, cette conférence aurait pu être bien car elle traitait d'un sujet que nous rencontrons chaque jour lors de nos audits : la non sécurisation du code qui amène diverse injection. Basée sur des langages sûrs (e.g. OCaml), la solution présentée apporte certainement beaucoup par sa complexité et son niveau de technicité. Pour avoir touché du doigt ce type de langage, je peux vous assurer que ce n'est pas simple. Malheureusement, l'orientation de la présentation était mal choisie avec une présentation des attaques WEB en guise d'intro ... qui a duré 40 minutes ! :(
Vraiment dommage mais je serai ravi de voir une présentation qui entre dans le vif du sujet dès les premières minutes et comprendre comment la solution permet de pallier aux lacunes de sécurité aux sein des codes et jusqu'à quel point.


Après-midi

PoC(k)ET, les détails d'un rootkit pour Windows Mobile 6 / Cédric Halbronn

J'avais déjà vu cette conf lors du séminaire de l'ESEC et encore une fois, Cédric nous montre qu'il est possible de tout faire avec un Windows Mobile 6 : pour l'utilisateur ... mais aussi pour un attaquant. Pour avoir échangé pas mal avec le sujet avec Cédric, on se rend compte qu'on ne peut malheureusement pas faire grand chose (OS multi utilisateur, manque de paramétrage sécurité nativement, facilité de contournement des protections, ...).
Problème, on se rend compte qu'une fois le rootkit installé (via la mémoire, via le WAP Push), l'attaquant a notamment accès à toutes les données confidentielles contenues sur le smartphone. Bon, bah ça, c'est fait !


Projet OsmocomBB / Harald Welte

La suite de la présentation du même orateur : Projet OpenBSC
Lors des deux conférences, on a le droit à du haut niveau ! On parle ici des réseaux GSM et de leur faiblesses sécurité. C'est un gros travail qu'a réalisé Harald en décortiquant les spécifications des réseaux GSMs. il nous fait alors un état de l'art de ces réseaux. Mais plus que la théorie, on a le droit aussi à la pratique.
En créant son propre réseau, Harald maîtrise le sujet et à travers sa maquette montre les possibilités en termes d'attaque. Et on ne voit qu'une chose : rien n'arrête notre orateur !


L'ANSSI / Patrick Pailloux

Le directeur de l'agence nationale de la sécurité (anciennement DCSSI) nous décrit l'agence et ses travaux. En plus des audits pour les différentes administrations, l'agence traite de sujets très intéressants et concrets tels que la sécurité des bracelets électroniques pour prisonniers, la sécurité des systèmes de votes électroniques, etc.
Clairement, ici aussi, ça recrute ! Alors on note une petite concurrence DGSE / ANSSI mais tout à fait cordiale ;)


Voilà, c'est la fin de l'édition du SSTIC. Cette année, j'ai apporté mes commentaires (trop ?) en retard mais va falloir faire mieux la prochaine fois ! :) J'aurais la chance de participer au HITB au début du mois prochain : j'essaierai de vous donner un retour au plus vite pour me rattraper ;)

[SSTIC 2010] Day 2

Une deuxième journée plus intéressante selon moi ;)

Matinée

Sécurité de la plateforme d'exécution JAVA : Limites et propositions d'amélioration

Après une brève présentation du fonctionnement particulier de JAVA, les orateurs nous ont montré les limites de ce langage. Pourtant, ce dernier bénéficie de mécanismes de sécurité et c'est loin d'être le cas de tous les langages. En l'occurrence, des contrôles sont réalisés à trois niveaux :

• à la compilation ;
• au chargement de la classe ;
• à l'exécution pour les instructions dangereuses.

Malheureusement, des faiblesses sont bien connues à propos de ce langage. D'ailleurs, le dossier du MISC n°45 était consacré à ce sujet. En particulier, les vulnérabilités sont dues à une mauvaise utilisation des mécanismes de sécurité (quand ils sont employés ...), le niveau de privilège des bibliothèques standards et l'éternel soucis de performance au détriment de la sécurité.
Pour résumer les solutions proposés, nous pouvons citer :

• la formulation d'un guide de développement et de configuration des paramètres ;
• un audit du code pour les fonctions sensibles ;
• l'application des bonnes pratiques comme limiter le nombre de bibliothèques utilisées ;
• augmenter la confiance dans la JVM et profiter de ses possibilités.

Analyse de l'efficacité du service fourni par une IOMMU

Un bon topo sur les protections et les limitations d'une IOMMU. Une démonstration qui a bien marché. Bref, intéressant ! En résumé, un tel système de protection permet de contrôler les accès aux périphériques et à la mémoire. Cependant, des faiblesses sont notés concernant les périphériques PCI ... tiens tiens, nous n'en n'aurions pas parlé avant de ça ??? Une piste qui a été exploitée ici aussi en montrant l'interception de flux (ici du flux vidéo) entre deux machines.


Quelques éléments en matière de sécurité des cartes réseaux / Loïc Duflot

Alors là, on s'attaque à du lourd ! Quand on parle de mener nos célèbres attaques MITM sur la toile directement, on ne rigole plus. Vous avez rêvé de contrôler le réseau (via la carte réseau donc) de quiconque sur Internet ... ils l'ont fait !
Bon, j'exagère un tout petit peu et il s'agissait d'un POC mais qui semble bien marché et qui pourrait faire très mal si ces connaissances étaient entre les mains d'attaquants ...
Pire, ce dernier a tout le temps d'agir vu les temps extrêmement lents pour la correction d'un firmware dur ce type de matériel.


Après-midi

La sécurité des systèmes de vote / Frédéric Connes

Il s'agissait ici surtout d'une proposition d'une réflexion, d'un protocole pour la sécurisation des systèmes de vote électronique. C'est un sujet qui fait débat car il est difficile d'apporter un niveau de sécurité fort sur ce sujet alors que l'enjeu est très important. Et qui plus est, certains états aux USA en ont de mauvais souvenirs ...
Dans le même temps, les Français prennent de moins en moins la peine d'aller voter (il suffit de regarder les taux d'abstention pour s'en rendre compte de suite) et il s'agit d'une solution qui en soit pourrait apporter une solution ... sur le plan pratique en tout cas car sur le plan de la SSI, cela soulève de nouveaux problèmes.


Applications Facebook : Quels risques pour l'entreprise ?

Une présentation intéressante dans le sens où l'expérience a été bien mené. Maintenant, pourquoi parler de l'entreprise alors que ce genre d'application ne devrait certainement pas être autorisé au bureau. Il existe certainement des réseaux sociaux plus appropriés. Et finalement, je dirai que les utilisateurs chez eux sont certainement plus impactés.
Pour en revenir à la présentation elle-même, les deux orateurs ont voulu faire une démonstration d'une application malicieuse et ils l'ont fait sérieusement ! Après avoir récolté un maximum de membres via une application dont le rôle était de savoir qui nous a supprimé de ses contacts, ils nous ont montré que de multiples informations personnelles ont pu être obtenues. Ils ont aussi montré au passage quelques faiblesses sur le cloisonnement apporté par les applications.
De plus, je pense que les idées qui permettraient de "piéger" un grand nombre d'utilisateurs sont certainement nombreuses : il suffit de voir les communautés déjà existantes (qui ne se préoccupe pas de l'orthographe d'ailleurs ;) et qui suscitent souvent la curiosité des utilisateurs.


Projet OpenBSC / Harald Welte

Je reprendrai cette très bonne présentation dans le billet suivant où un sujet similaire a été traité.


Les rumps sessions

Alors pas de rumps "fun" cette année. il faut dire que nous étions bien servis l'année dernière, notamment avec l'alcootest relié au PAM ;) mais plusieurs rumps sur les pentests (mon sujet de prédilection !) comme le pentests d'un blackBerry Server, le case study d'un pentest d'une société X (ou Y :)), l'exploitation d'Oracle, etc... Bref, frustrant de voir ces sujets abordés en 5 minutes seulement.

[SSTIC 2010] Day 1

Une nouvelle éditions, de nouvelles conférences et des choses nouvelles ... ou pas !

Matinée

Systèmes d'information : les enjeux et les défis pour le renseignement d'origine technique / Bernard BARBIER / DGSE

Nous pouvons dire que cette édition commence de manière plutôt originale : une présentation de la DGSE ... qui a dit un entretien de recrutement ? :) Sérieusement, passionné par ce milieu, j'ai écouté attentivement ce keynote. La présentation a permis notamment de démystifier ce milieu et de montrer ce qui se passe dans la vraie vie. Bon, je connaissais un peu pour connaître une certaine personne mais chuuuuuuut ... on nous écoute peut être ?
Globalement, on apprend les différentes briques du renseignement en France, l'organisation du renseignement qui est fondé sur le triptyque "voir - sentir - écouter". On ne nous annonce pas que la France est la meilleure dans le domaine (je tiens à le dire car j'en ai vu des conférenciers chauvins ! ;) mais on apprend qu'on s'en sort pas mal et surtout que les menaces sont connues, priotisées et manque "juste" les moyens. Notre pays a pour but de recruter dans ce sens et améliorer encore ses services de renseignements. Les déclarations sur la LIO (ou Lutte Informatique Offensive) font leur effet et on le verra lors de conférences qui suivront. Cependant, Bernard BARBIER, notre orateur, estime qu'il faut avant tout savoir se défendre : "c'est pas faux !".


Tatouage des données d'imagerie médicales / Gouenou COATRIEUX

Quand j'ai lu le titre de la conf, je me suis dit : "encore du watermarking ! mais qu'est ce qu'on va apprendre ?". En effet, nous avions déjà eu une conférence à ce sujet l'année dernière et elle était, à mon goût, très bien faite alors qu'est ce que cette conférence pouvait apporter de plus ? En réalité, un angle tout à fait différent a été abordé ici puisqu'il s'agissait de traiter le sujet dans une tout autre domaine que le média : le domaine médicale et aussi, de prendre en compte de nouvelles contraintes. Donc finalement, cette conférence avait bel et bien un intérêt mais nous restons cloisonné à un milieu particulier qu'est la médecine et il est rare que nous ayons à travailler dans ce domaine ... mais c'est peut être ça le problème ! Un ver du nom de confiker dans les scanners médicaux, ça ne vous rappelle rien ? On n'en parlait justement ce soir devant un verre (et oui j'ai pris un coca et j'assume même publiquement ! :)). C'est donc au sens large qu'il faudrait s'intéresser à la sécurité dans le milieu de la médecine.


Visualisation et analyse de risque dynamique pour la cyber-défense / Philippe LAGADEC

Les termes clé de cette présentation sont la "défense dynamique". Plus précisément, il s'agit de répondre aux attaques menées sur un SI en direct. Pour cela, quatre principes sont pris en considération :

• Observe ;
• Orient ;
• Decide ;
• Act.

Pour observer, nous savons faire et ce ne sont pas les moyens qui manquent. Et justement ! En effet, de nombreux équipements et devices en général nous remontent des logs. Mieux, il existe des aggrégateurs de logs. Encore mieux, des corrélateurs de logs que nous appelons SIM (Security Information Management). Cependant, les outils du marché ne sont pas satisfaisant ou en tout cas, pas toujours.
Petit souvenir : je vous parlais de l'outil OSSIM il y a un bon moment déjà et il fait partie de la famille des SIMs. Le défi de l'outil présenté était de rendre l'exploitation de logs la plus simple possible et surtout utile ! Et ce, afin de prendre les bonnes décisions et d'agir en conséquence pour se défendre et voilà, la boucle est bouclée. Et l'outil y parvient dans le sens où il permet d'avoir in fine une cartographie des machines exposées graphiquement et dans une interface qui semble ergonomique. Pour obtenir de tels résultats, il est possible de customiser l'outil en attribuant des valeurs aux assets et la criticité en sera ainsi mieux évaluée.
En réalité, OSSIM faisait déjà pas mal de choses. Je passerais sur les défauts de ce dernier mais il apportait déjà pas mal d'éléments pour la customisation et la cartographie par subnet en moins convivial et ergonomique bien sûr. Alors cette présentation nous a montré une solution qui permettra aux décisionnaires d'avoir de l'information utile et pas seulement du "bruit" car ne l'oublions pas, "trop d'information tue l'information". Quand il s'agit de traiter des événements, les solutions finissent régulièrement dans un placard car trop complexe.
Néanmoins, une petite déception qu'il n'y ait pas eu plus d'avancée dans ce domaine depuis tout ce temps. Ou alors les améliorations se situe sur des aspects plus techniques qui n'ont pas été abordés ?


CASTAFIOR : Détection automatique de tunnels illégitimes par analyse statistique / Fabien ALLARD et Mathieu MOREL

Voilà un sujet nouveau et intéressant ! Nous restons dans la défense de l'information pour protéger son S.I. Il s'agit ici de repérer les flux illégitimes qui y transitent. plus précisément, il ne s'agit pas d'une solution de prévention car les flux illégitimes sont repérés ... une fois qu'ils ont été transmis ! Mais la solution CASTAFIOR qui permet de faire ça a pour objectif de les localiser et de pouvoir entreprendre des actions de forensics afin de trouver notamment les auteurs de ces flux illégitimes.
Et comment fait-on ? Afin de classifier les flux selon leur protocole, plusieurs paramètres sont pris en compte et leur agrégation permet de se faire une idée relativement précise de sa nature. A titre d'exemple, les paramètres en question pourront être la durée d'un flux ou le nombre de paquets échangés entre le client et le serveur ou le temps de latence entre chaque échange, etc.)
Les données sont récupérées tout simplement via TCPDUMP pour analyse. Une fois l'analyse réalisée et le flux classifié, il pourra être traité en conséquence. Une interface graphique a été implémentée dans la solution CASTAFIOR afin de gérer les flux considérés comme illégitimes. En combinant deux méthodes d'analyse que sont RandomForest et BHM, des résultats tout à fait satisfaisant ont pu être obtenus.
Bien sûr, des améliorations sont toujours possibles mais dans le domaine, il existe peu d'équivalent et ce type de solution pourrait servir dans ces nombreuses entreprises (qui a dit "toutes ou presque" ?:) où les utilisateurs cherchent à contourner les protections réseau qui sont pourtant si difficiles et parfois lourdes à mettre en place.


Après-midi

Réflexion sur un plan d'action contre les botnets / Eric Freyssinet

Haaaaaaa les botnets ! On en entend parlé de ce fléau et à juste titre. La pérennité et la force de cette menace tient du fait qu'elle repose sur le faible niveau de sécurité que l'on retrouve sur les postes de travail des utilisateurs. Et que ce soit dans le privé ou au sein des entreprises, l'élément que l'on ne maitrise pas est bien souvent le poste de travail. Il suffit aussi de faire quelques recherches sur Google quand une nouvelle vulnérabilité sort pour s'apercevoir combien de machine pourrait être infectées et servir de zombie au sein d'un botnet. Et cette fois, nous parlons aussi de serveurs. Donc un sujet qui a été, est et sera d'actualité. La présentation a permis de formaliser le sujet et de montrer qu'un effort de communication et de recherche est réellement fait à travers la presse et les laboratoires de sécurité informatique.
C'est de manière exhaustive que l'orateur propose un plan d'action qui vise à s'attaquer selon différents axes :

• l'axe humain : on parle alors de sensibilisation ;
• l'axe technique : on parle alors de prévention, de détection et de réaction (les outils existent !) ;
• l'axe juridique : on parle alors de clarification de la législation.

L'étape suivante consisterait à synchroniser tout ça ...


Virtdbg, un débogueur noyau utilisant la virtualisation matérielle / Damien Aumaître et Christophe Devine

Bon, certains diront que je suis partie pris mais pour moi la meilleure conférence de la journée. Une évolution dans les travaux de Damien qui ne cesse de repousser les limites de l'accès système. Avec Christophe, on assiste à un duo de choc. L'objectif de cette conférence est d'obtenir un accès via le bus PCI (alors que le bus Firewire avait été utilisé l'année dernière). En l'occurrence, l'équipe a basé sa solution sur l'hypervision et la furtivité (notamment en reprenant les technos des rootkits évolués). Bon, je ne rentrerai pas dans les détails car on passe à un autre niveau ;)
Lors de la conférence, le duo a ciblé un Windows 7 : encore un succès ! Il reste encore des améliorations possibles mais charge à nous d'être patients aussi ... jusqu'à l'année prochaine !



Intéressez-vous au droit ... avant que le droit ne s'intéresse à vous / Eric Barbry

Comme tous les ans, une conférence sur le droit en matière de sécurité des systèmes d'information nous est présentée et c'est bien. D'ailleurs, aucune présentation sur la sécurité organisationnelle cette année. En effet, la sécurité de l'information a besoin d'être traitée sous les angles techniques, organisationnels et juridiques pour arriver à ses fins (ou du moins, faire de son mieux).
Ici, une présentation dynamique qui nous a permis de faire le tour des différentes lois touchant la SSI. Nous ne sommes pas rentrés dans le détail des lois mais ce n'était pas le but. En fait, l'orateur souhaité surtout apporter un discours plutôt percutant et nous montrer notre implication à tous vis-à-vis des lois sur le sujet. Avec les nouvelles lois telles que le fameux "article 34" et la fameuses (pour d'autres raisons ;) loi Hadopi, entreprises et utilisateurs sont aujourd'hui impliqués qu'ils le veuillent ou non. En effet, chacun a des obligations et chacun est tenu d'y tenir. Bref, va falloir être carré !

[DISCOVERY PHASE] Rock it!

Tout bon test d'intrusion devrait commencer par une phase de découverte. Les tests se déroulent sur des durées très courtes (en général, quelques jours) et le seul moyen de s'imprégner de la cible, c'est d'apprendre à la connaître. Mais voilà, où aller dans le temps imparti ? Il y a certainement des choses à automatiser.


Pourquoi ce post ?

Une phase de découverte est une étape que l'on réalisera systématiquement. Et il y a des tests récurrents et avouons-le, autant cette phase de découverte est importante, autant on a qu'une hâte pendant un "TI" comme disent les habitués, c'est de passer à l'attaque ! Alors je propose ici de donner les pistes pour se constituer un script dédié à la phase de découverte.
Dans le même temps, on donne en fait une synthèse des outils de découverte qui nous sont bien utiles tous les jours :)
NB : En fait, il existe certainement déjà des outils qui font ça. Cependant, je vous propose ici ma version selon mon retour d'expérience.

Et ce post est particulier dans le sens où il est ouvert : vos avis sont les bienvenus (comme toujours d'ailleurs tant qu'ils sont constructifs ;).


Y a quoi au programme ?

1/ Que se passe-t-il en couche 3 ?

On commence ici par analyser les requêtes ICMP. Qu'est ce qui est autorisé ou non ? Du ping aux requêtes TSTAMP en passant par le traceroute ICMP, un bon filtrage de la cible est requis sinon, nous serons en mesure de cartographier la cible. Rien de compliqué ici puisque les outils en question sont bien connus (Ping, Traceroute, Sing, etc.) mais utilisons nous bien les options de ces outils ?

2/ Qui est notre cible ?

Internet recèle souvent des informations très intéressantes sur notre cible. En vrac, nous pouvons citer :

• les requêtes de type WHOIS (ex : Dmitry) ;
• les scripts permettant de rechercher des noms/emails d'employés tels que theHarvester ;
• les scripts permettant de récupérer les documents (malencontreusement ?) égarés sur le Net tels que metagoofil ;
• A compléter avec les recherches Google : je vous renvoie vers le site de référence à ce sujet, le site de Johnny LONG.

3/ Les requêtes DNS

Très importantes pour trouver de nouvelles machines ou pour mener certaines attaques, ces requêtes devraient être prise en compte. Les outils ne manquent pas, voici ma sélection :

• dnsenum ;

# perl dnsenum.pl --enum -f dns.txt cible

• fierce

# perl fierce.pl -dns cible

4/ On passe aux requêtes UDP et TCP

On ne peut pas passer à côté de celui là, je parle du scan de port ! Pour le coup, il existe des tonnes d'outils mais si nous ne devons en citer qu'un seul, c'est bien NMAP (et NASL pour faire plaisir à l'agent M. ;)).

En plus de réaliser un scan TCP et un scan UDP que nous utiliserons avec l'option -oG pour approfondir avec l'outil AMAP. Nous n'oublions pas HTTPRINT pour les services WEB.

Pour compléter, nous pouvons aussi utiliser SinFP qui approche une démarche différente pour fournir des résultats supplémentaires.


5/ Tests sur l'architecture

Les premiers tests permettent de déterminer différents équipements déjà :

• les routeurs (ex : avec Traceroute) ;
• les pare-feux (filtrage ICMP / UDP / TCP) ;
• les serveurs DNS (requêtes DNS paramètre NS) ;
• les serveurs de messagerie (requêtes DNS paramètre MX) ;
• présence d'autres machines (e. g. requêtes DNS) ;
• découverte des services présents (e g. scan TCP et UDP) ;
• etc.

A cela, nous pouvons ajouter la découverte d'autres équipements comme les load-balancers (ex : avec le script lbd.sh) ;


6/ Tests WEB

De nouveau, voici une petite sélection pour mieux comprendre l'application WEB :

• Trouver de nouveaux répertoires et nouvelles pages (ex : list-urls.py) ;
• Vérifier la sécurité des communications SSL si implémenté (e. g. commandes openssl) ;
• Vérifier les méthodes autorisées (ex : metoscan) ;
• Etc.

Nous pouvons compléter avec des classiques comme Nikto mais personnellement, je préfère Wikto qui permet de faire pas mal de choses. Bon, il est un peu violent quand même ;)

Voilà un ensemble de tests qui devraient nous permettre de récupérer pas mal d'information sur notre cible. Après, comme toujours, il faut savoir s'adapter.
Je crois que nous sommes prêts pour passer aux choses sérieuses !!!

Have fun!

[INTERNAL PENTESTING] Windows Hacking

De retour pour un post qui ne devrait pas manquer d'intérêt. Notre mission du jour est de trouver tous les postes ayant un compte administrateur local connu. Dans notre quête de prise de contrôle de l'AD, ceci devrait être bien utile ...


Contexte (rapide)

Lors d'un test d'intrusion interne, le scénario ressemble souvent à ça :

1. J'ai un poste utilisateur et j'ai un compte utilisateur => je deviens administrateur local ;
2. En général, tous les postes de travail ou presque ou du moins un bon groupe ont le même mot de passe pour le compte administrateur local => nous pouvons donc nous connecter avec ce compte sur d'autres PCs ;
3. On récupère tous les comptes du domaine sur tous les postes en priant que l'un d'entre eux contient un compte ayant les droits "Admin du domaine". Des outils nous permettent de connaître les comptes recherchés.

C'est pas mal tout ça mais ça prend du temps, ce n'est pas très ciblé et donc pas très discret. On admet donc que le compte administrateur local est en notre possession (vous savez autant que moi comment faire ...) et alors, c'est là qu'entre en jeu l'outil keimpx. Démonstration ...


Installation

Voici les étapes à suivre pour installer l'outil :

1. Commencer par le télécharger, c'est un programme python ;
2. Si vous le lancez tel quel, vous aurez certainement des erreurs. Vous aurez donc sûrement besoin d'installer py2exe que vous pouvez trouver ici ;
3. ça ne marche toujours pas ? Normaaaaaaaaaal ;) En réalité, il vous faudra télécharger les classes Python Impacket (de Core Impact : hé oui, le tool est d'eux). Tout est ici.

Cette fois, vous n'avez plus d'excuse si ça ne marche pas ;)


On passe à l'action !

Pour le lancer, c'est très simple. Vous pouvez soit cibler une seule machine avec -t adresse_cible ou une liste de machine avec -l fichier_texte_avec_liste. Ensuite, vous utiliser l'option -U utilisateur -P mot_de_passe.
NB : Vous pouvez aussi utiliser les hashes : pratique !
Vous pourrez voir par vous mêmes les résultats de l'outil mais avant de voir ces possibilités, j'ai ajouté ma petite touche personnelle alors mieux que des mots, illustration !


Petite touche personnelle ...

J'avais deux choses à reprocher à l'outil en l'essayant une première fois sachant qu'en audit interne, nous sommes souvent confrontés à un grand nombre de poste de travail alors essayons de gagner en rapidité et en efficacité.
En effet :

• quand on choisit de donner une liste d'hôte en paramètre, on ne peut utiliser de plages d'adresse de type 172.16.1.0-172.16.4.255 et je ne me vois pas écrire toutes les adresses une à une dans un fichier ... Ou alors, je n'ai pas vu la bonne syntaxe ?
• keimpx va tester les credentials pour toutes les machines de la listes et c'est assez long surtout s'il y en a beaucoup.

Alors à ces deux points, j'ai rédigé un petit script (oui oui, j'aurais certainement pu trouver "tout fait" sur le Net mais un peu de scripting à la bourrin, càd tout ce que je sais faire, fait du bien de temps en temps ;)) :

• mon script prend en paramètre un fichier texte contenant des plages d'adresses et/ou des adresses uniques pour en faire une liste d'hôtes unique que keimpx saura gérer ;
• dans cette liste, je ping les machines pour connaître celles qui répondront. Les autres ne seront alors pas traitées par keimpx et là, on gagne du temps !
  

J'ai donc une liste de machines "optimisée" dans le sens où elle devrait être exhaustive sans avoir eu à taper 298361 adresses IP à la main, et en ne gardant que celles qui répondent. Pour terminer, mon script ne fait que lancer keimpx avec cette liste et les credentials sensé être connus (hypothèse) :



Je parle de keimpx depuis tout à l'heure mais quelles sont ces possibilités en fait ? Petite démonstration ;)


Keimpx en action ...

Une fois le traitement de fichier le pinging effectué, Keimpx est lancé. Il nous fournit la liste des machines ayant le couple login/mdp connu pour l'admin local. 2 adresses sont "matchées" ici :

La machine XXX.XXX.XXX.136 est ma machine donc aucun intérêt. On s'attaquera donc à la machine XXX.XXX.XXX.219.
Ensuite, chose intéressante, keimpx nous propose un shell : moi je dis "oui" !


On nous demande donc de choisir la machine cible, ici la deuxième. Puis, les credentials à utiliser. Il n'y a pas le choix : tapez 1 puis entrée.

Ensuite, les commandes (et possibilités) sont nombreuses. En voici quelques exemples :

• Naviguer sur les disques (via les shares) :

#shares

Puis choisissez le disque souhaité, ici C$ :

• Lister les utilisateurs ainsi que la politique de sécurité sur les comptes (extrait) :

#users

• Obtenir un shell :

#shell

Bon bah ça, c'est fait ;)


Conclusion

L'engouement pour les applications WEB et tests externes fait que de nombreux outils existent dans ce sens. Keimpx touche un autre domaine où les outils sont moins présents. Ils ne permettra pas nécessairement de faire plus de chose qu'avant mais il nous servira certainement de couteau suisse de tests internes en nous simplifiant les choses.

Maintenant à vous de jouer pour le tester et découvrir ces autres fonctions.
Have fun!