si paga (caro) anche per le richieste di accesso negate – .

Le richieste di accesso ai bucket del servizio AWS S3 portano il titolare a pagare cifre che possono diventare molto elevate, anche quando tali richieste vengono respinte, con importanti risvolti di utilizzo improprio che possono portare a veri e propri attacchi. Questa è la scoperta di Maciej Pocwierz, uno sviluppatore polacco che si è ritrovato con una bolletta di oltre 1.200 dopo aver scelto, per puro caso, di dare al suo bucket su S3 un nome utilizzato anche nella configurazione di esempio di un progetto open source. La causa sta nel fatto che Finora AWS ha fatturato anche gli accessi negati alle risorse ospitate in S3. Un problema che forse verrà risolto dopo l’attenzione che questo caso ha suscitato.

Problemi con AWS S3: la denominazione dei bucket può portare a fatture elevate

Come spiega sul suo blog, Pocwierz ha iniziato a lavorare nella regione con una benna S3 qualche settimana fa eu-ovest-1 di AWS, lasciandolo vuoto. I bucket sono contenitori (letteralmente “bucket”) sul servizio di storage S3 e possono contenere file e oggetti; vengono spesso utilizzati per archiviare grandi quantità di dati, in particolare in ambienti aziendali.

Due giorni dopo averlo creato, lo sviluppatore ha controllato il suo secchio e ha scoperto che la fattura aveva raggiunto i 1.300 dollari (poco più di 1.200 dollari al tasso di cambio attuale). Il motivo sta nel fatto che aveva scelto, non senza qualche sfortuna, un nome per il secchio utilizzato anche da un progetto open source come valore predefinito che deve essere sovrascritto durante l’installazione. Molti però hanno lasciato invariato questo nome, con il risultato che il secchio di Pocwierz è stato inondato di richieste.

Sebbene siano stati rifiutati, perché gli utenti che tentavano di accedere (inconsapevolmente) al bucket non avevano il permesso di farlo, tali richieste furono addebitate a Pocwierz. Questa, come gli ha confermato il supporto dell’azienda, è la norma: anche le richieste respinte vengono addebitate, indipendentemente dal fatto che l’utente non abbia alcun controllo su di esse.

Il problema con questo approccio, come segnalano molti sviluppatori e ingegneri di sistema su Internet, è che non esiste una vera difesa. Scegliere un nome non facilmente identificabile per i bucket è sicuramente una buona pratica, ma non protegge dal fatto che un malintenzionato lo scopra può però bombardare il secchio di richieste e quindi portare a fatture molto elevate.

Pocwierz ha anche sottolineato che in questo caso specifico c’è un problema di la sicurezza dei dati: poiché il nome del suo bucket è quello utilizzato su molte installazioni dello strumento open source, aprendo il bucket alla scrittura di chiunque è riuscito a raccogliere in pochi minuti circa 10 GB di dati da utenti ignari che avevano mantenuto il default nome del secchio. Questo non è un problema del servizio AWS in quanto tale, ma un problema generale nella gestione dei valori di default; ovviamente, date le policy AWS, l’opzione di creare un bucket inaccessibile con lo stesso nome di quello nella documentazione diventa un’opzione non praticabile. Questo aspetto della sicurezza resta tuttavia teorico, poiché finora non sono noti attacchi di questo tipo.

Questa storia ha scatenato un forte dibattito, che ha portato Jeff BarrCapo evangelista presso AWS, per confermare https://twitter.com/jeffbarr/status/1785386554372042890 come l’azienda sta lavorando per modificare questo meccanismo, anche se non sono state fornite tempistiche certe per l’intervento. Non è nemmeno chiaro se l’azienda deciderà di rendere indisponibile il nome del bucket interessato dal problema: nonostante Pocwierz abbia deciso di cancellare il suo, resta la possibilità che qualcun altro ne apra uno e possa così raccogliere i dati inviati dall’open source. attrezzo .

Abbiamo chiesto ulteriori dettagli all’ufficio stampa, ma al momento non c’è nulla oltre il tweet di Barr che ci è stato segnalato: c’è solo la promessa che riceveremo eventuali aggiornamenti in futuro.