Une interface web auditée en 2020, 2022 et 2024. Un code source relu. Et pourtant, une surface entière n’avait jamais été regardée : le client lourd, ce logiciel installé sur le poste qui donne accès aux actions d’administration. Présenté à SecSea 2026, cet audit d’un ERP métier montre ce qu’on trouve quand on ouvre enfin cette porte : une chaîne complète, de la lecture de fichiers au jeton d’administrateur forgé jusqu’à l’exécution de code.

Onzième et dernier volet de notre couverture de SecSea 2026. Nous avons volontairement anonymisé le produit : la leçon est universelle, le nom ne l’est pas.

Le point aveugle : ce qui n’est jamais audité

Un ERP (un logiciel de gestion d’entreprise) expose souvent une interface web, bien balisée par les audits, et un client lourd réservé aux usages avancés. Ce dernier passe fréquemment sous le radar, parce qu’il est moins visible et plus pénible à analyser. C’est exactement pour cela qu’il mérite l’attention : la surface qu’on n’audite pas est celle qui accumule les défauts.

Avant d’auditer un client lourd, on cherche à savoir en quel langage il est écrit, quel protocole réseau il emploie, et si l’on peut intercepter ses échanges. Ici, les communications étaient interceptables, et même partiellement lisibles, portant des objets sérialisés, ces structures qu’une application reconstruit à la réception, et qui sont une source classique de failles.

Une chaîne, maillon par maillon

L’audit a enchaîné des défauts banals mais complémentaires. Nous en décrivons la logique, pas la reproduction :

  • Des rôles modifiables dans la réponse. Le client affichait les menus que le serveur lui autorisait ; en modifiant cette réponse, on faisait apparaître toutes les fonctions. Afficher ne donne pas les droits, mais révèle les outils disponibles et les requêtes du client.
  • Un défaut de contrôle d’accès menant à la lecture de fichiers. Une fonction de supervision se comportait comme un lecteur de fichiers, et le chemin qu’elle manipulait pouvait être remplacé, ouvrant une lecture arbitraire.
  • Un secret de session volé, puis un jeton forgé. La lecture de fichiers a mené à un secret de configuration. Un défaut de traitement de certains caractères dans ce secret a permis, à partir de là, de forger un jeton de session d’administrateur.
  • De l’administrateur à l’exécution de code. Une fonction d’édition cachée s’appuyait sur un composant de reporting dont les modèles pouvaient contenir des éléments exécutables, ouvrant la voie à une exécution de commandes et à un accès au conteneur, là où les secrets sont regroupés. L’équipe s’est arrêtée au périmètre autorisé par le client.
Chaque maillon, pris seul, est un défaut mineur. Enchaînés, ils mènent du simple utilisateur à l’exécution de code. C’est la définition même d’une chaîne d’attaque, et la raison pour laquelle on n’évalue pas une faille isolément.

Le retournement : le client lourd attaqué à son tour

Dernier enseignement, souvent négligé : un client lourd ne fait pas que émettre, il reçoit. S’il reconstruit sans précaution les objets envoyés par le serveur, un attaquant placé entre les deux peut lui renvoyer un objet piégé et obtenir une exécution sur le poste lui-même. Or les utilisateurs d’un client lourd occupent souvent des rôles importants dans l’entreprise, ce qui fait de leur poste une cible de valeur. La confiance ne va pas que du client vers le serveur.

Ce qu’on en retient chez Humanix

  • On n’audite que ce qu’on regarde. Une interface web impeccablement testée ne dit rien du client lourd, de l’API mobile ou du connecteur hérité. Le périmètre d’un audit doit couvrir toutes les surfaces, pas la plus visible. C’est le même angle mort que le cache local d’Outlook : le défaut est là où personne ne regarde.
  • Un ERP n’a pas sa place sur Internet. L’intervenant déconseille formellement d’exposer une instance directement en ligne, et il en a trouvé plusieurs dizaines accessibles. Mettre un logiciel de gestion derrière un accès contrôlé est une décision d’architecture, pas une option.
  • La désérialisation reste un classique mortel. Reconstruire un objet venu du réseau sans restreindre strictement ce qui est autorisé est une faille récurrente, côté serveur comme côté client lourd. À vérifier en priorité dans toute application métier.
  • Une chaîne se démonte maillon par maillon. Couper un seul maillon (contrôle d’accès, gestion des secrets, désérialisation) suffit souvent à casser toute la chaîne. C’est là qu’un audit apporte sa valeur : montrer l’enchaînement, pas lister des failles. La preuve avant le verdict.

À retenir

  • Le client lourd d’un ERP, rarement audité, concentrait les défauts que l’interface web n’avait pas : la surface non regardée est la plus fragile.
  • La chaîne enchaînait rôles modifiables dans la réponse, lecture arbitraire de fichiers, vol d’un secret de session, jeton d’administrateur forgé, puis exécution de code via un composant de reporting.
  • Un client lourd qui désérialise sans précaution les réponses du serveur peut être compromis à son tour, et ses utilisateurs occupent souvent des rôles sensibles.
  • Mesures clés : ne jamais exposer un ERP sur Internet, auditer toutes les surfaces, et restreindre strictement la désérialisation.

Note. Compte-rendu, à visée pédagogique, d’une présentation de SecSea 2026 sur l’audit du client lourd d’un ERP métier. Nous avons anonymisé le produit et décrivons la logique de la chaîne d’attaque, sans reproduction ni détail exploitable. L’audit a été mené dans un cadre contractuel, et l’équipe s’est tenue au périmètre autorisé par le client. Onzième et dernier volet de notre couverture de l’événement. Une application métier ou un client lourd jamais audité ? Contactez-nous.