Ubuntu a publié l’avis USN-8299-1 pour corriger une vulnérabilité affectant rclone, un outil très répandu de synchronisation et d’accès à des stockages distants utilisé aussi bien sur des serveurs d’hébergement que dans des chaînes CI/CD, des sauvegardes automatisées et des scripts d’administration. Le point sensible concerne l’interface RC pour remote control, c’est-à-dire l’API HTTP d’administration de Rclone. Lorsqu’elle est activée et accessible à un tiers, une faille d’autorisation peut permettre l’accès à des informations sensibles ainsi que l’exécution d’actions non autorisées.

Le risque ne vient pas seulement du bug lui-même, mais de la combinaison entre une surface d’administration exposée et des déploiements parfois réalisés rapidement, sans cloisonnement réseau suffisant. Dans beaucoup d’environnements, rclone tourne avec des privilèges élevés, manipule des identifiants d’accès à des buckets S3, à des espaces OpenStack Swift, à Google Drive, OneDrive, WebDAV ou à des stockages internes, et peut lire ou écrire des données critiques. Une API de contrôle accessible depuis un réseau mutualisé, un VPN trop large, un reverse proxy mal filtré ou Internet transforme alors un utilitaire d’infrastructure en point d’entrée opérationnel pour un attaquant.

La source officielle à retenir est l’avis Ubuntu USN-8299-1: Rclone vulnerabilities, qui référence une correction de sécurité dans les paquets Ubuntu. Le score CVSS n’est pas systématiquement mis en avant dans les avis Ubuntu, mais l’impact pratique est élevé dès lors que l’API RC est active et joignable. Pour les équipes DevOps, administrateurs systèmes et RSSI, la priorité est double : mettre à jour immédiatement les paquets concernés et vérifier l’exposition effective de l’API RC sur les hôtes, conteneurs et VM qui exécutent rclone.

Ce sujet concerne directement les exploitants d’infrastructures Ubuntu sur site, chez OVHcloud, Scaleway, o2switch, en VPS, en VM privées, sur des nœuds Kubernetes, ou dans des environnements de sauvegarde où rclone est souvent déployé comme composant discret mais puissant. Lorsqu’un service d’administration HTTP échappe à une politique de moindre privilège, la compromission peut dépasser le simple périmètre de l’outil et devenir un incident de sécurité affectant des données, des secrets et des workflows d’exploitation.

Versions affectées

L’avis USN-8299-1 indique que les paquets rclone fournis par Ubuntu avant la publication des mises à jour de sécurité sont vulnérables. Les versions exactes dépendent de la branche Ubuntu déployée et du paquet de sécurité publié dans les dépôts officiels Ubuntu. La règle opérationnelle est simple : toute instance Ubuntu n’ayant pas encore reçu le correctif USN-8299-1 doit être considérée comme exposée si l’API RC est activée et accessible.

Dans la pratique, il faut distinguer trois cas :

  • Paquet Ubuntu installé via APT : vulnérable tant que la mise à jour de sécurité issue de USN-8299-1 n’est pas appliquée.
  • Binaire autonome téléchargé hors dépôts Ubuntu : non couvert par l’USN, la correction dépend de la version amont réellement déployée.
  • Image conteneur ou appliance intégrant Rclone : vulnérable si l’image embarque une version non corrigée, même si l’hôte Ubuntu est à jour.

Pour identifier la version installée sur une machine Ubuntu :

rclone version
apt-cache policy rclone
dpkg -l | grep rclone

Exemple d’interprétation :

$ rclone version
rclone v1.xx.x
- os/version: ubuntu 24.04
- os/kernel: 6.x
- os/type: linux

Il faut ensuite comparer la version paquetée disponible localement avec celle proposée par les dépôts de sécurité Ubuntu :

$ apt-cache policy rclone
rclone:
  Installé : 1.xx.x-0ubuntu0.y
  Candidat : 1.xx.x-0ubuntu0.z
  Table de version :
     1.xx.x-0ubuntu0.z 500
        500 http://security.ubuntu.com/ubuntu noble-security/universe amd64 Packages
 *** 1.xx.x-0ubuntu0.y 100
        100 /var/lib/dpkg/status

Si la version Candidat issue de security.ubuntu.com est plus récente que la version installée, le système n’est pas encore corrigé.

Pour les équipes qui gèrent plusieurs versions Ubuntu, le plus fiable est de s’appuyer directement sur l’avis officiel USN-8299-1 et sur les paquets publiés pour chaque distribution prise en charge. En environnement de production, il faut recenser au minimum :

  • les serveurs physiques et VM Ubuntu exécutant rclone en tâche planifiée via cron ou systemd ;
  • les conteneurs qui embarquent le binaire rclone ;
  • les outils de sauvegarde ou de migration qui lancent rclone rcd ;
  • les scripts d’administration exposant indirectement l’API RC via un proxy HTTP interne ;
  • les nœuds d’intégration continue qui utilisent rclone pour publier ou récupérer des artefacts.

Sur le plan de l’identification de la faille, l’avis Ubuntu mentionne une vulnérabilité au niveau de l’API RC. Selon le cycle de publication et la nomenclature retenue par l’éditeur amont, un ou plusieurs CVE-ID peuvent être associés à cette correction. La référence de suivi prioritaire côté exploitation reste ici USN-8299-1. Les équipes de veille doivent néanmoins vérifier dans leurs outils de gestion de vulnérabilités si le correctif est corrélé à un CVE-20xx-xxxx spécifique dans les bases NVD, Ubuntu CVE Tracker ou les scanners d’inventaire.

Si vous maintenez une CMDB ou un référentiel de sécurité, l’entrée à créer doit inclure :

  • Produit : rclone
  • Composant concerné : API RC
  • Source : USN-8299-1: Rclone vulnerabilities
  • Condition d’exploitation : API RC activée et accessible à un tiers
  • Impact : accès à des informations sensibles, actions non autorisées
  • Correctif : mise à jour du paquet Ubuntu vers la version corrigée publiée dans les dépôts de sécurité

Vecteur d’attaque

Le cœur du problème tient à la nature même de l’API RC de Rclone. Cette interface HTTP est conçue pour piloter l’outil à distance : lancer des opérations, interroger l’état du service, manipuler des tâches, et dans certains cas accéder à des informations de configuration ou à des capacités d’administration qui ne devraient être accessibles qu’à un opérateur légitime. Sur le papier, c’est un mécanisme pratique. En production, c’est aussi une surface d’attaque à haut risque si elle est exposée au mauvais endroit.

Une configuration typique d’activation ressemble à ceci :

rclone rcd \
  --rc-addr 0.0.0.0:5572 \
  --rc-no-auth \
  --log-file /var/log/rclone.log

Cette ligne concentre plusieurs erreurs fréquentes :

  • --rc-addr 0.0.0.0:5572 écoute sur toutes les interfaces réseau ;
  • --rc-no-auth désactive toute authentification ;
  • aucun filtrage IP ni reverse proxy de protection n’est interposé ;
  • le service tourne parfois avec un compte disposant d’accès étendus aux fichiers et aux secrets.

Dans un tel scénario, un attaquant qui atteint le port d’écoute peut interagir directement avec l’API d’administration. Même lorsque l’authentification est activée, une faille d’autorisation peut permettre de contourner les restrictions attendues sur certains endpoints ou certaines actions. C’est la raison pour laquelle une simple exposition réseau d’une interface administrative ne doit jamais être banalisée.

Le vecteur d’attaque concret peut prendre plusieurs formes :

Exposition directe sur Internet

Cas le plus grave : le port RC est publié sur une interface publique, volontairement ou non. Cela arrive sur des VPS, des serveurs cloud, ou derrière des groupes de sécurité trop permissifs. Un scan réseau repère rapidement le service HTTP, puis l’attaquant tente des requêtes sur des endpoints connus de l’API RC.

ss -lntp | grep 5572
sudo ufw status
sudo iptables -S

Un simple oubli dans les règles de pare-feu, une ouverture temporaire non refermée, ou une mauvaise configuration Terraform peut suffire. Dans des environnements hébergés chez OVHcloud ou Scaleway, l’erreur est d’autant plus courante que l’on cumule parfois règles locales, security groups et reverse proxies, avec une visibilité fragmentée sur l’exposition réelle.

Exposition sur un réseau interne trop large

Le risque ne se limite pas à Internet. Une API RC liée à 0.0.0.0 sur un réseau d’entreprise, un VLAN d’administration partagé, un cluster Kubernetes, un réseau Docker par défaut ou un VPN ouvert à de nombreux prestataires reste exploitable par tout tiers présent sur ce périmètre. Beaucoup d’incidents naissent d’un mouvement latéral interne plutôt que d’une attaque externe directe.

Exemple avec un service lancé dans un conteneur :

docker run -d --name rclone-rc \
  -p 5572:5572 \
  -v /root/.config/rclone:/config/rclone \
  rclone/rclone:latest \
  rcd --rc-addr :5572 --rc-no-auth

Ici, le port est publié sur l’hôte. Si le serveur est lui-même accessible depuis un réseau d’administration large, l’API l’est aussi.

Exposition via reverse proxy ou tunnel mal protégé

Autre cas fréquent : l’API n’est pas directement publiée, mais exposée via Nginx, Apache, Traefik, un tunnel SSH, un accès Cloudflare Tunnel, Tailscale Funnel ou un VPN applicatif. Si l’authentification amont est incomplète, ou si des routes internes sont accessibles sans contrôle strict, la faille reste exploitable.

Exemple de proxy insuffisamment restrictif :

location /rc/ {
    proxy_pass http://127.0.0.1:5572/;
}

Sans filtrage IP, sans authentification forte et sans journalisation adaptée, ce type de configuration rend l’API atteignable par des tiers non prévus.

Abus fonctionnel après compromission partielle

Dans un scénario de post-exploitation, un attaquant ayant obtenu un accès limité sur un serveur peut découvrir une instance RC locale et l’utiliser pour étendre son contrôle. L’API devient alors un multiplicateur d’impact : lecture d’informations, déclenchement d’opérations, interaction avec des remotes configurés, voire extraction de données selon les droits du processus rclone.

Cette dimension est importante pour les RSSI : même si l’exposition Internet est absente, une faille d’autorisation sur une interface d’administration interne réduit la capacité de confinement en cas d’intrusion initiale.

Impact

L’impact annoncé par Ubuntu est clair : accès à des informations sensibles et exécution d’actions non autorisées. Sur un outil comme rclone, ces deux volets sont particulièrement critiques, car il se situe au carrefour des données et des secrets d’accès aux stockages.

Divulgation d’informations sensibles

Une instance rclone manipule souvent des éléments à forte valeur :

  • noms de remotes et paramètres de connexion ;
  • métadonnées sur les stockages distants ;
  • chemins de sauvegarde, structures de répertoires, noms de clients ou de projets ;
  • journaux d’exécution révélant des opérations internes ;
  • dans certains cas, secrets ou éléments permettant de reconstituer une chaîne d’accès.

Même lorsque les secrets ne sont pas exposés en clair, la simple connaissance de l’architecture de sauvegarde, des buckets distants ou des cibles utilisées peut faciliter une attaque ultérieure. Cela vaut particulièrement pour les environnements MSP, infogérance, hébergement mutualisé ou plateformes multi-clients.

Exécution d’actions non autorisées

Le second impact est souvent plus grave encore. Une API d’administration permet par définition d’agir. Selon les endpoints accessibles et les privilèges du processus, un tiers peut :

  • lancer des transferts ou des synchronisations ;
  • modifier l’état opérationnel de tâches en cours ;
  • interagir avec des remotes configurés ;
  • provoquer des lectures ou écritures de données ;
  • déclencher des opérations perturbant la disponibilité ou l’intégrité des sauvegardes.

Dans un contexte de sauvegarde, une action non autorisée peut se traduire par une suppression logique, une altération de jeux de données, ou un écrasement de versions si les mécanismes de protection côté stockage sont insuffisants. Dans un contexte CI/CD, cela peut affecter des artefacts, des dépôts de paquets ou des contenus distribués.

Scénario d’attaque concret

Un exemple réaliste sur une VM Ubuntu hébergée chez un fournisseur cloud :

  • un administrateur déploie rclone pour envoyer des sauvegardes applicatives vers un bucket S3 compatible ;
  • pour faciliter la supervision, il active rclone rcd sur 0.0.0.0:5572 ;
  • le pare-feu local autorise le port depuis tout le réseau privé du projet ;
  • une autre VM du même périmètre est compromise via une application web vulnérable ;
  • l’attaquant scanne le réseau, découvre le port RC, puis interroge l’API ;
  • il obtient des informations sur les remotes et déclenche des actions non autorisées ;
  • les sauvegardes deviennent inexploitables ou des données sont exfiltrées vers une destination contrôlée.

Ce scénario illustre pourquoi une API d’administration exposée est un multiplicateur de risque. Le bug d’autorisation n’est pas isolé : il s’inscrit dans une chaîne de sécurité qui inclut l’exposition réseau, les privilèges du service, la sensibilité des données manipulées et la qualité du cloisonnement.

Comparaison avec des failles antérieures de surfaces d’administration

L’écosystème infrastructure a déjà connu de nombreux incidents comparables dans leur logique, même lorsque le composant exact diffère : interfaces Redis exposées sans mot de passe, API Docker accessibles sur TCP, consoles Elasticsearch ouvertes, tableaux de bord Kubernetes mal protégés, interfaces d’administration GitLab ou Jenkins insuffisamment restreintes. Le motif récurrent est toujours le même : une fonction d’administration pensée pour un usage contrôlé devient un service attaquable dès qu’elle est joignable.

Le cas de rclone s’inscrit dans cette famille de risques. Ce n’est pas un serveur web métier, mais un composant d’exploitation. C’est précisément ce qui le rend dangereux lorsqu’il est négligé : il est peu visible, rarement supervisé comme une application exposée, mais il dispose d’un pouvoir opérationnel élevé.

Comment patcher

La remédiation prioritaire consiste à appliquer les mises à jour de sécurité Ubuntu publiées avec USN-8299-1. Sur Ubuntu, la méthode standard est la mise à jour via apt. Avant toute intervention, il est recommandé de vérifier si rclone est lancé en service persistant, via systemd, cron, un conteneur ou un superviseur tiers.

Mise à jour via APT

sudo apt update
sudo apt install --only-upgrade rclone

Pour appliquer l’ensemble des correctifs de sécurité disponibles :

sudo apt update
sudo apt full-upgrade

Vérifiez ensuite la version installée :

rclone version
apt-cache policy rclone

La version installée doit correspondre à la version corrigée fournie par les dépôts de sécurité Ubuntu pour votre release. La référence à consigner dans le ticket de changement ou le rapport d’intervention est USN-8299-1.

Redémarrage des services utilisant Rclone

Si rclone est lancé par un service systemd, il faut redémarrer le processus pour charger le binaire corrigé :

sudo systemctl restart rclone
sudo systemctl status rclone

Si le nom de service diffère :

systemctl list-units --type=service | grep -i rclone

Pour un service personnalisé, inspectez l’unité :

sudo systemctl cat rclone.service

Dans les environnements conteneurisés, il faut reconstruire l’image ou tirer une image corrigée, puis redéployer :

docker ps | grep rclone
docker inspect <container_id>
docker pull <image_corrigee>
docker compose up -d --force-recreate

Si l’image intègre un paquet Ubuntu, un simple redémarrage du conteneur ne suffit pas tant que l’image n’est pas reconstruite avec les paquets corrigés.

Validation post-correctif

Après mise à jour, il faut valider trois points :

  • la version du paquet correspond bien à celle publiée dans les dépôts de sécurité ;
  • le service actif utilise le nouveau binaire ;
  • l’API RC n’est pas exposée au-delà du périmètre strictement nécessaire.

Commandes utiles :

which rclone
readlink -f $(which rclone)
ps aux | grep [r]clone
ss -lntp | grep 5572
sudo lsof -iTCP -sTCP:LISTEN -nP | grep rclone

Si vous exploitez des serveurs Ubuntu chez un hébergeur français ou européen, profitez de la fenêtre de changement pour vérifier également les ACL réseau, groupes de sécurité et règles de pare-feu périphériques. Une mise à jour logicielle corrige le bug, mais une API d’administration exposée reste une mauvaise pratique structurelle.

Mitigation

Lorsque le correctif ne peut pas être déployé immédiatement, il faut réduire la surface d’attaque sans attendre. L’objectif est simple : empêcher tout accès non indispensable à l’API RC. La mitigation doit être envisagée comme temporaire, mais elle est aussi l’occasion de durcir durablement l’exploitation de rclone.

Désactiver l’API RC si elle n’est pas indispensable

Dans de nombreux déploiements, l’API RC a été activée pour des tests, une supervision ponctuelle ou une intégration devenue obsolète. Si elle n’est pas nécessaire, le meilleur choix est de la désactiver.

Recherchez les options RC dans les unités systemd, scripts et conteneurs :

grep -R --line-number --color=always "rcd\|--rc" /etc/systemd /opt /usr/local /srv /home 2>/dev/null
crontab -l
sudo find /etc/cron* -type f -print -exec grep -H "rclone\|--rc" {} \;

Puis supprimez les options rcd ou --rc-* de la commande de lancement, et redémarrez le service.

Limiter l’écoute à l’interface locale

Si l’API est requise, elle doit écouter uniquement sur 127.0.0.1 ou sur un socket local lorsqu’une architecture de proxy sécurisé le justifie. Évitez toute écoute sur 0.0.0.0.

rclone rcd \
  --rc-addr 127.0.0.1:5572 \
  --rc-user admin \
  --rc-pass 'mot_de_passe_fort'

Dans un fichier d’unité systemd, une ligne de service plus sûre ressemble à :

[Service]
ExecStart=/usr/bin/rclone rcd \
  --rc-addr 127.0.0.1:5572 \
  --rc-user ${RCLONE_RC_USER} \
  --rc-pass ${RCLONE_RC_PASS} \
  --config /etc/rclone/rclone.conf

Il reste préférable de stocker les secrets via des mécanismes adaptés, par exemple des variables d’environnement injectées par un gestionnaire de secrets, plutôt qu’en clair dans une unité.

Interdire l’accès réseau au port RC

Même avec une écoute locale, il est prudent d’ajouter un filtrage réseau explicite. Avec ufw :

sudo ufw deny 5572/tcp
sudo ufw status numbered

Avec iptables :

sudo iptables -A INPUT -p tcp --dport 5572 -j DROP
sudo iptables -S | grep 5572

Avec nftables :

sudo nft add rule inet filter input tcp dport 5572 drop
sudo nft list ruleset

En cloud, complétez ce blocage avec les règles de sécurité du fournisseur. Un filtrage local seul n’est pas suffisant si une erreur future réouvre le service.

Supprimer les options sans authentification

La présence de --rc-no-auth doit être considérée comme un signal d’alerte immédiat. Recherchez-la activement :

grep -R --line-number --color=always "rc-no-auth" /etc /opt /usr/local /srv 2>/dev/null

Si l’API est maintenue, activez une authentification forte et limitez l’accès aux seuls administrateurs concernés. Néanmoins, dans le contexte d’une faille d’autorisation, l’authentification ne remplace pas la mise à jour. Elle ne fait que réduire le risque d’exposition opportuniste.

Passer par un reverse proxy durci si l’accès distant est indispensable

Si une administration distante est réellement nécessaire, placez l’API derrière un proxy avec :

  • restriction IP stricte ;
  • authentification forte ;
  • journalisation détaillée ;
  • éventuellement mTLS ;
  • absence d’exposition publique générale.

Exemple minimal avec Nginx et ACL IP :

location /rc/ {
    allow 192.0.2.10;
    deny all;
    proxy_pass http://127.0.0.1:5572/;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;
}

Pour un environnement sensible, une exposition via VPN d’administration dédié reste préférable à une publication web classique.

Détection

La détection doit viser à la fois l’exposition, l’usage anormal et les traces de compromission. Comme rclone n’est pas toujours inventorié comme un service exposé, il faut combiner inspection système, analyse réseau et revue des journaux.

Identifier les instances RC actives

ps aux | grep [r]clone
ss -lntp | grep 5572
sudo lsof -iTCP -sTCP:LISTEN -nP | grep rclone
systemctl list-units --type=service | grep -i rclone

Recherchez en particulier :

  • rclone rcd
  • --rc-addr
  • --rc-no-auth
  • --rc-user et --rc-pass
  • des ports atypiques si l’API a été déplacée hors de 5572

IoC et signaux faibles à surveiller

Les indicateurs de compromission ne sont pas toujours spectaculaires. Voici les plus utiles dans un contexte Rclone RC :

  • présence d’un processus rclone rcd non documenté ;
  • écoute réseau sur 0.0.0.0 ou sur une interface publique ;
  • usage de --rc-no-auth ;
  • requêtes HTTP vers le port RC depuis des adresses non prévues ;
  • pics d’activité réseau sortante vers des stockages ou IP inhabituels ;
  • modification inattendue de tâches de synchronisation ou de rétention ;
  • journaux rclone contenant des appels RC à des horaires anormaux ;
  • création ou modification non planifiée de fichiers de configuration rclone.conf ;
  • anomalies dans les buckets ou espaces de stockage : suppressions, copies massives, renommages, changements de destination.

Chemins à examiner selon les déploiements :

  • /root/.config/rclone/rclone.conf
  • /home/*/.config/rclone/rclone.conf
  • /etc/rclone/rclone.conf
  • /var/log/rclone.log
  • journaux journald associés au service

Exemples de recherche dans les logs

sudo journalctl -u rclone --since "7 days ago"
sudo grep -R "rc/" /var/log 2>/dev/null
sudo grep -R "127.0.0.1:5572\|0.0.0.0:5572\|:5572" /var/log 2>/dev/null

Si un reverse proxy est utilisé :

sudo grep -R "/rc/" /var/log/nginx /var/log/apache2 2>/dev/null

Les champs HTTP à surveiller incluent notamment :

  • Host
  • User-Agent
  • X-Forwarded-For
  • codes de réponse et fréquence des requêtes

Une série de requêtes courtes et répétées sur des endpoints RC depuis une IP inconnue constitue un signal d’investigation prioritaire.

Détection d’exposition réseau depuis un autre hôte

Depuis un bastion ou une machine d’audit interne :

nmap -sV -p 5572 <ip_serveur>
curl -i http://<ip_serveur>:5572/

Il faut aussi tester les IP privées, interfaces de cluster et adresses de conteneurs si l’architecture le permet. Beaucoup d’instances ne sont pas publiques mais restent exposées à tout un sous-réseau d’exploitation.

Perspective CERT-FR et gouvernance

À la date de publication de l’avis Ubuntu, la référence première reste l’avis éditeur USN-8299-1. Si un relais ou une note de vigilance du CERT-FR est publié, il doit être intégré aux flux de veille internes. Pour les organisations françaises, ce type de faille rappelle une exigence de gouvernance simple : toute interface d’administration HTTP doit être inventoriée, classée comme surface sensible, et soumise à un contrôle d’exposition périodique.

Dans des environnements d’hébergement ou d’infogérance, la bonne pratique consiste à inscrire rclone dans les revues de durcissement au même titre qu’un serveur web, une base de données ou un outil de sauvegarde. Une API d’administration ne doit jamais rester “hors radar” parce qu’elle appartient à un utilitaire d’exploitation.

La priorité immédiate est de vérifier les versions Ubuntu concernées, d’appliquer les paquets corrigés de USN-8299-1, puis de confirmer que l’API RC n’est ni exposée inutilement ni exploitée sans contrôle strict. Pour aller plus loin sur le durcissement des services, la réduction de surface d’attaque et les réflexes de confinement, les équipes techniques peuvent utilement compléter cette remédiation par les recommandations de la catégorie /categorie/pratiques, en particulier pour standardiser les audits d’exposition, les règles de pare-feu et la revue des interfaces d’administration oubliées.

Rubrique Serveurs
Partager
Retour aux actualités