L’uso di SSRF per raggiungere i metadati AWS e sottrarre credenziali cloud si intreccia con ondate di phishing su PyPI mirate ai maintainer di librerie: due vettori diversi che convergono nella stessa superficie d’attacco, la supply chain. Un’analisi tecnica mostra come una richiesta server-side mal validata possa forzare IMDSv2 fino a ottenere token temporanei di ruolo IAM, mentre campagne mirate su pacchetti Python puntano a prendere il controllo degli account per inserire codice malevolo nelle release. Il risultato è un rischio sistemico che inizia da un endpoint web, passa per pipeline CI e finisce in produzione. Le contromisure esistono, ma richiedono disciplina d’ingegneria, visibilità sugli eventi e governo delle identità, perché l’avversario sfrutta ogni anello debole tra applicazione, infrastruttura e sviluppo.
Cosa leggere
Come un SSRF ha accesso agli account AWS?
Un SSRF nasce quando un’applicazione lato server consente a un input controllato dall’utente di pilotare richieste HTTP interne. Se la convalida è insufficiente, l’attaccante indirizza il traffico verso risorse di rete non esposte, come l’endpoint dei metadati dell’istanza 169.254.169.254. Con IMDSv2, l’accesso richiede un token ottenuto via richiesta PUT e riutilizzato come intestazione; non è un muro invalicabile, perché un SSRF “completo” può riprodurre la sequenza: prima ottiene il token, poi interroga le credendiali temporanee dello IAM role associato all’istanza. Da qui emergono Access Key, Secret e Session Token di STS, sufficienti per chiamate AWS API limitate dal profilo del ruolo. Quando il ruolo è troppo ampio o ereditato da istanze con privilegi eccessivi, l’SSRF si trasforma in un pivot verso l’intero account.
Metadati, ruoli IAM e token temporanei: l’anello debole
Il design dei metadati serve a fornire al processo locale le informazioni di configurazione; la scorciatoia è esporre tali dati a logiche applicative non fidate. Con IMDSv2 le richieste richiedono hop-limit e protezioni contro redirezioni; tuttavia, dove il codice lato server funge da proxy HTTP e consente metodi arbitrari, l’attaccante orchestra la richiesta per ottenere il token IMDSv2 e poi i credentials JSON del ruolo.
Quelle credenziali, pur a scadenza, bastano per elencare bucket S3, leggere segreti mal posizionati, interagire con ECS o EKS, o arrivare a un AssumeRole verso ambienti più privilegiati. Il furto non è solo accesso: è movimento laterale nel cloud, spesso silenzioso, perché le chiamate provengono da indirizzi sorgente legittimi del provider.
Phishing su PyPI: takeover di maintainer e rilascio malevolo
Il fronte PyPI mostra l’altra metà della minaccia. Gli attaccanti inviano email convincenti a maintainer e publisher, imitate su domini simili o compromessi, sollecitando reset credenziali, approvazioni OAuth per strumenti CI/CD o token di pubblicazione. Con un singolo consenso errato, l’avversario ottiene l’accesso al progetto, pubblica una versione “puntuale” con payload offuscati o esfiltrazione di segreti, e sfrutta la fiducia transitiva delle dipendenze. Il colpo è tanto più efficace quanto più il pacchetto è radicato in ecosistemi aziendali, dove build automatizzate aggiornano versioni senza pinning rigoroso. La campagna di phishing non mira solo alla password: insidia 2FA con tecniche di richiesta ripetuta, intercetta link di recupero e punta ai token a lunga durata nei sistemi di integrazione.
Dalla libreria alla produzione: catena di compromissione
Una volta infettata la libreria, il codice malevolo si propaga nei pipeline. Script di post-install, hook di build e step CI possono inviare credenziali cloud verso server controllati dall’attaccante. Il passaggio successivo è la ricerca di chiavi in variabili d’ambiente o file di configurazione, spesso contenenti segreti AWS o endpoint interni. L’impianto nella supply chain aggira i perimetri: viene introdotto “dall’interno”, con la stessa identità che l’azienda ha autorizzato. L’uso di nomi di versione legittimi, changelog minimi e compatibilità API maschera la modifica, mentre la telemetria standard, se non arricchita da controlli di provenance, non distingue un artefatto genuino da uno contaminato.
Indicatori utili senza cadere in falsi positivi
Nel caso SSRF→IMDS, un segnale forte è l’accesso all’IP 169.254.169.254 originato da processi web o percorsi di codice che non dovrebbero interagire con i metadati. Anche la sequenza PUT per il token IMDSv2 seguita da richieste GET puntuali su percorsi delle credentials è indicativa. Nel cloud, un altro segnale è l’uso improvviso di STS da risorse applicative non previste, con mappatura UserAgent atipica e chiamate verso servizi mai toccati prima. Sul fronte PyPI, anomalie come release fuori cadence, introduzione improvvisa di maintainer aggiuntivi, modifica di script di build o incremento di dipendenze non spiegate sono campanelli d’allarme. La chiave è correlare gli eventi: una nuova release, seguita da allarmi su egress DNS e richieste insolite verso domini esfiltranti, indica una compromissione della catena.
Mitigazioni pratiche per ambienti AWS
La difesa parte dal minimizzare la raggiungibilità dei metadati da percorsi non fidati. Impostare IMDSv2 come obbligatorio, ridurre l’hop-limit a uno, bloccare a livello di host e security group l’IP dei metadati per i processi che non lo richiedono, e applicare egress filtering in uscita dalle applicazioni per impedire richieste arbitrarie. La progettazione deve evitare che servizi web fungano da proxy generico; dove il caso d’uso lo impone, bisogna attuare allowlist rigorose per host, porte e metodi. Lato IAM, la risposta è least privilege sui ruoli di istanza, segmentazione per funzione, session duration ridotta e monitoraggio di AssumeRole con policy condition mirate. Se un’applicazione deve leggere segreti, farlo tramite parametrizzazione e accessi sigillati, mai riversando Secret in variabili d’ambiente di processi esposti.
Mitigazioni pratiche per PyPI e pipeline CI
Nel mondo Python, la resilienza si costruisce sul controllo della pubblicazione e sulla verificabilità dell’artefatto. Abilitare 2FA con chiavi hardware per gli account, preferire Trusted Publishers con OIDC per eliminare token statici, e adottare provenance firmata (ad esempio integrazioni basate su attestazioni) consente di dimostrare la provenienza del pacchetto. In produzione e CI, l’uso di hash pinning con --require-hashes, file constraints e repository interni con mirror verificati limita l’impatto di una release avvelenata. Gli step CI vanno isolati con principio del minimo privilegio, segreti a portata minima e scadenza breve; l’analisi statica e dinamica sui pacchetti aggiornati deve includere controlli di network egress e ricerca di stringhe ofuscate. Ogni variazione del grafo delle dipendenze merita una revisione: il costo di un controllo in più è inferiore al costo di una compromissione.
Coordinare detection e risposta tra app e cloud
La telemetria deve unire mondo applicativo e infrastrutturale. I log del reverse proxy e dell’app segnalano gli input sospetti che innescano l’SSRF; i log VPC Flow e CloudTrail mostrano le conseguenze a valle, come GetCallerIdentity, ListBuckets o chiamate inusuali a KMS. Collegare questi due lati consente di reagire rapidamente: revoca delle credenziali STS, rotation dei segreti, blocco temporaneo dei role session e patch del punto di ingresso. La stessa filosofia vale per la supply chain: correlare eventi di pubblicazione PyPI, build CI e comportamenti runtime porta a contenere il danno prima che si traduca in esfiltrazione su larga scala.
Cosa insegna il dibattito della community tecnica?
Le discussioni della community sottolineano che IMDSv2 è efficace ma non sostituisce la validazione degli input e il confinamento delle richieste in uscita. Allo stesso modo, l’ecosistema PyPI ha alzato l’asticella con meccanismi più robusti, ma la sicurezza degli account dei maintainer resta il vero perimetro. La convergenza è chiara: identità, rete e software supply chain devono essere difesi come un’unica superficie, perché l’avversario sfrutta proprio le intersezioni dove i controlli sono meno coordinati. Le organizzazioni che trattano SSRF e phishing come problemi separati perdono il nesso causale che trasforma un bug applicativo in un incidente cloud.
Dalla postura reattiva a una disciplina di progettazione
La riduzione del rischio passa per architetture sicure di default: input sanitizzati, output-encoding e proxy di uscita a deny-by-default; ruoli cloud minimali e IMDSv2 blindato; pipeline con provenance verificabile, firmware delle chiavi aggiornato e distribuzione “gated” sui servizi critici. Ogni misura, da sola, limita una classe di attacco; nel loro insieme creano resilienza difensiva, l’unica risposta sostenibile alla velocità con cui evolvono le campagne contro credenziali cloud e pacchetti Python.
