Passa al contenuto principale

Impersonificazione IMDS

ID Bollettino: AWS-2025-021
Ambito:
AWS
Tipo di contenuto:
importante (richiede attenzione)
Data di pubblicazione: 8/10/2025 11:15 PDT

Descrizione:

AWS è a conoscenza di un potenziale problema di impersonificazione del Servizio di metadati di istanza (IMDS) che porterebbe i clienti a interagire con account AWS anomali. IMDS, quando viene eseguito su un’istanza EC2, gira su un’interfaccia di rete di loopback e fornisce le credenziali di metadati dell’istanza, che i clienti utilizzano per interagire con i servizi AWS. Queste chiamate di rete non lasciano mai l’istanza EC2, e i clienti possono contare sul fatto che l’interfaccia di rete di IMDS si trovi all’interno del perimetro dei dati di AWS.

Quando si utilizzano strumenti AWS (come AWS CLI/SDK o l’Agente SSM) da nodi di calcolo non EC2, è possibile che un IMDS controllato da terze parti fornisca credenziali AWS anomale. Perché ciò si verifichi, è necessario che il nodo di calcolo sia in esecuzione su una rete in cui la terza parte ha una posizione privilegiata. AWS consiglia ai clienti di seguire le guide all’installazione e alla configurazione (AWS CLI/SDK o Agente SSM) quando utilizzano gli Strumenti AWS al di fuori del perimetro dei dati di AWS per garantire che questo problema venga mitigato. Consigliamo, inoltre, di monitorare gli endpoint IMDS che potrebbero essere in esecuzione nell’ambiente locale per prevenire in modo proattivo tali problemi di impersonificazione da parte di terzi.

Versioni interessate: IMDSv1 e IMDSv2

Risoluzione:

AWS consiglia ai clienti di seguire le guide all’installazione e alla configurazione (AWS CLI/SDK o Agente SSM) quando utilizzano gli Strumenti AWS al di fuori del perimetro dei dati di AWS per garantire che questo problema venga mitigato.

Monitoraggio:

è necessario che le organizzazioni monitorino il traffico anomalo del Servizio di metadati di istanza (IMDS) AWS in ambienti on-premises, poiché ciò indica potenziali configurazioni errate, applicazioni cloud eseguite localmente o problemi di sicurezza.

È necessario monitorare le connessioni a 169.254.169.254 (endpoint di metadati locali del collegamento IPv4 di AWS) e fd00:ec2::254 (endpoint di metadati IPv6 AWS), le richieste HTTP a percorsi specifici di AWS come /latest/meta-data o /latest/api/token, e la presenza di intestazioni di metadati AWS come X-aws-ec2-metadata-token. Questi endpoint non dovrebbero mai apparire in reti puramente on-premises poiché sono riservati alle istanze AWS EC2 per recuperare dati di configurazione, credenziali IAM e informazioni sull’istanza.

Ai clienti viene offerta questa panoramica delle linee guida al rilevamento in SIGMA, un formato di regole generico che si traduce in linguaggi di interrogazione SIEM specifici, consentendo l’implementazione universale del rilevamento. Per creare questa regola, è necessario definire logsource: category: network per correlare diverse telemetrie di rete, quindi creare più blocchi di selezione. ip_aws_dst: dst_ip: 169.254.169.254 acquisisce le connessioni dirette, mentre http_url_paths: url|contains: [’/latest/meta-data’, ’/latest/api/token’] rileva le richieste di metadati utilizzando la sintassi dell’elenco di SIGMA. Consigliamo di utilizzare varianti di campo come destination.ip, c-ip e request_url|contains all’interno di blocchi di selezione separati per adattare diversi schemi di log tra i diversi fornitori e implementare la logica delle condizioni per far corrispondere tutti i blocchi di selezione in base ai prefissi forniti (ad esempio, condizione: 1 di ip_* o 1 di http_* dove il carattere jolly * corrisponde a tutti i blocchi di selezione che iniziano con quei prefissi). Il rilevamento può essere reso preciso utilizzando il modificatore “contains” di SIGMA: request_headers|contains: 'X-aws-EC2-metadata-token' per le richieste di token IMDSv2. Dopo l’implementazione, SIGMA converte questa sintassi universale nei linguaggi di query nativi del SIEM (SPL di Splunk, AQL di QRadar, KQL di Sentinel o KQL di Elastic) mantenendo la stessa logica di rilevamento e adattandosi al contempo ai nomi di campo e agli operatori specifici della piattaforma.

Per migliorare la fedeltà della regola, i clienti possono prendere in considerazione l’attivazione dell’avviso solo per il traffico di rete on-premises applicando una logica di soppressione basata su VLAN o sottoreti di origine.


Per eventuali domande o dubbi sulla sicurezza, inviare un’e-mail all’indirizzo aws-security@amazon.com.