Trendmicro smaschera per una seconda volta  l’organizzazione criminale TeamTNT. 

Il report pubblicato dalla società di sicurezza, conferma  di aver trovato una seconda versione della botnet, più potente e raffinata. Se una prima versione del malware colpiva solo Docker ora è in grado di colpire anche i server di AWS.

Gli sviluppatori TeamTNT non sono più interessati solo al mining, ma ora gli script dannosi vengono sviluppati per rubare dati come credenziali e password. Inoltre la nuova versione del botnet è in grado di preparare l’ambiente per assicurarsi che abbia risorse sufficienti per minare la sicurezza di altre piattaforme, in effetti si nascondono nel sistema e installano anche backdoor nel caso in cui debbano connettersi da remoto ai server infetti.

Cosa succede? TeamTNT accede ai container Docker esposti, installando un malware di cripot mining, e ruba  le credenziali per i server di AWS al fine di pivot su altri sistemi IT di un’azienda per infettare ancora di più server e distribuire miner di criptovalute. Questo tipo di attacco è pericoloso per le aziende che sono esposte online e anche per quelle che utilizzano API di gestione Docker. A questo punto una domanda sorge spontanea, è davvero possibile subire un simile attacco? Come è possibile lasciare spazio e dare libero accesso ai container?

La risposta è legata ad una delle seguenti alternative:

  • Bug dell’applicativo, o di altri pezzi software contenuti nel container;
  • API di Docker esposte a tutti;
  • Repository Git non protetti, o protetti male (credenziali finite pubbliche, ecc.);
  • Eventuali DB usati dall’applicativo esposti su internet.

Per non cadere nell’errore ed evitare che di esporsi a rischi di questo tipo, abbiamo stilato una lista di Best Practices da mettere in atto per proteggere i clienti da un eventuale attacco malware:

  •  Utilizzo di IAM Roles invece di utilizzare chiavi programmatiche come Access Key e Secret Access per le chiamate autenticate a servizi AWS
  •  Organizzazione networking con subnet pubbliche/private per proteggere i nodi “master” se utilizzato EKS o non esporre le EC2 in caso di ECS su EC2
  • Avere un unico punto di accesso all’infrastruttura (come CDN) che sarà protetto poi con Web Application Firewall (WAF) per evitare attacchi di tipo DDoS, XSS, SQL Injection (protezione a livello 7 pila ISO/OSI) e protezione a livello 3-4.
  • Utilizzo sempre di repository private (Code Commit/git/ecr)
  • Non esporre credenziali applicative nei repository ma con altre soluzioni, come Bucket S3 locked da policy stringenti, AWS System Manager.

Inoltre  bisogna ricordare che tutte le chiamate a servizi AWS richiedono un’autenticazione, anche via API e che AWS di default non espone nulla su internet.

 

Ecco due casi studio reali sui quali VMEngine è riuscita a impostare al meglio tutte le policy di sicurezza andando ad incidere positivamente sulle prestazioni e rendendo l’architettura IT protetta e scalabile:

Share This