Finding
stegomalware in an ocean of apps…
10:00 – 11:00 par Alfonso Muñoz y
Antonio Guzman
|
|
Cette seconde journée débute par une présentation sur
le thème de la recherche de malwares embarquant des
mécanismes de dissimulation d'information par stéganographie sur le magasin
d'applications mobiles Google Play.
Après avoir rappelé les enjeux liés à la dissimulation
de code malveillant par la stéganographie et les difficultés
liées à la détection de tels mécanismes, l'auteur a présenté les
objectifs et le périmètre de son étude : analyser le
maximum d'applications Android présentes sur Google Play à la recherche de
traces stéganographiques.
Deux millions d'applications
ont ainsi été analysées selon la méthode suivante :
- Les 20 outils les plus courants de stéganographie (Jsteg, Openstego, camouflage etc.) et les 4 algorithmes les plus utilisés (LSB, EOF, DCT, Chi-square) ont été testés...
- ... sur chaque ressource graphique constituant une application Android :
- Les images de sa page sur Google Play ;
- Les images référencées par des liens dans le code exécutable de l'application (classes.dex) ;
- Les images stockées dans les ressources de l'application
Résultat, 3% des images pointées par les URLs et 10%
des fichiers PNG stockés dans les fichiers APK sont rapportés comme étant
potentiellement porteur d'un message steganographié...sans pour autant avoir pu
les décoder. Il a néanmoins été possible de confirmer
que deux applications utilisent une méthode de stéganographie :
- La première, dans un objectif de contournement des restrictions de contenu autorisé sur le Play Store : cette application propose en effet des recettes de cuisine pour différentes drogues ;
- La seconde est un faux-positif, il s'agit en réalité d'un projet de recherche d'une université espagnole visant à évaluer le niveau des contrôles de sécurité effectués avant la publication d'une application sur le Play Store.
En conclusion, l'auteur a insisté sur le fait que la menace de code malveillant dissimulé est réel dans un contexte d'attaque APT et que très peu d'outils existent actuellement.
Doing
research about Web Application Firewalls
Titre
original : Investigando sobre los cortafuegos de aplicaciones web
11:00 – 11:30 par Carmen Torrano
|
|
Cette présentation académique
avait pour objectif de présenter la méthode et les résultats d'une étude visant
à évaluer les différents
modèles de détection possibles pour un WAF :
- Via une approche stochastique, au moyen :
- D'indicateurs statistiques : les écarts en terme de complexité (caractères utilisés, longueur etc.) de valeurs légitimes et malveillantes pour les paramètres attendus d'une requête HTTP;
- et des chaines de Markov;
- Via une approche par Machine Learning.
Après avoir énoncé les difficultés rencontrées pour utiliser des jeux de données qui soient volumineux, étiquetés (requêtes légitimes vs requêtes malveillantes) et publics; l'auteur a indiqué avoir créé ses propres jeux de données et a présenté les résultats:
- Le modèle statistique assure le meilleur taux de détection (99%), quasiment à égalité avec le modèle markovien mais supérieur au modèle par Machine-Learning (95%) ;
- Le modèle par Machine Learning assure quand même une analyse rapide (0.3 ms) contre quelques millisecondes pour les autres modèles.
1.3.
WebEx : analyse de données brutes
Titre original :
WebEx: Análisis de datos en bruto
12:00 – 12:30 par Abel Valero
|
|
Dans cette présentation, Abel Valero a détaillé les
différentes étapes qu'il a suivi afin de découvrir et reconstruire
le format de fichier des présentations WebEx.
C'est en effet suite à la perte
accidentelle du support PowerPoint d'une formation qu'il avait dispensé
via WebEx quelques temps auparavant qu'il a été contraint d'en savoir un peu
plus sur le fonctionnement du protocole de streaming développé par WebEx...afin
de pouvoir espérer récupérer l'enregistrement vidéo de la formation !
Il a par suite détaillé la réflexion et les résultats
de cet exercice de recouvrement d'un format de fichier
inconnu et propriétaire :
Démo à l'appui, il a réussi à reconstruire un fichier
vidéo depuis une projection WebEx : ce résultat est important dans la mesure où
WebEx offre la possibilité aux diffuseurs de contenu
d'empêcher le téléchargement d'une présentation ou même du flux vidéo.
Soulignant l'absence de chiffrement ou même
d'obfuscation du format de fichier, il assure que son outil
sera public...une fois que Cisco aura été prévenu par le staff
RootedCon.
En conclusion, l'auteur indique qu'il ne voit pas
comment Cisco pourrait intenter une action juridique contre lui dans la mesure
où il n'a attaqué aucun service, ni même procédé à une ingénierie-inverse du plug-in WebEx.
Deep
inside the Java framework Apache Struts (Str-SUCK-ts)
12:30 – 13:00 par Julian Vilas
|
|
Cette présentation a détaillé une vulnérabilité critique affectant le framework de développement
Java Struts et découverte en 2014 permettant d'exécuter
du code arbitraire sans authentification. Cette vulnérabilité est due à
un défaut de traitement des paramètres contenus dans toute requête HTTP qui, en
utilisant des méthodes d'introspection, permet la manipulation
du ClassLoader.
La fonctionnalité vulnérable est plus précisément liée au support des expressions OGNL, qui sont très
synthétiquement des expressions Java…mais écrites
avec une syntaxe différente : par exemple, l'expression OGNL
"#foo.bar" permet l'exécution de l'instruction Java
"Foo.getBar()".
De nombreux exploits,
principalement sous forme de modules metasploit,
ont été publiés depuis. Tous les serveurs d'application ne sont néanmoins pas
exploitables :
- Les versions 1 et 2 du framework sont vulnérables :
- La branche 1 n'étant plus supportée, aucun patch officiel n'est disponible. Un patch non-officiel est toutefois disponible (@pwntester);
Pour
la version 2, qui est toujours maintenue, le
speaker a fortement insisté sur le fait que les
différents patchs développés jusqu'ici ont pu être contournés, les
CHANGELOG mentionnent très clairement a posteriori "incomplete
fix"...depuis une première tentative de correction en 2007 :
Comment reconnaitre une
application J2EE utilisant Struts et connaitre la version utilisée ?
Très simple :
- Si vous trouvez ".do" dans l'URL c'est du Struts v1 ;
- Si vous trouvez ".action" dans l'URL c'est du Struts v2.
On Relaying NFC Payment Transactions using
Android devices
13:00 – 14:00 par Ricardo J.
Rodríguez y José Vila
|
|
Après avoir rappelé et décrit de manière très précise
les différentes normes et protocoles régissant les
communications NFC, les auteurs ont évoqué l'historique du support NFC
au sein d'Android, dans le but de montrer comment et dans quelle mesure il est
possible d'effectuer une attaque par relai lors d'un
paiement via NFC par un terminal Android.
Pour rappel, une attaque par relai
correspond, de manière similaire à une attaque Man-in-The-Middle, à la capacité
d'intercepter un message échangé entre 2 interlocuteurs (A et B) via un
interlocuteur tiers C : A va communiquer avec C et C va communiquer avec B.
L'interlocuteur tiers peut néanmoins être composé de 2 systèmes indépendants C'
(appelé taupe) et C'' (appelé proxy) communiquant entre eux via un autre canal que celui d'origine.
Ramené à la situation de terminaux mobiles Android
pouvant réaliser des paiements via NFC, cette attaque peut prendre la forme
suivante :
- Un attaquant effectue un scan physique (dans le métro etc.) d’une Carte Bleue dans la poche de la victime avec son terminal Android (taupe) : en ayant 'cloné' la Carte Bleue, il possède ainsi les informations bancaire nécessaires pour réaliser permettant un paiement NFC;
- Il transmet ces informations, via un autre canal (3G, Bluetooth etc.) à un autre terminal Android maitrisé par un complice (proxy) dans le but d'utiliser les informations de la Carte Bleue clonée pour effectuer un paiement malveillant sur un TPE (maitrisé ou non par l'attaquant).
Les auteurs ont démontré que tout
terminal équipé à minima d’Android 4.4 peut
réaliser cette attaque : nul besoin de rooter son terminal ou d'avoir un
firmware modifié.
Dans un scénario plus large
de fraude, une telle méthode pourrait être utilisée de la façon suivante
:
- La victime télécharge une application malveillante qui scan en permanence des éventuelles dispositifs NFC (CB dans la poche etc.) ;
- L'application malveillante transmet ces informations à un terminal Android central, qui peut les rejouer sur un TPE : dans le cas d'un paiement inférieur à une certaine somme, aucune validation par un code PIN n'est requise.
Des contre-mesures sont proposées face à ce scénario :
- Vérifier les paiements de manière centralisée et appliquer des limites temporelles et géographiques;
- Utiliser un facteur d'authentification supplémentaire.
Demystifying Apple "Pie" & TouchID
Titre
original : Desmitificando Apple Pay
15:30 – 16:30 par Sebastian
Guerrero
|
|
À travers cette présentation, l'auteur a souhaité
détailler le fonctionnement technique du
système de paiement mobile Apple Pay ainsi que
le système de reconnaissance par empreinte digitale TouchID.
En préambule, l'auteur a souhaité insister sur les
faits suivants :
- Les travaux de recherches de vulnérabilité sur ces mécanismes sont toujours en cours ;
- Les vulnérabilités présentées par la suite requièrent toutes que le terminal soit jailbreaké ;
- Et qu'aucun 0-day n'est diffusé dans cette présentation.
La première partie a permis de rappeler le rôle du
composant physique appelé "Secure Element"
(SE) utilisé par Apple Pay et qui permet de stocker matériellement
(JavaCard) et de manière sécurisée des données et secrets
cryptographiques, tel un HSM.
Pour Apple Pay, le SE
contient un token pour chaque carte de crédit
enregistrée par l'application PassBook:
- Un token correspond à une valeur anonymisée d'une CB;
- Ce token est émis par un service Web d'Apple;
Pour TouchID, le
composant "Secure Enclave" (SEnclave)
est utilisé pour stocker les empreintes :
- Le SEnclave correspond concrètement à une mémoire Flash de 4 Mo qui dispose de son propre processeur, de son propre OS (SEP OS) ;
- L'utilitaire SEPUtil assure les communications avec le SEnclave ;
- Les données stockées au sein du SEnclave peuvent uniquement être déchiffrées par une clé qui est contenue dans le SEnclave.
Le processus de décision
pour une tentative d'identification via TouchID est le suivant et a pour
principe de vérifier l'empreinte scannée avec un "template"
préalablement enregistré :
L'auteur a ensuite détaillé les étapes de reverse-engineering qu'il a suivi afin de comprendre
précisément comment ce processus se décline :
- L'utilitaire FileMon a été utilisé afin de découvrir les programmes et données utilisés lors d'une tentative d'identification ;
- Des protections anti-debugging ont été supprimées sur les binaires utilisés, notamment la protection kernel "seat-belt", pour pouvoir ensuite dumper les classes avec cyscript;
Par suite il a découvert qu’une option de débogage est accessible dans le binaire biometrickitd assurant l'identification
:
- En positionnant l'option "DebugLog" à true pour ce binaire, il a réussi à faire afficher les "noeuds" digitaux de l'utilisateur souhaitant s'identifier dans la console de débogage. Pour rappel cette console est accessible pour tout terminal, sous réserve que celui-ci soit déverrouillé ;
- En analysant les fichiers appelés par ce binaire il a réussi à découvrir que les templates sont stockés au sein d'un fichier plat, dont le contenu est bien chiffré mais qui n'est pas sur le SEnclave.
Enfin, l'auteur a prouvé qu'il a réussi à patcher la routine de vérification pour qu'elle accepte
n'importe quelle empreinte...en déverrouillant son téléphone avec son
nez. La faute à l'utilisation du fournisseur d'identification
"LocalAuthentication" situé au niveau OS, dont la routine de
vérification peut être patchée (en étant jailbreaké); contrairement à l'utilisation du KeyChain qui fait appel au SEnclave.
En conclusion, les trois
idées à retenir sont :
- L'implémentation de la technologie Apple Pay est jusqu'ici robuste malgré les quelques ratés (notamment l'option de débogage accessible) ;
- Un terminal jailbreaké est nécessaire pour tout attaque, qui de toute façon ne permet pas d'obtenir d'informations sensibles ;
- Mieux vaut faire appel au KeyChain plutôt qu'à l'API LocalAuthentication pour utiliser TouchID comme fournisseur d'identité.
Rouges et Bleues : deux équipes, deux saveurs
Titre
original : Rojos y Azules: dos equipos con dos sabores
16:30 – 17:30 par Alejandro Ramos
|
|
Les couleurs rouge et bleue
font référence aux deux principales approches constituant le domaine de la
sécurité : l'attaque et la défense.
Les performances de ces deux équipes peuvent être
mesures à l'aise des indicateurs suivants :
- Red Team :
- MTTC : Mean Time To Compromise
- MTTP : Mean Time To Privilege escalation (ou Pwnage)
- Blue Team :
- MTTD : Mean Time To Detect
- MTTR : Mean Time To Recover
L'auteur a souhaité ensuite établir ici un top 5 des TTP (Tools, Techniques and Procedures) les
plus utilisés, rapides et efficaces mis en œuvre par
les Red Team et à mettre en œuvre par les Blue
Team sur différents thèmes.
Il est à noter que beaucoup sont de fausses bonnes
idées ou sont a minima inapplicables dans le 'vrai monde' : par exemple le
whitelisting d'application sur tous les postes de travail.
Red Team
|
Blue Team
|
|
Gestion des authentifiants
|
|
|
Vulnérabilités applicatives
|
|
|
Attaques réseau
|
|
|
Escalade de privilèges
|
|
|
Infiltration et exfiltration
|
Tunneling
par des flux chiffrés (ICMP, DNS etc.)
Gmail
|
|
Le temps entre mes mains
Titre
original : El tiempo en MIS manos
18:00 – 19:00 par Jose Selvi
|
|
L'auteur de ce talk s'est concentré sur le fonctionnement d'HSTS ou plutôt dans quelles mesures
HSTS ne pourrait pas fonctionner. Pour rappel HSTS
permet qu'un client ne se connecte plus jamais en HTTP sans SSL à un serveur
suite à une première connexion.
Lors de cette première connexion, le serveur spécifie
via un entête de retour que le client doit
directement, dans le futur, essayer de se connecter en HTTPS et non plus en
HTTP, durant une période de temps définie.
Dans le cas où cette période de temps est révolue et
qu'aucune mise à jour n'a été indiqué par le serveur, cette obligation de se
connecter via HTTPS ne tient plus et le navigateur se
connectera ainsi en HTTP.
Le constat de base est que les navigateurs embarquent
tous une liste de sites connus (Google, Facebook etc.)
pour lesquels il n'y aura jamais cette première connexion en clair : le
problème est que pour la plupart de ces navigateurs,
la référence temporelle utilisée se base...sur l'heure du système.
L'idée est que si un attaquant arrive à modifier l'heure du système, en interceptant par
exemple les flux NTP, il pourrait alors rendre ineffectif le fonctionnement d'HSTS et ainsi
voir les communications en clair !
Tous les systèmes et tous les navigateurs ne sont pas vulnérables de la même façon :
- Windows refuse tout changement NTP de plus de 15 jours tandis que Linux et Mac OS X acceptent tout changement sans condition;
- Safari positionne une validité infinie (passée comme future) pour ces listes tandis que Chrome embarque une liste dont la date initiale correspond à la date de la compilation;
Un autre angle d'exploitation a été mentionné par
l'auteur et vise les tâches planifiées Windows. En effet la date de l'exécution N+1 d'une tâche est calculée lors de l'exécution N : si l'exécution N n'a
jamais lieu, les futures n'auront également pas lieu.
Appliqué au cas de tâches assurant les mises à jour
via WSUS, un attaquant manipulant l'heure pourrait faire en sorte qu'un système ne soit jamais mis à jour.
Ingénierie inverse de circuits intégrés
Titre
original : Ingeniería inversa de circuitos integrados
19:00 – 20:00 par Eduardo Cruz
|
|
Cette seconde journée se termine sur un talk très
pointu techniquement concernant le reverse-engineering
de circuits imprimés où Eduardo Cruz raconte comment il lui a été
possible de casser la protection anti-copie d'une
borne d'arcade des années 80, en procédant à une analyse inverse du chipset 'cryptoprocesseur' Kabuki
responsable de la protection.
Après avoir rappelé le principe fonctionnement d'un
transistor, l'historique autour de cette technologie ainsi que les procédés de
fabrication, il a présenté les principales phases de son projet, soit :
- Décapsuler le processeur, c'est-à-dire retirer la résine époxyde au moyen d'acides ;
- Analyser le résultat au microscope. Pro-tip de l'auteur : aller dans les labos universitaires, qui louent à bas prix des séances de microscopie ;
- Déconstruire les différentes couches et faire des acquisitions d'images numériques via le microscope ;
- Modéliser les couches internes du processeur à partir des images, au sein d'un simulateur logiciel afin de représenter chaque transistor et chaque liaison. L'auteur raconte que cette phase lui a pris 6 mois ;
- Analyser, à partir des différents signaux électriques possibles en entrées, les sorties du processeur.
En suivant ces étapes et en réalisant ce travail titanesque, l'auteur a été en mesure de recouvrir l'algorithme de protection et la clé de
chiffrement symétrique utilisée.
Thomas DEBIZE
Aucun commentaire:
Enregistrer un commentaire