Subscribe: MISSION: Security
http://mission-security.blogspot.com/feeds/posts/default?alt=rss
Added By: Feedage Forager Feedage Grade A rated
Language: French
Tags:
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: MISSION: Security

MISSION: Security



Votre mission, si vous l'acceptez, trouver et neutraliser vos ennemis, assurer notre défense et bien sûr, être opérationnel pour l'attaque. Pour cela, vous disposez de la dernière arme créée pour vous : la Sécurité Informatique des SI !



Last Build Date: Mon, 22 Jan 2018 20:01:09 +0000

 



[SMSI] Evalsmsi install

Fri, 28 Jan 2011 21:59:00 +0000

Je continue mes péripéties sur l'étude des SMSI mais je fais une pause sur les normes pour vous présenter un outil permettant l'évaluation des SMSI : evalsmsi. Cet outil avait été présenté par Michel Dubois pendant les rump sessions du SSTIC 2009. Une telle solution, libre qui plus est, je n'en connais pas d'autre : il me paraît donc important de s'y intéresser.En fait, ce poste sert peut-être à rien !Le but de ce post est d'installer la solution mais la réalité, c'est qu'il existe déjà une image virtuelle toute faite et alors, il n'y a rien à faire si ce n'est de l'importer dans sa virtual box. Sauf que me concernant, j'avais des erreurs avec le fichier *.ova alors je ne me suis pas découragé pour autant et j'ai pris le tar.gz (on est joueur ou on l'est pas ;)).Pour faire cela, je suis parti d'une nouvelle image Ubuntu 10.10 donc je reprends tout depuis e début. Certaines choses ne vous seront donc certainement pas utiles. En tout cas, même si l'auteur a pensé à faire un README.txt, je pense qu'un tuto pourra faciliter la vie de certains.Donc ce post va peut-être servir finalement ...Étape 1 : Installation des packagesLa solution repose sur un architecture LAMP. Nous installons les packages en conséquence. Notez que nous devons créer la base de données avant l'installation de phpmyadmin :jer001@ubuntu:~$ sudo apt-get install apache2jer001@ubuntu:~$ sudo apt-get install mysq-serverjer001@ubuntu:~$ mysql -u root -p create evalsmsijer001@ubuntu:~$ sudo apt-get install phpmyadminÉtape 2 : Apporter les restrictions principalesCe serait un outrage de parler de hardening mais un minimum de mesures de sécurité me paraît nécessaire :On commence par changer l'alias pour atteindre l'interface d'administration de phpmyadmin, histoire qu'elle soit moins visible : jer001@ubuntu:~$ sudo vi /etc/phpmyadmin/apache.conf (rajouter cette ligne) :On évite de fournir la version de PHP, question de principe (variable expose_php à Off) : jer001@ubuntu:~$ sudo vi /etc/php5/apache/php.iniOn passe à la configuration d'Apache pour cacher empêcher l'accès au fichier config.inc.ini de phpmyadmin, cacher les bannières, limiter les accès à l'application par filtrage IP :jer001@ubuntu:~$ cd /etc/apache2jer001@ubuntu:~$ sudo vi apache2.conf #rajouter ces lignes ...jer001@ubuntu:~$ sudo vi conf.d/security #vérifier/changer la valeur de ces variablesjer001@ubuntu:~$ sudo vi sites-available/default #rajouter les lignesjer001@ubuntu:~$ sudo /etc/init.d/apache2 reload Étape 3 : Installation et configuration de la solution# Nous installerons la solution dans un répertoire accessible par le serveur WEBjer001@ubuntu:~$ cd /var/wwwjer001@ubuntu:~$ sudo wget http://downloads.sourceforge.net/project/evalsmsi/evalsmsi_2.3.1.tar.gzjer001@ubuntu:~$ sudo tar -xzvf evalsmsi_2.3.1.tar.gzjer001@ubuntu:~$ sudo rm evalsmsi_2.3.1.tar.gz# On attribue les droits du serveurs WEB au répertoire où est localisée la solutionjer001@ubuntu:~$ sudo chown -R www-data:www-data evalsmsi/# On récupère le fichier SQL pour configurer la base de données.jer001@ubuntu:~$ sudo gunzip -d /var/www/evalsmsi/docs/evalsmsi.sql.gzPour lancer les requêtes SQL de ce fichier, j'ai fait simple un copier du contenu du fichier et un coller dans phpmyadmin (onglet SQL) et "Go" (cliquer) :On crée un nouvel utilisateur dans MySQL pour la gestion de la base "evalsmsi". Je le fais via phpmyadmin de nouveau (onglet "Privileges") :On fournit les données de connexions de la BDD à la solution (renseigner les comptes notamment) :jer001@ubuntu:~$ sudo vi /var/www/evalsmsi/functions.phpOn vérifie que tout fonctionne dans l'interface d'Evalsmsi > Cliquer sur "Accès établissement" ...... et entrer les crédences d'un admin (ex : compte admin1). Si ça marche, vous verrez cette page :Success!ConclusionRares sont ceux qui maîtrise la technique et l'organisation de la sécurité. Or, le SMSI est destiné avant tout à cette 2e catégorie de personnes. Alors autant leur permettre d'utiliser une telle solution sans qu'ils soient b[...]



[SECURITY STANDARD] Episode 3: Are you compliant to ... ISO 27003

Wed, 05 Jan 2011 18:45:00 +0000

Dans la continuité de la revue des normes internationales sécurité, il est temps dorénavant de mettre en place le SMSI. Et pour cela, il existe depuis moins d'un an la norme ISO 27003, dédiée à l'implémentation d'un SMSI.Petit résumé avant de commencer ...Comme la norme ISO 27002 et toutes les normes qui vont suivre, il s'agit d'un guide et non d'exigence. L'idée principale est de mettre en place un SMSI en construisant un projet. Il s'agit en effet de déterminer les tâches à réaliser et de les synchroniser correctement dans le temps et d'impliquer les ressources nécessaires pour chacune d'entre elles.Nous allons parcourir cette norme à travers ses clauses 5 à 9 qui nous fournissent les lignes directrices pour le démarrer un projet de SMSI en 5 phases donc qui suivent un ordre logique. Cependant, la norme ne fournira pas d'indication pour faire vivre le système de management en question une fois lancé.Ce que raconte la norme ...Clause 5 : Obtenir l'accord de la direction pour initier le projet de SMSIL'objectif de cette clause est double : obtenir l'accord de la direction et rédiger une première version de la planification du projet de SMSI. Plus précisément, cette clause a pour vocation de définir les besoins en termes de sécurité et de business afin de déterminer les objectifs de la direction et le périmètre qui sera impliqué dans le SMSI. Ceci sera réalisé à travers 3 sous-étapes :Clarifier les priorités qui amènent au déploiement du SMSI ;Définir le périmètre préliminaire du futur SMSI ;Réaliser un plan business et le planning du projet pour approbation.Finalement, nous cherchons ici les axes stratégiques et les raisons d'une telle implémentation à mettre en accord entre les besoins et les exigences. Le fait de définir et de clarifier l'ensemble des composantes du futur SMSI devraient amener à un consensus entre la sécurité et la direction.Clause 6 : Définir le périmètre du SMSI, ses limites et la politique du SMSIPour ceux qui se sont intéresser à la norme ISO 27001, nous retrouvons ici deux documents requis par celle-ci. Rappelons que la certification ISO 27001 est attribuée à un périmètre précis. Il s'agit donc d'une composante importante. Quant à la politique du SMSI, elle représentera le vecteur de développement tout au long du projet. Cinq sous-étapes sont nécessaires cette fois :Définir le périmètre d'organisation et ses limites en termes (ex : responsables et personnes impliqués dans le projet) ;Définir le périmètre IT et ses limites (ex : logiciels, serveurs, technologies, ...) ;Définir le périmètre physique et ses limites (ex : les sites qui feront partie du périmètre) ;Synthétiser les 3 étapes précédentes pour définir le périmètre global et final avec ses limites (attention : toute exclusion doit être justifiée) ;Rédiger la politique du SMSI et la faire valider.Nous savons maintenant sur quoi nous allons travailler. En effet, nous avons correctement cadré le projet de SMSI. Les bases étant posées et approuvées, nous pouvons passer à l'étape suivante.Clause 7 : Analyser les pré-requis sécuritéTout simplement, il s'agit ici d'établir un état des lieux du périmètre en termes de sécurité. Les résultats de cette analyse nous permettront de mieux appréhender les actions à mener par la suite. Pour obtenir ces informations, 3 sous-étapes sont proposées :Définir les pré-requis sécurité pour les process relatif au SMSI (processus critiques ? contraintes légales ? biens prioritaires ? vulnérabilités impliquées ? besoin de sensibilisation et de formation ?) ;Définir les biens dans le périmètre du SMSI (classification des biens et besoins à partir de l'étape précédente) ;Évaluer le niveau de sécurité (à l'aide d'un audit de conformité (ex: ISO 27002) et des résultats d'audits précédents).Une fois l'état des lieux établi, il est possible de connaître le travail restant à réaliser. Avant cela, il nous reste à savoir à quel niveau de risque est exposé la so[...]



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

Thu, 30 Dec 2010 10:44:00 +0000

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 27002Tout 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.ExemplePour 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'informationMesure : 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) ...ConclusionPour 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?

Tue, 28 Dec 2010 09:37:00 +0000

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[...]



[SCADA] SCADA Security ... or not

Sun, 24 Oct 2010 19:50:00 +0000

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 NetOn 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 vieBon, 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 SCADASCe 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[...]



[HITB COnference] Day 2

Fri, 02 Jul 2010 19:11:00 +0000

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 CroceFidè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 HOFMANNJe 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 ma[...]



[HITB Conference] Day 1

Fri, 02 Jul 2010 07:01:00 +0000

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 ChasmCette 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 |BoxL'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 SAPSPLOITJe continue mon aventure sur la sécur[...]



[HITB Conference] SAP Hacking - Overview 2/2

Wed, 30 Jun 2010 20:56:00 +0000

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'authentificationSur 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 utilisateursTout 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 passeL'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 autorisationsUn 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 communicationsUn 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 environnementsDans 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 graalIl 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 mo[...]



[HITB Conference] SAP Hacking - Overview 1/2

Tue, 29 Jun 2010 17:58:00 +0000

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 RouterPour 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 * motdepasseD * * * *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 WebdispatcherCette 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'adminis[...]



[ARJEL] Sécurité et jeux en ligne

Fri, 18 Jun 2010 21:01:00 +0000

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 ê[...]



[SSTIC 2010] Day 3

Mon, 14 Jun 2010 21:22:00 +0000

Une troisième journée qui finit en beauté cette édition 2010 !MatinéeTrusted Computing : limitations actuelles et perspectivesEuh ... ça avait l'air intéressant ... ;)JBOSS AS : Exploitation et sécurisationVoilà 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 RuffLe 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 BodetDisons 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-midiPoC(k)ET, les détails d'un rootkit pour Windows Mobile 6 / Cédric HalbronnJ'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 WelteLa suite de la présentation du même orateur : Projet OpenBSCLors 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 à l[...]



[SSTIC 2010] Day 2

Mon, 14 Jun 2010 20:45:00 +0000

Une deuxième journée plus intéressante selon moi ;)MatinéeSécurité de la plateforme d'exécution JAVA : Limites et propositions d'améliorationAprè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 IOMMUUn 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 DuflotAlors 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-midiLa sécurité des systèmes de vote / Frédéric ConnesIl 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 malicieu[...]



[SSTIC 2010] Day 1

Wed, 09 Jun 2010 21:47:00 +0000

Une nouvelle éditions, de nouvelles conférences et des choses nouvelles ... ou pas !MatinéeSystèmes d'information : les enjeux et les défis pour le renseignement d'origine technique / Bernard BARBIER / DGSENous 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 COATRIEUXQuand 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 LAGADECLes 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[...]



[DISCOVERY PHASE] Rock it!

Wed, 14 Apr 2010 21:06:00 +0000

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 DNSTrè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 ciblefierce# perl fierce.pl -dns cible4/ On passe aux requêtes UDP et TCPOn 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'architectureLes 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 WEBDe 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) [...]



[INTERNAL PENTESTING] Windows Hacking

Wed, 24 Mar 2010 14:18:00 +0000

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 :J'ai un poste utilisateur et j'ai un compte utilisateur => je deviens administrateur local ;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 ;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 ...InstallationVoici les étapes à suivre pour installer l'outil :Commencer par le télécharger, c'est un programme python ;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 ;ç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 pos[...]



[SSTIC 2009] Day 3

Fri, 05 Jun 2009 22:51:00 +0000

Troisième et dernière journée. Il manque pas mal de gens à 9h15 ... et même à 13h. On peut en déduire que le social event s'est bien passé :) Une petite pensée aux collègues qui ont tourné pendant trois heures dans Rennes pour trouver des strip-teaseuses ... en vain ;)MatinéeJ'ai bien aimé cette matinée qui a commencé par une conférence sur les XSS , présentée par Pierre GARDENAT. L'objectif est ici de montrer les conséquences possibles de ces failles. Déjà, OWASP - dont nous avons déjà parlé sur ce blog - classe ce type de vulnérabilités dans ses top vulnérabilités. J'ai bien aimé l'exemple du site mySpace où on marque de ne pas taper les balises scripts. Ouais mais on est des rebeeels ! Bonne conf dans l'ensemble avec des résultats sans équivoque mais j'aurais bien aimé qu'on détaille plutôt les attaques sous jacentes comme le DNS rebinding et le click jacking. Cette dernière attaque est cependant expliquée par XMCO partners ici.Nous continuons avec une présentation d'un petit gars de chez nous. Il doit s'appeler Fred RAYNAL je crois ou quelque chose comme ça ;) Alors il s'agit ici de montrer qu'après avoir décrié les éditeurs de texte Microsoft, puis OpenOffice, on s'attaque maintenant aux PDFs. Alors des présentations ont déjà été faites comme on peut le voir ici. En tant qu'exemple, on voit comment nous arrivons a tirer partie des failles relevées sur ce format de fichier pour récupérer les hashes windows de la machin. De plus, Fred nous frounit ici d'e nouvelles pistes en cours d'exploitation car il s'avère que le sujet est vaste. Snif, même PDF n'est pas sûr.Quant à la troisième conf, j'ai beaucoup apprécié aussi : il s'agissait du projet macaron à télécharger ici dont l'auteur est Philippe PRADOS. C'est un programme malicieux qui s'utilise en tant que backdoor dans une application J2EE (ex ; JBOss, JoNAS, etc ...). Nous avons déjà traité ce genre de sujet sur ce blog et mon petit doigt me dit qu'on en entendra encore parlé prochainement ... La valeur ajoutée de l'outil présenté est :qu'il apour but d'être furtif et apparemment, ça marche ;les commandes proposées nativement par la backdoor sont nombreuses ;des fonctions d'audits ont l'air intéressantes. En tout cas, l'idée est bonne.Je rajoute dans ma liste de tool à tester suite au SSTIC.On continue avec un autre tool qui me paraît lui aussi intéressant : IpMORPH par Guillaume PRIGENT. Le but de cet outil est de dérouter les solutions de fingerprinting actives et passives en fournissant de faux résultats au niveau OS (ex : une OpenBSD à la place d'un Linux). Un début de présentation longuet avec des beaux powerpoints mais qui n'apporte pas grand chose. La suite est bien mieux et les résultats tout à fait satisfaisant. Les démonstrations ont porté sur nmap, ring2, p0f et SinFP qui sont largement répandus. Je me demande cependant ce que cela aurait donné avec des outils plus pointus comme AMAP et si des tests ont été réalisés avec nessuscmd ?J'aurais bien aimé vous parler des deux dernières confs de la matinée (analyse dynamique depuis l'espace noyau avec le projet Kolumbo et GPGPU pour la cryptographie) mais j'ai un peu décroché, non pas que les présentations n'étaient pas intéressantes, c'est juste que j'accusais le coup des 8 heures de sommeil ... en 2 nuits. En même temps, ça peu paraître beaucoup pour certains : Ok Alexandre et Yann, -100 au geek scoring :)Après-midiL'après-midi était courte avec deux présentations seulement : ça sent déjà la fin :' Nous commençons avec une présentation de Martin Vugnoux sur "les émanations compromettante[...]



[SSTIC 2009] Day 2

Fri, 05 Jun 2009 00:27:00 +0000

ça continue pour cette deuxième journée. Déjà, certains ont du mal à se lever pour la première conf. de la journée. Bon, l'objectif est de faire un post moins long que pour le jour 1 !MatinéeUne matinée dédiée au fuzzing ! En guise d'introduction, on commence avec une conf. d'Ari TAKANEN, Finlandais. Il nous explique sa vision sur le sujet : "Fuzzing : le passé, le présent et le futur". Ici, le but, c'est pas de montrer des vulns mais vraiment de voir les techniques de fuzzing et l'évolution de cette technique. Pour savoir quelle technique est la meilleure ou quelle sera celle qui nous conviendra le mieux, il faut prendre en compte trois critères :les fonctionnalités offertes par le fuzzer ;sa robustesse ; ses performances.L'idée est ici de considérer le modèle de fuzzing (mutation, pre-generated/scripted, block based, model based). Aussi, on souhaite ici se coller au fuzz en cours et l'automatiser au mieux. Par exemple, on cherchera à tenir compte des spécificités du protocole audité. Pour terminer, Ari nous propose une checklist pour choisir ou concevoir son fuzzer.La deuxième conf est proposée par Gabriel CAMPANA. Elle fait la transition avec la précédente en présentant l'outil "Fuzzgrind". Ce dernier repose sur deux tools existants : Valgrind et STP. L'idée est que pour chaque nouveau protocole, c'est long de refaire son fuzzer. C'est là que Fuzzgrind arrive. Cet outil va travailler selon les 3 étapes suivantes :exécution symbolique du programme audité ;prise en compte des conditions (tous les cas) ;création d'une équation pour chacune de ces conditions.Des améliorations sont en cours mais déjà, l'outil a déjà trouvé des vulnérabilités dans des programmes comme readelf et swfextract ... en moins d'une heure ! Bravo !La dernière conf sur ce thème du fuzzing est présentée par Laurent BUTTI. On s'attaque maintenant - dans le contexte d'une "architecture de convergence fixe-mobile" - à des protocoles dits de sécurité comme IKEv2 ou EAP . Et là où ça commence à faire peur, c'est qu'on trouve des failles là aussi ... En réalité ces protocoles apparaissent comme sûrs mais l'idée à retenir, c'est qu'il ne faut pas négliger les points sensés être sécurisés pendant les tests de tout genre car les failles vont provenir de l'ingénierie réseau et de l'implémentation de ses protocoles. En résumé, "don't trust any(one|thing)" ... (Source : Mulder dans X-Files ;).On enchaîne avec la présentation de Romain RABOIN sur la sécurité des smartphones. Le speaker nous donne d'abord une vue d'ensemble des 4 OS les plus répandus sur le marché (Symbian, iPhone, RIM Blackberry et Windows Mobile). on va faire court : il existe des failles pour tous et il est possible d'espionner les données (appels, voix, ...) via des logiciels appropriés. on se focalise ici sur Windows Mobile et on essaie d'injecter le logiciel espion (un fichier *.cab). A priori, nous avons besoin d'un accès physique au téléphone, le temps d'injecter le programme. Ensuite, on peut agir à distance. Pour éviter cette nécessité, d'accès au téléphone de la victime, plusieurs solutions passent en revue et la gagnante consiste à utiliser le poste de travail avec qui le smartphone se synchronise. Le schéma est alors simple :avoir un accès au poste de travail de l'utilisateur (ça n'a jamais posé problème) ;programmer la synchronisation du logiciel espion avec le smartphone ;c'est tout !Il faut quand même savoir que notre programme malicieux n'est pas signé. une popup pourrait donc avertir d'utilisateur de son installation. Mais la modification (via rapi) d'un[...]



[SSTIC 2009] Day 1

Wed, 03 Jun 2009 23:15:00 +0000

Premier jour de conf pour l'édition 2009. On retrouve les mêmes, les meilleurs et ... les meilleurs ;) De bonnes confs en perspective. Alors malgré un passage obligé à la crêperie et au pub, je ne pouvais pas manquer de faire quelques commentaires sur mon blog ;)MatinéeBon, pour les 3 confs du matin, je vais résumer mieux que sur tous les autres blogs SSI, si si ! Écoutez : "Suite à un problème d'aiguillage à Massy, le train partira avec 20 minutes de retard + 50 minutes de retard car nous prendrons les voies classiques à la place des voies TGV" ...Après-midi :Projet WOMBAT :L'après midi commence avec une conférence intitulée "Le point de vue d'un WOMBAT sur les attaques Internet" par M. DACIER, SYMANTEC.Alors avant de commencer faut savoir qu'il cherche à recruter dans le sud de la France (mouais, bah il fait beau même en Bretagne ! ;)) et qu'il recherche des ressources pour y installer des "sensors". On explique tout ça :La présentation se découpe en 3 parties : La collecte d'information ; L'analyse de l'information et l'enrichissement des données ; Les menaces causées par l'attaque.On connaît les honeypots (ou "pots de miel") mais ici, c'est juste une des sources utilisées pour la collecte d'infos. En effet, ils utilisent aussi les crawlers et des flux externes. Les honeypots sont basés sur SGNET, la nouvelle génération de ce type de solution. SYMANTEC demande à des partenaires d'installer sur leur(s) machine(s) un "sensor" qui est une "entité logicielle" légère. Le but est que ces "sensors" soient les plus nombreux et les mieux répartis possibles dans le monde pour des résultats d'autant plus pertinents. Plus précisément, ces sensors disposent d'un automate à états finis (constitué des chemins d'attaque connus).Afin que les personnes de la communauté WOMBAT récupère les données, ils disponsent d'une passerelle qui sert notamment de proxy anonymiseur pour ses partenaires qui envoient leurs données.On arrive à la deuxième étape où on effectue une analyse des codes malicieux. On l'enrichit de données si on en dispose déjà. On retrouve deux cas d'attaque :les attaques connues qui seront facilement traitées et répertoriées ;les attaques non connues qui nécessitent d'analyser le shellcode de l'attaque (+ long !).Malheureusement, la tendance étant à l'attaque ciblée, on se rend compte que les attaques non connues et spécifiques prennent de plus en plus d'importance.Enfin, troisième étape : l'étude des menaces. On a vu de beaux graphiques et ça a l'air de fournir vraiment des résultats. En tout cas, de donner des éléments de réponses sur les caractéristiques des attaques en cours ou à venir. Par exemple, on a une vue sur les sources et cibles des attaques, leur mode opératoire, etc. et tout plein de stats.Le projet est initialement prévu sur 3 ans et donc pas encore terminé. C'est pourquoi on attend d'autres résultats. Mais l'idée de départ et les moyens mis à disposition semblent être bons et prometteurs. Seulement, il faut que les données collectées soient :plus nombreuses ;pertinentes et arriver à trier les bonnes données malgré la quantité croissante ; trouver un moyen d'automatiser l'analyse de code malicieux pour les attaques non connues.Donc, à suivre !Les attaques physiques :Alors des projets tout à fait louables se déroulent pour la mise en place de l'informatique de confiance. Très bien sauf que Loïc DUFLOT, speaker de la conférence "Quelles limites pour l'informatique de confiance", commence par nous montrer qu'en débranchant et en rebranchant 5 fois de s[...]



[Pentesting] [Messaging] Lotus hacking

Mon, 20 Apr 2009 22:20:00 +0000

Nous continuons sur les posts techniques en nous attaquant cette fois à un autre type de serveur : le serveur de messagerie. Et plus exactement, l'attaque portera sur un serveur LOTUS. Nous verrons que l'attaquant peut encore une fois frapper très fort par cette voie.1 - Briefing: LotusLe post est à but purement éducatif et ne devra en aucun cas être testé sur un réseau qui ne vous appartient pas, en tout cas, sans autorisation.Il s'agit ici de donner une démonstration tiré d'un article paru dans le HS n°1 de MISC. Se référer à celui-ci pour plus d'information.Nous agissons ici de l'extérieur puisque nous nous focalisons sur la partie webmail de la messagerie.2 - Repérage de la cibleTrouver la messagerie de la compagnie auditée n'est pas difficile. Il y a la méthode que j'appelerai "intuitive" qui consiste à deviner le nom. Par exemple : mail.compagny.com, webmail.compagny.com, mx.compagny.com, etc...Et il y a la méthode plus intelligente ;) Il suffit d'exécuter une requête DNS sur le champ MX :dig MX compagny.comNotre cible utilise du Lotus ? Alors à l'attaque !3 - Des informations bien utiles ...3.1/ Récupération d'informations intéressantesNous allons regarder dans une premier temps si nous avons accès aux fiches des utilisateurs. Pour cela, essayer d'ouvrir le fichier names.nsf. Par exemple, à l'adresse : http://mail.compagny.com/names.nsf. Vous devriez avoir les listes des utilisateurs ! Cliquer sur ceux qui ont un icône "terre" et qui ont donc un accès webmail. Vous devriez trouver facilement ... le login ! ça commence plutôt pas mal, non ?3.2/ Récupération des comptes adminitrateurObtenir le compte d'un adminitrateur nous permettrait une compromission encore plus importante dans le sens où cela nous permettrait d'obtenir des accès sur le système hôte. Comment connaître l'identité de l'administrateur de la messagerie ? Deux manière au moins :Regarder les mailing-lists. L'une d'elles pourraient s'appeler mail_adminitrator ou quelque chose du genre. Sinon, toutes les listes d'administration pourrait être intéressante pour connaître les utilisateurs-clé ;)Regarder la configuration du serveur Lotus si celle-ci est accessible en lecture au moins. Le ou les nom(s) des adminitrateurs de la messagerie devraient vous être fournis sur un plateau ...3.3/ Récupération des hashesEt c'est à partir de maintenant que ça fait peur ! Mal configuré - comme souvent - il est possible de connaitre le hash du mot de passe des utilisateurs depuis Internet. ça ne peut pas être si simple me direz-vous ? En effet, c'est encore plus simple que ce que vous pouvez penser !Sélectionner la fiche de votre utilisateur cible ;Faire un clic droit sur sa fiche et choisir "Ce cadre" puis "Code source de ce cadre" (éventuellement en anglais) ;Dans le code source, faire une recherche sur la chaîne HTTPPassword ;Récupérer la valeur dans le champ "value" sans les guillemets mais avec les parenthèses ;C'est tout !Il existe deux formats de hash que nous pouvons récupérer (éventuellement sur le même serveur) :le format plus ancien :le format plus récent basé sur du MD5 + sel :4 - Juste une histoire de mot de passeNous avons donc obtenu un hash et en bon agent que vous êtes, ce n'est certainement pas la première fois que vous avez un hash à déchiffrer. Ici, notre arme de choix est le célèbre casseur de mot de passe, nommé John ! John the Ripper [1] !Néanmoins, nous aurons besoin d'utiliser une version avec les patches qui vont bien. Perso, j'utilise john-banquise [2] qui contient les patches pour Domi[...]



[PENTESTING] [Database] MS-SQL Audit

Sun, 19 Apr 2009 22:27:00 +0000

Après notre aventure théorique sur l'OWASP, je reviens sur le blog pour un post technique. Et pour ce "comeback", je vous propose dans un premier temps de nous attaquer à un élément du S.I très sensible : les bases de données ! En effet, c'est ici que nous trouverons souvent les données les plus confidentielles ... Plus précisément, nous allons prendre pour exemple les bases de type MS-SQL.1 - Mission: MS-SQLLe post présente une technique qui n'est pas supposée être la meilleure, ni être exhaustive. Le but ici est de voir une façon de faire. Au risque de me répéter, mais c'est très important, ce qui est présenté ci-dessous ne peut être réalisé qu'au sein de son propre réseau ou dans un cadre légal (avec autorisation de la compagnie auditée).Avant d'entrer dans le sujet, il faut savoir que ce type de tests est plus approprié aux tests d'intrusion internes. Si jamais une telle base était accessible depuis Internet, je vous laisse imaginer la criticité du problème !Pour terminer, le client OSQL, utilisé dans la suite, est fourni gratuitement sur le site de Microsoft dans le package MSDE. La connexion vers la serveur se fait ainsi :osql.exe /S ip_serveur|nom_serveur /U nom_utilisateur /P mot_de_passe2 - Repérage de notre cible2.1/ Trouver les serveurs MS-SQLPar défaut, les bases MS-SQL utilisent les ports :TCP/1433UDP/1434NMAP peut donc nous permettre de trouver les serveurs MS-SQL présents sur le réseau audité (par exemple, sur le réseau 172.16.XXX.XXX) :nmap -v -sV -sS -p 1433 -oN NMAP_MS-SQL.txt 172.16.0.0/16Ou mieux :nmap -sV -sS -p 1433 172.16.0.0/16 | grep "open" -B 3 > nmap_mssql_list.txtCette méthode simple est tout de même limitée car si l'administrateur n'utilise pas le port par défaut, nous passons à côté de notre cible !2.2/ Prise d'information sur les serveurs MS-SQLIl existe plusieurs outils pour obtenir des informations sur les serveurs MS-SQL audités. Nous montrons ici l'exemple de SQLRecon :Le but est de connaître les numéros de version notamment pour éventuellement jouer un exploit si le serveur de base de données n'est pas maintenu à jour.3 - Compromission de la cible3.1/ Juste une question de compte ...Une base de données MS-SQL a un compte administrateur appelé par défaut sa. Ce compte doit donc être protégé spécifiquement. Cependant, il arrive qu'il soit configuré avec le mot de passe ... vide ou sa ! Les credentials par défaut peuvent donc très simplement fournir un accès total à la base de données.Si les comptes par défaut ne donnent pas de résultats positifs, nous pouvons tenter une attaque par dictionnaire. Pour cela, il existe l'outil SQLPing3cl :Nous avons auparavant :rempli le fichier user.txt avec les noms de compte possible (ex : sa) ;rempli le fichier pass.txt avec la liste de mots de passe (sinon, il existe des tonnes de fichiers préconçus sur le Net contenant les mots du dictionnaire ;).Un de nos serveurs a le mot de passe sa (extrait de l'output) ...172.XXX.XXX.XXX,1433,NOM_Serveur,MSSQLSERVER,8.00.194,8.0.766,8.00.760,,No,(UDP)ServerName;NOM_Serveur;InstanceName;MSSQLSERVER;IsClustered;No;Version;8.00.194;tcp;1433;np;\\Nom_Serveur\pipe\sql\query;; (SA)Server present but blank SA login failed (BruteForce)**** Brute force attempt successful! User:sa Pass:sa ****,UDP TCP SA BruteForce3.2/ Regarder les vulnérabilités !Si malgré tous vos efforts vous n'obtenez pas le mot de passe du compte sa, il faut se retourner vers un site de veille sécurité pour trouver une faille exploitable selon la version trou[...]



[STANDARD] OWASP - Episode 10

Sun, 22 Mar 2009 09:15:00 +0000

Nous y sommes ! La dernière étape avec la fin de notre aventure sur la méthodologie OWASP. Après avoir vu un grand nombre de points à contrôler - de la collecte d'information à l'exploitation d'injections - il ne nous reste plus qu'à voir les attaques possibles sur AJAX. Je finirai par un résumé très rapide sur la vision de la norme pour la partie "post-pentest".1 - Avant-proposDixième épisode ! Hé oui, nous y voilà ! Il synthétise la section 4.11 de la norme. J'irai très vite car je ne suis pas un expert AJAX ;) Mais il me fallait être exhaustif en abordant tous les chapitres de la méthodo. Pour finir, je décrirai brièvement la partie 5 de l'OWASP à propos du travail d'un pentester une fois les tests réalisés.2 - Phase de tests actifs 9 - tests sur les applications AJAXAJ-001 - Les vulnérabilités d'AJAXNotre démarche consiste dans un premier temps à explorer les vulnérabilités potentielles sur les applications AJAX ou du moins, de contrôler qu'il n'y a pas de faille exploitable par un attaquant. Pour s'en assurer, nous devons couvrir un champ assez large de recherche car les applis AJAX sont concernées par de nombreux vecteurs d'attaque :Les attaques de type injection (cf. épisode 7) : ex ; SQL / XSS /CSRF ;Les dénis de services (cf. épisode 8) ;Attaque côté client (navigateur). Surveiller les nouvelles failles ! (ex : www.securityfocus.com).AJ-002 - Tests sur les applications AJAXIl n'y a pas de méthode précise ici mais nous donnerons quelques pistes. La première est de travailler avec un proxy local (ex : paros). Comme pour tout type d'application WEB, ce genre d'outil nous permet souvent de trouver "ce qui cloche". Du moins, cela nous permet de mieux comprendre l'application.La deuxième piste est de trouver les erreurs ou les lacunes dans le code JavaScript. Cette fois, nous pourrons utiliser une extension de Firefox comme Firebug. L'objectif est de trouver les failles dans le code qui nous permettront de réaliser des injections.3 - Après les tests ...La réalisation des tests constituent le coeur de la prestation d'un test d'intrusion d'une application WEB. Cependant, le résultat final, c'est le rapport.3.1 - Étude des failleCependant, le résultat final, c'est le rapport. L'OWASP propose six étapes pour étudier une faille :Étape 1 : Description et identification du risque pour la faille trouvéePar exemple, atteinte à l'image de la compagnie, pertes financières, etc...Étape 2 : Estimation de la probabilitéEst-il envisageable qu'une telle attaque se produise ? Si oui, dans quelle mesure ? Par exemple, s'il existe un gain financier à la clé, un attaquant sera plus motivé à attaquer la cible en question.Deuxième cas : imaginons une attaque distante. Si la compagnie a bien sécurisé les accès extérieurs avec pare-feu correctement configuré et plateforme de protection WEB, l'attaque aura moins de chance de succès.Étape 3 : Estimation de l'impact sur l'entrepriseLes risques identifiés doivent être évalué. Nous apportons un coefficient différent selon que une ou plusieurs personnes peuvent être touchées par l'exploitation de la faille étudiée. Les impacts financiers consistent-ils en une perte d'une journée de production ou d'une durée plus longue ?Étape 4 : Estimation de la sévérité du risque.sévérité risque = probabilité d'exploit (étape 2) * impact (étape 3)Nous obtenons une criticité de "Faible" à "Critique".Étape 5 : RecommandationsIl est temps ici d'apporter les solutions pour corriger les fai[...]



[STANDARD] OWASP - Episode 9

Thu, 19 Mar 2009 20:43:00 +0000

A grand pas, nous arrivons à la fin de notre étude sur la méthodologie OWASP. Dans ce neuvième épisode, nous traitons des Web Services. Mine de rien, c'est fou tout ce qu'ils peuvent nous permettre de faire ! Mais comme toujours, tout dépend de la sécurité de leur implémentation. Alors, prêt à tester ?1 - Avant-proposDans la norme OWASP, il s'agit de la section 4.10. Nommée Web Services Testing - WS, elle aborde les grands axes d'attaques des services en question de leur découverte à leur exploitation en sept points.2 - Phase de tests actifs 8 - tests sur les Web Services2.1 - Collecte d'information sur les Web ServicesSi nous ne connaissons pas la localisation des Web Services sur le serveur WEB hôte et que celle-ci n'est pas triviale, il nous faudra la trouver. Pour cela, plusieurs moyens s'offrent à nous :grâce à notre ami Google avec un requête du type :inurl:wsdl site:nom_ciblegrâce à des sites de recensements de Web Services comme seekda.com, wsindex.org ou soapclient.com.Sinon, nous pouvons tenter de les trouver avec les chemins, nom et extensions bien connus Pour cela, prendre les URLs connues et ajouter (combiner) :/services/nom_serviceswsdl, uddi, disco, etc. Essayer aussi en les précédant d'un "?"2.2 - Tests des WSDLUne fois repérés les WSDLs, nous aurons accès à leur description. Ce qui nous intéresse alors, ce sont :les noms des opérations (avec éventuellement leurs paramètres) ;les URLs et/ou adresses IP fournies (adresses externes ou internes ...).Pour cela, deux outils peuvent nous être utilise : WebScarab (en version complète) et WSDigger.2.3 - Structure des fichiers XMLLa description des WSDL est enregistrée au format XML. Le présent paragraphe s'attache à la bonne constitution de ces fichiers XML. Pour cela, nous allons vérifier les points suivants :Le fichier est-il correctement formé ? Les balises sont-elles correctement fermées ?Des éléments permettent-ils d'injecter des données larges ?Des éléments permettent-ils d'injecter des binaires (éventuellement en base64) ?Des éléments permettent-ils de lancer des injections malicieuses (voir Épisode 8) ?2.4 - Attaque XML Content-LevelSuite à l'analyse effectuée dans l'étape précédente, nous allons tenter d'exploiter les vulnérabilités potentielles repérées. Le but est de s'amuser avec les paramètres et de les transformer à notre guise pour tester le comportement du serveur et/ ou de mener des attaques. Cela suppose néanmoins de pouvoir intéragir avec les WSDL.Nous allons illustrer nos propos avec le screenshot suivant (avec WebScarab) :Pour commencer, nous choisissons le WSDL que nous voulons tester (WSDL :). Puis, on choisit l'opération qui nous intéresse (1). Ensuite, On change la valeur du paramètre souhaité (2). Nous chargeons l'outil de créer la requête SOAP associée en cliquant simplement sur "Execute" (3). Le résultat est fourni en (4).2.5 - Requête HTTP GETCette fois, nous tentons de modifier les paramètres via l'URL directement. indirectement, notre but est d'agir sur le WSDL. Alors, dans les paramètres, nous modifierons les valeurs fournies dans les requêtes en GET ou mieux, d'exécuter des commandes précédées du séparateur approprié (e.g. & ' ; ou |). Par exemple, la commande pourrait être lancée par la procédure master..xp_cmdshell d'un MSSQL :' exec master..xp_cmdshell + commande2.6 - Requête SOAP avec attachementUn peu plus complexe que l'étape 2.4, il s'agit ici de forger une requête SOAP aus[...]



[STANDARD] OWASP - Episode 8

Wed, 18 Mar 2009 19:33:00 +0000

Nous continuons sur notre lancée pour aborder le huitième épisode sur la méthodologie OWASP. Il s'agit ici de traiter des dénis de service. Rarement demandé lors d'un pentest, des effets pourtant ravageurs en cas de succès ...1 - Avant-proposCe chapitre correspond à la section 4.9 de la norme, nommé Denial of Service Testing - DS. Puisque nous parlons de déni de service, les attaques correspondantes ne devront être lancées que si elles sont explicitement demandées. En effet, la compagnie demandeuse est rarement prête à prendre le risque de voir tomber sa prod'. Cependant, les tests peuvent se dérouler sur un environnement de test ou le client peut très bien être intéressé par des tests exhaustifs ou les dénis de services ont largement leur place.2 - Phase de tests actifs 7 - tests sur les dénis de service2.1 - DS-001 : Attaque DoS basées sur les "wilcard characters"Les "wildcard characters" sont les caractères spéciaux qui remplacent plusieurs caractères ou une chaînes. Par exemple, le caractère "*" peut remplacer toutes les chaînes. Le but est de les utiliser pour forcer la base de données cible à chercher le plus longtemps possible pour répondre à notre requête. Voici quelques règles à suivre :La requête doit demander un élément inexistant ou très rare dans un champ de recherche très large ;Utiliser de longues et complexes requêtes avec des "wildcard characters" ;Commencer et terminer la requête par un "%" (pour le LIKE).L'objet de cette attaque et de rendre la BDD inutilisable ou du moins très ralentie.2.2 - DS-002 : Bloquer les comptes utilisateurGénéralement, un seuil est imposé pour le nombre d'essais autorisés pour se connecter avec un compte. Cela évite notamment les attaques de type "brute force". Cependant, une fois la totalité des essais épuisée, le compte est bloqué pendant une durée indétermminée. Nous avons deux cas :Nous connaissons le login des comptes à bloquer. Dans ce cas, tenter au moins 15 essais jusqu'à blocage du compte ;Nous ne connaissons pas de login. Alors, il nous faut les trouver grâce : aux messages et pages d'erreur fournis à partir de la page de login (point déjà traité) ;à la page de création de compte en tentant de créer un utilisateur déjà existant ;à la page permettant de recouvrer son mot de passe (point déjà traité).2.3 - DS-003 : DoS basés sur des attaques de type "Buffer Overflow"Nous avons déjà abordé le sujet des "buffer overflow" dans l'épisode précédent. La différence est qu'ici, le but est de simplement rendre inacessible un service. Par exemple, nous pourrons le vérifier si une page ou une fonctionnalité n'est plus disponible suite à notre attaque.2.4 - DS-004 : DoS sur l'allocation d'objetParmi les actions permises pour l'utilisateur, ce dernier peut parfois - directement ou non - créer des instances d'un objet quelconque (propriété, caractéristique, entrée dans un base, etc.). Pour illustration, au niveau du code, la création d'un objet se fera avec un new.2.5 - DS-005 : Utilisation d'une boucleLes codeurs utilisent souvent des boucles dans leurs programmes. Si une boucle est localisée ou supposée, l'utilisateur pourra tenter de dépasser les limites d'une boucle (ex : dans le cas d'une boucle for) ou de lancer une boucle infinie (ex : avec une boucle while).2.6 - DS-006 : Saturation d'un disqueSi la gestion des logs n'est pas sécurisée, il peut arriver que de nombreux logs soient enregistrés[...]



[STANDARD] OWASP - Episode 7

Thu, 12 Mar 2009 22:34:00 +0000

Septième épisode de notre épopée vers la connaissance de la méthodologie OWASP. Nous n'avons pourtant pas encore couvert tous les sujets, ni même les plus classiques. En effet, s'il y a bien une recette qui marche à presque tous les coups en termes de pentests d'applis WEB, ce sont les injections en tout genre !1 - Avant-proposL'épisode 7 traite du contrôle des données fournies en entrée par un utilisateur (Data Validation Testing - DV). Dans le cas d'un attaquant, il tentera d'injecter des caractères spéciaux puis du code malicieux si le contrôle des données n'est pas efficace. Le but n'est pas d'expliquer le fonctionnement de chaque type d'injection (ou alors, je tente la page de blog la plus longue de la toile ;) mais de passer en revue les principales possibilités à la disposition d'un attaquant proposées par la norme en question.2 - Phase de tests actifs 6 - tests sur les injections2.1 - DV-001 : XSS non persistantIl existe deux catégories d'attaque de type XSS (ou Cross Site Scripting) :les XSS non persistants qui ne sont pas maintenus dans l'application, lancé en "one-shot" (cf. le paragraphe présent) ;les XSS persistants qui sont maintenus et pourront être rejoués par les victimes à leur insue en consultants un page affectée par exemple sans que l'attaquant n'intervienne de nouveau (cf. paragraphe suivant) ;Il existe en réalité une troisième catégorie plus particulière, les attaques de type CSRF (vue dans l'épisode 4).Pour trouver un XSS non persistant, nous abordons la démarche suivante :Quels sont les entrées possibles ? Où avons-nous une chance de réussir une telle attaque. La réponse a normalement été élucidée dans l'épisode 1 ;Phase d'analyse : tenter un XSS classique (cf. exemple ci-dessous. Encoder la requête si nécessaire).Phase d'attaque : injecter le code souhaité (ex : récupération des cookies).2.2 - DV-002 : XSS persistantLes XSS persistants sont encore plus appréciés de l'attaquant puisqu'ils peuvent avoir des retombées après coup. Une démarche similaire sera suivie pour injecter de tels codes :Trouver un moyen d'"enregistrer" votre XSS (formulaire, page de profil, page de configuration, etc.) ;Analyser le code HTML de la page pour y trouver le champ vulnérable ;Tester avec un XSS classique (un autre exemple est fourni ci-dessous).Injecter le code qui sera exécuter lorsque la page infectée sera consultée manuellement ou automatiquement (ex : par une moulinette). Il est aussi possible d'utiliser des outils d'exploitation (un prochain post ?).2.3 - DV-003 : DOM Based XSSEn boîte grise, ce test consiste àtrouver dans le code les fonctions potentiellement injectables (ex : document.location, document.url, ...) ;tenter l'attaque :ex1 : concaténer le caractère # suivi du code malicieux (javascript) dans l'URL ;ex2 : essayer le code XSS à la place des valeurs des paramètres.Je vous invite à voir le document d'Amit KLEIN pour plus d'info sur ce sujet.2.4 - DV-004 : Cross Site FlashingNous testons ici la sécurité des animations flashs :Dans un premier temps, récupérer le *.swf avec un simple wget ; Puis, utiliser flare pour le décompiler ;Trouver les méthodes potentiellement dangereuses (ex : loadVariables(), getURL(), etc.) ;Injecter le code malicieux (ex : javascript:code_malicieux).Pour n'en citer qu'un seul, il existe un outil pour auditer ce genre d'animation : SWFIntruder.2.5 - DV-005 : injections SQLLà, on s'attaque [...]



[STANDARD] OWASP - Episode 6

Wed, 25 Feb 2009 10:41:00 +0000

Ce nouvel épisode est la suite de notre étude de la nouvelle version de la norme OWASP. Le but est de pratiquer les tests d'intrusion de manière méthodologique et aussi, de donner de nouvelles idées. Particulièrement, ce sixième épisode s'attache aux spécificités métiers de l'application cible.1 - Avant-proposLe sixième épisode que nous traitons ici représente le cinquième chapitre de tests actifs après un premier chapitre de découverte. Dans la norme OWASP v3, il s'agit du chapitre 4.7 relatif aux tests de l'application WEB cible et notamment les fonctions métiers qui peuvent être sujettes à des problèmes de sécurité.2 - Phase de tests actifs 5 - tests sur les fonctionnalités métiers2.1 - BL-001 : Tests des fonctionnalités métiersPuisque chaque application est différentes, il n'existe pas de tests particuliers que nous pouvons fournir de manière certaine. Cependant, une démarche précise est proposée pour couvrir au mieux l'application et tenter de trouver les failles de sécurité éventuelles.1/ Comprendre l'application :Il s'agit ici de connaître les possibilités offertes par l'application. Pour cela, l'auditeur pourra s'aider de la documentation disponible (test en boîte blanche) et de sa propre exploration de l'application en navigant sur les différentes pages. Il est important de noter à cette étape :les limites rencontrées (que nous essaierons ensuite de contourner) ;les différentes manières de réaliser certaines actions (notamment les actions les plus importantes).Cette première étape nous fournit un aperçu de l'application et nos premières pistes.2/ Etablir les scénario de tests : Nous prenons ici en compte tous les cas possibles que nous devrons croiser entre eux pour être exhaustif. Les cas en questions sont :les fonctionnalités principales (recherche d'un produit, commande d'un produit, ...) ;le circuit de validation d'une action (ex : de la commande à la validation d'un achat) ; les différents rôles intervenant sur l'application (e.g. de l'administrateur au directeur) ;les différents services (service IT, marketing, ...) ;les droits et privilèges accordés à chacun ... et à vérifier.Ces cinq éléments doivent nous permettre de constituer un tableau avec l'ensemble des actions permises pour chaque niveau d'utilisateur.3/ Préparation des testsSuite à l'étape précédente, nous devons déterminer ici le ou les test(s) à réaliser en conséquence pour nous assurer que l'application est correctement cloisonnée par type d'intervenant et par action.Par conséquent, à l'issue de cette troisième étape, un nouveau tableau sera créé contenant les tests résultants de l'étape précédente. Nous nous appuierons donc largement sur le précédent tableau.4/ Obtention des pré-requisMaintenant que les tests à réaliser sont connus, il est temps de demander au client les ressources nécessaires à leur réalisation. La plupart du temps, il s'agira de comptes avec des niveaux de privilèges différents. Aussi, il peut s'agir d'URL d'administration pour les comptes les plus privilégiés. Il est préférable de commencer avec un compte standard et de demander les ressources au fur et à mesure pour ne pas influencer les tests.Par exemple, est-il possible de trouver et d'accéder à l'interface d'administration avec un compte standard sans information préalable ?5/ Exécution des testsL'exécution des tests issus [...]