Catégories
Actualité

Hackito Ergo Sum 2012 deuxième journée

Résumé de la deuxième journée de la conférence Hackito Ergo Sum 2012 à Paris.

Après une première journée très intéressantes, la communauté s’est retrouvée à une petite soirée, beaucoup ont annoncé ne pas être présent avant 10h pour cette deuxième journée, à priori ce n’est pas la majorité, la salle est déjà bien remplie.

Keynote #2 par Fyodor Yarochkin

#HES2012 2012-04-13 9h-10h

hackito-ergo-sum-2012-8557

Fyodor aborde la cybercriminalité et le panorama de leur monétisation au niveau internationale. Les nouveaux moyens de paiement notamment mobiles sont plébiscités car peu ou mal surveillés. Il aborde enfin la sécurité active et passive. Des groupes scannent internet (tous les ranges d’ip) pour trouver des failles. Il faut donc en prévention faire un certain nombre de machines virtuelles passives équipés de honeypot pour différents protocoles. Ainsi un ISP ou fournisseur de services sont capables de rapidement analyser les risques sur leurs infrastructures. Cette politique est un gage de réactivité accrue.

Hacking the NFC credit cards for fun and debit par Renaud Lifchitz

#HES2012 2012-04-13 10h-11h

Renaud commence par présenter ses activités au sein de BT et le principe du paiement sans contact (NFC). En France 100 000 terminaux sont déjà compatibles et 10 millions de cartes sont compatibles aux USA. Il existe deux systèmes un par Visa et un pour MasterCard. Le paiement est pour le moment limité à 4 paiements de maximum 20€. Les cartes NFS compatibles ont un logo de signal radio comme le wifi. Dans l’assemblée seule une personne a une carte NFC, sans doute que certains n’ont pas préféré le dire :). Le but du paiement sans fil est censé simplifié l’utilisation du moyen de paiement et au Canada les statistiques montrent que les gens consomment plus facilement.

Le stockage et la sécurité est assuré par le standard EMV et la norme ISO 7816-4. La carte a un vrai filesystem avec un root directory et des répertoires / fichiers. Les données sont encodées en BER TLV. Renaud analyse les données présentes dans une requête de paiement sans contact. On retrouve une class, une instruction, deux paramètres, la longueur des données, les données et la longueur de la réponse espérée. A présent un parallèle est fait avec le pass Navigo, le ticket sans contact des transports parisien. La sécurité est bonne car aucune donnée personnelle n’est présente, aucun lien ne peut être fait entre une personne et sa carte sauf par les serveurs centraux. La carte possède un bon cryptage, une bonne authentification et une signature digitale.

hackito-ergo-sum-2012-8561

Les cartes de paiement sans contact sont au contraire du pass navigo, aucun cryptage des données, aucune authentification, tout est ouvert. Le NFC regroupe le RFID, le NFC et le Cityzi, les fréquences sont en HF à 13,56Mhz et en LF entre 125 et 134 Khz. On trouve des lecteurs usb et des téléphones capables de lire les NFC. Pour les outils utiles scriptor pour le prototype, libnfc et pn53x-tamashell pour la partie NFC et quelques scripts persos sont nécessaires.

Les données que l’on peut extraire sont les données du propriétaire : sexe, nom, prénom, votre numéro de compte PAN, votre date d’expiration, les données de la bande magnétique, l’historique de vos transactions. Potentiellement d’autres données restent à découvrir comme les clefs publiques. Par contre le numéro de la carte CVV n’est pas inscrit dans les données NFC, on ne peut donc pas le récupérer.

Les attaques possibles, sont le fait de récupérer les données et de les utiliser pour des paiements en ligne. On peut aussi bloquer une carte bleue en envoyant trois requêtes de code pin erronés et ainsi bloquer tout paiement avec cette carte. On peut aussi tenter la duplication de la carte, les données NFC sont presques complètes et les données de la piste magnétique peuvent être reproduites. Une telle carte clonée pourra être utilisé dans les pays ne demandant pas le code pin comme les USA et certains pays européens par exemple. Enfin on peut reconnaître la présence d’une personne et déclencher des actions : surveillance des passages, terrorisme avec une voiture qui explose uniquement si la personne visée est présente.

Renaud aborde la méthode pour faire une attaque avec la libnfc. On envoie une séquence d’initialisation, il faut après retrouver le code AID de l’application de la banque, ce numéro se trouve sur tous les tickets de reçu de carte bleue et n’est pas tronqué. Enfin il faut lire la réponse EMV de la carte. Renaud nous présente les code AID des différents types de paiement visa, mastercard, american express, …

hackito-ergo-sum-2012-8562

Une démonstration est faite avec sa carte bleue dans son porte feuille qu’il approche du lecteur. Instannnément toutes les données se trouvant dans sa carte sont apparues. On y voit son numéro de carte bleue, sa date d’expiration, son identité et l’historique de ses achats. Une deuxième démonstration est faite sur un système Android, les mêmes données apparaissent. On imagine aisément les conséquences de scan avec un téléphone dans un métro bondé.

A présent nous voyons les limites des attaques. La principale contrainte est la distance entre 3 et 5 cm est la distance idéale. Mais en utilisant des amplificateurs on peut monter à 1,5m. Avec un récepteur type USRP avec une antenne directive on peut monter à 15m. Il rappel que des hackers avaient réussi en 2004 à monter la distance opérationnelle du bluetooth de 10m à 1,7km. La seule protection possible est un porte feuille anti RFID capable de bloquer les ondes radios comme une cage de Faraday. Renaud fait à présent les recommendations de ce que devrait être la sécurité sur les cartes NFC. Authentification, cryptage des communications, les sessions doivent être sécurisées. Aussi pour lui le système doit être entièrement revu et ne pas être utilisé. Le paiement NFC n’est pas compatible avec les recommandations PCI DSS alors que ces derniers sont à l’origine du paiement NFC. Aussi c’est un grand échec de la politique de sécurité et de lutte contre la fraude des paiements au niveau internationale. En France le fait de ne pas protéger des données personnelles est un acte criminel, la CNIL est déjà prête à demander des actions concrêtes, aussi l’utilisation de cartes NFC en France semble incompatible.

Renaud termine sur le fait qu’il n’a pas eu besoin de faire de reverse engineering puisque le protocole est public, qu’il n’est entré dans aucun système et n’a cassé aucune sécurité puisqu’il n’y en a simplement aucune.

Secure Password Managers and Military-Grade Encryption on Smartphones par Andrey Belenko, Dmitry Sklyarov

#HES2012 2012-04-13 11h-12h

hackito-ergo-sum-2012-8563

La présentation commence avec Andrey par les différences de modes d’authentification entre un ordinateur et un smartphone. Les ordinateurs ont de bons systèmes mais les portables n’ont qu’un code pin, un code alphanumérique ou un geste. Les mots de passe avec une longueur intéressante pour la sécurité sont compliqués sur un portable par rapport à un pc. L’avantage des PC est la capacité à craquer rapidement des mots de passe, même si ces derniers sont issus des smartphones.

L’accès aux données de smartphones iPhone se fait par afc comme l’accès iTunes, l’accès SSH pour les appareils jailbreaké ou en faisant une image complète du téléphone ou en utilisant le backup. Pour les BlackBerry l’accès se fait le mot de passe du terminal.

Pour les terminaux Blackberry, le conteneur des mots de passe supporte 5M de clefs/sec en attaque par CPU et 20M de clefs/sec avec un GPU. Le Blackberry Wallet est encore plus faible au niveau sécurité, 6M de clefs/sec en CPU et 300M de clefs/sec en GPU. Avec l’évolution des versions, on atteint 3,2M de clef/sec en GPU avec la version 1.2 du Blackberry Wallet.

hackito-ergo-sum-2012-8564

Dmitry aborde la partie iOS et aborde différentes applications star pour le stockage des mots de passe. Certaines applications stoquent les données dans une base SQLite et ne sont pas encodées. Les mots de passe de protection d’accès sont souvent stoquées en clar ou sont très facilement crackables. Quelques exemples iSecureLite Password Manage, Secret Folder Lite, Ultimate Password Manager Free. My Eyes Only utilise RSA uniquement pour coder les mots de passe mais toutes les clefs publiques et privées sont dans le même fichier avec seulement 512 bits en taille. Keeper Password & Data Vault utilisent aussi une base SQLite, md5 pour le mot de passe principal, SHA1 du master password est utilisé comme clef AES. On arrive à 60M clefs/sec pour le MD5, 6000M pour le GPU. Il n’y a pas de salt sur le chaines, les raimbow tables MD5 peuvent donc être utilisées rendant le craque d’un mot de passe simple très facile et pratiquement instantanné. Password Safe iPassSave Free utilise aussi une base SQLite et bloque l’utilisateur sur des pins trop simples. Une master key aléatoire est utilisée et est utilisée pour le codage des mots de passe. Avec l’algoritme AES-256 on peut atteindre 20M de clefs/sec sur CPU et construire une raimbow table car pas de salt utilisé.

Les applications payantes ne sont pas en reste, SafeWallet Password Manager peut être attaqué à hauteur de 20M de clefs/sec. DataVault Password Manager utilise le keychain d’iOS pour stocker une clef SHA-256 du master password mais ce dernier est accessible facilement par l’accès SQLite. Le master password est donc un SHA1(SHA-256(password)). C’est un peu plus long mais attaquable facilement. mSecure Password Manager utilise une clef SHA-256 et une blowfish on arrive à une attaque de 300K clefs/sec en CPU. LastPass for Premium Customers utilisé par le gouvernement américain pour les documents sensibles est aussi attaquable à hauteur de 12K clefs/sec en CPU et 600K clefs/sec en GPU. 1Password Pro utilise un pin password ou un master password. Ils utilisent MD5 et AES-128 on arrive donc à très rapidement trouver les clefs 15M clefs/sec sur CPU et 20M clefs/sec sur GPU. SplashID utilise une clef aléatoire qui est en fait statique dans la base livrée avec l’application. Le mot de passe principal peut donc être décodé instantanément.

Les solutions de stockage de mot de passe sur mobile qu’elles soient gratuites ou payantes ne sont pas une manière sécurisée pour stocker vos informations. Dmitry recommande aux développeurs d’utiliser les systèmes de sécurité interne aux OS et de ne pas réinventer de solutions de cryptage à leur manière.

How We Compromised the Cisco VoIP Crypto Ecosystem par Enno Rey et Daniel Mende

#HES2012 2012-04-13 13h30-14h30

Enno nous présentes 7 clefs de la sécurité, les ACL listes de contrôles d’accès, l’isolation / segmentation, la restriction / le filtrage, le cryptage, la protection des accès physiques, l’administration sécurisé et la visibilité des informations. Par le biais d’exemple il va nous expliquer comment se passent des pen tests. Premier cas une société d’assurance avec 3000 utilisateurs VOIP, possibilité de se branche n’importe où dans le bâtiment. Les scan du réseau montre les premières brèches du réseau interne et permettent de se rebondir entre plusieurs vlans. Un serveur ftp n’est pas très sécurisé et il se trouve que ce serveur héberge une messagerie email sous windows. Lors des tests pour chaque composant critique, il établit un tableau présentant les risques pour les 7 clefs précédemment présentées. Par recoupement d’informations il trouve des correspondances de mots de passe entre les serveurs. Dans un autre exemple de 25K d’utilisateurs VOIP, des mots de passe par défaut étaient présent sur du matériel du coeur de réseau.

hackito-ergo-sum-2012-8577

La conclusion de ses audits c’est que le cryptage ne solutionne pas toute la question de la sécurité mais est simplement utile. Les solutions Cisco VOIP utilisent des certificats et c’est globalement la seule solution mise en place quand d’autres protections ne sont pas possibles comme le filtrage ou les acl. Le souci entre deux téléphones c’est que l’on est obligé de faire confiance aux clefs du tiers que l’on connait (sur son réseaux) ou que l’on ne connait pas (prestataire, sip externe). La seule solution est d’utiliser un certificat d’autorité connu et validé des deux téléphones signé par une partie externe. Soit le certificat est en interne dans chaque téléphone, ou ce dernier est récupéré sur le réseau. Les équipementiers utilisent plutôt la mise en place des certificats dans le matériel. C’est le cas des téléphones Cisco, les CUCM les managers voip Cisco avec leurs proxy de certificats.

Des dongles CTL fournis avec les solutions Cisco contiennent des clefs privées servant à signer les certificats de la chaines. Dans la documentation Cisco il est précisé que le dongle usb doit rester branché tout le temps et plus loin le mot de passe d’accès est marqué en clair. Daniel prend la parole et nous explique comment fonctionne le CTL. Ce module n’est pas documenté et il a entreprit de l’analyser. L’analyse du parcours de certification donne des pistes d’analyses et on voit comment le CTL est signé et chainé. Or le CTL est le seul élément utilisé pour que le client communique avec les managers CUCM de manière sécurisée.

hackito-ergo-sum-2012-8579

Le but de l’attaque va consister à générer et à placer de manière dynamique en un faux certificat CTL dans les téléphones. A partir de cette manipulation on peut alors pousser en TFTP à peu près tout, firmware, configuration signée et faire alors exécuter ce que l’on souhaite au téléphone. Une démonstration est faite sur l’attaque du CTL d’un téléphone VOIP Cisco. L’attaque consiste à faire un man in the middle sur le réseau et provoquer le reboot des téléphones par exemple en coupant l’alimentation PoE. Lors du processus de boot du téléphone, ce dernier va récupérer un firmware signé avec le faux certificat qui fait partie de sa nouvelle trust list. Le téléphone corrompu appel un autre téléphone et l’icone indique bien que la communication est cryptée mais en amont on voit bien les informations comme les identifiants, les numéros utilisés et avec un peu de debug les data SIP de la conversation. Les outils mis en place vont être mis à disposition sous peu, pour faire réagir Cisco et pour permettre des audits plus approfondis.

The System of Automatic Searching for Vulnerabilities par Nikita Tarakanov

#HES2012 2012-04-13 14h30-15h30

L’intervention de Nikita nous a montré différentes méthodes d’analyses de code et de binaire pour trouver des failles de sécurité. Je n’ai pas plus de note ayant du m’entretenir avec une personne.

hackito-ergo-sum-2012-8580

TBD (Android Exploitation) : Georg Wicherski

#HES2012 2012-04-13 15h30-16h30

Georg parle de webkit le framework basé sur KHTML du projet KDE. Chrome, Safari (fixe et mobile) et le navigateur Android utilisent webkit. Il nous présente l’arbre de rendu fait par webkit, l’ordre des séquences, le DOM. Le souci de ce rendu c’est l’allocation et la libération de mémoire qui se font très souvent. Avec différents shémas, on voit comment l’allocation de mémoire se fait et comment le vidage peut désordonner les données. L’avantage c’est que le comportement du vidage de mémoire est connu donc prévisible.

hackito-ergo-sum-2012-8585

Le rendu de l’arbre contient quelques bugs qui ne sont pas backportés pour Android, il suffit donc de prendre connaissance du changelog de webkit pour trouver les failles potentielles d’Android. Un élément intéressant est la possibilité de causer des crash volontaires en donnant des casts invalides ou des confusions de type. Ces crashs vont libérer de la mémoire et c’est après cette libération de mémoire qu’il va falloir jouer sur les pointeurs restants pour y placer des objets C++. L’exploitation de la mémoire est facilité sur Android car la mémoire est en rwx pour les versions <= 2.2.1

Georg passe à une démonstration avec un Samsung Galaxy. Il ouvre un navigateur internet et nous présente le code source webkit qui va être servi. Le navigateur crash et produit une erreur typique de page non chargeable. Il nous montre différentes étapes de son code qu’il a fait, des stacks graphiques de debug du rendu de l’arbre et les espaces qu’il a pu créer dans la mémoire pour mettre ces objets.

hackito-ergo-sum-2012-8590

Round Table : How do you manage yours “hacker” profiles ?

hackito-ergo-sum-2012-8592