(par A. Moulu)

Cette présentation s'attardait sur la sécurité des systèmes Android, et plus précisément aux surcouches opérateurs.

En soit, le système de base est plutôt bien sécurisé (un peu comme tout système informatique). Pour accéder à certains composants sensibles du téléphone, comme les contacts, les données de la carte SD, etc... il faut que l'application demande des permissions au système, et au cours de l'installation l'utilisateur doit choisir s'il accepte (ou non) de donner ses autorisations à l'app. qu'il installe.

L'objectif de la présentation était de montrer qu'il existait sur un Samsung Galaxy S3 (sous ROM Stock, en prendant l'hypothèse que l'utilisateur est sensibilisé à la sécurité, aux permissions, et qu'il utilise le market officiel) des backdoors et plusieurs vulnérabilités accessibles depuis le userland (c'est à dire depuis des applications lancées par l'utilisateur, contrairement aux applications en kernel-land lancée par le noyau).

Tout d'abord, il a observé que le téléphone neuf possède (si je me souviens bien), plus de 160 applications installées (apps de base d'Android + applications tierces installées par Samsung). Pour comparaison, un Nexus 4 n'en a que 90.

Dans sa présentation il détaille plusieurs attaques possibles sur Android depuis une application installable par l'utilisateur.

Par exemple, sur les versions du SDK d'Android inférieures à la v3 (Android 4.2.2 est aux alentours de la 15-16 je crois) le système donne un accès complet à la carte SD en lecture et écriture par défaut aux apps. C'est à dire que l'on n'a même pas à demander de permissions. Ainsi, si on configure son application pour utiliser cette version du SDK (1 ligne de configuration dans le code source), on aura un accès total à la carte SD, et de fait, aux données qui y sont stockées par les autres applications.

Il est également possible, entre autres choses, d'envoyer des données en HTTP (pour faire du leak d'informations), d'élever ses privilèges, ou d'envoyer des SMS sans demander de permissions. Vous retrouverez plus de détails dans le white paper et dans les slides de la conf.

Original post of Quack1.Votez pour ce billet sur Planet Libre.

Au cours de la deuxième journée de conférences, nous avons pu assister à 3 présentations courtes, sur des sujets aussi variés que la sécurité d'Android, la VOIP Cisco ou encore la résilience d'Internet

Hacking d'Android/Samsung (par E. Comet)

Cette présentation c'est penchée sur les vecteurs d'attaque possibles pour une application Android. Les principaux vecteurs sont :

• Par un accès physique, en modifiant le bootloader, ou directement par USB
• À distance, en utilisant des failles dans les navigateurs Web, dans des protocoles de communication utilisés ou des applications malveillantes
• Ou encore, le point le plus développé dans la conférence, avec un accès local au téléphone, on peut accéder à beaucoup plus de privilèges. Les solutions les plus évidentes sont d'utiliser des applications malveillantes, des failles dans les surcouches opérateur, ou encore des attaques sur le noyau.

Le noyau est plus vulnérable puisque la surface d'attaque est plus grande. Basé sur un kernel GNU/Linux, les patchs de celui-ci ne sont pas appliqués sur les smartphones puisque peu d'entre eux reçoivent des MAJ des constructeurs. De plus, le kernel est compilé pour une plateforme ARM, beaucoup moins auditée que la plateforme x86 traditionnelle.

Enfin les applications constructeurs ou les surcouches opérateurs intègrent parfois (et même souvent) des modifications du noyau ce qui offre beaucoup de nouvelles possibilités d'attaques.

Compromission d'un environnement de VOIP Cisco (Exploitation du Call Manager) (par Francisco)

Un système de VOIP Cisco est basé sur un réseau en étoile, avec en périphérie les équipements de type téléphone/softphone, et au centre un Call Manager. (ou CM)

Ce CM reçoit les demandes d'appel, contacte le numéro demandé, et quand une liaison est établie, renvoie la communication à l'appelant.

L'orateur nous a présenté ici plusieurs failles de type 0-day (c'est à dire jamais publiées) sur ce Call Manager, qui permettent en quelques étapes de p0wner tout le système de VOIP.

En executant une injection SQL, puis en utilisant des failles de type Remote Code Execution permettant d'exécuter du code sur l'hôte distant, on peut arriver avec quelques étapes supplémentaires à obtenir un compte root sur le Call Manager.

Le seul point négatif est que l'entreprise n'a pas contacté l'éditeur, ce qui se fait généralement avant de publier des failles aussi critiques sur des systèmes massivement déployés en production.

Observatoire de la résilience de l'Internet Français (par G. Valadon)

Cette dernière présentation courte était consacrée à une action menée conjointement par l'ANSSI et l'AFNIC (association française qui gère les noms de domaines rattachés à la France (le .fr, et dérivés)). Cette enquête réalisée sur plusieurs années a permis d'obtenir de nombreuses statistiques concernant l'internet français.

Notamment, on apprend que certains préfixes IP appartenant à des opérateurs français sont parfois usurpés par d'autres AS en utilisant des annonces BGP, on peut également obtenir le taux de pénétration d'IPv6 en France, ou également avoir une carte des AS français et la répartition des sites Web dans ces AS.

Original post of Quack1.Votez pour ce billet sur Planet Libre.

Pour la deuxième journée du SSTIC, nous avons eu droit à 6 conférences, des présentations courtes, les résultats du challenge proposé par les organisateurs avant les inscriptions, et enfin une conférence invitée par Laurent Chemla!

UEFI

La journée a commencée par 2 conférences sur l'UEFI, on a donc eu une présentation commune par les deux orateurs sur l'UEFI, avant qu'ils attaquent leurs présentations respectives.

L'UEFI est le remplacant du BIOS dans les machines récentes. Il est plus moderne, avec un code de plus haut niveau (en C), multi-architecture, et qui intègre de nouvelles fonctionnalités au point qu'il soit presque un OS complet. Il possède notamment une gestion des drivers intégrée, une stack TCP/IP complète, un support du VGA, le SecureBoot, etc...

L'UEFI possède également une implémentation from scratch de la libc, sujette à de nombreuses vulnérabilités.

Dreamboot & UEFI (par Sébastien Kaczmarek)

Dreamboot est un bootkit pour Windows 8 permettant de corrompre le noyau, de bypasser l'authentification locale de la session Windows et escalader les privilèges. Simplement, la méthode utilisée est de placer des hooks depuis l'UEFI pour remplacer les actions lancées par le noyau. Pour bien comprendre ça, il faut avoir des notions de base sur le système des hooks (voir le lien plus haut).

UEFI & Bootkits PCI - Le danger vient d'en bas (par Pierre Chifflier)

Slides

Ici, on a (pour faire simple) une méthode similaire que pour Dreamboot, sauf qu'on passe par la carte graphique, qui doit aller patcher des données qui ne sont pas encore en mémoire, qu'on ne peut pas lire sur le disque et sans exécuter du code. Je n'ai pas plus de précisions, le mieux sera d'attendre les slides et la vidéo!

Programmation d'un noyau sécurisé en Ada (par Arnauld Michelizza)

L'objectif était ici de présenter les étapes de développement d'un noyau sécurisé en Ada, permettant de supprimer environ 80% des attaques connues sur les noyaux actuels (GNU/Linux, Windows), en supprimant les Buffer Overflows, Integer Overflow et autres Null Pointer Dereference.

Au final, le micro noyau a 11000 lignes de code, nécéssitant 1 an de travail, et avec quelques optimisations est (presque) aussi rapide (+15%) et un peu plus gros qu'un kernel GNU/Linux écrit en C.

Challenge

Le challenge du SSTIC est un bon défi pour ceux qui veulent se frotter un peu à des cas concrets de sécu. Le challenge de cette année a été résolu pas 15 équipes, et comportait 4 parties à résoudre séquentiellement. Au final, c'est plus de 17000 visites, représentant 3500 IP qui se sont rendues sur le site du challenge, depuis 62 pays et 534 villes françaises.

Les solutions complètes seront normalement bientôt en ligne, mais si vous voulez quelques infos rapides, @g4l4drim a fait un billet résumant la solution

La couleur du Net (par L. Chemla)

J'attendais beaucoup cette conférence, puisque Laurent Chemla a de très bonnes idées et réflexions concernant la liberté sur Internet, et un peu tout ce qui touche au Net. Il est revenu sur les "problèmes" que posent l'Internet (partage, droit d'auteur, pédonazi, ...), mais aussi sur tous les changements apportés à la société par Internet.

J'ai d'ailleurs retenu deux citations :

L'objectif de ceux qui veulent la neutralité du Net c'est de garantir qu'Internet continue de changer notre société.

et

Quand on pourra surveiller ses surveillants, on sera vraiment libres.

Malheureusement, Laurent Chemla a juste eu le temps de faire son introduction au cours du temps qui lui était imparti pour sa conf, donc j'espère que l'article complet sera disponible sur Internet!

Présentations courtes

Sécurité des applications Android constructeurs et backdoors sans permissions (par A. Moulu)

Limites des Rainbow Tables et comment les dépasser en utilisant des méthodes probabilistes avancées (par C. Tissieres)

Dans cette conférence très technique, l'orateur voulait montrer qu'il était possible de développer de nouveaux modèles pour construire des Rainbow Tables plus facilement, en adaptant leur construction et surtout les mots de passe construits en fonction de la cible.

Pour information, les tables d'Ophcrack font 2To, et contiennent tous les mots de passe de 8 caractères créés à partir d'un alphabet de 100 caractères. La construction de celles-ci a nécéssité 6 mois de travail sur 3 cartes graphiques ATI HD6990.

Je ne vais pas rentrer dans les détails parce que, encore une fois, les techniques utilisées me dépassent un peu et il faudrait que je passe un peu plus qu'un conférence pour appronfondir la chose pour bien tout comprendre ;-)

Le but ici est donc d'utiliser des méthodes probabilistes utilisées en Intelligence Artificielle, comme l'algorithme du Sac à Dos (ou Algorithme Glouton), ou encore des Modèles de Markov pour déterminer plus précisement les mots de passes qui auraient le plus de chances d'être choisies par l'utilisateur.

Rumps

Enfin, la journée de conférences c'est terminée par des rumps. Ce sont des conférences courtes de 3 min 30. À la fin de ce temps (ou même avant), si les spectateurs n'apprécient pas le contenu, ils applaudissent pour remercier l'orateur et pour qu'il parte. Au contraire, s'ils aiment bien, ils attendent avant d'applaudir pour donner un peu plus de temps au speaker.

Je n'ai pas eu le temps de prendre des notes puisque ça allait vraiment très vite, mais j'aurais tout de même retenu quelques petis trucs, soit dans des prez. sérieuses, soit dans certaines un peu plus humoristiques!

• Un protocole très utilisé en VOIP est le protocole MGCP, qui n'intègre aucune sécurité : pas d'authentification, pas de sécurité internet, on peut même faire un Man-In-The-Middle très simplement en annonçant à la gateway d'un réseau (qui transforme le traffic entre l'IP du réseau interne et l'analogique du réseau téléphone) en se faisant passer pour une gateway relais. De cette façon la gateway nous renverra tout le traffic!
• On a eu droit à une bonne prez de l'auteur du site java0day.com qui, en analysant ses logs Apache, a découvert qu'il recevait beaucoup de requêtes d'IP d'Oracle (il faut bien qu'ils s'informent pour savoir si quelqu'un a pété leur produit ;) ), mais depuis des vieux browsers tous pourris, ou depuis president.whitehouse.gov (avec un Firefox sur Ubuntu), et même depuis la Corée du Nord (avec un petit message en "North Korea, Democratic Republic Of").
• Enfin, Nicolas Ruff a démonté une appliance de sécurité (pourtant certifiée CSPN par l'ANSSI) qui possdait des mots de passe en dur dans le code source PHP (bon, ok, c'était plutôt le hash du password. Mais en commentaire c'était marqué /* Hash of '*********'), des clés secrètes ssh dispo dans un répertoire à n-1 de la racine, etc... En bref, que du lulz!

 

Pour conclure la soirée, nous avons été invités à un Social Event, en gros une soirée avec boisson et nourriture à volontée, pour pouvoir discuter un peu avec tout le monde. J'en ai profité pour aller discuter avec Zythom(, un expert judiciaire en informatique qui publie un blog dont je vous recommande chaudement la lecture!) que je suivais depuis un moment via son blog ou Twitter et que je voulais rencontrer AFK. Et honnêtement, j'ai bien fait, puisqu'il est vraiment super sympa, très abordable, et aussi "très bavard" (je le cite ;) ). J'ai aussi pu parler avec Galadrim, Cédric Foll et bien d'autres gens, comme des twittos avec qui j'ai sûrement aussi parlé via Twitter, avec des thésards de Supelec, ou simplement des professionnels de la sécu.

C'était vraiment une bonne soirée, ça valait vraiment le coup, et ça nous a emmené doucement vers la troisième journée

Original post of Quack1.Votez pour ce billet sur Planet Libre.

Après une upgrade party at $JOB de Ubuntu 10.04 vers 12.04, et  après avoir installé Gnome Classic,  sur deux d'entre elles un phénomène intéressant se produit: l'écran de boot (GRUB) affiche le theme de Debian 6 !




 Un cas de packaging qui a peut être mal tourné, et qui rappelle bien la synergie Debian / Ubuntu: Ubuntu c'est de mémoire 71% de paquets Debian recompilés sans modification et 29 % de paquets nouveaux/modifiés. (NB: Une source plus ancienne sur ce même thème  )

Original post of Emmanuel Kasper.Votez pour ce billet sur Planet Libre.

Ceux qui auront lu mon précédent article ne seront pas étonnés si j'annonce que j'ai tout récemment déployé une application web (Zend Framework 1 + Doctrine 2 + PHP5 + MySQL) sur un (petit - euh... enfin normalement petit) Raspberry Pi (modèle B). Toutefois, je décidai d'étudier plus avant le système mis en place en le soumettant à un 'stress test' simulant un fort afflux d'utilisateurs effectuant diverses requêtes au sein de l'application.

Les applications de 'stress test' ne manquent pas et j'avais déjà entendu parler de JMeter et Tsung. Mais pour ce test, je décidai d'utiliser Gatling :

Gatling (open source, disponible sur http://gatling-tool.org/) est codé en Scala et s'exécute sans difficulté dans un environnement disposant d'une machine virtuelle Java. Pas d'installation nécessaire : on décompresse l'archive et les binaires de l'application sont disponibles dans /bin/.

Mise en place d'un scénario de stress : à la main...

Les scénarios de test de Scala sont à créer et placer dans /user-files/simulations dans des fichiers scala. La structure de base d'un fichier est la suivante :

import com.excilys.ebi.gatling.core.Predef._
import com.excilys.ebi.gatling.http.Predef._
import com.excilys.ebi.gatling.jdbc.Predef._
import Headers._
import akka.util.duration._
import bootstrap._
import assertions._

class SimulationWithFollowRedirect extends Simulation {
  val scn = scenario("My scenario")
            .exec(http("My Page")
              .get("http://mywebsite.com/page.html"))
  
  setUp(scn.users(1))
}

Il est donc possible en Scala de coder la liste des actions qu'effectueront les utilisateurs virtuels (des requêtes GET, des requêtes POST, le lancement de certaines routines PHP...). A la fin du fichier, la simulation est lancée par

  setUp(scn.users(x))

où x (entier naturel strictement positif) représentera le nombre d'utilisateurs qui seront simulés concurremment sur l'application.

Mise en place d'un scénario de stress : en automatique pour aller plus vite !

L'écriture du scénario "à la main" est très souple mais un petit peu complexe. Il existe donc un petit utilitaire (recorder) particulièrement pratique qui peut venir à notre rescousse. Il s'agit d'une application qui vient se positionner comme un proxy sur le navigateur web et qui enregistre toutes les opérations effectuées par le navigateur directement sous la forme d'un fichier Simulation.scala utilisable par Gatling.

Le 'recorder' se lance par :

sh bin/recorder.sh

Si les ports du proxy (HTTP/HTTPS, spécifiés en haut à gauche) conviennent, on clique sur 'Start' et désormais l'application enregistrera tout mouvement réalisé au travers du proxy.

Une fois l'enregistrement terminé, on peut bien sûr modifier le scénario de simulation (suppression des pauses non nécessaires, suppression de certaines étapes...) en éditant le fichier MaSimulationDuJour.scala qui aura été créé dans /user-files/simulations. On peut notamment augmenter le nombre d'utilisateurs qui seront simulés :

  setUp(scn.users(100))

et on peut simuler une montée en charge progressive par la commande finale :

  setUp(scn.users(100).ramp(200)

qui signifie que 100 utilisateurs se connecteront progressivement pendant 200 secondes (soit 1 nouvel utilisateur toutes les 2 secondes). Bien sûr, si votre serveur répond bien et que la durée de simulation est courte alors il est possible que vous n'ayez jamais 100 utilisateurs connectés en même temps (car une fois que l'utilisateur simulé a terminé toutes les étapes alors il se déconnecte à moins que vous ne paramétriez des boucles). Le rapport d'analyse (cf. infra) vous permettra de bien visualiser ce phénomène.

Lancement du stress test

On lance donc gatling

sh bin/gatling.sh

qui propose de choisir la simulation à lancer. Et c'est parti !

L'état d'avancement du 'stress test' s'affiche dans la console. Une fois celui-ci terminé, un rapport est généré et est accessible dans le dossier /results/.

Voici un petit aperçu d'un rapport obtenu (sur un PC de bureau 4 coeurs +4 Go de RAM) :

Conclusion du stress test

Sur mon Raspberry Pi, je suis un peu déçu car dès 10 utilisateurs en concurrence les accès à la base de données et les requêtes pour les contenus non statiques mettent un temps long (les moyennes vont de 20 à 40 secondes selon les requêtes) à s'exécuter... Je m'attendais à ce que la Raspberry Pi ne tienne pas bien la charge mais je pensais la limite atteinte moins vite. C'est également le signe que le code de l'application n'est pas optimisé pour une exécution très légère et très économe en ressources ! Il va me falloir plonger dans le code pour optimer tout cela !

Très bonne journée à tous et bons 'stress tests' !

Original post of Pierre-Alain Bandinelli.Votez pour ce billet sur Planet Libre.