[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!