Auteur/autrice : Julien

Réalisation d’un hotspot wifi

Cette article s’adresse à tous ceux qui ont déjà eu envie de se faire un réseau public et au amateur de spoofing.
Le problème des réseaux wifi public et qu’ils sont publics. L’authentification via un navigateur est trop facilement usurpable. Nous ne souhaitions pas réaliser un man in the middle qui a déjà été vu des centaines de fois sur la toile. Nous avons décider de nous plonger d’avantage et de proposer une solution qui reste légale puisqu’elle se contente d’imiter un réseau public. Nous l’appellerons « Noob Wifi ».

Afin de réaliser notre réseau nous avons utilisé la suite aircrack. La suite aircrack propose le module airbase. Celui ci permet de réaliser un réseau wifi ouvert. Il va alors diffuser les beacon frame. Ce sont les paquets contenant le nom du réseau (Free Wifi, Neuf Wifi, SFR Wifi, etc…). Ce qui nous intéresse dans le cadre de la sécurité c’est que si deux réseau avec le même ESSID (le même nom), le client se connectera automatiquement au plus puissant des deux.

Pour réaliser une attaque de type mitm ou bien spoofer le réseau tel que nous souhaitons le faire, il peut dont être intéressant de se procurer une antenne suffisamment puissante pour rayonner d’avantage que le hotspot que l’ont cherche à usurper.

Revenons à nos moutons. Après avoir installer la suite aircrack (ou bien à partir d’une backtrack).

Passage en mode monitoring :

$ airmon-zc start wlan0

Après cela, il va nous falloir configurer la fréquence d’émission de la carte. Pour cela il est nécessaire de sélectionner le chanel. Toute les cartes wifi ne sont pas compatible avec tout les chanels
Configuration du chanel de la carte :

$ iwconfig wlan0 channel 6
$ iwconfig wlan0 channel 6
$ ifconfig wlan0 up
$ ifconfig mon0 up

Lancement du point d’accès :

$ airbase-ng -c 6 --essid "Noob Wifi" mon0 &

Ceci nous permet alors de nous connecter librement à un hotspot. L’association sera faite et la partie protocole wifi est pleinement fonctionnel. Cependant, au même titre qu’une box adsl, airbase ressort une interface ethernet. Celle ci est virtuelle et s’appelle at0. Afin d’obtenir le point d’accès wifi pour relier tout vos équipement à internet par exemple, il vous suffit alors de réaliser une conection de pont entre votre interface web et at0.

Nous utiliserons at0 pour spoofer les requêtes dns et un par feu iptables pour rediriger le client fonction de s’il s’est authentifier auprès de nous ou non!

It’s oversimple, isn’t it?

Synchronisation sur un protocole bas niveau

Nous sommes en mesure d’espionner les premières transactions. Il ne nous reste plus qu’à configurer l’affichage sur la dalle tactile. Cet article va présenter la façon dont nous avons choisi de nous synchroniser avec le signal que nous espionnons. Cette méthode peut être extrapolée à d’autres protocoles de communication.

Synchronisation entre l’espion, le terminal et la carte

Les communications avec cartes à contact suivent la norme iso7816. Les communications sont réalisées en passant, sur la ligne, un état haut ou un état bas. Ce niveau logique doit être appliqué pendant une certaine durée; la durée de transmission d’un caractère. Afin de faire simple, cette durée dépend de la fréquence d’horloge appliquée à la carte par le terminal.

On peut le définir tel que :

Tc = a*f 
où :
f est la fréquence
Tc est la durée d'un caractère
a est un facteur de proportionnalité

Le temps que dure un caractère peut changer durant la transmission mais il sera toujours fonction de la fréquence. Pour le modifier, la carte demande à ce que se soit la valeur de a qui évolue.

Une explication plus détaillée (et surtout plus juste) est faite dans la norme iso 7816 ou bien dans l’EMV book 1 téléchargeable sur le site d’EMVco : http://www.emvco.com/specifications.aspx?id=223

Trame observée

La première action consistait à visualiser le signal obtenu. Pour ce faire,  j’ai décortiqué la norme et pris un oscilloscope. Dans le cas étudié, la première chose transmise est un octet décrivant le codage des caractères (Big endian / Little endian). Il est transmis par la carte et ressemble à ceci :

On remarque alors qu’aux temps t1 et t2, nous avons, bien que le caractère soit différent, un front descendant. Ceci correspond, d’après la norme, à la transmission de trois bits. Nous allons donc nous synchroniser sur ces deux fronts descendants lancer un compteur de temps et diviser le résultat par trois afin d’obtenir la durée de transmission d’un bit.

Code

Nous codons ceci sur un micro-contrôleur pic32. Le modèle de notre PIC est le pic32mx795F512L.
Configuration de l’interruption qui doit se déclencher sur les fronts descendants:

 /* Configure the interupt on IO to answer on each falling edge*/
    ConfigINT2(EXT_INT_ENABLE | FALLING_EDGE_INT | EXT_INT_PRI_1);

Implémentation de l’interruption pour lancer le timer 1 lors du premier front descendant puis le couper lors du second.

unsigned int state = 0;
unsigned int bitDuration = 0;
 
/* INT2 ISR */
/* Interruption externe 2 */
void __ISR(_EXTERNAL_2_VECTOR, IPL1) _Int2Handler(void) {
 
    /* State = 0 il s'agit du premier front descendant */
    if(0 == state)
    {
        /* Configure le Timer1*/
        mT1ClearIntFlag();
        /*Lance le timer 1 */
        OpenTimer1(T1_ON | T1_SOURCE_INT | T1_PS_1_1, 64000);
        state = 1;
    }
    else if(1 == state)
    {
          ConfigIntTimer1(T1_INT_OFF);
          bitDuration = ReadTimer1()/3;
    }
    /*Efface le flag d'interruption*/
    mINT2ClearIntFlag();
}

bitDuration contient alors le nombre de coups de clock que l’on doit compter pour obtenir le temps de transmission d’un bit.

It’s OverSimple, isn’t it?

Espionner une transaction avec carte à puce

La suite de l’article d’introduction sur la réalisation d’un espion pour carte à puce.
Afin de rendre les choses plus explicites on commence par un petit schéma :

Diagramme en boite de l'espion
Diagramme de l’espion de carte à puce

Le micro-contrôleur va lire les niveaux logiques qui circulent sur les entrées/sorties de la carte à puce. Pour cela il est nécessaire d’utiliser une rallonge. La construction de cette rallonge est décrite dans l’article précèdent :

Plus tard, une interface de lecture, pour les humains, sera développée avec un écran LCD. Au cous du développement, nous aurons besoin de réaliser des transactions. Cette article va traiter de la mise en place de l’environnement de test et de la lecture des données d’une carte bancaire.
Notez que nous utilisons une carte bancaire mais que ceci aurait pu marcher avec n’importe quelle autre carte à puce.

Lecteur de carte à puce

Afin de dialoguer avec la carte à puce, nous utiliserons un lecteur de carte à puce de type PC/SC. Ces lecteurs sont des lecteurs pour PC qui se connectent en USB. Il existe des librairies pour faciliter l’utilisation de ces lecteurs en Java. J’ai acheté le mien sur le site de Monéo : Boutique Moneo

une fois branché, il est nécessaire d’installer les drivers du lecteur. Pour ma Debian cela donne ça :

$:sudo apt-get install libpcsclite1
$:sudo apt-get install libacsccid1
$:sudo apt-get install pcsc-tools

Pour vérifier que l’installation s’est bien déroulée, on insère une carte dans notre lecteur et on le lance dans un terminal :

$pcsc_scan
PC/SC device scanner
V 1.4.18 (c) 2001-2011, Ludovic Rousseau 
Compiled with PC/SC lite version: 1.7.4
Using reader plug'n play mechanism
Scanning present readers...
0: ACS ACR 38U-CCID 00 00
 
Mon Jun 11 20:03:00 2012
Reader 0: ACS ACR 38U-CCID 00 00
  Card state: Card inserted, 
  ATR: 3F 65 25 08 66 04 6C 90 00
 
ATR: 3F 65 25 08 66 04 6C 90 00
+ TS = 3F --> Inverse Convention
+ T0 = 65, Y(1): 0110, K: 5 (historical bytes)
  TB(1) = 25 --> Programming Param P: 5 Volts, I: 1 milliamperes
  TC(1) = 08 --> Extra guard time: 8
+ Historical bytes: 66 04 6C 90 00
  Category indicator byte: 66 (proprietary format)
 
Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3F 65 25 08 66 04 6C 90 00
3F 65 25 .. .. 04 6C 90 .0
	Carte Bancaire (Frenc

Si vous recevez une réponse du type, alors le driver pcsc est correctement installé.

Analyse de la réponse

L’ATR (Answer to reset) provient de la carte et nous indique quel protocole doit être utilisé aussi bien en terme de durée d’un caractère que de signification d’un niveau logique. Nous y reviendrons plus en détails lorsqu’il s’agira de programmer notre espion puisqu’il devra se caler sur le rythme de la transaction.

Dans le prochain article nous parlerons de l’échantillonnage à proprement parlé et nous montrerons comment se synchroniser avec les données de la carte.
Si vous souhaitez reproduire les échanges de l’article http://oversimple.fr/que-trouve-t-on-dans-une-carte-bancaire/ vous pouvez utiliser le programme gscriptor présent dans le paquetage pcsc-tool que vous venez de télécharger.

It’s oversimple, isn’t it?

Que trouve-t-on dans une carte bancaire?

Que peut on lire sur une carte bancaire?
En réalité, pas grand chose, en tout cas pas grand chose de clair. Nous allons retrouver les informations tel que le PAN présent sur la devanture,  votre nom ainsi que la date d’expiration. Concrètement, voici un log commenté d’une transaction avec carte bancaire. Le log a été obtenu en réalisant une transaction avec un lecteur PCSC et en utilisant l’outil :.

Je déconseille fortement d’utiliser votre carte bancaire pour faire ce test. Tout d’abord, nous ne savons pas si les données sont stockées avec cet outil. De plus ceci est totalement illégal. Avant d’utiliser ceci, nous avons supprimé les données sensibles de la carte.

On commence par sélectionner l’application bancaire présente sur la carte à notre disposition

00 A4 04 00 07 A0000000041010

Et la réponse commentée :

6F File Control Information (FCI) Template
 	84 Dedicated File (DF) Name
 	 	A0000000041010
 	A5 File Control Information (FCI) Proprietary Template
 	 	50 Application Label
 	 	 	O V E R S I M A P P
 	 	9F12 Application Preferred Name
 	 	 	O V E R S I M A P P
 	 	87 Application Priority Indicator
 	 	 	02
 	 	5F2D Language Preference
 	 	 	f r e n
 	 	9F11 Issuer Code Table Index
 	 	 	01
 	 	BF0C File Control Information (FCI) Issuer Discretionary Data
 	 	 	DF60 Unknown tag
 	 	 	 	0B28
 	 	 	9F4D Log Entry
 	 	 	 	0B28
90 00 : Successful

On demande ensuite le Get Processing Option. Cette commande initialise la transaction bancaire.
C’est à ce moment que les compteurs de transactions de la cartes sont incrémentés.

Terminal : 80 A8 00 00 02 8300

La carte répond

77 Response Message Template Format 2
 	82 Application Interchange Profile (AIP)
 	 	3800
 	94 Application File Locator (AFL)
 	 	08010201 10010300 18010201
90 00 : Successful

L’AIP décrit les paramètres de sécurité de la carte. Il sont décrit dans l’EMV Book 3.
L’AFL liste l’ensemble des enregistrement que l’on a le droit de lire dans la carte.

Lecture des records :

Terminal : 00 B2 01 0C 17

70 EMV Proprietary Template
 	57 Track 2 Equivalent Data
 	 	1122334455667788D15031111111111111111F
90 00 : Successful

Le track 2 equivalent data est une copie des données de la piste magnétique.
On a ici le PAN : 1122334455667788 et la date d’expiration 1503 (mars 2015).

Terminal : 00 B2 02 0C 17

70 EMV Proprietary Template
 	5F20 Cardholder Name
 	 	O V E R S I M P L E . F R
 	9F1F Track 1 Discretionary Data
 	 	0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
90 00 : Successful

Terminal : 00 B2 01 14 96

On retrouve à l’intérieur la clé publique de la banque signée par l’autorité de certification.
Dans le cas de notre carte, il s’agit de Mastercard.

Terminal : 00 B2 02 14 56

70 EMV Proprietary Template
 	8F Certification Authority Public Key Index
 	 	01
 	92 Issuer Public Key Remainder
 	 	94AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 	9F32 Issuer Public Key Exponent
 	 	03
 	9F47 Integrated Circuit Card (ICC) Public Key Exponent
 	 	03
 	9F48 Integrated Circuit Card (ICC) Public Key Remainder
 	 	BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
 	9F49 Dynamic Data Authentication Data Object List (DDOL)
 	 	9F3704
90 00 : Successful

On retrouve là encore des clés de signatures. Cependant on remarque aussi la présence
du tag 9F49 qui désigne les donnés que requiert la carte pour générer une signature RSA.
La carte demande dans cet exemple un nombre aléatoire de 4 octets.

Terminal : 00 B2 03 14 97

Ce record contient la clé publique de la carte signée par la banque.

Terminal : 00 B2 01 1C 58

70 EMV Proprietary Template
 	5F25 Application Effective Date
 	 	130301
 	5F24 Application Expiration Date
 	 	150330
 	5A Application Primary Account Number (PAN)
 	 	1122334455667788
 	5F34 Application Primary Account Number (PAN) Sequence Number
 	 	00
 	9F07 Application Usage Control
 	 	FF00
 	8E Cardholder Verification Method (CVM) List
 	 	000000000000000042514403010302031E031F03
 	9F0D Issuer Action Code – Default
 	 	B840FD8000
 	9F0E Issuer Action Code – Denial
 	 	0010000000
 	9F0F Issuer Action Code – Online
 	 	B860FD9800
 	5F28 Issuer Country Code
 	 	0250
 	9F4A Static Data Authentication Tag List
 	 	82
90 00 : Successful

La CVM list décrit la manière dont peut être authentifiée le porteur de la carte.
(Code pin, signature etc…)
Les action codes décrivent la politique de sécurité de la carte. Ainsi, c’est en fonction
de ces codes qu’elle choisit de refuser une transaction, d’aller en ligne demander à
sa banque ou bien de l’accepter directement sans aller en ligne.
Les cartes d’étudiants vont généralement systématiques interroger la banque alors que
les cartes plus haut de gamme se valident les transactions en offline.

Terminal : 00 B2 02 1C

70 EMV Proprietary Template
 	8C Card Risk Management Data Object List 1 (CDOL1)
 	 	9F02069F03069F1A0295055F2A029A039C019F37049F35019F45029F4C089F3403
 	8D Card Risk Management Data Object List 2 (CDOL2)
 	 	910A8A0295059F37049F4C08
 	9F08 Application Version Number
 	 	0002
90 00 : Successful

Le record qui va nous permettre de terminer la transaction. Dans celui se trouve
les donnés que la carte requiert pour générer le cryptogramme qui valide la
transaction.

70 EMV Proprietary Template
 	8C Card Risk Management Data Object List 1 (CDOL1)
 	 	9F02069F03069F1A0295055F2A029A039C019F37049F35019F45029F4C089F3403
 	8D Card Risk Management Data Object List 2 (CDOL2)
 	 	910A8A0295059F37049F4C08
 	9F08 Application Version Number
 	 	0002
90 00 : Successful

Dans le premier generate application cryptograme la carte demande 43 octets de donnés. Nous
les remplierons avec des zéros. Dans la réalité on y retrouve la date, le montant, etc…

80 AE 40 00 2B 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Nous indiquons que nous souhaitons approuver la transaction directement. La carte devrait répondre
qu’elle refuse la transaction car le code pin n’a pas était validé. Ceci n’est pas forcément vrai.
En effet, la carte peut répondre qu’elle accepte la transaction. La preuve ci dessous :

77 Response Message Template Format 2
 	9F27 Cryptogram Information Data
 	 	40
 	9F36 Application Transaction Counter (ATC)
 	 	0042
 	9F26 Application Cryptogram
 	 	1122334455667788
 	9F10 Issuer Application Data
 	 	4F56455253494D504C452E46520000000000
90 00 : Successful

Le cryptogram Information Data (CID) indique 40,  ce qui signifie que la carte a approuvé la
transaction. Bien entendu ceci ne marche que parce que nous avons judicieusement choisi
de mettre un montant égal à 0;
Il est inutile de penser que la sécurité des carte bancaires
est à remettre en question. Il est toujours bien plus facile de braquer le sac à main
d’une personne âgée que de pirater des cartes bancaires.

Espionner une transaction avec carte à puce

On aime bien les défis, et quand il s’agit de monter un projet, du hardware jusqu’à la couche applicative, on est toujours partant.
Nous étions à la recherche d’un outil capable de comprendre le protocole ISO7816. Cette norme est celle qui régit les transactions entre une carte à puce et un lecteur. Bien que cela existe sur le commerce, ils sont souvent réservés à des professionnels et donc hors de prix.

Associé à notre école, disposant de ressources assez intéressantes autour d’architecture à base de microcontroleurs pic32, il était tout à fait concevable de réaliser un espion bas niveau.

Conception

Afin de concevoir cet espion il est au préalable nécessaire de concevoir une sonde. Cette sonde a le format d’une carte à puce (à savoir le format ISO7816). On peut aussi trouver le schéma dans l’EMV Book 1. Celui ci sera réalisé sur un PCB dans la version finale.
Pour la phase de développement, j’ai choisi une platine de chez Selectronic : Carte d’étude SMARTCARD ISO7817 pastillée

A ce module s’ajoute un connecteur pour carte à puce : Connecteur pour carte à puce contact NO

On soude le tout et on obtient ceci :

Ce n’est pas très esthétique mais ça fonctionne correctement. Vous remarquerez les deux condensateurs de 47pif rajoutés entre les signaux à observer et la masse afin de filtrer les signaux que l’on va espionner.

La prochaine partie concernera la manière de mettre en place l’environnement de développement MPLAB X et l’environnement de simulation.

Hacking the NFC credit cards

On a pas mal entendu parler du soit disant fail de la technologie utilisée par les cartes sans contact.

Tout d’abord, revenons sur l’article publié par Korben. Quel ne fut pas notre étonnement de voir sur ce site, que nous suivons régulièrement (et passionnément), cet article. Entrons dans les détails d’une transaction, afin de comprendre pourquoi, il est impossible de dupliquer une carte bancaire aujourd’hui.

Les clés utilisées pour les transactions bancaires verrouillées avec des clés de chiffrement privé qui ne sont possédées que par la banque et la carte. Ces clés sont inaccessibles (à part pour la carte et la banque bien sur).

La question se pose quand à la possibilité d’obtenir des informations non confidentiels mais nuisibles à la vie privée des utilisateurs. Les informations disponibles ne sont rien d’autre que celles présentes en clair sur la carte. Donc plutôt que de pouvoir récupérer ces informations via un système complexe d’antenne NFC, pourquoi ne pas tout simplement se munir de bons yeux et lire par dessus l’épaule des utilisateurs. (Ou encore de bonnes oreilles et d’écouter le boulanger dire bonjour monsieur Dupont).

L’article de Renaud

Comme le souligne judicieusement les slides de la présentation, le protocole contactless est calqué tant au niveau protocolaire que du point de vue de l’application sur les principes « contact ». En fait, pour aller plus loin la spécification applicative qui décrit le processus de la transaction bancaire est totalement indépendant du protocole de communication utilisée. La norme ISO 7816 citée dans les slides est bien une référence, mais pour le protocole de communication contact. Pour la partie contact, inutile de chercher des informations dans cette norme, allez plutôt voir l’ISO 14443.

Après seulement 3 slides, je commence déjà à douter du sérieux et des connaissances de ce Renaud.

Un soucis sur les protocoles

Sans entrer dans les détails, l’attaque porte sur la possibilité de dupliquer les données publiques de la carte. Les plus malins d’entre vous aurons remarqué qu’il s’agit des données publiques. En gros, celles qui ne permettent pas de réaliser de fausse cartes. Les clés cryptographiques sont quant à elles bien gardées au chaud. De plus, ceci n’est vrai que si la personne ne possède pas plusieurs cartes de ce type. En effet, si plusieurs cartes sans contact sont présentes, il y a une collision et le lecteur est incapable d’identifier quels octets proviennent de quelles cartes. Pour faire de la lecture en masse dans une foule, çela pose déjà un assez gros problème.

Ensuite, les données présentes sur la piste magnétique sont aussi présentes dans l’application sans contact. Cette affirmation erronée vient d’une mauvaise compréhension des spécifications d’implémentations. En effet, les cartes sans contact proposent une version de paiement utilisant un mécanisme très similaire à celui des bandes magnétiques pour les petits paiements. Le mécanisme utilisé les CVC Track 2 et 3 qui sont des données équivalentes aux données que l’on trouve sur une piste magnétique. Cependant les données présentes dans la carte à puces ne sont pas les mêmes que sur la piste magnétique et ne sont pas valides pour des paiements par piste magnétique.

Source : Hacking the NFC credit cards for fun and debit 😉
Source : EMV Book 2 – Security and Key Management
Source : EMV Book 3 – Application Specification
Source : Korben

It’s over simple, isn’t it?