From 70e94764205bd894788bc10a885f8e7680c5036c Mon Sep 17 00:00:00 2001 From: Pierre Martin Date: Wed, 23 Sep 2026 01:13:02 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20retire=20la=20recommandation=20de=20res?= =?UTF-8?q?triction=20r=C3=A9seau=20/api/internal/*?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit INTERNAL_TOKEN est le bon périmètre d'authentification pour cet endpoint, pas l'adresse réseau — une restriction reverse-proxy serait redondante. Le token a de toute façon été roté, ce qui referme ce point. Co-Authored-By: Claude Sonnet 5 --- incidents/2026-09-14-gitea-cryptominer.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/incidents/2026-09-14-gitea-cryptominer.md b/incidents/2026-09-14-gitea-cryptominer.md index bb35e4e..be8e82a 100644 --- a/incidents/2026-09-14-gitea-cryptominer.md +++ b/incidents/2026-09-14-gitea-cryptominer.md @@ -1,6 +1,6 @@ # Incident : mineur de cryptomonnaie via Gitea (packObjectsHook) -- **Statut** : contenu, secrets serveur rotés et Gitea mis à jour vers 1.27.3 (2026-09-23). Reste : restriction `/api/internal/*`, mots de passe utilisateurs/tokens/webhooks. +- **Statut** : contenu, secrets serveur rotés et Gitea mis à jour vers 1.27.3 (2026-09-23). Reste : mots de passe utilisateurs/tokens/webhooks. - **Date de compromission** : 2026-09-14 ~15:16-15:17 - **Date de détection** : 2026-09-22 (via un `git clone` cassé) - **Impact** : exécution de code sur le serveur hébergeant Gitea (et potentiellement l'hôte partagé, ~40 services CapRover) ; minage de cryptomonnaie (Monero) actif pendant ~8 jours @@ -34,7 +34,9 @@ Cette technique fait croire, à la lecture rapide du fichier, qu'il s'agit d'une L'endpoint interne Gitea `/api/internal/manager/add-logger` (normalement réservé à un usage interne, protégé par `INTERNAL_TOKEN`) semble avoir été atteignable depuis l'extérieur via le reverse-proxy public (l'IP source `10.0.1.105` observée dans les logs correspond au conteneur `captain-nginx`, donc toutes les requêtes publiques passent par cette IP côté Gitea — la requête malveillante est arrivée par le chemin HTTP public normal). Ceci est cohérent avec des vulnérabilités connues de Gitea permettant l'injection de config git via cette API interne mal exposée. -**À vérifier/confirmer** : version exacte de Gitea au moment de l'attaque (`gitea/gitea:1.25.4`), CVE correspondant, et si `/api/internal/*` est bien bloqué au niveau du reverse-proxy CapRover. +**Décision** : pas de restriction réseau supplémentaire sur `/api/internal/*` au niveau du reverse-proxy. L'authentification par `INTERNAL_TOKEN` est le bon périmètre de sécurité pour cet endpoint (pas l'adresse IP source) ; ajouter un blocage réseau serait redondant. Le vecteur réel reste donc **la compromission du `INTERNAL_TOKEN` lui-même** (fuite non identifiée), pas son exposition réseau — token désormais roté (voir plus bas), ce qui referme ce point sans action supplémentaire. + +**À vérifier/confirmer** : version exacte de Gitea au moment de l'attaque (`gitea/gitea:1.25.4`), CVE correspondant à une éventuelle fuite/faiblesse du `INTERNAL_TOKEN`. ## Charge malveillante @@ -105,7 +107,6 @@ La mise à jour CapRover de `DB_PASSWD` faite plus tôt (rotation des secrets, c ## Reste à faire -- [ ] Vérifier/restreindre l'accès à `/api/internal/*` au niveau du reverse-proxy (défense en profondeur, même si Gitea patch le bug) - [ ] Changer les mots de passe des 3 comptes Gitea (pierre, Sans.pub, Duogeeks) par précaution - [ ] Révoquer et régénérer les 4 tokens d'accès personnels (LML, Piaire CI/Deploy, Piaire, Laptop .npmrc) — penser à mettre à jour partout où ils sont utilisés - [ ] Régénérer les 4 tokens de webhook CapRover (déploiement tmp-fc, dechets-agglo-muretain, etherpad, domi-marche) et mettre à jour les URLs de webhook correspondantes dans Gitea