Questi sintomi suggeriscono un attacco man-in-the-middle. Un pezzo di malware in esecuzione sul router può generare certificati fasulli al volo - è facile compilare tutti i campi, ma se l'utente malintenzionato non ha accesso alla chiave privata di un certificato radice attendibile, non può firmarlo correttamente - , intercettando il traffico HTTPS e facendo finta di essere vari server web. Poiché il tuo traffico scorre attraverso il tuo router WiFi quando sei connesso ad esso, questo tipo di attacco non deve necessariamente comparire nei record DNS; un router direttamente sul percorso da te al server web ha il potere di agire come se fosse un endpoint TCP. Se, per una ragione o per l'altra, l'utente sbaglia e sceglie di accettare il certificato fasullo come valido, il malware in esecuzione sul router può ascoltare e manomettere il traffico da questo utente a questo server e utilizzare questa potenza come trampolino di lancio per ulteriori attacchi, i cui obiettivi possono eventualmente includere uno o entrambi l'hardware o l'identità legale dell'utente.
Potrebbe essere possibile diagnosticare questa classe di problemi tentando connessioni TCP a server HTTPS lontani ma impostando il valore TTL su valori bassi. ( hping3 è uno strumento utile per questo tipo di esperimenti.) Normalmente, su ogni hop nel percorso di un pacchetto IP, i router decrementano di uno il campo dell'intestazione TTL del pacchetto IP e quando TTL raggiunge lo zero, il pacchetto non sarà inoltrato; invece, i router "polite" restituiranno una risposta TTL scaduta ICMP. Questa strategia aiuta a difendersi dai pacchetti immortali che viaggiano eternamente in circuiti di routing accidentale, sprecando risorse. È anche utile per strumenti di diagnostica come traceroute .
Supponiamo che tu stia un salto dal router WiFi e, ad esempio, account.google.com si trova a dieci punti di distanza. Se invii a accounts.google.com:443 un pacchetto TCP con il suo flag SYN, che indica che stai provando ad aprire una connessione HTTPS, ma il suo TTL ad un valore di, ad esempio, cinque, il pacchetto non dovrebbe mai essere in grado per raggiungere accounts.google.com, in questo modo:
$ sudo hping3 -c 3 -p 443 -S -t 5 accounts.google.com
HPING accounts.google.com (en1 216.58.209.141): S set, 40 headers + 0 data bytes
TTL 0 during transit from ip=62.115.61.30 name=google-ic-314684-s-b5.c.telia.net
(nota, tuttavia, che la risposta ICMP potrebbe non essere consegnata o persa nel traffico, quindi il criterio diagnostico è la mancanza di una risposta SYN + ACK TCP piuttosto che l'arrivo di una risposta ICMP scaduta TTL).
Se, tuttavia, ottieni una risposta ACK SYN, come questa:
len=44 ip=216.58.209.141 ttl=59 id=23005 sport=443 flags=SA seq=0 win=42780 rtt=8.1 ms
significa che qualcuno entro cinque luppoli da te - che, se sei a dieci luppoloni lontano da un account.google.com originale, è quasi certamente un impostore malvagio - sta rispondendo al traffico destinato a accounts.google.com, e puoi sapere con certezza che qualcosa è sbagliato all'interno di questi cinque hop sul percorso IP.
Si noti, tuttavia, che il malware intelligente può essere saggio a questo trucco, quindi questo è decisivo in una sola direzione. Se, infatti, non riesci a raggiungere server lontani con pacchetti TTL bassi, suggerisce, ma non è una prova evidente, la presenza di malware MiTM nel router WiFi. Inoltre, è possibile essere più vicini di dieci hop a accounts.google.com, quindi potresti voler giocare con il valore TTL ( -t su hping3 ) un po '.
