La minaccia rappresentata dagli attacchi di credential stuffing ai servizi di streaming OTT è diventata evidente di recente. Nel giro di poche ore da un lancio tanto pubblicizzato di un popolare servizio di streaming, gli account utente sono stati violati e messi in vendita a prezzo scontato. Questa violazione si è trasformata in una sfida di pubbliche relazioni, poiché migliaia di abbonati si sono rivolti ai social media per sfogare le loro frustrazioni in merito 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 prove gratuite, taglio dei cavi e contenuti esclusivi, hanno generato grandi raccolte di informazioni sugli utenti, rendendo i servizi OTT sempre più attraenti obiettivi per il furto di dati. Rivendere l’accesso a account violati non è l’unico motivo per gli hacker. Possono anche recuperare preziosi dettagli privati da account utente violati, come indirizzi, cronologia telefono e navigazione e dati della carta di credito. L’hacker può quindi vendere queste informazioni sul dark web o causare ulteriori danni attraverso l’ingegneria sociale e gli attacchi di phishing.
La zona danneggiata 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, causando il caos nell’infrastruttura delle applicazioni. Anche con un basso tasso di successo, 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 back-end delle applicazioni, soprattutto nel cloud, le richieste di accesso, che dipendono fortemente dai sistemi back-end, sono l’attacco più costoso. In definitiva, un alto livello di attività nefaste non controllate compromette il servizio per gli utenti legittimi che tentano di autenticare, navigare e trasmettere contenuti in streaming.
Come può un servizio di streaming 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 ridurre 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 attraverso diversi mezzi, tra cui la scoperta di database mal configurati, attacchi di phishing, infettare i dispositivi degli utenti con malware o acquistare credenziali violate sul dark web. Successivamente, gli autori degli attacchi indirizzano 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 convenienti, da parte di gestori di bot su forum web bui. Infine, gli autori degli attacchi creano script per automatizzare le richieste di autenticazione utilizzando l’elenco delle credenziali violate, in genere prediligendo password riutilizzate o semplici, 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.
Difendersi dagli attacchi di credential stuffing
Fermare tali attacchi richiede la capacità di distinguere i bot dagli esseri umani. Purtroppo, gli operatori dei bot trovano continuamente nuovi modi per aggirare i metodi di rilevamento dei bot. L’ultima generazione di bot è quasi indistinguibile dagli esseri umani.
Poiché 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’user-agent (UA), non sono più sufficienti. Gli autori degli attacchi oggi utilizzano con molta probabilità uno dei servizi proxy IP a rotazione economici e abbondanti invece di attaccare da IP statici, il che li aiuta a eludere la limitazione della velocità e la protezione ACL (Simple Access Control List). Inoltre, il blocco non è consigliabile perché funge da utile meccanismo di feedback per gli operatori bot, dicendo loro di evolvere la loro automazione per sconfiggere il metodo di rilevamento.
Le tecniche di rilevamento dei bot hanno dovuto diventare più sofisticate per adattarsi alla crescente complessità degli attacchi bot. Le moderne tecniche di rilevamento dei bot prevedono tre forme di analisi sia sul lato server che sul lato client. Sono:
- Richiesta di impronte digitali
- Impronte digitali del client
- 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
La richiesta di impronte digitali viene solitamente eseguita sul lato server non appena il server riceve tutte le informazioni richieste dal client. Una richiesta client è in genere costituita da una combinazione di rete (IP), connessione, crittografia e altri metadati HTTP analizzati e utilizzati per generare un’impronta digitale della richiesta. Questa impronta digitale include dettagli fondamentali come indirizzo IP, handshake TCP, handshake TLS (ad esempio, protocollo TLS, crittografia ed estensioni), intestazioni HTTP e ordini di intestazione e altre informazioni derivate dai metadati, come l’ASN e il tipo di dispositivo. Una volta raggruppate, queste caratteristiche di richiesta possono fornire una firma o un’impronta digitale univoca per ciascun cliente.
Figura 1. Un piccolo esempio di caratteristiche della richiesta che possono collaborare per creare un’impronta digitale della richiesta univoca.
Dalle impronte digitali, possiamo iniziare a cercare anomalie. Ad esempio, se una richiesta afferma di provenire da un’unità di controllo Chrome, include 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 Chrome? Oltre ad analizzare i metadati della richiesta, il server può anche eseguire alcune analisi del comportamento limitate, come il numero di richieste e la loro frequenza e se esiste un modello di navigazione 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 dei client
La sfida legata al rilevamento delle impronte digitali delle richieste è che gli autori degli attacchi possono ora richiedere impronte digitali che, più spesso, appariranno identiche al 100% al client reale. Se gli aggressori commettono un errore, richiedere il fingerprinting identificherà quegli errori – ma non puoi contare su che ciò avvenga regolarmente.
Fondamentalmente, la richiesta di impronte digitali racconta solo metà della storia. Il server deve vedere cosa sta accadendo sul lato client e generare un’impronta digitale del cliente 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ò iniettare un piccolo pezzo di JavaScript (JS) da eseguire sul lato client riscrivendo il codice 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. Il 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 rendering, il browser, il motore JS e altro ancora per generare un’impronta digitale completa del client.
In un browser normale è previsto il supporto dei cookie e l’abilitazione JS (in modo che possano accedere e utilizzare correttamente i servizi di streaming); la mancata attivazione può causare sospetti. Le impronte digitali del client possono identificare altri elementi sospetti non tipici del dispositivo pubblicizzato che possono indicare un potenziale client falso, come un UA browser Safari con Blink (motore browser) o Chrome con un motore SpiderMonkey JS.
Questi dettagli vengono raccolti e possono essere trasmessi a un server remoto quando l’API richiede ulteriori analisi oppure crittografati e impostati come cookie o intestazione da inviare al server per l’analisi nelle successive richieste client. Le tecniche di cui sopra per la raccolta e la generazione delle impronte digitali dei client possono essere adottate anche per applicazioni di streaming non browser, come app per iPhone/Android, TV Roku o Samsung tramite SDK diversi.
Figura 2. Un piccolo esempio di caratteristiche che possono lavorare insieme per creare un’impronta digitale unica del cliente.
Mentre la combinazione di richiesta e impronte digitali dei client era efficace con i bot di prima generazione, i bot più avanzati si basano sugli stessi client degli umani, inclusi Chrome, Firefox e Safari. Possono anche utilizzare browser headless come Headless Chrome. A differenza dei bot di base che potrebbero non disporre di funzionalità, come il supporto di JavaScript e cookie, i bot più avanzati possono utilizzare il browser e il motore JS appropriati per eseguire le richieste di handshake TCP e TLS e HTTP formate correttamente in base al 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 dei dispositivi degli utenti reali possono essere dirottati e utilizzati per attività di credential stuffing, e tali attacchi sono quasi certi di essere mancati solo con questi approcci.
Metodo di rilevamento degli attacchi 3: Impronte digitali comportamentali
Per battere davvero il credential stuffing, è necessario aggiungere il fingerprinting comportamentale intelligente. Quando gli utenti interagiscono con un servizio di streaming, non si limitano a fare richieste di contenuti, ma si spostano, fanno clic, toccano e navigano all’interno dell’app. Le impronte digitali comportamentali studiano queste azioni raccogliendo i dati di telemetria dell’utente sul lato client, di solito tramite JS. Questi possono includere modelli di movimento del mouse, battute di tasti, tempistica di un’azione, o persino toccare sensori di dispositivi come accelerometri telefonici o giroscopi per misurare il modello in 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 motivo casuale o non organico? Il mouse si muove in pattern lineari o la velocità di scorrimento è più veloce di quanto un essere umano possa raggiungere? Il telefono si trova sempre a un angolo fisso per tutta la sessione di navigazione? Il numero di richieste di accesso al secondo è umanamente possibile?
Questo è il campo di battaglia di scienziati dei dati e ricercatori che devono impiegare tecniche di apprendimento automatico per analizzare continuamente i dati e ricavare informazioni sull’automatizzazione 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 mouse 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, ad esempio il comportamento di navigazione del client durante tutta la sessione, per analizzare l’intento del client e quindi identificare se la richiesta è dannosa. Ad esempio, è normale che un utente visiti direttamente la pagina di accesso di un servizio di streaming senza passare attraverso la home page? È normale che un utente passi 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 con altri dati comportamentali può produrre un’impronta digitale più ricca e completa con minori probabilità di falsi positivi.
Gestione dei bot
Una volta che hai rilevato con successo un bot che tenta di fare 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 tramite 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.
Mentre è inevitabile che gli operatori bot sofisticati alla fine riescano a rilevare che sono stati mitigati e a far 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 riesce, ad esempio 200 OK, unitamente a una risposta statica su piastra caldaia che non espone dati sensibili.
Gli operatori bot sono più propensi che non presumere che una risposta corretta indichi che il loro metodo attuale è riuscito. E che le credenziali rubate sono utili anche se non è così, tenendo l’aggressore al buio. Un’altra opzione è quella di bloccare 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 notevole capacità di server, ad esempio una rete per la distribuzione dei contenuti (CDN). 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 dell’utente in caso di falso positivo, 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 vengono erroneamente identificati come bot. Fornisce inoltre un feedback utile per regolare il metodo di rilevamento per ridurre i falsi positivi.
Proteggi lo streaming
Prevenire gli attacchi di credential stuffing è una priorità importante per qualsiasi servizio di streaming OTT. Man mano che questi servizi acquistano popolarità, 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.
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.
