Andare a mangiare al sushi o ristorante oggi significa spesso vivere un’esperienza “digitale”: si ordina dal tablet al tavolo, ci si collega al Wi-Fi del locale mentre si aspetta il proprio piatto e si paga col POS contactless. Tutto comodo, veloce e moderno.

Il problema? Tutto questo porta con sé anche rischi che spesso vengono ignorati. Password di default mai cambiate, reti wireless mal configurate, server esposti direttamente a Internet: basta poco perché un attaccante possa fare breccia nei sistemi nel tempo di una cena. Ed è proprio di questo che vogliamo parlare con la Sushi Security: una breve raccolta di esempi di sicurezza informatica offensiva legati agli attacchi ad infrastrutture e servizi dei ristoranti di sushi.

In questo articolo sono presenti scenari reali di attacchi informatici utilizzati puramente a scopo informativo.

Setup e Misconfiguration

Da dove nascono le vulnerabilità?

Come abbiamo detto, molti ristoranti e sushi bar adottano soluzioni digitali ormai comuni: device smart per ordinare, reti aperte a tutti, telecamere IP e menù hostati su rete interna e accessibili con QR-Codes. Tutto questo di solito viene configurato rapidamente, con il minimo indispensabile per “far funzionare le cose”, senza particolari accorgimenti di sicurezza.

Il motivo (solitamente) è semplice: si pensa che l’ambiente non sia a rischio e rimanga poco utilizzato e trafficato, accessibile solo dallo staff e da qualche cliente e quindi al sicuro. Una convinzione che porta a trascurare aspetti fondamentali come:

• Password di default lasciate invariate su router, telecamere o sistemi di cassa.
• Reti uniche dove convivono dispositivi amministrativi e Wi-Fi pubblico per i clienti.
• Aggiornamenti mancanti, con software che rimane vulnerabile per mesi o anni.
• Permessi troppo ampi, che permettono a chiunque sia dentro la rete di vedere e fare molto più del necessario.

Queste configurazioni superficiali creano un ecosistema fragile, in cui basta un accesso minimo, ad esempio collegarsi al Wi-Fi degli ospiti, per muoversi lateralmente verso sistemi più sensibili e ancora peggio configurati.

Il risultato è che, in un contesto che appare “piccolo e isolato”, le misconfiguration diventano il vero punto debole. E per un attaccante, sfruttarle è più facile di quanto si pensi.

Ecco quindi che presentiamo una lista di vulnerabilità “comuni” che abbiamo trovato nel corso degli anni in questi ambienti.

Token Hardcodati nelle richieste di ordinazione

Come prima vulnerabilità presentiamo un errore nella logica di ordinazione in modalità “autenticata” in un ristorante sushi.

In questo caso il ristorante di sushi mette a disposizione un tablet per l’ordinazione in cui ogni richiesta viene autenticata da un token fisso legato al numero del tavolo. Fin qui sembra non esserci nessun problema. Questa logica diventa vulnerabile nel momento in cui l’applicazione per ordinare è esposta su rete esterna e non protetta da una doppia autenticazione, come ad esempio rendere disponibile l’ordinazione dopo aver dimostrato di essere un device autorizzato e legato al locale.

La vulnerabilità risiede quindi nel fatto che un’ ordinazione del tipo

https://vulnerable-sushi.com/tavolo?passKeyGuid=<TOKEN>

Può essere riprodotta da qualunque dispositivo esterno anche al ristorante. Il trucco sta infatti nel trasferire tramite il tablet usato per l’ordinazione a un dispositivo Android l’URL tramite la modalità Quick Share, accessibile facilmente da chiunque abbia accesso fisico al device.

D’ora in poi potremo quindi ordinare al tavolo di questo sushi comodamente da remoto.

Per risolvere questo tipo di vulnerabilità è necessario rendere accessibile solo su circuito chiuso l’ordinazione e legare tramite un sistema di login il device al tavolo del ristorante.

Cross-Site Scripting nei menù

Un’altra pratica comune è tralasciare la sicurezza nelle pagine in cui si visualizza il menù. Spesso infatti nei locali è presente un QR-Code che se scansionato ci porta ad una pagina in cui si può scaricare il menù in formato PDF. In questo caso è presente un server che di solito ricerca la path del menù all’interno del filesystem e la restituisce. Data la semplicità dell’operazione, è facile trovare i permessi non correttamente configurati o inesistenti.

Nel caso che vi presentiamo, una funzione visualizzamenu.php cerca il menù all’interno della path del server e restituisce il PDF, ma se non lo trova, renderizza il messaggio di errore insieme a quello che viene passato al parametro file. Questa è a tutti gli effetti una vulnerabilità di tipo Cross-Site Scripting (XSS) Reflected, perché è possibile iniettare codice JavaScript malevolo nel messaggio di errore restituito.

In questo caso infatti l’attaccante può sfruttare la vulnerabilità per reindirizzare la vittima verso un sito potenzialmente malevolo passando da un URL legittimo (ma vulnerabile) che proviene dal sito del ristorante.

Questa misconfiguration (in particolare usare funzioni PHP vulnerabili) può portare ad attacchi ben più gravi come LFI & RFI (Local & Remote File Inclusion) nelle quali un attaccante può addirittura caricare sul sistema vittima dei propri file ed eseguirli per prendere poi il controllo dell’infrastruttura.

Ma come si può risolvere questa vulnerabilità? Per prima cosa è necessario deprecare funzioni PHP vulnerabili e rimpiazzarle con codice più sicuro. In secondo luogo sarebbe utile appoggiare un WAF (Web Application Firewall) al weberver in modo da bloccare sul nascere gli attacchi di tipo XSS e SQL Injection.

Autenticazione & Broken Access Control

Una delle vulnerabilità più comuni è avere delle scarse protezioni per l’accesso alle risorse fornite dai servizi. Secondo OWASP questa è una delle vulnerabilità più sfruttate nell’ambito della web security.

Navigando infatti nei menù e sottomenù delle webpage dei ristoranti di sushi (oppure facendo un po’ di fuzzing o di Google Dorking), è possibile trovare cartelle (contenenti la struttura di una parte del webserver) che dovrebbero rimanere private.

In questo caso abbiamo la possibilità di caricare l’intera directory framework che come si vede dall’immagine appartiene al sito del ristorante fatto in WordPress, con tutte le funzioni php elencate e chiamabili a piacere.

In questo caso abbiamo quindi una misconfiguration di WordPress grazie alla quale l’attaccante può sfruttare l’Information Leakage per costruire potenzialmente attacchi più complessi al sito web. Inoltre avere la completa visibilità dell’alberatura del sito, fa risparmiare notevole tempo all’attaccante per l’enumeration, dato che ha la maggior parte delle informazioni in plaintext.

Un altro caso di Broken Access Control lo possiamo trovare molto facilmente in qualunque rete interna di ristorante o sushi che non abbia configurato gli apparecchi di rete in modo opportuno. In quest’altro scenario che vi presentiamo (in questo caso l’intranet di una pizzeria) è bastato un leggero bruteforce (a seguito di una enumeration lanciata da smartphone) delle credenziali di accesso di un ripetitore TP-Link per avere accesso al (semplice) schema della rete e a tutti i dispositivi connessi, potenzialmente disconnettere tutti i client, creare reti malevole o causare disservizio agli apparati connessi al ripetitore (come POS o telecamere interne).

Se oltre a questo, manca anche la segmentazione di rete, l’attaccante può facilmente sfruttare dei lateral movement per raggiungere e compromettere tutte le zone dell’infrastruttura.

Evitare questo tipo di vulnerabilità è abbastanza facile. Per evitare gli attacchi è necessario porre sotto pagine di autenticazione le sezioni con i dati più sensibili e avere delle password efficaci con (se possibile) una autenticazione a 2 fattori.

Insomma, gli esempi che abbiamo visto dimostrano come nei ristoranti e nei sushi le vulnerabilità non siano il risultato di attacchi sofisticati, ma quasi sempre di configurazioni superficiali.

Queste debolezze, spesso considerate innocue perché presenti in ambienti “chiusi”, diventano invece punti di ingresso reali per attacchi che possono compromettere la disponibilità dei servizi o esporre dati sensibili.

La lezione è semplice: anche nei contesti più piccoli è necessario applicare controlli di base e buone pratiche di hardening. Trascurarli significa solo aumentare il rischio che la propria infrastruttura venga compromessa con un attacco di base.