La minaccia rappresentata dagli attacchi di credential stuffing sui servizi di streaming OTT è diventata di recente estremamente chiara. Nel giro di poche ore dal lancio di un popolare servizio di streaming, gli account utente sono stati violati e offerti in vendita a prezzo scontato. Questa violazione si è trasformata in una sfida di pubbliche relazioni, mentre migliaia di abbonati si sono rivolti ai social media per sfogare le loro frustrazioni riguardo all’accesso bloccato agli account e ai problemi di accessibilità ai servizi.
Come dimostra questa esperienza, gli attacchi di credential stuffing rappresentano una sfida emergente per i team di sicurezza OTT. Gli abbonamenti ai servizi di streaming, basati su versioni di prova gratuite, contenuti esclusivi, hanno generato ampie raccolte di informazioni sugli utenti, rendendo i servizi OTT sempre più attraenti per il furto di dati. Rivendere l’accesso agli account violati non è l’unico motivo per gli hacker. Inoltre, possono estrarre preziosi dettagli privati da account utente violati, come indirizzi, cronologia telefono e navigazione e dati delle carte di credito. L’hacker può quindi vendere queste informazioni attraverso il dark web o causare ulteriori danni attraverso attacchi di social engineering e phishing.
La zona di danno di un attacco di credential stuffing va ben oltre l’impatto sulla privacy e sulle finanze di un utente. Gli attacchi di credential stuffing utilizzano botnet in grado di automatizzare milioni di richieste di accesso all’ora, creando disordine sull’infrastruttura delle applicazioni. Anche con un tasso di successo basso, un volume così elevato di richieste può far aumentare i costi di gestione della piattaforma di streaming. Cicli CPU aggiuntivi, memoria e costi di ingresso/uscita dati aumentano nel tempo. Considerato il costo relativamente elevato della gestione dei backend delle applicazioni, soprattutto nel cloud, le richieste di accesso, che dipendono in larga misura dai sistemi di back-end, rappresentano l’attacco più costoso. In definitiva, un alto livello di attività nefaste non controllate degrada il servizio per gli utenti legittimi che tentano di autenticare, sfogliare e trasmettere contenuti in streaming.
In che modo un servizio di streaming può neutralizzare questa crescente minaccia? Questo articolo tecnico esaminerà ciò che è necessario per gestire i bot nel mondo di oggi e ciò che serve per un servizio di streaming per ridurre al minimo l’impatto – e la probabilità – di un attacco di credential stuffing.
L’anatomia di un attacco di credential stuffing
I criminali informatici possono iniziare un attacco di credential stuffing ottenendo credenziali rubate con diversi mezzi, tra cui la scoperta di database mal configurati, attacchi di phishing, l’infettazione di malware ai dispositivi degli utenti o l’acquisto di credenziali violate sul dark web. Successivamente, gli autori degli attacchi inviano innumerevoli richieste di accesso attraverso server proxy distribuiti per oscurare l’origine dell’attacco e amplificare le richieste. I criminali possono acquistare l’accesso ai servizi proxy, a tariffe orarie accessibili, dai pastori di bot su forum dark web. Infine, gli autori degli attacchi creano script per automatizzare le richieste di autenticazione utilizzando l’elenco delle credenziali violate, in genere predando password riutilizzate o semplicistiche, per ottenere l’accesso ai servizi. Gli autori degli attacchi possono anche acquistare toolkit sul dark web, come solutori CAPTCHA, emulatori di browser o script di spoofing delle impronte digitali, per aiutare a contrastare le difese esistenti.
Difesa dagli attacchi di credential stuffing
Fermare tali attacchi richiede la capacità di distinguere i bot dagli esseri umani. Purtroppo, gli operatori di bot trovano continuamente nuovi modi per aggirare i metodi di rilevamento dei bot. L’ultima generazione di bot è quasi indistinguibile dagli umani.
Man mano che i bot sono diventati più sofisticati, le semplici strategie di mitigazione che potrebbero aver funzionato in passato, come bloccare la richiesta del bot, l’indirizzo IP o l’agente utente (UA), non sono più sufficienti. Oggi gli autori degli attacchi utilizzano probabilmente uno dei numerosi e economici servizi proxy IP rotanti invece di attaccare da IP statici, il che li aiuta a eludere la limitazione della velocità e la semplice protezione ACL (Access Control List). Inoltre, il blocco non è consigliabile perché serve come un meccanismo di feedback utile per gli operatori di bot, dicendo loro di evolvere la loro automazione per sconfiggere il metodo di rilevamento.
Le tecniche di rilevamento dei bot sono diventate più sofisticate per adeguarsi alla crescente sofisticazione degli attacchi bot. Le moderne tecniche di rilevamento dei bot prevedono tre forme di analisi sia sul lato server che sul lato client. Sono:
- Richiedi impronte digitali
- Impronte digitali del cliente
- Impronte digitali comportamentali
Avrai bisogno di una combinazione di tutti e tre per sconfiggere sofisticati attacchi di credential-stuffing.
Metodo di rilevamento degli attacchi 1: Richiesta di impronte digitali
L’impronta digitale della richiesta viene solitamente eseguita sul lato server non appena il server riceve tutte le informazioni richieste dal client. Una richiesta client consiste in genere in una combinazione di rete (IP), connessione, crittografia e altri metadati HTTP analizzati e utilizzati per generare un’impronta digitale di richiesta. Questa impronta digitale include i dettagli principali quali indirizzo IP, handshake TCP, handshake TLS (ovvero protocollo TLS, cifrari, e estensioni), intestazioni HTTP e ordini di intestazione e altre informazioni derivate dai metadati, ad esempio ASN e tipo di dispositivo. Quando vengono messe insieme, queste caratteristiche della richiesta possono produrre una firma o un’impronta digitale univoci per ciascun client.
Figura 1. Un piccolo campione di caratteristiche della richiesta che possono collaborare per creare un’impronta digitale univoca della richiesta.
Dall’impronta digitale, possiamo iniziare a cercare anomalie. Ad esempio, se una richiesta afferma di provenire da un’UA di Chrome, include le intestazioni nell’ordine previsto in quella versione del browser Chrome, come indicato nell’agente utente? Utilizza i protocolli HTTP e TLS tipici? Il messaggio ClientHello contiene il protocollo e la cifratura con l’ordine preferito tipico di questa versione di Chrome? Oltre ad analizzare i metadati delle richieste, il server può anche eseguire alcune analisi del comportamento limitate, come il numero di richieste e la relativa frequenza e se esiste un modello di esplorazione che potrebbe aiutare a determinare se le richieste sono automatizzate.
Richiedere il rilevamento delle impronte digitali è un primo passo necessario, ma di per sé è insufficiente.
Metodo di rilevamento degli attacchi 2: Impronte digitali del client
La sfida con il rilevamento delle impronte digitali delle richieste è che gli autori degli attacchi possono ora falsificare le impronte digitali che, molto spesso, appariranno identiche al 100% al cliente reale. Se gli autori degli attacchi commettono un errore, Richiedi il rilevamento delle impronte digitali identificheranno quegli errori, ma non puoi contare che ciò accada regolarmente.
Fondamentalmente, richiedere il rilevamento delle impronte digitali è solo metà della storia. Il server deve vedere cosa sta succedendo sul lato client e generare un’impronta digitale del client per integrare l’impronta digitale della richiesta per ottenere maggiori informazioni. Ciò fornisce ai sistemi di rilevamento dei bot un quadro più completo del client e rende più difficile per gli autori degli attacchi evitare il rilevamento.
Un server di impronte digitali client può inserire un piccolo JavaScript (JS) da eseguire sul lato client riscrivendo l’HTML in risposta alla pagina richiesta. In alternativa, il server può inserire un tag script che punta a un JS remoto che il client può scaricare quando carica la pagina di accesso. JS può eseguire controlli sul lato client e raccogliere informazioni sul dispositivo, ad esempio se JS o i cookie sono abilitati, ed esamina il sistema operativo, il canvas, il renderer, il browser, il motore JS, e altro ancora per generare un’impronta digitale completa del cliente.
Un browser normale dovrebbe avere il supporto per i cookie ed essere abilitato per JS (in modo che possa accedere correttamente e utilizzare i servizi di streaming); la mancata attivazione può causare sospetti. Le impronte digitali dei client possono identificare altri elementi sospetti non tipici del dispositivo pubblicizzato che potrebbero indicare un potenziale client falso, come un browser Safari UA con Blink (motore del browser) o Chrome con un motore SpiderMonkey JS.
Questi dettagli vengono raccolti e possono essere trasmessi a un server remoto come richieste API per ulteriori analisi o essere crittografati e impostati come cookie o intestazione da inviare al server per l’analisi nelle richieste client successive. Le tecniche sopra descritte per la raccolta e la generazione delle impronte digitali dei client possono essere adottate anche per le applicazioni di streaming non browser come le app per iPhone/Android, Roku o le TV Samsung tramite SDK diversi.
Figura 2. Un piccolo campione di caratteristiche che possono lavorare insieme per creare un’impronta digitale del cliente univoca.
Mentre la combinazione di richieste e impronte digitali dei client è stata efficace con i bot di prima generazione, i bot più avanzati sono basati sugli stessi client umani, tra cui Chrome, Firefox e Safari. Possono anche utilizzare browser headless come Headless Chrome. A differenza dei bot di base che potrebbero mancare di funzionalità, come il supporto per JavaScript e cookie, i bot più avanzati possono utilizzare il browser e il motore JS appropriati per eseguire correttamente le richieste TCP e TLS handshake e HTTP coerenti con il tipo di dispositivo.
Gli attacchi lenti e bassi possono essere eseguiti distribuendo le richieste attraverso migliaia di indirizzi IP, annullando qualsiasi metodo di rilevamento basato sulla velocità. Per aggravare ulteriormente il problema, i browser reali provenienti da dispositivi di utenti reali possono essere dirottati e utilizzati per le attività di credential stuffing, e questi attacchi sono quasi certi che non potranno essere sfruttati solo con questi approcci.
Metodo di rilevamento degli attacchi 3: Impronte digitali comportamentali
Per battere davvero il credential stuffing, è necessario aggiungere impronte digitali comportamentali intelligenti. Quando gli utenti interagiscono con un servizio di streaming, non si limitano a effettuare richieste di contenuti, ma si spostano, fanno clic, toccano e navigano all’interno dell’app. Le impronte digitali comportamentali analizzano queste azioni raccogliendo dati di telemetria dell’utente sul lato client, in genere tramite JS. Questi possono includere modelli di movimento del mouse, battute di tasti, la tempistica di un’azione o persino il tocco di sensori del dispositivo come accelerometri telefonici o giroscopi per misurare il modello di movimento e il posizionamento di un utente.
In base ai dati raccolti, le impronte digitali comportamentali vengono generate e inviate per l’analisi in tempo reale o offline. L’utente mostra un modello casuale o non organico? Il mouse si muove in ripetizioni lineari o la velocità di scorrimento è più veloce di quella che un essere umano potrebbe raggiungere? Il telefono ha sempre un’angolazione fissa durante l’intera sessione di navigazione? Il numero di richieste di accesso al secondo è umanamente possibile?
Questo è il campo di battaglia di scienziati e ricercatori di dati che devono utilizzare tecniche di apprendimento automatico per analizzare continuamente i dati e ricavare informazioni sull’automazione di una richiesta. Ciò è dovuto in parte alla crescita esponenziale della combinazione di richieste, dispositivi e attributi comportamentali raccolti. Poiché i bot hanno migliorato la loro capacità di imitare il comportamento umano attraverso il dirottamento comportamentale, affidarsi a caratteristiche comportamentali di base come i movimenti del topo non è più adeguato e può aumentare il tasso di falsi positivi e influire sull’esperienza degli utenti reali.
Questi tipi di bot rappresentano la sfida più difficile per mitigare il credential stuffing. L’arresto dei bot più sofisticati richiede più dati, come il comportamento di navigazione del client durante la sessione, per analizzare l’intento del client e quindi identificare se la richiesta è dannosa. Ad esempio, è un comportamento normale quando un utente visita direttamente la pagina di accesso di un servizio di streaming senza passare attraverso la home page? È normale che un utente acceda immediatamente alla pagina dell’account dopo aver effettuato l’accesso al servizio di streaming e non esegua altre azioni? Questi punti dati possono identificare con precisione l’intento dei bot. L’interazione dell’utente con il servizio di streaming durante l’intera sessione e altri dati comportamentali può produrre un’impronta digitale più ricca e completa con minori possibilità di falsi positivi.
Gestione dei bot
Una volta che hai rilevato con successo un bot che tenta di effettuare una richiesta di accesso, qual è la risposta corretta? E’ per bloccare il bot e sperare che sparisca? Nella maggior parte dei casi, questa è l’azione sbagliata. Supponiamo di rispondere con un errore 4xx, ad esempio una risposta non autorizzata 401. Gli autori degli attacchi conoscono le attuali tecniche inadeguate e aggiornano i loro strumenti di automazione per superare il meccanismo di rilevamento attraverso tentativi ed errori. In questo caso, hai inavvertitamente aiutato gli autori degli attacchi fornendo un ciclo di feedback per avvisarli di evolvere il loro metodo.
Anche se è inevitabile che gli operatori di bot sofisticati alla fine riescano a rilevare che stanno venendo mitigati e ad evolvere i loro metodi, ci sono alcune buone pratiche per evitare o ritardare questi sforzi. Quando viene rilevato, invece di bloccare le richieste bot, il server può inviare un codice di risposta standard previsto quando un tentativo di accesso viene eseguito correttamente, ad esempio 200 OK, insieme a una risposta statica boilerplate che non espone dati sensibili.
È più probabile che gli operatori di bot suppongano che una risposta corretta indichi che il loro metodo attuale ha successo. E che le credenziali rubate sono utili anche se potrebbero non essere così, mantenendo l’autore dell’attacco all’oscuro. Un’altra opzione è quella di individuare la richiesta bot non fornendo alcuna risposta, lasciando la richiesta bot sospesa fino al timeout. Ciò può essere fatto se si utilizza una piattaforma di grandi dimensioni distribuita a livello globale con una grande capacità di server, ad esempio una CDN (rete per la distribuzione dei contenuti). Questi metodi di disinformazione sono probabilmente più efficaci del semplice blocco delle richieste bot.
Un’altra strategia per la gestione dei bot, che ha un impatto minore sull’esperienza utente in caso di falsi positivi, richiede che un bot sospetto risolva un CAPTCHA. Solo dopo aver completato il CAPTCHA l’accesso avrà esito positivo. Ciò consente agli utenti reali di continuare anche se sono erroneamente identificati come bot. Fornisce inoltre un feedback prezioso per regolare il metodo di rilevamento per ridurre i falsi positivi.
Tieni lo streaming al sicuro
Prevenire gli attacchi di credential stuffing è una priorità importante per qualsiasi servizio di streaming OTT. Con l’aumentare della popolarità di questi servizi, anche i rischi per la sicurezza aumentano. Un approccio multilivello alla sicurezza delle applicazioni e alla gestione dei bot è in grado di identificare con precisione anche i bot più sofisticati utilizzati per alimentare gli attacchi di credential stuffing e impedire che tali attacchi influiscano sulla customer experience o sulla reputazione dell’utente.
Scoprite di più su come le nostre funzionalità di sicurezza sul cloud possono proteggere la vostra presenza online da attacchi di credential stuffing, attacchi DDoS e altro ancora.
