Blog ESEC Lab

Récemment lors d'un audit nous avons été confronté au besoin d'interpréter et de modifier des objets java sérializés. Ça a été l'occasion de développer une librairie à cet effet. Librairie écrite bien entendu en Ruby.

Lire la suite

J'ai souvent l'habitude de travailler sur IDA, puis de charger Immunity Debugger après que l'analyse a été un peu dégrossie. L'analyse d'ImmDbg est bonne, mais ne vaut pas celle d'IDA. Les noms de variables et de fonctions détectées par IDA, ajoutés par l'utilisateur ou retrouvés depuis un fichier de symboles ou une signature peuvent être exportées dans un fichier MAP. MapConv, un plugin C pour OllyDbg, charge ces fichiers et modifie le nom des fonctions détectées dans OllyDbg. Il est facilement recompilable pour Immunity Debugger, mais ne fonctionne qu'avec l'exécutable debuggé (pas les modules chargés) et ne charge que les noms trouvés dans la première section du programme (la section de code, en général).

J'ai donc développé un nouveau plugin ajoutant aussi les noms trouvés dans les autres sections, en exploitant l'interface en Python, plus souple, d'Immunity Debugger.

Lire la suite

On sait ce qu'on cherche, mais le programme est relativement gros : par où commencer? On trouve facilement plusieurs fonctions de hachage, et même plusieurs MD5, qui doivent provenir de différentes bibliothèques. En outre il n'est pas certain que la fonction de hachage utilisée soit un MD5.

Lire la suite

Le boîtier NetScreen contient un processeur Intel IXP425 cadencé à 400MHz. C'est un processeur utilisé pour l'embarqué, et il est optimisé pour les applications réseau. Il est équipé notamment d'un co-processeur accélérant les procédures de chiffrement. C'est un processeur XScale (architecture ARM), reconnu par IDA. Le système d'exploitation est un système propriétaire, ScreenOS, développé par Juniper. Il est stocké sur une mémoire Flash de 32Mo. Il n'y a pas de documentation technique disponible, la seule source d'information étant le manuel d'utilisation.

Lire la suite

Ce document présente la méthodologie qui nous a permis d'analyser le format de stockage des mots de passe des utilisateurs de NetScreen, solution de gestion unifiée des menaces développée par Juniper Networks. Une étude préliminaire a été faite par observation du format des mots de passe. Elle n'a pas permis de comprendre en totalité les algorithmes utilisés pour encoder le mot de passe. Une autre phase a été nécessaire : la ROM du boîtier a été désassemblée. Cela a permis finalement d'écrire un programme permettant de casser les mots de passe utilisés. -

Lire la suite

Windows contient des fonctions de debuggage offrant des possibilités équivalentes à ptrace sous Linux. Contrairement aux systèmes UNIX, plusieurs fonctions sont disponibles, et ont des noms assez explicites. Alors que les possibilités de debuggage sous UNIX sont regroupés dans une seule fonction, Windows en propose 17. En plus de cela, une bibliothèque supplémentaire, DbgHelp, permet de manipuler les symboles de debuggage s'ils sont présents dans l'exécutable ou dans un fichier annexe. Cette bibliothèque est utilisée généralement à des fins classiques : elle permet de debugger plus facilement ses programmes ou ceux dont les symboles sont disponibles. Les fonctions de cette bibliothèque n'étant pas (ou peu) utilisable d'un point d'un point de vue malicieux, elles ne seront pas traitées ici.

Lire la suite

Ce billet est une annexe concluant les deux articles déjà postés sur le cheval de Troie KBD. Il contient :

• Le diagramme des utilisées
• Une liste de serveurs contaminés diffusant le cheval de Troie
• La réécriture en C d'une fonction trouvée dans le cheval de Troie, qui récupère les mots de passe retournées par MessenPass

Lire la suite

Le package JavaVirtualMachine.jar

Cette archive jar contient le coeur du cheval de Troie. Via des classes Java, il charge une bibliothèque dynamique en mémoire, et l'utilise pour réaliser certaines de ses actions.

Avant l'ajout de Twain.class comme nous venons de le voir, l'archive contient :

>> unzip JavaVirtualMachine.jar
Archive:  JavaVirtualMachine.jar
 creating: META-INF/
 inflating: META-INF/MANIFEST.MF        inflating: JPEGEncoder.class      
 inflating: AttackTCP.class             inflating: LoggerThread.class    
 inflating: AttackUDP.class             inflating: MailSender.class       
 inflating: AutoController.class        inflating: MesajGonderici.class  
 inflating: AutoOrderServer.class       inflating: NativeKaynaklar.class 
 inflating: BridgeWay.class             inflating: ProcThread.class       
 inflating: Decyrptor.class             inflating: ProtectorClass.class  
 inflating: Encriptor.class             inflating: RegistryAPI.class      
 inflating: Encyrptor.class             inflating: URLDownloader.class   
 inflating: IPChangeListener.class      inflating: Win32.class            
 inflating: JarUpdate.class             inflating: WinEnum.class         
 inflating: JKeyMailThread.class

Cette archive est lancé en tant que processus à part entière. Nous l'analysons donc à partir de son point de départ, la fonction main() de la classe RegistryAPI.

Lire la suite

Une des grandes forces des systèmes UNIX est d’offrir une forte compatibilité malgré la diversité des systèmes. Cela se vérifie également en matière de debuggage puisqu’une fonction unique centralise cela :

long ptrace (enum __ptrace_request request , pid_t pid , void *addr , void *data ) ;

Le prototype est assez explicite :

• request spécifie l’opération à effectuer ;
• pid indique le processus cible ;
• les 2 derniers arguments dépendent de la requête, addr indiquant l’adresse à traiter, et data des données en entrée ou sortie. En revanche, et contrairement à une idée rependue, les versions de ptrace() ne sont pas toutes équivalentes, loin de là. Par exemple, les capacités de debuggage sous Mac OS X avec ptrace() sont très pauvres, l’effort étant porté sur les capacités tirées du noyau Mach. Inversement, la version Linux de ptrace() est extrêmement puissante et donne un contrôle complet sur le processus debbuggé.

Voyons les possibilités offertes par cette fonction.

Lire la suite

Ce document présente l'analyse un cheval de Troie qui s'installe sur le poste de la cible via son navigateur. Il s'agit d'une applet Java auto-signée, pouvant donc accéder au disque local. Il utilise en outre une bibliothèque dynamique en C/C++, interfacées avec le Java, pour étendre son emprise sur le système.

L'intérêt de ce cheval de Troie tient en plusieurs points :

• il n'utilise aucun exploit pour compromettre la machine cible ;
• il est (presque) indépendant du système d'exploitation car essentiellement réalisé en Java ;
• il échappe aux détections grâce à des astuces simples et efficaces.

Tout part d'un site compromis par un pirate ...

Lire la suite

Pourquoi debugger des programmes ? En général, on se lance dans ces opérations quand on est développeur et qu’on recherche la cause d’un plantage dans son programme. Alors, pourquoi se préoccuper de debuggage quand on traite de sécurité ? Simplement parce que quiconque sait debugger peut faire quasiment tout sur un système d’exploitation. En effet, cela demande de toucher au cœur même du système, et donc de connaître tous ses principes de fonctionnement. Dans cette série de trois billets, nous présentons les méthodes classiques de debuggage sous Linux et Windows, puis nous développons quelques exemples de ce qu’il est possible de faire grâce à cela.

Lire la suite

Qui a dit que l'exploitation d'une faille noyau ou d'une faille à distance devait être compliquée ? Ce billet décrit une faille apparue pendant l'été 2006 avec l'ajout d'une nouvelle fonctionnalité : l'appel système prctl.

Lire la suite