Dirottamenti del front-end: quando il sito reale si rivolta contro di te

La maggior parte dei consigli contro il phishing si riduce a una regola: verifica di essere sul sito reale. Digita tu l'indirizzo, usa i segnalibri, ignora i link nei messaggi. È un buon consiglio, ma ha un punto cieco. A volte il sito reale, all'indirizzo reale, inizia a servire qualcosa di malevolo.

Questo è un dirottamento del front-end. Gli smart contract dietro una dApp possono essere perfettamente sicuri mentre il sito web che usi per raggiungerli è stato sostituito di nascosto, e ogni transazione che ti chiede di firmare è progettata per svuotare il tuo wallet.

Il sito web è una cosa diversa dal protocollo

Un'applicazione decentralizzata ha due metà:

• I contratti sulla blockchain, che custodiscono i fondi e fanno rispettare le regole.
• Il front-end — il sito web — che legge i dati, costruisce le transazioni e le invia al tuo wallet perché tu le firmi.

I contratti di solito sono sottoposti ad audit, pubblici e difficili da modificare. Il front-end è un normale sito web, ospitato su una normale infrastruttura, e decide esattamente cosa ti viene presentato da firmare. Se un attaccante controlla il sito, non ha alcun bisogno di toccare i contratti. Gli basta che tu firmi la sua transazione al posto di quella vera.

Come vengono dirottati i front-end

• Dirottamento DNS. L'attaccante prende il controllo delle impostazioni del dominio — spesso tramite il registrar o l'account che lo gestisce — e fa puntare l'indirizzo reale al proprio server. L'URL nel tuo browser è corretto; il sito no.
• Hosting o deployment compromessi. Un attaccante con accesso all'hosting del progetto, alla pipeline di build o alle chiavi di deployment pubblica una versione modificata del sito.
• Dipendenze malevole. Uno script o una libreria di terze parti caricati dal sito — strumenti di analisi, un componente dell'interfaccia, un pacchetto per la connessione dei wallet — vengono compromessi, e ogni sito che li usa inizia a servire il codice dell'attaccante.
• Script iniettati. Una vulnerabilità consente a un attaccante di inserire codice in una pagina altrimenti legittima.

In ogni caso, durante la visita tutto sembra normale. Stesso URL, stesso design, stesso flusso… fino alla richiesta di transazione.

Che aspetto ha l'attacco

Un front-end dirottato di solito punta a una tra poche richieste di alto valore:

• Approvazioni illimitate di token verso un indirizzo dell'attaccante, camuffate da normale passaggio «approva per continuare».
• «Approvazione per tutti» sugli NFT, presentata come messa in vendita o riscatto.
• Firme off-chain — permit o ordini di marketplace — che possono essere inviate in seguito per spostare fondi senza ulteriori richieste.
• Trasferimenti diretti camuffati da depositi, riscatti o migrazioni.

Il segnale rivelatore è una discrepanza tra ciò che stai facendo e ciò che ti viene chiesto di firmare. Scambiare un piccolo importo non dovrebbe richiedere l'approvazione di un'autorizzazione illimitata verso un indirizzo che non riconosci. Riscattare una ricompensa non dovrebbe richiedere il trasferimento di tutto.

Come difenderti

Non puoi individuare un server dirottato guardando la pagina. La tua difesa è il momento della firma, perché è lì che l'intento dell'attaccante deve diventare visibile.

• Leggi ogni richiesta nel tuo wallet, non sul sito. La pagina può dire qualsiasi cosa; il wallet mostra ciò che stai davvero firmando.
• Controlla lo spender e l'importo nelle approvazioni. Indirizzi sconosciuti e autorizzazioni illimitate meritano uno stop deciso.
• Diffida dei cambiamenti improvvisi nel flusso. Un sito che a un certo passaggio non chiedeva mai una firma o un'approvazione e all'improvviso lo fa è un campanello d'allarme.
• Usa la simulazione quando ce l'hai. Vedere in anteprima cosa farà una transazione smaschera le richieste il cui effetto reale è diverso dall'etichetta.
• Segui gli annunci. I progetti che rilevano la compromissione del proprio front-end di solito avvisano rapidamente sui canali ufficiali. Se qualcosa non ti convince, verifica prima di firmare.
• Revoca in seguito se hai dubbi. Se hai approvato qualcosa in un periodo in cui un sito era compromesso, revoca l'approvazione subito.

Tutto questo affianca i consigli classici sul phishing invece di sostituirli. Controllare l'indirizzo ti protegge dai siti falsi; leggere la richiesta ti protegge dai siti reali finiti male.

Dove aiuta SSP

Quando una dApp collegata tramite WalletConnect chiede a SSP di firmare, la richiesta mostra quale sito la sta facendo, la rete e l'indirizzo, e SSP decodifica le chiamate più comuni prima che tu approvi: trasferimenti, approvazioni e richieste di approvazione per tutti sugli NFT vengono etichettati, con avvisi espliciti su quelli più rischiosi. I messaggi vengono mostrati come testo leggibile quando possibile, con i dati grezzi disponibili per l'ispezione.

Ogni richiesta richiede poi una seconda approvazione su SSP Key, su un dispositivo separato. Questo non impedisce a un sito dirottato di chiedere qualcosa di malevolo, ma ti dà due chiare occasioni per vedere la richiesta per ciò che è, e nessuna delle due sulla pagina controllata dall'attaccante.

Per i team, i vault di SSP Enterprise aggiungono la simulazione delle transazioni e avvisi di rischio prima che i firmatari approvino, così una proposta creata tramite un front-end compromesso riceve un secondo sguardo indipendente da parte di tutti coloro che devono firmarla.

Il riepilogo onesto

Un dirottamento del front-end trasforma un sito affidabile nello strumento dell'attaccante senza toccare i contratti né l'URL. Non puoi accorgertene controllando la barra degli indirizzi.

Quello che puoi fare è trattare ogni richiesta di firma come la vera interfaccia: leggila nel tuo wallet, controlla lo spender, l'importo e il destinatario, e rifiuta tutto ciò che non corrisponde a ciò che intendevi fare.