SMS pumping: come un modulo di verifica del telefono puo' prosciugare in silenzio il budget messaggi di un sito di annunci

Arriva la bolletta degli SMS, ed e' tre o quattro volte il normale. Nient'altro si e' mosso: il numero di nuovi inserzionisti sembra ordinario, la bacheca degli annunci sembra ordinaria, il conto dei pagamenti non mostra nessuna attivita' insolita. Il primo sospetto naturale e' un errore di fatturazione, cosi' l'operatore apre un ticket col fornitore di messaggistica e aspetta. La risposta che arriva e' peggiore di un errore di fatturazione, perche' significa che ognuno di quei messaggi e' davvero partito, e il fornitore non stornera' l'addebito per un testo consegnato per davvero.

Quello che e' successo ha un nome: SMS pumping, chiamato anche SMS toll fraud o traffico artificialmente gonfiato. Prende di mira esattamente il tipo di modulo su cui una directory di annunci si appoggia per tenere onesti gli annunci, quello dove un inserzionista digita un numero di telefono e preme un pulsante che dice invia codice. Questo blog ha gia' spiegato perche' quel controllo esiste, dato che i controlli su telefono e identita' sono cio' che davvero impedisce a una bacheca di riempirsi di account falsi. La frode descritta qui non si interessa per niente dell'annuncio. Le interessa solo il pulsante.

Come funziona davvero la frode

L'SMS pumping e' una variante di uno schema delle telecomunicazioni molto piu' vecchio, chiamato international revenue share fraud, e il meccanismo non e' affatto sottile una volta spiegato. Un truffatore stabilisce un accordo, formale o sfruttato, con un operatore telefonico che guadagna sulle tariffe di terminazione dei messaggi, spesso in un paese lontano da dove opera l'attivita'. Il truffatore usa poi dei bot per far scattare ripetutamente l'azione invia codice del sito, puntando su numeri di telefono reali che si trovano sulla rete di quell'operatore. Ognuno di quei numeri e' una SIM attiva capace di ricevere un testo, quindi i messaggi non rimbalzano e non falliscono. Arrivano.

Poiche' i messaggi vengono davvero consegnati, non c'e' nessun segnale di frode sul lato telecomunicazioni che spinga un operatore a rifiutarsi di inviarli o un fornitore di messaggistica a rifiutarsi di fatturarli. L'operatore incassa una tariffa di terminazione per ogni messaggio che consegna, e in base all'accordo di compartecipazione una quota di quella tariffa torna indietro a chi gestisce il traffico dei bot. L'attivita' che paga i messaggi e', dal punto di vista della rete, semplicemente un cliente che ha chiesto l'invio di un numero molto alto di testi. Nessuno a monte ha un motivo per fermarlo da solo.

Nessuna delle parti a monte dell'attivita' e' motivata a fermare tutto questo di sua iniziativa, ed e' un dettaglio su cui vale la pena soffermarsi. L'operatore viene pagato per messaggi che sta davvero consegnando, quindi dai suoi registri non risulta niente di sbagliato. L'API di messaggistica sta fra l'attivita' e l'operatore e fattura fedelmente cio' che le e' stato chiesto di inviare. La responsabilita' di accorgersi che il traffico sul modulo di iscrizione non somiglia a inserzionisti finisce per stare in capo all'unica parte che ha sia il motivo sia la visibilita' per accorgersene: l'attivita' che paga la bolletta.

Cio' che rende tutto questo attraente per i truffatori, e costoso per una directory, e' che non serve nessun account vero. Il bot non deve completare la verifica, non deve pubblicare nessun annuncio, e il codice non deve mai essere digitato in una casella. Gli basta che il modulo del sito accetti un numero di telefono e spedisca un messaggio. Un flusso di iscrizione che non porta mai a termine una sola verifica riuscita puo' comunque generare un mese intero di traffico fatturabile.

Perche' la bolletta arriva prima di qualunque altra cosa

La maggior parte delle API per SMS e verifica, compresa quella di Twilio, fattura per messaggio inviato o tentato, non per verifica effettivamente completata. Questo modello di fatturazione non e' un difetto di progettazione specifico di un fornitore: e' il modo in cui la rete telefonica sottostante gia' addebita all'attivita' la consegna di un messaggio, e l'API si limita a girare quel costo. L'effetto pratico e' che una campagna di frode costa denaro all'operatore fin dal primo messaggio, ore o giorni prima che qualcuno si accorga che il tasso di completamento sul modulo di iscrizione e' crollato in silenzio.

La scala che puo' raggiungere non e' teorica. Nel dicembre 2022 Elon Musk ha dichiarato pubblicamente, durante una sessione Twitter Spaces, che Twitter perdeva circa sessanta milioni di dollari l'anno esattamente per questo schema, e ha indicato circa 390 operatori telefonici che secondo lui erano coinvolti nel gonfiare traffico fraudolento di autenticazione a due fattori verso la piattaforma. Quella cifra era un'affermazione di Musk, non una divulgazione aziendale verificata, ma la risposta e' stata reale e riportata ben oltre il marketing degli strumenti antifrode: Twitter ha interrotto i rapporti con gli operatori il cui traffico sembrava fraudolento, e pochi mesi dopo ha limitato l'autenticazione gratuita via SMS agli abbonati paganti proprio a causa del costo. Un'azienda con il volume e il personale tecnico di Twitter ha comunque impiegato mesi ad accorgersene e reagire. Una directory che si appoggia a un unico account di messaggistica indipendente, senza un team antifrode che legge i log ogni mattina, ha molto meno preavviso incorporato.

Il numero che rivela davvero la frode non e' il volume di messaggi inviati, perche' anche una spinta di marketing vera o una settimana genuinamente intensa possono far salire quel numero. E' il rapporto fra codici inviati e codici inseriti con successo. Un tasso di completamento che scende in silenzio rispetto al suo valore normale, anche mentre il volume totale sale, e' il segnale che il traffico sul modulo non e' fatto di persone intenzionate a finire l'iscrizione.

Perche' un modulo annunci aperto e' esattamente il profilo bersaglio

Una directory di annunci ha una ragione strutturale per rendere facile da raggiungere il pulsante invia codice: qualunque attrito aggiunto all'iscrizione di un inserzionista alla prima esperienza costa conversioni, e questo blog ha gia' spiegato perche' quell'attrito vada difeso con cura proprio alla porta ancora prima che entri in scena il pagamento. Un passaggio di verifica telefonica rapido e accogliente per un inserzionista legittimo e', per la stessa progettazione, rapido e accogliente anche per un bot che non ha nessuna intenzione di diventarlo.

L'esposizione e' anche piu' netta per un operatore piccolo e indipendente di quanto sembri da fuori. Una grande piattaforma negozia prezzi a volume e di solito ha un contratto che include un certo monitoraggio antifrode come parte del rapporto. Una directory che fa passare il proprio flusso di iscrizione attraverso un'API di messaggistica standard a consumo non ha nessun cuscinetto del genere: ogni messaggio fraudolento viene fatturato alla stessa tariffa per messaggio di ogni messaggio legittimo, dritto sulla carta registrata, senza niente che assorba il picco finche' un essere umano non si accorge della fattura.

Niente di tutto questo significa che bloccare un prefisso nazionale sia una decisione da impostare una volta e dimenticare. Una directory che si espande in una nuova citta', o che raccoglie inserzionisti che viaggiano, puo' trovarsi un gruppo legittimo di iscrizioni dietro un prefisso che era stato bloccato per un buon motivo un anno prima. Trattare l'elenco dei prefissi limitati come qualcosa da rivedere ogni pochi mesi, insieme a tutto il resto che viene rivisto con quella cadenza, evita che la difesa si trasformi in silenzio in una seconda fonte di iscrizioni perse.

Questo e' un guasto diverso da quello che questo blog ha descritto quando ha trattato il motivo per cui un'email di verifica a volte non raggiunge mai la casella di un inserzionista. Quel pezzo riguardava un messaggio che fallisce in silenzio, costando solo un'iscrizione persa. Questo riguarda un messaggio che riesce rumorosamente, arrivando esattamente come previsto, e costando soldi veri ogni singola volta che lo fa.

Cosa lo ferma davvero

Il primo livello e' il rate limiting sull'azione invia codice stessa, applicato lato server e non affidato al browser: un tetto rigido su quanti codici un singolo indirizzo IP, una sessione o un numero di telefono puo' richiedere in una finestra breve. Da solo non fermera' una rete di bot distribuita su molti indirizzi IP, ma toglie di mezzo la versione piu' economica e pigra dell'attacco e costringe chi e' piu' determinato a lavorare di piu'.

Il secondo livello e' un controllo antibot posizionato prima che l'azione di invio scatti, non dopo: qualcosa che conferma che a far partire la richiesta e' stato un essere umano senza chiedergli di risolvere niente di fastidioso, come una sfida invisibile che valuta la richiesta in background. Poiche' l'intera frode dipende dal far scattare invii in modo automatico e in grande volume, qualunque cosa rallenti in modo significativo l'attivazione automatica riduce direttamente il costo dell'attacco, anche se lascia passare qualche bot.

Il terzo livello e' applicare attrito, non necessariamente un blocco netto, ai prefissi telefonici che la base reale di inserzionisti di una directory praticamente non usa mai. Un sito che serve citta' in un solo paese ha poco motivo di accettare, senza un secondo controllo, un'ondata di richieste di verifica rivolte a un prefisso internazionale dove la base di inserzionisti non ha mai avuto una presenza significativa.

Il quarto livello e' attivare qualunque protezione antifrode il fornitore di messaggistica gia' offra, invece di dare per scontato che le impostazioni predefinite bastino. Twilio, per fare un esempio concreto, offre una funzione chiamata Verify Fraud Guard che analizza i pattern di traffico per rilevare e bloccare automaticamente l'attivita' sospetta di pumping, ed e' attiva di default per i clienti Verify, con livelli di protezione regolabili che scambiano un piccolo tasso di falsi positivi per un tasso piu' alto di blocco. Verificare che una funzione del genere sia accesa, e tarata su un livello adatto al traffico reale del sito, non costa niente e intercetta cio' che la logica interna del sito si lascera' sfuggire.

Il quinto livello e' un avviso di spesa impostato direttamente col fornitore, non scoperto un mese dopo su una fattura. Una soglia che fa scattare una notifica quando la spesa giornaliera in messaggi supera un livello privo di una spiegazione ordinaria trasforma una campagna di frode che altrimenti correrebbe in silenzio per settimane in una che viene notata entro poche ore.

Cosa fare questa settimana

Estrai i log di messaggistica del mese scorso e calcola il rapporto reale fra codici inviati e codici verificati con successo, non solo il volume totale. Un numero che sembra a posto in aggregato puo' comunque nascondere una settimana specifica o un prefisso specifico dove il rapporto e' crollato. Quel singolo calcolo dira' a un operatore piu' cose su se questa frode sta gia' accadendo di qualunque altra cosa in questo pezzo.

Poi controlla tre impostazioni direttamente col fornitore di messaggistica: se una protezione antifrode come Fraud Guard e' attiva e a quale livello, se esiste un avviso di spesa e a quale soglia, e se l'endpoint invia codice ha un limite di frequenza lato server che non dipende da niente che il browser possa essere istruito a ignorare. Nessuno di questi tre controlli richiede nuovo software o un nuovo rapporto con un fornitore, solo il tempo di chiedere direttamente al fornitore e leggere la risposta che arriva.