Après avoir rapidement parlé de tests d'infrastructure dans un billet précédent, je vais tenter ici de refaire la même chose sur les pentests de clients lourds. J'ai fait quelques paragraphes synthétiques pour ne pas écrire un roman. Si vous voulez plus de détails, n'hésitez pas à demander dans les commentaires ou par mail.
Vous avez dit client lourd?
- Papa, dis moi c'est quoi un client lourd?
- Oui biensûr, tu vois la bouteille de lait?
Avant de commencer, je reprends la définition de Wikipedia pour mettre les idées de tout le monde au clair :
Un client lourd est un logiciel qui propose des fonctionnalités complexes avec un traitement autonome. La notion de client s'entend dans une architecture client-serveur. Contrairement au client léger, le client lourd ne dépend du serveur que pour l'échange des données dont il prend généralement en charge l'intégralité du traitement.
Finalité des tests
Pourquoi éprouver la sécurité d'un client lourd?
- Pour connaître ses faiblesses (ben tiens...)
- Pour connaître et maitriser les risques potentiels liés à l'application,
- Pour savoir si l'application ne dégrade pas le niveau de sécurité du SI,
- Pour savoir quoi corriger,
- Pour avoir un joli plan d'action et savoir par quel bout commencer.
Bref il est tout pourri ce paragraphe, désolé ... 
Types d'applications
La plupart des applications lourdes sont développées en interne par le client lui-même. Elles sont souvent orientées métier pour répondre à des besoins spécifiques. Parmi les principales sociétés qui développent ce genre d'applications et que nous avons la (mal)chance d'auditer, on retrouve énormement de banques, d'industriels pointus, de sociétés du CAC40 ...
Pour se faire une idée du type d'applications que nous pouvons auditer, voilà quelques exemples concrets qui me viennent à l'esprit :
- Application de salle de marché,
- Application de virements et de flux financiers,
- Application de gestion du personnel (salaires, ...)
- Application de gestion de stocks,
- Application d'E-SSO.
Technologies / Systèmes / Base de données
De nos jours, la plupart des applications lourdes sont développées en Java / .NET. Les applications qui ont besoin de performances restent codées dans des langages plus bas niveau comme du C / C++ (M'enfin c'est rare).
Dans les bons vieux environnements, on peut croiser du Fortran ou du Delphi. En environnement bancaire on peut retrouver des langages tordus ou plutôt exotiques comme PowerBuilder ... (cf Wikipedia. Voilà vous êtes des experts! 
).
Côté système, les applications lourdes tournent généralement sur des postes clients ... donc dans un environnement Windows. Les services tiers tournent par contre souvent sur des serveurs UNIX (Linux, Solaris, AIX) ...
Côté bases de données, on retrouve beaucoup de bases proprio comme Oracle, MSSQL ou DB2 chez les grands comptes. Faut croire que payer une licence Oracle c'est bandant. ;). Les PME utilisent beaucoup plus facilement MySQL et PostgreSQL. Reste une forte dominante MSSQL.
Le panel de technologies que les clients lourds utilisent est donc varié. Le consultant doit assimiler rapidement les informations que le client lui fournit pour pouvoir utiliser les techniques d'intrusions les plus adaptées. Ce type d'audit est souvent laissé aux consultants confirmés / seniors.
Il est en effet difficile de s'improviser expert lorsque l'on débute sur une techno ou lorsqu'une mission est trop courte ...
Si c'est le cas, on se sort les doigts et on devient dans un premier temps expert Wikipedia. On apprend ensuite sur le terrain pendant la mission.
On passe accessoirement pour un gros blaireau devant le client et on est dans la merde! Pas évident de se former seul sur des technos particulières, difficiles d'approche telles que TIBCO, CORBA, ... Celà demande beaucoup de temps. Le temps pour nos managers préférés c'est de l'argent
Conditions des tests
Dans la plupart des cas, ces tests se déroulent chez le client en interne. Les consultants sont généralement (sous)vendus 5 a 10 jours sur place. Avec leur cable réseau (...) et leur couteau, ils doivent regarder au plus profond de la matrice
Les pré-requis pour débuter les tests ne sont pas énormes ...
- Avoir une à deux prises réseaux disponibles : une pour le PC portable du consultant, une pour un poste client,
- Avoir une plateforme d'homologation ou de pré-prod sur laquelle le consultant pourra effectuer ses tests,
- Avoir la bonne version du client lourd à auditer,
- Avoir des comptes applicatifs si besoin est,
- Avoir un compte administrateur sur le poste client pour lancer certains types d'attaques avec privilèges,
- Avoir les adresses IPs des serveurs avec lesquels l'application communique,
- Avoir le code source de l'application si un audit de code est également vendu,
- Avoir un contact disponible en cas de problème.
Si l'application s'installe facilement et démarre sans problème, les tests se font depuis nos portables. Je ne vous cache pas que c'est assez rare lorsqu'il s'agit de grosses applications ; il nous manque toujours un petit truc pour les lancer (une librairie Oracle à la con, un fichier de configuration stocké sur un partage réseau...). On installe donc nos outils sur un poste client reservé mais ça grignotte du temps sur la mission et c'est loin d'être super sexy...
Voilà, sinon dans la majorité des cas, lorsque l'audit commence, les 3/4 des pré-requis ne sont pas prêts. Génial d'attendre la première matinée (voire la journée) pour avoir des comptes applicatifs.
Les grandes étapes de l'audit
Je ne rentre pas dans les détails sinon ça prendrait 3 plombes (à part si on me le demande). Voilà donc de manière synthétique, les grandes étapes à suivre (pas forcément dans le même ordre) :
- Recherche de chaînes secrètes dans l'application,
- Ecoutes réseaux à divers moments (avant et après authentification),
- Examen de la mémoire (avant et après authentification),
- Désassemblage (sexy le Java et le .NET),
- Modification des flux à la volée (Man In The Middle, Injection DLL ...)
- Espionnage du système (Base de registre, Variables d'environnement, File descriptors ...)
- Debugging / Cracking (On sort l'artillerie lourde, s'il reste du temps on fait du patch à gogo pour contourner certains contrôles de sécurité).
Globalement, si vous suivez ces étapes, vous devrez relativement bien vous en servir et trouver quelques failles
Les Outils
Voici une liste d'outils non exhaustive. On y retrouve les principaux outils passe-partout!
- strings & grep : Recherche de chaînes dans le binaire, DLLs, scripts et fichiers de configuration. N'oubliez pas d'utiliser tous les types d'encodage quand vous cherchez (man strings quoi). En général, on strings puis on grep sur des mots clés standards (passw, secret, key, ...).
- wireshark : L'outil par excellence pour faire des captures réseaux. Celà permet de savoir si des mots de passe ou d'autres secrets passent pas en clair sur le réseau. En pratique, il est très rare de voir des clients lourds chiffrer les communications ...
- WinHex : Très bon outil pour lire ou modifier la mémoire d'un processus à chaud. Il permet également de faire des recherches en UTF8/ASCII dans n'importe quel fichier. Je l'utilise aussi beaucoup pour patcher un binaire ou une DLL. L'outil à ne pas oublier!
- .NET Reflector & Dis# : Ces deux softs décompilent du .NET. Il en existe bien d'autres mais celà sont déjà pas mauvais. On retrouve souvent des mots de passe ou des clés de chiffrement dans le code décompilé, il ne faut pas hésiter!
- JODE & JAD & Java Decompiler : Ceux là décompilent du Java. Là aussi on en trouve toute une floppée sur le net, il suffit de se servir.
- Ettercap & Cain : Les softs parfaits pour faire des attaques Man In The Middle. En pratique, on les utilise très peu. Ca marche toujours, et on n'a trop de chances de planter un réseau avec un outil mal utilisé.
- EchoMirage : Cet outil permet d'intercépter les flux réseaux de l'application et les modifier à la volée. C'est redoutable lorsqu'on audite une application deux tiers qui dialogue avec une base de données. Celà permet par exemple de modifier des requêtes SQL à la volée facilement. Je vous invite à lire ce post
- La suite Sysinternals : On retrouve toute une collection d'outils qui permettent de monitorer l'application ainsi que son environnement système. On peut par exemple, voir quelle DLL est chargée par l'application, quelles sont les clés de base de registre qui sont utilisées, ... Ca prendrait un billet à détailler!
- Win32dasm & IDA Pro : Des désassembleurs bien pratiques lorsqu'on fait du reverse et que l'on essaye de patcher l'application pour contourner un contrôle de sécurité réalisé côté client. Plusieurs plugins d'IDA permettent de faire des trucs sexy. J'aime énormément Hex-Rays qui permet de générer du pseudo code.
- OllyDbg & Immunity Debugger : Puissants débuggers qui permettent de comprendre pas à pas comment l'application fonctionne. Ca aide énormément lorsque l'on doit pondre du patch (très rare).
- DbVisualizer : Il ne faut pas oublier un client SQL générique. La plupart des applications lourdes se connectent directement à une base de données. Pratique de pouvoir se connecter à la base une fois que l'on a récupéré le mot de passe du DBA en mémoire
Constatations
D'une manière générale, après avoir fait une trentaine d'audits de clients lourds, je trouve que le niveau de sécurité des applications testées est faible pour ne pas dire mauvais. Il faut dire que la plupart des applications possèdent des architectures 2 / 3 difficiles à sécuriser. Beaucoup de secrets sont donc stockés côté client dans des fichiers de configuration ou en mémoire. Beaucoup de contrôles de sécurité sont effectués par les clients lourds ce qui est une abérration. En effet, une simple modification des flux réseau (EchoMirage), une modification de la mémoire (WinHex) permettent de contourner relativement facilement des contrôles trop souvent graphiques. Pour casser la baraque, il est très rare de faire du reverse puis de patcher une application (et de toute façon on viole les développeurs).
Sur l'ensemble de mes audits, seule une application lourde d'E-SSO ne s'est pas vu gratifiée d'une faille critique dans un rapport, l'exploitation des failles critiques étant difficile...
Et non... je vous donnerai pas le nom de l'application sauf moyennant finance
(Vive la pseudo éthique du métier. Heureusement qu'on n'est pas tous CEH ... )
Pour en finir, ces résultats font relativement peur... Certaines banques prennent compte nos remarques mais réagissent à moindre coût.
Ne pouvant pas changer l'architecture de toutes leurs applications internes, on fait du bricolage souvent immonde qui vise à complexifier
la difficulté d'exploitation des vulnérabilités. Sniff 