pierre/sans.pub
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: retire la recommandation de restriction réseau /api/internal/*

Browse Source 
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 <noreply@anthropic.com>
This commit is contained in:
Pierre Martin
2026-09-23 01:13:02 +02:00
co-authored by Claude Sonnet 5
parent 2e0ae9a91c
commit 70e9476420
1 changed files with 4 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
incidents/2026-09-14-gitea-cryptominer.md
+4 -3
View File
@@ -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