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 à 2²⁵.

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.