vendredi 5 mars 2010

Lockpicking avec une clé magnétique Winkhaus ?

Cette semaine j'ai fait la rencontre avec une clé particulièrement intéressante : une clé en plastique permettant d'ouvrir et de fermer une serrure. Cette clé en plastique est en effet suffisemment épaisse pour exercer une pression suffisante pour tourner le barillet de la serrure et ne présente aucune caractéristique pouvant faire croire à un possible lockpicking traditionnel.

Lorsque l'on recherche sur le net on trouve facilement la technologie qu'il y a derrière. Cette serrure est en fait electrifiée et repose sur la technologie RFID, en effectuant un challenge response chiffrée sur 128 bits. Lorsque le challenge response est OK, une tige en fer est déplacée électriquement permettant à la serrure de s'ouvrir.

La magie de l'insécurité intervient alors. Même si l'inventivité humaine est suffisemment grande pour créer des serrures de plus en plus modernes (je ne dit pas compliquée, ni complexe car ce n'est pas vraiment le cas), les concepteurs ne pensent pas forcément à tous les styles d'exploitations de ces serrures. En 2005, au Chaos Communication Congress, une démonstration a été faite : avec un très gros aimant collé sur la poignée on arrive avec n'importe quelle clé à ouvrir la serrure. Ces serrures très couteuses n'ont pas été modifiées durant plus de 6 mois après la démonstration d'une faille très sérieuse, aujourd'hui ces serrures sont normalement corrigées.

Il existent cependant des exploitations avec un aimant particulier permettant à la petite tige de métal qui bloque la serrure d'être déplacée. On trouve cet aimant sous le nom de "Ring of The Devil". Les nouvelles serrures déplacent la petite tige bloquante avec un petit moteur électronique (les exploitations sont plus faciles lorsque la tige est déplacée de manière magnétique).

lundi 14 décembre 2009

Pentest web avec Firefox

Depuis deux ans on voit apparaitre divers plug-ins Firefox pour faciliter le travail des développeurs Web, mais aussi des pen-testeurs. Voici une petite collection d'add-ons plus ou moins pratiques, qui vous aiderons dans vos pen-tests...

jeudi 10 décembre 2009

Ne confondons pas (fonction de hachage et de chiffrement) !

Fonction de hachage et fonction de chiffrement.

C'est une erreur commune de croire que md5, sha1 et ses équivalents plus solides, sont des fonction de chiffrement. En effet, lorsque les mots de passe ne sont pas stockés en clair, il le sont souvent sous la forme d'un condensat (hash), et ce en se basant sur la propriété suivante : la fonction de hachage est une fonction à sens unique.

A partir du mot de passe, on peut obtenir le hash, mais pas l'inverse (les collisions c'est une autre histoire ;) ). Donc, si un attaquant obtient le hash, il ne pourra rien faire avec, puisque ce n'est pas le mot de passe !

Et là c'est le drame...

En effet, bien qu'en théorie on ne puisse retrouver de façon formelle le mot de passe à partir du hash, il est toujours possible d'effectuer une attaque par force brute à l'aide d'un outil comme John The Ripper.

En essayant toutes les combinaisons possibles de mots de passes et en passant ces combinaisons dans la fonction de hachage approprié, l'attaquant peut retrouver le mot de passe !!!

"Mais alors, pourquoi n'utilise-t-on pas de fonction de chiffrement !!!" me direz vous...
  1. la crypto c'est compliqué : forcément, quand pour vous enseigner l'usage de la cryptographie, on vous bassine avec la théorie mathématique qui en est à l'origine... ça ne donne pas envie.
  2. la crypto c'est lent : quand on doit traiter plusieurs milliers d'opérations de login, on veut des fonctions rapides, et les fonctions de hachage sont bien plus rapides que celles de chiffrement.
  3. on a toujours fait ainsi : sur bien des systèmes, les mots de passe ont toujours été stockés sous forme de condensat, car à l'époque on avait pas la puissance nécessaire pour bruteforcer le hash. C'etait bien suffisant.
Sauf que les temps ont changé... mais pas les habitudes.

La solution : mettez y un peu de SEL.

Lorsque vous souhaitez stocker le mot de passe d'un utilisateur, utilisez la fonction de hash comme ceci : hash("mot-de-passe" + "sel")

Si jamais un attaquant tombe sur un hash, et qu'il le casse, il se retrouvera alors avec une chaine qui sera la concaténation du mot de passe et du sel ce qui allongera la durée nécessaire au cassage du mot de passe, et ajoutera de la complexité au mot de passe lui même, rendant bien plus longue sa découverte.

lundi 30 novembre 2009

Upload d'une backdoor jsp depuis la console JMX de JBoss

Il arrive parfois de rencontrer des serveurs JBoss dont la console JMX traine nonchalamment sur le réseau derrière un port 8080.

En accédant à l'url suivante http://url_jboss:8080/jmx-console vous pouvez accéder à cette console fort pratique, et au travers du Mbean service=BSHDeployer sous jboss.deployer, vous pouvez créer à loisir un script BeanShell. Et ce n'est pas les exemples qui manquent sur internet (Google est votre ami :) ).

Grâce au Beanshell vous pourrez créer et copier une JSP au bon endroit (ex: le répertoire de la console JMX) et ainsi exécuter des commandes sur le serveur au travers de la JSP !!!

Cependant la taille est limitée...

Voici quelques liens si vous souhaitez explorer plus en détail les diverses techniques associées à la console JMX :

http://www.nruns.com/_downloads/Whitepaper-Hacking-jBoss-using-a-Browser.pdf
http://www.notsosecure.com/folder2/2009/10/27/hacking-jboss-with-jmx-console/
http://carnal0wnage.blogspot.com/2009/11/hacking-unprotected-jboss-jmx-console.html

Happy hacking !!!

lundi 23 novembre 2009

Sécurité des applications FLEX/AMF

Les applications riches (RIA) posent de nouveaux problèmes aux pen-testeurs, car on se retrouve face à un client lourd, dont le code source n'est pas aussi accessible que peut l'être le Javascript (modulo l'obfuscation ;) ).

Le client lourd en environnement WEB à un premier effet pervers sur le développeur : l'impression de contrôler les actions du client, ce qui s'accompagne d'un relâchement des contrôles coté serveur.

Et là, c'est le drame !!!

Car le flash peut être décompilé et analysé à l'aide d'outils comme SWFScan d'HP.
les requêtes flex (au dessus d'HTTP) peuvent être analysées à l'aide de Burp,
et bien sur, il est possible d'interagir avec la partie serveur à l'aide de librairies AMF comme pyAMF :D

Happy Hacking !

OpenVPN sous Debian Lenny

En environnement professionnel on a souvent besoin d'accéder au réseau de l'entreprise de manière directe... Nous avions déjà parlé de SSL-Explorer qui permet via un client "léger" (une applet JAVA) d'accéder a des services situé dans le réseau interne d'une entreprise. Cependant les VPNs SSL malgré leur forte augmentation doivent répondre a des contraintes assez importantes notamment pour la connexion vers le S.I. de l'entreprise. En effet le VPN SSL a besoin comme point d'entrée la plupart du temps une connexion sécurisée sur le port 443. Ce qui n'est pas forcément facile si l'entreprise possède qu'une seule IP d'entrée et des services déjà disponibles sur ce port.

C'est ce type de contrainte qui me fait préférer le déploiement "ultra-rapide" d'un VPN SSL "lourd". Aujourd'hui dans l'esprit de la plupart des personnes VPN SSL est synonyme de VPN léger accessible depuis un navigateur. Mais ce n'est pas forcément vrai... et OpenVPN est la pour le prouver. La contrainte essentielle d'OpenVPN est qu'il nécessite un client et qu'il ne s'adapte pas à toutes les typologies de réseau : un certain port doit être ouvert, et non les ports les plus couramment utilisés comme 80, 443...

La commande clé :

aptitude install openvpn

Le reste (la configuration) est suffisamment bien décrit ici (exemple sur Etch mais fonctionne sur Lenny) : Coagul.

Il faut garder à l'esprit que la machine OpenVPN va devenir "un routeur" de l'extérieur vers le réseau interne. Il est nécessaire de bien filtrer les flux depuis et vers cette machine. Il très recommandé d'installer un filtrage IPTables sur la machine. Le firewall Shorewall me semble tout indiqué pour ce type de filtrage rapide.

vendredi 30 octobre 2009

Scam

Aujourd'hui j'ai reçu mon premier scam !!!

A votre aimable attention,
Je viens par la présente vous offrir une importante proposition d'affaires qui sera bénéfique pour nos deux parties au terme de la transaction.
Etant conscient que sur internet il existe de mauvaises blagues et de gens pas sérieux ,j'ai besoin de quelques précisions sur vous avant de vous donner les détails.

Vous devez savoir que ceci n'est point une mauvaise blague et que je ne perdrai pas inutilement mon temps et le vôtre.
Mon nom est George Weba et je vis ici à Londres en Angleterre.
Voici ma préoccupation avant d'aller plus loin :

Pouvez-vous être mon associé dans un transfert légal de fonds sur un compte que vous fournirez ?
Je vous donnerai plus de détails sur l'opération dès que je serai convaincu que vous êtes la bonne personne qui sera mon partenaire d'affaires
Je vais juste ajouter qu'un pourcentage des fonds sera le vôtre.

J'attends votre réponse, bien de choses .

Weba.

Ça m'a amusé, et j'ai pris la peine d'y répondre... à ma façon.

Cher Georges,

Il est clair que sur internet il existe de mauvaises blaques, et des gens pas très sérieux, heureusement pour toi, je suis très sérieux, c'est pourquoi j'ai pris la peine de tracer l'origine de ton e-mail, afin de confirmer tes dires...

En relisant le header de ton mail, je tombe sur ceci :

Received: from [196.201.85.90] by web3311.mail.ogk.yahoo.co.jp via HTTP; Fri, 30 Oct 2009 21:15:24 JST

M'indiquant que tu rédiges ce mail sur une webmail yahoo, et cette dernière m'indique depuis quelle ip tu la rédiges (196.201.85.90)

Grâce à une petite géo-localisation, je tombe sur ceci :

196.201.85.90 CI Cote D'Ivoire 82 Lagunes Abidjan 5.3411 -4.0281 Cote d'Ivoire Telecom ISP Cote d'Ivoire

Ce qui signifie que tu m'écris d'Abidjan !!! Moi qui croyais que tu m'écrivais d'Angleterre...

J'ai aussi fait quelques recherches sur ton nom... histoire de voir :)
On retrouve ta trace ici ou la sur internet :

http://www.419scam.org/emails/2006-05/18/527339.479.htm
http://www.thescambaiter.com/FORUM/showthread.php?t=10915

Hélas dans des e-mails d'arnaque :(
Tu sembles faire parti des gens pas sérieux qui font de mauvaises blagues... mais je ne t'en veux pas, tu m'as bien fait rire :)

Cordialement,
Bon, le souci, c'est que les headers ne sont pas toujours facilement consultables sur les webmails... et c'est pourtant très pratique pour vérifier d'où vient un mail :)

Sous Gmail, il suffit d'aller en haut a droite du message, et dans les options de réponse (en haut à droite du message), vous trouverez "afficher l'original", sous yahoo mail voici les instructions.

En lisant ces headers, vous pourrez très simplement tracer le cheminement du mail sur internet, ce qui vous donnera quelques informations sur l'expéditeur, histoire de croiser les informations.

Si vous avez les méthodes pour hotmail et d'autres webmails moins connus, laissez donc un commentaire :)