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) # 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 compromission** : 2026-09-14 ~15:16-15:17
- **Date de détection** : 2026-09-22 (via un `git clone` cassé) - **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 - **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. 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 ## Charge malveillante
@@ -105,7 +107,6 @@ La mise à jour CapRover de `DB_PASSWD` faite plus tôt (rotation des secrets, c
## Reste à faire ## 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 - [ ] 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é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 - [ ] 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