Dans un billet technique publié le 1 janvier 2026, un chercheur en sécurité raconte comment il a abouti à une chaîne d’exploits menant à une RCE pré-auth sur LogPoint SIEM/SOAR après une première divulgation responsable de failles majeures découverte en 24 heures.

Le contexte: l’analyse commence par un accès en labo à l’appliance (basée sur Ubuntu), la récupération des sources Python (en partie livrées en .pyc) via décompilation, et la cartographie de l’architecture: un backend historique en Python sur l’hôte et des microservices Java en Docker pour la partie SOAR.

Architecture réseau: l’investigation met en évidence deux couches Nginx. Le premier, en frontal (ports 80/443), reverse-proxy vers un second Nginx dans le conteneur (localhost:9443) qui route vers plusieurs microservices internes (API, backend, data, scheduler, notifications, SSO, Elasticsearch). Les règles de routage sont jugées très permissives, transformant Nginx en simple répartiteur de chemins plutôt qu’en barrière de sécurité.

Chaîne d’exploitation (TL;DR de l’auteur): à partir d’« exposed internal routes » fournissant des primitives d’authentification, un secret de signature en dur permet de forger l’accès; des identifiants d’API internes divulgués élargissent les privilèges côté microservices; une SSRF pivote vers des endpoints Python accessibles seulement depuis l’hôte pour frapper une session admin; enfin, un sink eval() du moteur de règles devient atteignable en contournant la validation via une clé AES statique dans des packages de règles importés, déclenchant l’exécution de code sur l’appliance.

Points saillants techniques: l’auteur souligne un premier problème (« Bug 1 ») de mauvaise configuration de routage Nginx, l’absence d’un véritable gardien d’authentification inter-services, et la coexistence de piles hétérogènes (Python historique vs Java conteneurisé) avec des secrets statiques et hypothèses de confiance implicites.

IOCs: Aucun indicateur (hash, domaine, IP malveillante) n’est cité. TTPs observées:

  • Exposition de routes internes via reverse proxy trop permissif 🔀
  • Secrets/signing key et clé AES statiques codés en dur 🔐
  • Divulgation d’identifiants d’API internes 🪪
  • SSRF pour atteindre des endpoints host-only 🌐
  • Élaboration de session admin par primitives d’auth et SSO 🪙
  • Exploitation d’un sink eval() pour RCE 💥

Conclusion: il s’agit d’une publication de recherche qui retrace le raisonnement, les indices et l’enchaînement de six « petits » bugs en une RCE pré-auth sur LogPoint, avec une démarche narrative et technique.

🔗 Source originale : https://mehmetince.net/the-story-of-a-perfect-exploit-chain-six-bugs-that-looked-harmless-until-they-became-pre-auth-rce-in-a-security-appliance/