Thick Client Methodology

Architecture

- 2 Tiers :

1) TCP View :

Très utile pour déterminer l'adresse de destination du client lourd.

2) Wireshark :

Allumer Wireshark et essayé de vous connecter au client lourd, de tester des fonctionnalités, etc... Filtrer le host avec l'IP trouvée dans TCPView.

• • La connexion à la base de données est-elle chiffrée?

• • Les données sensibles, telles que les numéros de sécurité sociale ou les informations médicales, username ou mot de passe, sont-elles transmises en clair ? Si c'est lisible ça signifie que la connexion à la base de données n'est pas cryptée et que toute personne ayant accès à ce réseau peut lire ces infos.

3) Echo Mirage :

Echo Mirage permet d'intercepter et de modifier le trafic TCP. C'est un espece de BurpSuite pour les clients lourds. Utile pour comprendre comment marche le client lourd. Essez de modifier des paramètres pour voir comment le client réagis.

- 3 Tiers :

Si un client lourd est construit sur une architecture à trois niveaux, la partie réseau du test sera essentiellement la même que le test d'une application Web.

Beaucoup plus complexe pour proxyfier le tout :

• Proxy-aware : Un client lourd qui a des options ou des paramètres pour se proxyfier dans l'application elle-même.

• Non-proxy-aware : Un client lourd qui n'a pas d'options de paramètres dans l'application elle-même et nécessite une approche de test différente.

Burp Proxy: invisible proxying

BurpSuite :

L'astuce est de proxyfier tout le système Windows en allant dans les réglages de son PC et en cherchant "proxy".

Informations Gathering

1) Strings :

Balancez un petit coup de strings sur votre binaire en .exe pour voir si vous trouvez des creds en clairs ou des choses croustillantes.

2) CFF explorer :

Permet de rapidement connaitre la technologie utilisée et donc d'adapter son analyse (.NET différent d'autre assembly par exemple.)

Attaque coté client

• SQL Injection (probable)

• XXE (probable)

• Error Handling avec fuite d'infos (probable)

• XSS (Peu probable)

DLL Hijacking

1) ProcMon (Process Monitor) :

Ouvrez Procmon et appliquez ces règles :

• Process Name is "Nom_client_lourd.exe"

• Result is "Name not found"

• Path end with ".dll"

  Vous aurez quelque chose qui ressemble à ça :

Remplacer la DLL :

• Il faudra maintenant trouver un chemin sur lequel vous avez les droits d'écriture ( Genre "/AppData" ou "/User/"). Les chemins du type "/System32" ou "/Windows" ne sont pas bons (il faudrais être admin sur la machine pour modifier des fichiers dedans)

• Téléchargez cette DLL non vulnérable :

  GitHu - carterjones/hello-world-dll: a DLL that will show a MessageBox with the message, "Hello world!"

• Remplacer votre DLL manquante par votre DLL en la déplaçant dans le dossier dans lequel vous avez des droits d'écritures et modifiez son nom par le nom de la DLL manquante.

• Rallumez votre client lourd. Si "hello world" pop up alors vous avez une DLL Injection

Interesting files

1) Config files :

Cherchez dans le meme dossier que votre client lourd un fichier du type : Client_Lourd.exe.config. Ce fichier peut contenir beaucoup d'informations.

2) Les logs :

Trouvez les logs de votre client lourd et examinez les.

Analyse du binaire

1) GetPE-Security:

Utilisez ce script Github pour allez plus vite, il vérifiera si l'ASLR est en place ou encore si le strongNaming est activé.

GitHub - NetSPI/PESecurity: PowerShell module to check if a Windows binary (EXE/DLL) has been compiled with ASLR, DEP, SafeSEH, StrongNaming, and Authenticode.

2) Décompiler le binaire :

J'utilise dnSpy pour décompiler le binaire et chercher des requêtes SQL vulnérables ou des mot de passe écrit en clair.

Analyse de la mémoire

1) Gestionnaire de taches :

Ouvrez le gestionnaire de taches, ouvrez la fenêtre en grand, cliquez droit sur votre Client Lourd et créez un fichier de vidage.

2) HxD :

Importez votre fichier de vidage dans HxD et fouillez pour des mots de passes, requêtes spéciales, ou username. Depuis HxD vous pouvez modifier des datas (genre augmenter un compte de 10k a 200k). Ecrasez la mémoire pour valider. Si cela marche alors vulnérable.

Les vulnérabilités critiques les plus répandues :

1. Credentials en clairs

2. Clefs d'api en clairs

3. Sel de mdp en clairs

4. Pas de chiffrement dans la transmission

5. Injection SQL

6. Bypass d'autorisation

7. XXE

8. Manipulation de requêtes SQL

9. Changement des méthodes de chiffrements