Avertissement sur l’Accès Non Autorisé Récent aux Organisations Japonaises

Résumé

Une série d’incidents d’accès non autorisés visant des organisations japonaises a maintenant été observée, conduisant principalement à la fuite d’informations personnelles. L’activité comprend l’exploitation de vulnérabilités logicielles connues, des manipulations non autorisées d’API, des injections SQL dans Metabase, et le déploiement de web shells via des fichiers WAR. Ces cas semblent cibler les systèmes de gestion, les outils de BI, et les applications internes qui n’étaient jamais destinés à être exposés au public.

Enquête

JPCERT/CC a identifié plusieurs vecteurs d’attaque, y compris l’exploitation de points de terminaison API, l’injection NoSQL et l’utilisation d’adresses IP malveillantes spécifiques. L’enquête montre que les attaquants recherchent des vulnérabilités et des mauvaises configurations connues, telles que des fichiers de configuration ou de sauvegarde non protégés. Les mises à jour récentes soulignent spécifiquement les web shells intégrés dans des fichiers .war utilisés pour exécuter des commandes shell via des paramètres de requête.

Atténuation

Les atténuations suggérées incluent la limitation du débit sur les points de terminaison d’API sensibles, des contrôles d’accès stricts, et des correctifs de sécurité pour les logiciels vulnérables tels que Metabase. Les organisations doivent appliquer le principe du moindre privilège aux jetons d’API et restreindre la disponibilité du service à certaines régions géographiques. Il est fortement conseillé de durcir les outils de gestion et de BI pour qu’ils ne soient pas exposés à Internet public.

Réponse

Après détection, les organisations doivent révoquer immédiatement les jetons API compromis, bloquer l’accès des IP malveillantes identifiées, et rechercher tout mouvement latéral possible. La révision des journaux du serveur web pour des requêtes GET/POST inhabituelles et la vérification des déploiements non autorisés de fichiers .war ou .jsp est conseillée. Les organisations doivent également préparer des plans de communication pour informer les clients affectés des éventuels dommages secondaires.

Exécution de simulation

• Narration d’attaque & Commandes : Un adversaire effectue une reconnaissance et un scan de vulnérabilités (T1595.002) contre l’API publique de l’organisation. Pour éviter la détection, l’attaquant utilise généralement un pool de proxies ; cependant, pour cette validation, nous simulerons l’attaquant utilisant l’une des IP spécifiques définies dans la liste noire de renseignement sur les menaces (par exemple, 20.210.128.125). L’objectif est de simuler une tentative de connexion entrante qui atteint le pare-feu, déclenchant la règle basée sur l’IP source.

• Script de test de régression :

  # Ce script simule une connexion réseau à partir d'une IP sur liste noire.
  # Remarque : Dans une simulation réelle, cela serait effectué par une source 
  # externe contrôlée. Pour les tests locaux, nous injectons une entrée de log dans le 
  # pipeline de journalisation pour mimer le pare-feu voyant ce trafic.
  
  echo "$(date '+%b %d %H:%M:%S') firewall-01 filter: inbound permit tcp 20.210.128.125 44332 -> 192.168.1.50 443 tcp dport=443 spt=44332 state=NEW" >> /var/log/firewall.log
  
  echo "Simulation : entrée de log injectée pour l'IP sur liste noire 20.210.128.125"

• Commandes de nettoyage :

  # Supprimez l'entrée de log simulée pour restaurer la base de référence
  sed -i '/20.210.128.125/d' /var/log/firewall.log
  echo "Nettoyage : Entrée de log simulée supprimée."