Scripts John The Ripper - Jumbo

Bon, cet article est un peu lame, surtout vu les exemples que je vais donner, mais l'idée c'est d'aborder la possibilité de récupérer le mot de passe d'un conteneur chiffré à l'aide de John the Ripper et ses outils (généralement fournis par le patch Jumbo).

Premièrement, ce que j'entends par conteneur, c'est un fichier dont le contenu est chiffré, et pour lequel un mot de passe est nécessaire pour obtenir/dériver une clé permettant le déchiffrement du contenu chiffré. Ici je vais présenter l'exemple de KeePassX et de TrueCrypt.

Il existe des outils certainement plus performants que John The Ripper pour ces algorithmes là. Je pense particulièrement à "truecrack" que je n'ai pas encore eu l'occasion de tester, mais qui est adapté pour la récupération du mot de passe d'un volume TrueCrypt. Mais mon propos ici est de montrer que le patch Jumbo de John The Ripper apporte un certain nombre de scripts très intéressants (ensuite, il est parfaitement possible d'utiliser oclHashCat pour casser le hash d'un volume TrueCrypt une fois qu'on l'a).

Je n'explique pas ici comment récupérer et compiler John the Ripper et son patch Jumbo (rtfm).

J'ai créé un volume TrueCrypt pour l'occasion, avec un mot de passe bateau: "toto", présent dans une de mes wordlists. Les algos utilisés sont ceux proposés par défaut par TrueCrypt :

On utilise ensuite le script "truecrypt_volume2john" fourni par John Jumbo :

Puis on passe le fichier résultant à John en spécifiant l'algo de hash utilisé (même si par défaut il utilise le bon), ainsi que le chemin vers notre wordlist bien fournie. Au bout de quelques secondes, on obtient notre mot de passe:

On peut faire la même chose avec KeePassX. J'ai créé une base KeePassX standard (pas de keyfile), puis le script keepass2john :

Là encore, on utilise John, et on a le mot de passe :

Bien évidemment, il existe un très grand nombre d'autres scripts, dont en vrac :

- 7z2john.py

- androidfde2john.py

- ecryptfs2john.py

- odf2john.py

- office2john.py

- pdf2john.py

- rar2john

...

La crypto dans la vie de tous les jours

C'est parfois effrayant:

[...] it was very interesting to examine the Outlook 2003 PST files. This file format has three levels of encryption. “None“, “Compressible Encryption” and “Best Encryption” with “Compressible Encryption” being the default.

“None” is not encrypting the data at all - just like the Netscape Mail example.

“Compressible Encryption” is simply a substitution cipher. It is exactly what the “secret decoder ring” does; it is also called a Caesar cipher. For data, a particular byte always gets substituted by a fixed other one. That is why the PST file still compresses well. It just obscures the data and would have stopped my naïve Notepad attack. But this would not stop any forensic software from undoing this substitution on the fly.

“Best Encryption” is similar but the substitution table changes depending on the data’s position. This also can be automatically undone without the password.

moar gmail security

Voilà une excellente nouvelle, gmail qui utilise du https par défaut pour l'ensemble de la session (et pas seulement pour l'authentification). Pour rappel, c'était en phase de test ces quelques derniers mois (afin d'évaluer la charge que cela pourrait engendrer).

cryptophail

Korben (le fameux) a balancé dans la matinée un lien vers une sorte de lib permettant de réaliser des formulaires web dont le contenu est chiffré (par le browser, en javascript) avant d'être envoyé sur le réseau, puis déchiffré côté serveur et ensuite utilisé.
En lisant la FAQ, un truc m'a quelque peu ennuyé:

* How secure is jCryption ?
Well that’s not easy to say, the RSA public key encryption algorithm is one of the strongest and most secure in the world. It has survived over 20 years although it has some disadvantages/weaknesses. For example if you use a keylength +512bit. Like I mentioned before, everytime you submit a form the keypair will be newly generated, because of this fact jCryption, with it’s functions, is immune to some attacks. But I think in most cases it should be enough using a 512bit key because it’s not that easy to factorize a 512bit prime. But you can adjust the security level of jCryption very easy in PHP (see documentation page). But remeber the higher the security, the longer it takes to generate the keypair. Although jCryption offers some nice ways to bypass the waiting time of the key generation (see the full featured example).

* Why should I use jCryption instead of SSL ?
In my opinion jCryption is much easier to install and configure. Although I don’t think that jCryption is a replacement for SSL. It could be a nice addtion for your contact form or login page to simply make it more secure. If you need highest security you have to use SSL, because jCryption offers no way of authentication.

Et c'est là que vous réalisez à quel point des années de sécurité informatique tombent aux oubliettes. Parce que bon, les attaques Man in the Middle ça n'existe pas, c'est bien connu; donc on peut utiliser une clé de 512 bits (trop la classe, quand on lit que RSA 1024 bits ne doit plus être utilisé d'ici quelques années, même si ce n'est pas pour tout de suite) sans avoir peur que, au hasard, quelqu'un détourne le flux, et se fasse passer pour le véritable correspondant sans le prouver (car vous l'avez bien lu, "jCryption offers no way of authentication"), et puisse déchiffrer les données chiffrées et/ou les modifier (et ça, que ça soit 512 bits ou 4096).
Bon, au moins ils disent que ça ne remplace pas SSL. C'est déjà ça.