SecurityInsider
Le blog des experts sécurité Wavestone

Compte-rendu de la Rooted Con 2015 : Journée #2




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.
Le point commun entre ces méthodes étant la notion d'apprentissage avec des requêtes légitimes.
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 :
  1. L'utilitaire FileMon a été utilisé afin de découvrir les programmes et données utilisés lors d'une tentative d'identification ;
  2. 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
  • La vulnérabilité liée aux Group Policy Passwords
  •  Les mots de passes dans les commentaires d'un utilisateur du domaine
  • L'absence ou les authentifiants triviaux pour les utilisateurs ou les comptes techniques
  • La présence sur partage réseau accessible à tous d''un sympathique fichier excel comprenant les mots de passes d'administration


  • Renforcer les politiques de mots de passe, si besoin avec des outils tiers (utilisation de password filter pour les domaines Windows)
  • Renforcer l'authentification (double facteur etc.)
  • Validation 4 yeux pour les opérations sensibles

Vulnérabilités applicatives
  • Windows XP
  • Java, Flash
  • Backups
  • Vulnérabilité Web (SQLi, RCE etc.)


  • Segmenter le réseau
  • Patcher, Patcher, Patcher
  • Déployer EMET sur les postes Windows
  • Activer Grsecurity sur Linux
  • Controler les versions d'applets Java, via un contrôle des User-Agent au niveau des flux de navigation Internet


Attaques réseau
  •  Interception sur le réseau filaire: ARP spoofing, WPAD (découverte automatique de proxy), LLMNR poisonning : 1 outil de réference 'Responder'
  • Interception sur les réseaux sans-fil

  • Mettre en place un contrôle d'accès réseau
  • Activer l'inspection dynamique ARP et le DHCP snooping
  • Utiliser des protocoles chiffrés
  • Désactiver IPv6 si non utilisé
  • Désactiver la résolution de nom en multicast
  • Éviter l'utilisation de WPAD
  • Déployer un (des) IDS
  • Segmenter le réseau et filtrer les flux


Escalade de privilèges
  • Des services et des utilisateurs (notamment ceux étant admins locaux)
  • Des droits d'accès aux fichiers


  • Restreindre l'accès aux consoles cmd.exe et powershell (penser aussi à restreindre command.com)
  • Mettre en place une clé de registre refusant l'EULA de Sysinternals, et restreindre l'accès à cette clé de registre
  • Activer le firewall et l'UAC Windows
  • Restreindre les privilèges des taches planifiées
  • Faire du whitelisting d'application
  • Restreindre l'accès aux ports USB et lecteurs CD
  • Chiffrer les disques durs


Infiltration et exfiltration
Tunneling par des flux chiffrés (ICMP, DNS etc.)
Gmail

  • Appliquer des blacklists, raire de l'inspection SSL et bloquer le téléchargement d'exécutables au niveau du proxy Internet
  • Désactiver la résolution de noms de domaines externes pour des utilisateurs non authentifiés (empêcher le tunneling DNS)











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