Applications, sites et API

Particuliers et entreprises

Dépôt de fichiers dangereux

Unrestricted file upload / Malicious file upload

Un fichier envoyé à un service peut y être exécuté ou détourner son traitement.

Révision éditoriale : Comprendre : 2 min · Cas technique et détails : 5 min
Je pense être concerné : que faire ?
Illustration pédagogique : dépôt de fichiers dangereux.

Comprendre et agir

Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.

Une situation concrète

Un portail reçoit des justificatifs. Il range une pièce jointe dans un dossier où le serveur peut exécuter des scripts. Quand le fichier est appelé, le serveur l’interprète comme un programme.

Comment cela fonctionne

Un service d’envoi de fichiers doit décider ce qu’il accepte, où il le range et comment il le traite. Une attaque profite d’une erreur dans ces étapes. Le fichier peut être exécuté par le serveur, piéger un lecteur de documents ou être diffusé aux visiteurs. Un nom rassurant, une extension et une analyse antivirus ne suffisent pas, à eux seuls, à garantir un traitement sûr.

Comment le piège fonctionne
  1. Un fichier est envoyé

    Le service reçoit un document non fiable.

  2. Il accepte un traitement dangereux

    Stockage exécutable ou lecteur vulnérable.

  3. Le fichier produit un effet

    Exécution, accès indu ou diffusion d’un contenu piégé.

Ce que vous pouvez faire

Vos premiers réflexes

Consultez les documents reçus avec des logiciels à jour et signalez les pièces jointes au comportement inhabituel. N’activez pas une fonction supplémentaire à la demande d’un document non fiable.

Si vous êtes responsable du service ou de l’organisation

Séparez le stockage des fichiers reçus de toute zone d’exécution. Contrôlez les formats, les tailles et les droits de consultation, puis isolez les aperçus et conversions nécessaires.

Un point à vérifierUne idée reçue à corriger

Un fichier accepté par l’antivirus peut rester dangereux si le serveur l’exécute ou le traite avec un composant vulnérable.

À vous de décider

L’antivirus n’a rien signalé sur un fichier déposé. Le serveur peut-il le traiter sans autre précaution ?

Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.

Voir la réponse expliquée

Non. Le fichier peut être exécuté à cause de la configuration du serveur ou atteindre un lecteur vulnérable. Le service doit aussi contrôler le format, empêcher l’exécution dans le stockage et isoler les traitements.

Analyser un cas technique

Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».

Étude de cas fictive

Un justificatif déposé rejoint un répertoire exécutable

Le portail fictif valide une extension puis range le fichier dans un espace où le serveur sait interpréter des scripts. La consultation view-55 passe par un interpréteur. Dans la reproduction isolée, l’activité de processus confirme un effet qui dépasse le simple stockage. Le statut HTTP 200 indique seulement une réponse réussie ; il ne prouve pas cette exécution.

Il faut conserver le lien entre l’identifiant du dépôt, son contenu et le fichier réellement ouvert. Un renommage ou une conversion peut rompre une comparaison fondée seulement sur le nom d’origine. La politique du serveur web et les associations de types déterminent aussi le traitement.

Le dépôt corrigé se fait dans un espace privé sans interprétation de scripts. Les fichiers autorisés passent ensuite par un téléchargement contrôlé et, si nécessaire, une conversion isolée. Le module Chamilo CVE-2023-4220 de Rapid7 fournit un exemple documenté de dépôt dangereux ; les étapes et noms de notre portail sont fictifs.

Le déroulement en schéma

Qui échange avec quiLisez les échanges de haut en bas. Le point marque le départ et la flèche l’arrivée. Les vérifications après correction ne sont pas la suite de l’attaque.

Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.

Étape
DéposantFichier non fiable
PortailValidation et identité
StockagePolitique d’exécution
Serveur de consultationTraitement du fichier
  1. Action

    Envoi du justificatif

    Déposant vers Portail

    Trace upload-31

  2. Action

    Stockage après contrôle incomplet

    Portail vers Stockage

    Trace web_executable

  3. Réponse

    Identifiant attribué

    Stockage vers Portail

    Trace fichier conservé

  4. Action

    Demande de consultation

    Déposant vers Serveur de consultation

    Trace view-55

  5. Action

    Ouverture du fichier

    Serveur de consultation vers Stockage

    Trace handler configuré

  6. Action sur place

    Interprétation du fichier

    Serveur de consultation

    Trace activité vérifiée en laboratoire

  7. Action

    Nouvelle politique de stockage

    Portail vers Stockage

    Trace privé, sans exécution

Comment repérer cette attaque

Indices à rechercher

  • Un fichier reçu est interprété comme un programme lors de sa consultation.
  • Une pièce jointe déclenche un processus ou une connexion inattendus.
  • Des fichiers apparaissent hors de l’emplacement prévu ou sous un type incohérent.

Relier les dépôts aux appels de consultation et aux traitements associés. Rechercher un interpréteur ou processus inattendu, une écriture hors de la zone attribuée et les consultations d’autres utilisateurs, en vérifiant la configuration réelle du serveur.

Quelles informations comparer

Suivre l’identifiant et l’empreinte du dépôt jusqu’au fichier réellement consulté, puis au traitement choisi et au processus. Reconstituer les renommages et conversions avant de conclure que deux traces concernent le même contenu.

Ce que ces indices ne permettent pas de conclure

Un fichier suspect peut avoir été stocké sans être exécuté. Le type déclaré, l’extension et le verdict antivirus sont des indices partiels ; c’est la chaîne de traitement et ses effets qui déterminent l’impact.

Comment réagir

Couper l’accès au fichier tout en préservant sa copie et les journaux. Fermer le chemin de dépôt ou de traitement dangereux, examiner les autres fichiers reçus par ce chemin et l’activité du compte de service. Une simple suppression du fichier ne suffit pas si du code a déjà été exécuté.

Vérifier la correction

L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.

  1. Les fichiers reçus ne peuvent pas être exécutés par une requête au serveur web.
  2. Le format réel, la taille, les noms attribués et les droits de téléchargement sont contrôlés.
  3. Les conversions sont isolées ; les formats métier légitimes restent utilisables après correction.

À vous de raisonner

Le dépôt et la consultation répondent HTTP 200. Ces deux lignes suffisent-elles pour annoncer une exécution de code ?

Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.

Comparer avec le raisonnement expliqué

Non. Elles établissent des réponses HTTP. Il faut relier le fichier au traitement réellement choisi, à l’interpréteur et à ses effets. La correction doit supprimer la possibilité d’exécuter les dépôts, contrôler les formats et isoler les conversions.

Consulter les détails techniques

Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.

Lire les extraits commentés (reconstitution fictive)

Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-les dans les extraits.

storage_policy
Description pédagogique de la configuration de stockage ; ce n’est pas un champ automatiquement émis par nginx.
unexpected_process_observed
Constat de la reproduction isolée qui doit être appuyé par la filiation réelle des processus pour une enquête.

Dépôt, consultation et traitement d’un fichier factice

JSONL

Reconstitution normalisée de journaux applicatifs et d’une observation de processus. Les noms de fichiers, identifiants et champs sont inventés ; aucun programme piégé n’est fourni.

{"file_id":"upload-31","actor":"user-8","extension_check":"passed","storage_policy":"web_executable","stored":true}
{"file_id":"upload-31","request":"view-55","status":200,"handler":"script_interpreter"}
{"file_id":"upload-31","environment":"isolated_test","unexpected_process_observed":true}
{"file_id":"upload-32","storage_policy":"private_non_executable","script_request":"denied"}
Préparer une collecte dans votre environnement

Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les secrets.

  1. Service concerné — audit et historique à vérifier

    Où les trouver
    Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
    Quoi relever
    Retrouver l’identité, l’identifiant du fichier, l’empreinte, la validation et l’emplacement attribué. Documenter les copies et conversions : le nom fourni par le navigateur ne suffit pas à suivre le fichier.
    Accès et prérequis
    Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
    Documentation : Service concerné — audit et historique à vérifier
  2. nginx — journal d’accès HTTP

    Où les trouver
    Sur le frontal, dans le fichier désigné par access_log ; son contenu dépend de log_format. L’hébergeur peut devoir fournir cet export.
    Quoi relever
    Rapprocher la requête de dépôt et celle de consultation avec la configuration de traitement. Le statut 200 n’indique pas si la réponse provient d’un téléchargement ou d’un interpréteur.
    Accès et prérequis
    Lecture des journaux serveur. Vérifier que la route est journalisée : les temps de réponse et identifiants de requête ne figurent pas forcément dans le format configuré.
    Documentation : nginx — journal d’accès HTTP
  3. Linux — auditd

    Où les trouver
    Sur le serveur concerné, dans le fichier log_file d’auditd, généralement /var/log/audit/audit.log. Les enregistrements SYSCALL, EXECVE et PATH d’un même événement partagent le numéro dans msg=audit(...).
    Quoi relever
    Examiner les processus et les accès au fichier sur l’hôte de traitement. Les événements doivent être disponibles pendant les faits ; une création de fichier ne démontre pas son exécution.
    Accès et prérequis
    Service actif et règles d’audit adaptées avant les faits. Linux n’enregistre pas automatiquement toutes les exécutions et lectures ; les arguments et chemins collectés peuvent être sensibles.
    Documentation : Linux — auditd

Si vous pensez être concerné

Si vous utilisez le service

Consultez les documents reçus avec des logiciels à jour et signalez les pièces jointes au comportement inhabituel. N’activez pas une fonction supplémentaire à la demande d’un document non fiable.

Pour l’équipe qui exploite le service

  1. Retirez l’accès public au fichier en conservant une copie pour l’enquête.
  2. Faites vérifier le traitement appliqué et les actions du processus concerné.
  3. Corrigez le stockage et les contrôles avant de réactiver le dépôt.

Pour comprendre votre situation et trouver de l’aide : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.

Sources et repères pour approfondir