vendredi 3 juin 2011

Challenge #fail

Je ne parle pas du Challenge SSTIC évidemment, qui était encore une fois de très bonne facture (félicitations aux gagnants … et aux organisateurs).

Je parle plutôt du Challenge iAWACS/RSSIL. Enfin le challenge officiel, pas celui qui consiste à pirater des sites Internet en live et pouvoir rentrer chez soi tranquillement.

Le principe de ce challenge est simple: deux fichiers chiffrés avec un algorithme “maison” sont publiés. La première personne capable de produire les fichiers source gagne 3000€.

Bien entendu, afin de respecter le principe de Kerckhoffs, l’algorithme utilisé a également été publié. Le challenge consiste donc à cryptanalyser cet algorithme. Ou plutôt devrait consister.

En effet, une lecture attentive des sources permet d’identifier la séquence de code suivante:

PUNCT_CONC_CODE * generateCode()
{
(...)
  now = time(NULL);
  while(now == (time_t)(-1)) now = time(NULL);
  srand(now);

(...)

 

Et dans le programme de test:

aKey->INIT1 = (unsigned long int)((float)(0xFFFFFFFFL) * alea());
aKey->INIT2 = (unsigned long int)((float)(0xFFFFFFFFL) * alea());
aKey->INIT3 = (unsigned long int)((float)(0xFFFFFFFFL) * alea());
aKey->INIT4 = (unsigned long int)((float)(0xFFFFFFFFL) * alea());

 

Sachant que la définition de la macro alea() est plutôt simple:

/* alea(): a random float in [0, 1]      */
#define alea() (rand()/(RAND_MAX + 1.0))

 

Le lecteur averti aura remarqué que la simple connaissance du time() – en secondes - à l’instant de la génération du fichier permet de casser entièrement le challenge. Même en visant large - disons 1 an – la complexité calculatoire reste donc inférieure à 225.

Je ne cours pas après l’argent, mais 3000€ en 10 minutes reste une affaire rentable :) Toutefois les deux fichiers fournis présentent un entête qui ne semble pas provenir de la librairie fournie par l’auteur.

$ xxd -l 64 challenge_lipperseus1
0000000: 4631 3232 3938 4630 3030 0067 51b3 df01  F12298F000.gQ...
0000010: b663 4b33 4565 0637 0c1f 7912 4e39 64e5  .cK3Ee.7..y.N9d.
0000020: 7f71 3678 5438 2276 3c34 4726 13b8 6b37  .q6xT8"v<4G&..k7
0000030: 3a4a d9c5 3f9c 6d43 ccc6 37f8 59ec 33df  :J..?.mC..7.Y.3.
$ xxd -l 64 challenge_lipperseus2
0000000: 4638 3230 3946 3030 3030 ad94 31b0 1ec1  F8209F0000..1...
0000010: 82c1 4de0 9c97 2797 52f1 458a 5b40 2fe7  ..M...'.R.E.[@/.
0000020: 09b8 fe85 2ea7 2f7a 186b 277f 65a4 5275  ....../z.k'.e.Ru
0000030: 6cfb 845d c6a7 32b3 9141 db25 3526 456b  l..]..2..A.%5&Ek

D’ailleurs, la librairie disponible en ligne ne compile même pas à cause d’une typo. Il est donc difficile de croire que les fichiers aient été “produit directement à partir de ce code source” ;)

Je m’enquière donc du programme original (principe de Kerckhoffs, toujours). Et visiblement je ne suis pas le seul à avoir remarqué le problème.

L’affaire aurait pu en rester là, mais l’auteur a cru bon de répondre. Et là, à défaut d’un gros chèque, je tenais un solide blogpost ;)

Je vous laisse lire la réponse en question, car chaque ligne est délectable. Vraiment. Tenter de la résumer en quelques lignes serait risquer d’en perdre le substantifique fiel. Sans parler du blogpost d’origine qui a lui aussi été édité (oh la vilaine pratique).

Dans tous les cas, en ce qui me concerne, je vais continuer à penser “que les attaquants feront toujours des erreurs exploitables”, puisque l’usage de rand() pose toujours autant de problèmes en 2011 qu’en 2008 … ou qu’en 2003.

10 commentaires:

Anonyme a dit…

Il y a plusieurs problèmes avec ce challenge, en dehors du manque d'humilité de l'auteur de cette "technologie" :

D'abord s'il s'agit d'évaluer la sécurité de cette technologie et non une implémentation particulière,
alors il aurait été plus utile de fournir une description générale de la technologie en question.
Fournir une implémentation n'est pas inutile pour permettre à un attaquant de faire des tests sans avoir a tout coder,
mais dans ce cas il vaut mieux clairement préciser qu'il s'agit d'une preuve de concept faite spécialement
pour le challenge et non d'une vraie solution utilisable en condition opérationnelle.

Ensuite le scenario du challenge est faux : les 2 fichiers n'ont manifestement pas été protégé par cette librairie. Cela confirme que cette librairie est juste un jouet mal conçu...
(l'argument du code opensource, donc modifiable, donc implicitement modifié par tout utilisateur, relève d'une mauvaise foi caractérisée...j'adore !)

Enfin, on peut s'interroger sur la pertinence du scenario lui même :
Admettons que l'étude en condition opérationnelle exclue le problème de l'échange du secret (qui repose d'après
les commentaires de la lib, sur un tunnel SSL et donc sur une PKI avec tous les problèmes que cela comporte...),
et porte uniquement sur la technologie de "chiffrement" de flux.
Fournir simplement 2 fichiers protégés ressemble à ce genre de trolls habituels des groupes alt.crypto... ou
régulièrement des urluberlus viennent poster un fichier chiffré par leur super algo maison et demander aux
cryptographes de déchiffrer le fichier, concluant généralement à la supériorité géniale de leur algo bien sûr.
C'est limite consternant.
La moindre des choses qu'on puisse attendre d'une solution de chiffrement, c'est qu'il ne suffise pas de
quelques Mo de données chiffrées pour casser le chiffrement ! Cela ne suffira jamais à en faire une solution serieuse...

Anonyme a dit…

Je ne voudrais pas faire mon emmerdeur, mais en français, challenge, cela ne se dit pas défi ?

Kevin a dit…

Le dernier lien (2003) en parlant d'aléatoire est particulièrement fourbe :-)

Ensuite, je lis "les attaquants feront toujours des erreurs exploitables". Les attaquants? (il y a la même erreur sur le message de l'auteur d'origine).
Il s'agit bien des utilisateurs de solution mais non des attaquants (utilisateur au sens large, dans le sens utilisateur du procédé crypto programmeur, installeur ou celui qui va l'employer au final).
L'attaquant espère bien que l'utilisateur a fait une erreur afin de lui permettre d'avancer plus vite.

Ceci dit, je ne comprends pas le challenge. Il y a un prix financier non négligeable, ce qui n'est jamais bien (les gens se battent pour conserver leurs infos afin de gagner le prix au lieu de partager leurs infos).
Ensuite, il s'agit de casser le code. Pour étudier la solidité d'un procédé crypto, je donnerai l'algo à des gars compétents que je laisserai phosphorer par la suite. Donner un chiffré et dire "haha vous ne trouverez pas le clair" pour ensuite dire "mon procédé est solide" ne me paraît pas une garantie suffisante pour l'adopter...

sam280 a dit…

Ce n'est malheureusement pas la première fois que le code publié par M. Filiol ne correspond pas aux résultats qu'il prétend avoir obtenu, voir http://eprint.iacr.org/2003/022.pdf

Anonyme a dit…

Impossible d'accéder à la fameuse réponse.

Alex Is a dit…

J'ai eu Mr Filiol comme prof et je l'ai trouvé très bon pédagogue.

Je me souviens de sa volonté de nous faire comprendre la différence entre la sécurité d'un concept et celle d'une implémentation.

Je pense qu'il fallait prendre le challenge avec une certaine philosophie, d'une certaine manière un peu moins technique et plus conceptuelle (d'où, je pense peut être naïvement, la non divulgation du binaire). Je trouve donc que le "FAIL" est plus dans le fait qu'il n'ait pas réussi à le faire comprendre et à l'intégrer correctement au défi.

Du très peu que je connais Mr Filiol, ce n'est absolument pas quelqu'un qui prône la sécurité par l'obscurantisme. De plus, il n'a jamais soutenu que la bibliothèque était "secure". Je trouve donc dommage les attaques de Vincent qui ne sont pas très correctes.

Ceci dit, je trouve moche la ré-édite du post d'origine.

@bientôt au SSTIC ;-)

Alexis

Anonyme a dit…

c'est une vision negative de la chose, non ?

A mon avis, les reponses veulent juste dire qu'il voudrait que vous cherchiez dans une autre direction.

Monter un challenge, ce n'est (surement) pas facile. Et effectivement la il y avait peut etre une autre facon de le casser. Sauf que ca ne demontre pas la faiblesse de l'algo du challenge, donc ca ne l'interesse pas.

newsoft a dit…

@Anonyme: organiser un challenge n'est pas une chose facile. L'ESIEA, qui a organisé le Challenge SecuriTech pendant des années, devrait le savoir ... (mais il est vrai que tous les organisateurs ont quitté l'école depuis).

Maintenant une fois le challenge lancé, il y a quelques règles à respecter, comme par exemple:

* Ne pas changer les règles en cours de route.

* Ne pas exiger que les participants cherchent dans une direction plutôt qu'une autre.

La difficulté avec ce challenge, contrairement aux "hackers' challenges" classiques, c'est que l'auteur ne s'attend certainement pas à ce que sa technologie soit "cassée". En effet un support commercial est d'ores et déjà assuré par l'entreprise DFT Technologies ...

Anonyme a dit…

Le challenge a finalement été résolu grâce à une faille d'implémentation... http://cvo-lab.blogspot.com/2011/06/libperseus-challenge-results.html

Guillaume a dit…

Marrante sa fonction MY_FREE, surtout la dernière ligne:

void MY_FREE(void *p)
{
if (p == NULL)
return;

free(p);
p = NULL; // ne sert à rien...
}