Après vérification, le terme “désosser” est bien celui qu’il faut utiliser pour désigner, en français, le reverse engineering. Malheureusement, je n’aurai peut-être pas l’occasion d’apprendre de nouveaux mots avec eux, puisque le contrat de license stipule aussi ceci :

16.6    Québec :   En regard du Québec, les parties déclarent par les présentes qu’elles exigent que cette entente et tous les documents afférents, soit pour le présent ou l’avenir, soient rédigés en anglais seulement.

Too bad !

Go ahead and download the new version.

When Winlogon can’t load a GINA, the server reboots. I run all my tests in virtual machines attached to a remote kernel debugger. I had set up a rule to ignore this first hardcoded breakpoint. In a regular environment, Winlogon did the only sensible thing to do when it received that unhandled exception : terminate.

That triggered the reboot process.

Please use version 1.4.5. I have updated the project page, binary and source code snapshot. I also updated my build script so that it never happens again.

This release also comes with a important bug fix. You can donwload it here.

1. Login to the pc.
2. Hit CTRL-alt-Del to get to the Windows Security Screen
3. Click “Change Password”
4. Click “Cancel” to get back to the main Windows Security Screen.
5. Click “Lock workstation” At this point, the workstation won’t lock.
6. Click “Cancel”.

At this point Winlogon will crash and the pc will reboot. There are other ways to make the computer crash because of the same bug.

Please update to version 1.4.3.

Many thanks to Abdul Khaliq for helping me test and debug this release !

Billet bixi portant le code 21213

Ça semble bien peu, mais si les codes ne sont utilisables qu’au point de service où ils sont émis, et pour une durée limitée, avec peut-être une détection d’attaque en force brute, on devrais pouvoir dormir tranquille…

Je me suis rappellé une attaque mathémaitque sur des codes de ce genre. Avec une location de 24 heures à 5$, on peut prendre et remettre le vélo plusieurs fois, histoire de tester la théorie… Bonne nouvelle, Bixi n’est pas vulnérable. Mais j’écris quand même la démarche, c’est trop rare qu’on a l’occasion d’utiliser des math pour (tenter de) contourner les règles d’un système.

La vulnérabilité apparais lorsque l’implémentation utilise une fenêtre coulissante pour vérifier les codes entrés. Cette attaque a déjà été utilisée pour dévérouiller une porte de voiture à combinaison.

Pour les Bixi, les chiffres du codes de dévérouillage de vélo peuvent être 1, 2 ou 3. Le dictionnaire des valeurs possibles à une taille k=3. Il faut entrer 5 chiffres, on dit que n=5. Avec ces variables, une fenêtre coulissante fonctionne comme ceci :

1. On entre n chiffres (par exemple 12222)
2. Ce ne sera pas le bon code
3. On entre un chiffre supplémentaire, disons 3
4. Pour accomoder le chiffre supplémentaire, l’implémentation décale les chiffres déjà entrés pour faire de la place. Dans notre exemple, c’est le 1 qui disparaît à gauche à la faveur du 3 à droite.
5. L’implémentation vérifie le nouveau code dans la fenêtre, soit 22223.

On réussi ainsi à tester 2 codes en ne saisissant que 6 chiffres, au lieu de 10. Et ainsi de suite, à chaque fois qu’on ajoute un seul chiffre, on se trouve à tester un nouveau code de 5 chiffres. La première étape ne sert qu’à initialiser le processus, sans affecter la complexité de l’attaque.

C’est une vielle idée. Un mathématicien Hollandais, Nicolaas Govert de Bruijn, a formalisé une séquence de chiffres dans laquelle n’importe quelle séquence de n chiffres n’apparait qu’une seule fois. Autrement dit, si vous générez une séquence de Bruijn avec k=3 et n=5 (les codes Bixi) et que vous y cherchez votre code Bixi, il n’y sera qu’une seule fois. C’est la façon la plus optimale d’attaquer un système de codes comme celui de Bruijn.

Voici la séquence dans l’ordre. Elle se lit de gauche à droite, de haut en bas. 1111121111311…… Le 1111 de la fin de la séquence est en fait les premiers chiffres qui se répêtent.

11111 21111 31112 21112 31113 21113 31121 21121 31122 21122

31123 21123 31131 21131 31132 21132 31133 21133 31212 21212

31213 21213 31221 31222 21222 31223 21223 31231 31232 21232

31233 21233 31313 21313 31322 21322 31323 21323 31332 21332

31333 21333 32222 23222 33223 23223 33232 33233 33311 11

La protection contre cette attaque est heureusement toute simple : à l’étape 2, effacer tous les chiffres et en redemander n autres. C’est ce qu’on fait les designers de Bixi. L’histoire ne dit pas s’ils connaissaient l’attaque, ou s’ils ont été chanceux… Au moins il pourrons dire qu’il m’ont fais marcher et pédaler !

On Vista, you can also revert to the old interface by adding the /xp switch.

I am also investigating a timeout problem. In short, the timeout is not honoured if the user is doing something. A system default is used. On my Windows XP SP2 and Vista Business SP1, it is 10 seconds. Some users report shorter times than that (3 seconds).

You can download it here.

Credential Providers cannot make an authentication decision. They only collect credentials. The approach I took in “Aucun” is that the Gina actually makes the authentication decision. That will not work under the new Credential provider architecture.

When I started looking to port my Gina to a Credential Provider, I first though of saving the initial credentials (when the first user logs on), then check any other user’s credential in my own Credential Provider, and if all is good, replay the initial credentials.

That bothered on many grounds :

• There will be a unlock event logged to the initial user, although that user never unlocked the workstation
• I don’t like saving passwords, even to encrypted memory
• That architecture didn’t look like something that would last

Looking deeper into the Credential Provider interface, I saw that there is one decision a Credential Provider can make. It can select what Authentication Package will honor the logon request (or unlock request, in my case). That takes place in my (your) ICredentialProviderCredential::GetSerialisation, by setting the ulAuthenticationPackage field of the CREDENTIAL_PROVIDER_CREDENTIAL_SERIALIZATION structure.

So I believe the right way of doing this is to have two components :

1. An authentication package that implements the unlock policy (any user can unlock, depending on group membership).
2. A credential provider that collects credentials (and while you’re at it, the session you want to unlock) and instruct winlogon to forward them the “unlock” authentication package.

That architecture fixes all three points above. And as a bonus, I can greatly simplify my existing Gina by merely collecting the credentials and forward them to the same authentication package. No need to hook dialog procedures and sending magic, reversed engineered constants to winlogon. In short, instead of making the Credential Provider look like a Gina, I make the Gina behave like a Credential Provider.

Authentication packages are the same under Vista and XP, that’s a good thing. But to debug them, you need the scary kernel remote debugging tools. You also need to reboot every time you mess up. But I have a working authentication package from CVS NT code source, and another called YPAuth (YP means yellow pages, the old name of NIS). None of them support the unlock scenario, though…

Stay tuned !

Here is an example. With a stock build of ocrad, I have tried to get the text from the same image, with one or two lines over the text.

$ ocrad -v banane.pbm processing file ‘banane.pbm’ file type is P4 file size is 175w x 66h number of text blocks = 1 BANANE	$ ocrad -v banane-1.pbm processing file ‘banane-1.pbm’ file type is P4 file size is 175w x 66h number of text blocks = 1 _ANE	$ ocrad -v banane-2.pbm processing file `banane-2.pbm’ file type is P4 file size is 175w x 66h number of text blocks = 1

The text goes from 100% to 0% percent recognition just by adding two lines ! The word BANANE, then _ANE and after that … nothing !

This CAPTCHA is by no means robust, and I stay convinced that all forms of CAPTCHA are to be avoided. This example just goes to show the effect of segmentation on optical character recognition (OCR).

After all, artificial intelligence is a field of expertise you can spend your life learning. Just like cryptography, it should not be done by amateurs. But unlike cryptography, an AI challenge has no key. Microsoft and Google‘s CAPTCHA have been broken. Your CAPTCHA will be broken too, it someones takes a shot at it. It is a matter of time, and there is a shorter way than brute force.

If you think you must put a CAPTCHA, start thinking about plan B right away… Using an image based CAPTCHA is not good either (post in French).

Je déteste les CAPTCHA. C’est comme de la mauvaise crypto.

Fondamentalement, le CAPTCHA ne fonctionne pas. La tâche d’analyse (le test de Turing) est complexe juste parce que personne ne s’est encore donné la peine d’écrire le code pour réussir. C’est aussi vrai pour la crypto classique, mais ces mathématiques sont soumises à des études formelles et continues. On sait à quoi s’en tenir : avec de la bonne crypto, on déplace le problème ailleurs (la gestion de clé, souvent). En intelligence artificielle, la segmentation est difficile, mais l’ordre de grandeur d’effort est à la portée des botnets actuels.

Trouver un éléphant ou un burger est faisable. Google ne trouve-t-il pas déjà les visages sur les photos ? La faiblesse de ce CAPTCHA, en particulier, c’est l’apprentissage (en supposant que l’implémentation est bonne). La mémoire d’un ordinateur est infinie. Il est possible d’avoir la base de données complète des images en relativement peu de temps. D’identifier ce qui s’y trouve et automatiser le tout. Bien sûr, il ne faut pas que l’image soit déjà dans l’index Google… Autre faiblesse, on sait toujours d’avance combien il y a de (chat-chien-burger-bébé-éléphant). Ça aide à prendre une décision automatisée.

Les attaques sur les CAPTCHA de Microsoft et Google a montré que l’analyse de CAPTCHA n’a pas un taux de succès de 100 %. Un petit pourcentage, multiplié par un bon botnet, ça fait beaucoup de captcha résolus!

On n’a qu’à ajouter de nouvelles images, non? Oui, mais combien coûtera toute cette mécanique, en développement mais surtout en entretien? Quel est le coût réel d’une utilisation abusive du service? Combien coutera l’analyse préalable des images, le classement en mots clés, etc.? On m’a demandé de compter 3 bébés, mais une image en contenait deux, faut-il filtrer ces images-là aussi?

Mais surtout, l’aspect économique de la sécurité est complètement évacué. Ce CAPTCHA est sur une page qui demande un numéro de carte de crédit, mais pas sur la page qui permet d’utiliser le service une seule fois, gratuitement. Et c’est sans compter qu’une ferme de Turing coute 8 $ pour 4000 CAPTCHA résolus. Combien coûte un client légitime dégoûté par toutes ces précautions?

Ce CAPTCHA est l’œuvre d’amateurs. Et j’ai même pas regardé l’implémentation des cookies, session, etc. En bref, implémenter correctement ce CAPTCHA par image coûte beaucoup trop cher.

Si j’étais forcé d’utiliser un CAPTCHA, j’utiliserais un simple encodage javascript des champs du formulaire, variable dans le temps, peut-être avec un hashcash en javascript aussi, et vraiment accolé au pied du mur, j’essaierais recaptcha. L’idée est de transformer tes utilisateurs en ta propre ferme de Turing. Pas fou!