Il subscription bombing può causare parecchie grane quando una rete di spambot decide di inondare un sistema con richieste di iscrizione fraudolente: questo tipo di abuso, rilevato in forma massiva a partire dal 2016, come testimonia SpamHaus, sta diventando sempre più diffuso.

Ma andiamo con ordine e vediamo in cosa consiste l'attacco, perché viene fatto, quali conseguenze può portare, come ci si può difendere.

In cosa consiste

Il subscription bombing è una forma di attacco (abuso) da parte di spambot (programmi per computer che eseguono operazioni in automatico) spesso parte di botnet (reti di più spambot che operano in maniera coordinata) che compilano in maniera fraudolenta moduli di iscrizione o moduli di registrazione su vari siti web che forniscono una di queste funzionalità.

Esistono parecchi milioni di moduli di iscrizione a newsletter, probabilmente altrettanti siti che hanno una procedura di registrazione, altri ancora con un modulo contatti o la possibilità di inserire commenti. Tutti questi moduli possono essere compilati allo scopo di ottenere una pubblicazione, ma possono anche essere abusati con uno scopo differente, ovvero la notifica dell'iscrizione o registrazione: l'azione quasi irrilevante, presa singolarmente, di invio di un singolo modulo con dati fraudolenti diventa un problema serio quando viene distribuita su decine di milioni di moduli da parte di migliaia di spambot.

Perché viene messo in atto e quali conseguenze può portare

Le motivazioni per l'abuso di un modulo possono essere le più disparate. In genere l'azione viene fatta per danneggiare un singolo destinatario, bombardando una singola vittima di email di "conferma iscrizione": oggigiorno non è facile inviare decine di migliaia di email di spam ad un destinatario perché i filtri antispam agiscono velocemente e impediscono un simile comportamento, ma il subscription bombing permette di ottenere questo risultato aggirando di fatto i filtri antispam che vedranno solamente tante email tutte diverse tra loro, ognuna proveniente da un sito differente e spesso da indirizzi "reputabili" e non dai server dai quali vedono in genere arrivare lo spam.

Lo scopo di questo bombardamento può essere molteplice:

• infastidire semplicemente il destinatario
• rendere impossibile l'uso della posta al destinatario per qualche ora/giorno
• distrarre il destinatario in modo che, nel mezzo del bombardamento, non si accorga della ricezione di qualche email importante (ad esempio una email che lo avvisa di un pagamento fatto con la sua carta o del fatto che le sue credenziali su un determinato sito sono state cambiate)
• riempire temporaneamente la casella di un destinatario in modo che non possa ricevere una email, magari un avviso di sicurezza.

A volte però lo scopo può essere quello di danneggiare il proprietario del modulo simulando richieste di tanti utenti differenti ma fasulli.

• attacco tipo DoS (denial of service) per prosciugare le risorse del modulo e renderlo inutilizzabile a terzi
• danneggiamento della reputazione del server che invia le email per quel modulo: dal momento che le email non sono state richieste molte verranno segnalate come abusive e incideranno negativamente sulla reputazione rendendo molto probabile anche l'attivazione di blacklist

Anche nel caso in cui lo scopo principale dell'attacco fosse infastidire specifici destinatari si avranno gli effetti collaterali per gli intermediari i cui sistemi sono stati abusati, quindi sarà necessario mettere in atto misure di protezione adeguate.

Tutti questo è colpa del Confirmed Opt-in? Meglio il single opt-in?

Si potrebbe pensare che moduli di iscrizione senza conferma, quindi che usano il "single opt-in", siano quindi preferibili perché immuni da questo attacco ma in realtà quello che succede è che i bot provano comunque a inviare tali moduli anche se non ottengono il loro risultato nell'immediato e questo danneggia irreparabilmente l'intera lista che a quel punto conterrà oltre a chi voleva realmente le email anche tutta una serie di utenti assolutamente non interessati che per parecchio tempo dopo aver subito l'attacco di subscription bombing continueranno a ricevere newsletter da tantissimi mittenti diversi dai quali dovranno disiscriversi.

Il rischio, usando una iscrizione non confermata, è quello di trovarsi una lista in cui parte degli utenti non sono interessati e quindi in fase di invio danneggerà la reputazione. Al contrario con l'iscrizione confermata il danno avviene solo al momento dell'iscrizione e quindi si può correre ai ripari anche con rimedi estremi (ad esempio mettere offline il modulo di iscrizione). Nel caso dell'iscrizione non confermata spesso ci si rende conto del problema solo nel tempo e a quel punto diventa molto difficile capire quali indirizzi siano reali e quali siano quelli inseriti contro la loro volontà. Una volta che una lista è inquinata da indirizzi che non vogliono le email diventa molto difficile discernere i buoni dai cattivi e il rischio è quello di "buttare il bambino con l'acqua sporca".

In genere ci sono indizi che fanno pensare ad un attacco di subscription bombing per chi ha raccolto iscrizioni senza conferma:

• un numero fuori dal normale di iscrizioni tutte concentrate in un determinato periodo di tempo
• iscrizioni provenienti da indirizzi email inusuali per il proprio target (ad esempio indirizzi comunemente usati da cittadini di altre nazioni ma non frequentemente usati in italia, come comcast.net o mail.ru)
• indirizzi email che sembrano appartenere a stranieri quando invece il proprio target è prevalentemente italiano (non è facile ma parte degli indirizzi saranno comunque in un formato nome.cognome@dominio e quando diventano tanti potrebbero diventare sospetti)
• mancanza dei dati aggiuntivi eventualmente chiesti in fase di iscrizione o dati non congruenti: spesso gli spambot cercano di compilare qualunque campo ma non hanno consapevolezza di cosa compilano quindi magari se viene chiesto un nome e un numero di telefono mettono sequenze di testo casuali o di numeri casuali e da una revisione manuale può essere chiaro che siano dati fraudolenti.

Come proteggere un modulo?

Le protezioni più efficaci sono quelle che normalmente si utilizzano per impedire la compilazione automatica da parte di bot:

• inserimento di un CATPCHA: è la protezione universamente più accettata e oggigiorno funzionante. reCAPTCHA di Google o hCAPTCHA sono due strumenti molto diffusi ma non bisogna sperare nel 100% di efficacia in quanto i bot più avanzati hanno imparato anche a risolvere i loro indovinelli.
• inserimento di campi nascosti nel modulo: a volte questi bot compilano qualunque campo trovino nel modulo senza riuscire ad individuare quali siano quelli visibili e quelli invisibili e così spesso compilano anche i campi invisibili.
• inserimento di un campo di verifica: è una sorta di CAPTCHA anche questo, ma inventato dal gestore del modulo e quindi non abbastanza diffuso perché i gestori delle botnet si preoccupino di capire come funziona. A volte anche solo un campo con scritto a fianco "Scrivi in lettere il risultato dell'operazione 1+1" dove si va a verificare se sia stato scritto "due" è estremamente efficace nel bloccare tanti tentativi automatici.

Altri interventi più sostanziali possono prevedere:

• controllo dell'IP utilizzato dall'utente su blacklist esterne od interne (ad esempio StopForumSpam o ProjectHoneyPot)
• rallentamento (throttling / anti flood) delle richieste destinate allo stesso destinatario o fatte dallo stesso mittente.

Per ora è tutto! E voi avete subito attacchi di subscription bombing? Come li avete arginati?