Planet

Dernière journée, dernières présentations courtes au SSTIC 2013!

Détection comportementale de malwares P2P par analyse réseau

Slides

Afin de permettre une meilleure détection des malwares P2P qui sont de plus en plus répandus depuis quelques temps, l'orateur présente une "nouvelle" méthode qui consiste non plus à détecter un malware par sa signature au niveau du système, mais plutôt d'offrir une détection plus générique au niveau du réseau, puisque des communications entre clients P2P sont différentes des communications purement client-serveur dans le cas de clients dialoguant uniquement avec leur C&C.

Attestation distante d'intégrité avec Android

Cette conférence a été inspirée par un problème simple rencontré par beaucoup de personnes. Quand on dort à l'hôtel et qu'on sort manger en laissant son ordinateur dans sa chambre, comme savoir, en revenant, qu'il n'a pas été modifié par quelqu'un (cf ce tweet ;-)).

Pour détecter ces changements, on utilise un TPM (ou Trusted Platform Module), ici sous la forme d'un smartphone Android. Au moment d'allumer son PC, on branche le TPM au PC, qui va prouver son identité et prouver qu'il n'a pas été modifié au smartphone. Les détails d'implémentation seront disponibles dans les slides.

Le rôle des hébergeurs dans la Détection de Sites Web Compromis

Slides

Pour vérifier si les hébergeurs Web proposant des hébergements mutualisés prennent en compte la sécurité de leurs clients, des gentils pirates ont décidé de mettre en ligne sur une dizaine d'hébergeurs mutualisés différents des applications web trouées, puis de les attaquer.

Au final très peu d'entre eux détectent que des attaques sont en cours sur leurs plateformes et donc réagissent pour protéger leur(s) client(s). Pour aller plus loin ils ont même déposé des plaintes auprès des hébergeurs contre leurs propres sites (sur des versions propres) et soit ils ne recevaient pas de réponses, soit les sites étaient coupés sans plus de vérifications.

Dernière journée, dernières présentations courtes au SSTIC 2013!

Détection comportementale de malwares P2P par analyse réseau

Slides

Afin de permettre une meilleure détection des malwares P2P qui sont de plus en plus répandus depuis quelques temps, l'orateur présente une "nouvelle" méthode qui consiste non plus à détecter un malware par sa signature au niveau du système, mais plutôt d'offrir une détection plus générique au niveau du réseau, puisque des communications entre clients P2P sont différentes des communications purement client-serveur dans le cas de clients dialoguant uniquement avec leur C&C.

Attestation distante d'intégrité avec Android

Cette conférence a été inspirée par un problème simple rencontré par beaucoup de personnes. Quand on dort à l'hôtel et qu'on sort manger en laissant son ordinateur dans sa chambre, comme savoir, en revenant, qu'il n'a pas été modifié par quelqu'un (cf ce tweet ;-)).

Pour détecter ces changements, on utilise un TPM (ou Trusted Platform Module), ici sous la forme d'un smartphone Android. Au moment d'allumer son PC, on branche le TPM au PC, qui va prouver son identité et prouver qu'il n'a pas été modifié au smartphone. Les détails d'implémentation seront disponibles dans les slides.

Le rôle des hébergeurs dans la Détection de Sites Web Compromis

Slides

Pour vérifier si les hébergeurs Web proposant des hébergements mutualisés prennent en compte la sécurité de leurs clients, des gentils pirates ont décidé de mettre en ligne sur une dizaine d'hébergeurs mutualisés différents des applications web trouées, puis de les attaquer.

Au final très peu d'entre eux détectent que des attaques sont en cours sur leurs plateformes et donc réagissent pour protéger leur(s) client(s). Pour aller plus loin ils ont même déposé des plaintes auprès des hébergeurs contre leurs propres sites (sur des versions propres) et soit ils ne recevaient pas de réponses, soit les sites étaient coupés sans plus de vérifications.

(Par A. Dulaunoy)

Slides

Cette conférence fait elle aussi partie de mon TOP. Même si je ne suis pas très balèze dans le domaine des malwares, j'ai tout compris très simplement et en plus Alexandre Dulaunoy (membre d'un CERT Luxembourgeois) est un très bon orateur.

Il a voulu ici, contrairement aux autres orateurs, donner des conseils aux auteurs de malwares, plutôt que simplement casser leur boulot comme le font bien souvent les conférenciers.

Il est parti d'un constat simple : aujourd'hui dans les OS récents, une application doit être signée pour pouvoir être lancée en toute confiance sur le système. À partir de là, il commence à donner plusieurs conseils aux auteurs de malwares.

Premier conseil : puisque vos malwares doivent être signés, essayez de les signer. Il y a dans le monde plus de 600 autorités de certification (ou AC ou CA) et sous-autorités de certification. Au vu de la quantité on peut raisonnablement penser qu'il existe des failles permettant de récupérer la clé privée d'une de ces AC pour signer son malware.

Deuxième conseil : Au lieu de voler d'utiliser des signatures "illégitimes", autant en utiliser une presque vraie. Il est possible d'usurper un sous-domaine d'un domaine certifié, pour se faire certifier grâce à la chaîne de confiance entre certificats.

Mais sinon, on peut faire encore mieux ! Pour cela, il faut un peu comprendre le principe de vérification des signatures dans Windows. Ce principe est simple : on vérifie si le binaire chargé est signé, et après Basta!, on le laisse faire ce qu'il veut.

Donc si on veut écrire un bon malware, on a juste à écrire une DLL qui va charger notre petit code hostile. Ensuite on donne cette DLL à manger à une autre DLL ou à un exécutable Windows signé qui utilise la fonction LoadLibrary (pour charger la DLL). Il y aurait plus de 900 DLL vulnérables à cette attaque dans les derniers Windows.

(Par A. Dulaunoy)

Slides

Cette conférence fait elle aussi partie de mon TOP. Même si je ne suis pas très balèze dans le domaine des malwares, j'ai tout compris très simplement et en plus Alexandre Dulaunoy (membre d'un CERT Luxembourgeois) est un très bon orateur.

Il a voulu ici, contrairement aux autres orateurs, donner des conseils aux auteurs de malwares, plutôt que simplement casser leur boulot comme le font bien souvent les conférenciers.

Il est parti d'un constat simple : aujourd'hui dans les OS récents, une application doit être signée pour pouvoir être lancée en toute confiance sur le système. À partir de là, il commence à donner plusieurs conseils aux auteurs de malwares.

Premier conseil : puisque vos malwares doivent être signés, essayez de les signer. Il y a dans le monde plus de 600 autorités de certification (ou AC ou CA) et sous-autorités de certification. Au vu de la quantité on peut raisonnablement penser qu'il existe des failles permettant de récupérer la clé privée d'une de ces AC pour signer son malware.

Deuxième conseil : Au lieu de voler d'utiliser des signatures "illégitimes", autant en utiliser une presque vraie. Il est possible d'usurper un sous-domaine d'un domaine certifié, pour se faire certifier grâce à la chaîne de confiance entre certificats.

Mais sinon, on peut faire encore mieux ! Pour cela, il faut un peu comprendre le principe de vérification des signatures dans Windows. Ce principe est simple : on vérifie si le binaire chargé est signé, et après Basta!, on le laisse faire ce qu'il veut.

Donc si on veut écrire un bon malware, on a juste à écrire une DLL qui va charger notre petit code hostile. Ensuite on donne cette DLL à manger à une autre DLL ou à un exécutable Windows signé qui utilise la fonction LoadLibrary (pour charger la DLL). Il y aurait plus de 900 DLL vulnérables à cette attaque dans les derniers Windows.

07 Juin 2013 à 20:00

SSTIC 2013 Jour #3 via Quack1

Troisième et dernière journée du SSTIC 2013, mais surtout lendemain du Social Event, donc un peu fatigué :p

Fuzzing Intelligent d'XSS (par F. Duchene)

Slides

Pour être honnête avec vous, je n'ai pas tout compris (dans le détail), mais j'ai un peu compris le principe.

En fait, le doctorant a utilisé des fonctions génétiques et d'autres choses du genre utilisées en Intelligence Artificielle pour déterminer avec plus de précision quels payloads XSS envoyer.

Pour plus de détails, je ne peux que vous conseiller de vous réferer au papier ou aux slides.

Fingeprinting de navigateurs via XSS (par E. Abgrall)

Slides ~ Outil ~ Sources

J'ai trouvé cette conférence assez intéressante. Galadrim montre comment il utilise des payloads XSS dans des pages Web pour déterminer le navigateur utilisé. Pour cela, il a une liste complète de payloads reconnus par un ou plusiers navigateurs, et suivant le nombre de payloads qui fonctionnent, on peut déterminer quel navigateur fait tourner la page.

Duqu contre Duqu (par A. Thierry)

Slides

Ici, les chercheurs ont utilisé Duqu (un malware possédant pas mal de code en commun avec Stuxnet) pour détecter... Duqu!

Il l'ont reversé, enlevé le code malveillant, puis ils l'ont lancé afin qu'il se détecte plus simplement. Mais pourquoi faire ça ? Si j'ai bien compris, c'était pour que le soft possède ses clés de chiffrement et puisse détecter plus facilement dans la mémoire son alter-ego maléfique.

Disclaimer : Je suis peut être complètement à côté de la plaque, mais ce n'est pas mon domaine de prédilection et j'ai un peu lâché en cours de route...

La TEE, nouvelle ligne de défense dans les mobiles (par H. Sibert)

Slides

La TEE, ou Trusted Execution Environment, est un système développé par ST Ericson pour augmenter la sécurité des mobiles.

La TEE est en fait une sorte de sandbox, entre l'OS et les données sensibles. Toutes les fonctions sensibles (comme le stockage ou les accès à la SIM) sont lancées dans la TEE pour éviter d'être corrompues par des failles dans les apps ou le kernel et l'OS. En plus de cette sandbox, la TEE intègre la gestion des clés, un Secure Boot et des mécanismes d'isolation du code et des données.

Mais je dois quand même avouer que je suis un peu mitigé sur cette prez.

J'ai bien aimé la présentation technique "globale" des systèmes de TEE, mais je trouve que le reste a été un peu trop tourné sur leur produit. J'avais un peu l'impression d'être à une conf. commerciale pour acheter chez Sony.

Sinon, on a bien trollé sur Twitter, puisque les deux "premières fonctions populaires implémentées" dans leur TEE sont "le SIMLock et la gestion des DRM"...

La réponse aux incidents, ou quelques recommendations pratiques pour les auteurs de malwares (par A. Dulaunoy) Présentations courtes Faire face aux cybermenaces => détecter (les attaques) et former (des experts en SSI) (par L. Mé)
07 Juin 2013 à 20:00

SSTIC 2013 Jour #3 via Quack1

Troisième et dernière journée du SSTIC 2013, mais surtout lendemain du Social Event, donc un peu fatigué :p

Fuzzing Intelligent d'XSS (par F. Duchene)

Slides

Pour être honnête avec vous, je n'ai pas tout compris (dans le détail), mais j'ai un peu compris le principe.

En fait, le doctorant a utilisé des fonctions génétiques et d'autres choses du genre utilisées en Intelligence Artificielle pour déterminer avec plus de précision quels payloads XSS envoyer.

Pour plus de détails, je ne peux que vous conseiller de vous réferer au papier ou aux slides.

Fingeprinting de navigateurs via XSS (par E. Abgrall)

Slides ~ Outil ~ Sources

J'ai trouvé cette conférence assez intéressante. Galadrim montre comment il utilise des payloads XSS dans des pages Web pour déterminer le navigateur utilisé. Pour cela, il a une liste complète de payloads reconnus par un ou plusiers navigateurs, et suivant le nombre de payloads qui fonctionnent, on peut déterminer quel navigateur fait tourner la page.

Duqu contre Duqu (par A. Thierry)

Slides

Ici, les chercheurs ont utilisé Duqu (un malware possédant pas mal de code en commun avec Stuxnet) pour détecter... Duqu!

Il l'ont reversé, enlevé le code malveillant, puis ils l'ont lancé afin qu'il se détecte plus simplement. Mais pourquoi faire ça ? Si j'ai bien compris, c'était pour que le soft possède ses clés de chiffrement et puisse détecter plus facilement dans la mémoire son alter-ego maléfique.

Disclaimer : Je suis peut être complètement à côté de la plaque, mais ce n'est pas mon domaine de prédilection et j'ai un peu lâché en cours de route...

La TEE, nouvelle ligne de défense dans les mobiles (par H. Sibert)

Slides

La TEE, ou Trusted Execution Environment, est un système développé par ST Ericson pour augmenter la sécurité des mobiles.

La TEE est en fait une sorte de sandbox, entre l'OS et les données sensibles. Toutes les fonctions sensibles (comme le stockage ou les accès à la SIM) sont lancées dans la TEE pour éviter d'être corrompues par des failles dans les apps ou le kernel et l'OS. En plus de cette sandbox, la TEE intègre la gestion des clés, un Secure Boot et des mécanismes d'isolation du code et des données.

Mais je dois quand même avouer que je suis un peu mitigé sur cette prez.

J'ai bien aimé la présentation technique "globale" des systèmes de TEE, mais je trouve que le reste a été un peu trop tourné sur leur produit. J'avais un peu l'impression d'être à une conf. commerciale pour acheter chez Sony.

Sinon, on a bien trollé sur Twitter, puisque les deux "premières fonctions populaires implémentées" dans leur TEE sont "le SIMLock et la gestion des DRM"...

La réponse aux incidents, ou quelques recommendations pratiques pour les auteurs de malwares (par A. Dulaunoy) Présentations courtes Faire face aux cybermenaces => détecter (les attaques) et former (des experts en SSI) (par L. Mé)

(par A. Moulu)

Slides

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.

(par A. Moulu)

Slides

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.

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 : à l'attaque du kernel (par E. Comet)

Slides

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)

Slides

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.

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 : à l'attaque du kernel (par E. Comet)

Slides

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)

Slides

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.

Pages