Durante l’Epifania ho ripristinato il mio iPad Mini (con la speranza vana di migliorarne le prestazione, dovrò passare al nuovo modello) che quotidianamente uso al lavoro per sfruttare due applicazioni che mi vengono fornite dal colosso internazionale di telefonia e distribuite tramite Wireless AdHoc Distribution, ovvero non sono presenti nell’Apple Store.
Una di queste due applicazioni non può essere utilizzata dopo il ripristino poiché il sistema monitora eventuali re-installazioni, la procedura interna prevede pertanto che l’utilizzatore (io) contatti il Call Center dedicato e comunichi che vuole reinstallare l’applicazione nello stesso o in un nuovo device. Se non si segue tale procedura appare l’errore sottostante.
Questo è dovuto al fatto che ad ogni nuova installazione l’applicazione genera un tabletid univoco, id che verrà conservato nei database centralizzati e se eseguendo il login con le corrette credenziali il sistema non riconosce anche il Device ID precedentemente associato rigetta l’autenticazione. All’interno dell’applicazione vi sono memorizzate anagrafiche di diversi milioni di clienti ed è quindi un buona procedura per limitare accessi indesiderati.
Buona procedura che però non è stata implementata correttamente a livello tecnico, la comunicazione tra applicativo e server avviene esclusivamente sul canale cifrato SSL. Peccato che il canale sia garantito da un certificato Self Signed e l’applicazione non è stata sviluppata per analizzare e confermare il certificato del server di autenticazione, pertanto potremmo passarli qualsiasi certificato che continuerà ad eseguire le sue procedure a patto di conservare una connessione HTTPS.
Questa è l’ennesima dimostrazione che una comunicazione HTTPS basata su certificati Self Signed se non opportunamente implementata è medesima ad una comunicazione HTTP in chiaro.
L’applicazione è stata sviluppata, almeno dalle evidenze che ho ottenuto analizzando il traffico, dalla famosissima multinazionale di consulenze con sede a Chicago. Se lo sviluppatore voleva correttamente sfruttare un certificato SSL Self Signed, anziché aumentare i costi con l’acquisto di una certificato convalidato da terzi, doveva memorizzare all’interno dell’applicazione il certificato pubblico del server e confrontarlo ad ogni connessione, se il certificato è diverso da quello conosciuto rigettare la connessione. Invece viene accettato qualsiasi certificato, pertanto attraverso un Proxy Software (es. OWSAP Zed Attack Proxy) è possibile intercettare le comunicazioni tra il server e l’applicazione e modificare le stringhe di autenticazione.
Ho quindi eseguito un test sfruttando il mio iPad Mini e un iPad Air riuscendo ad installare e ad eseguire la medesima applicazione su due dispositivi, replicando il tabletid dell’iPad Mini sull’iPad Air. Dall’immagine di apertura potete vedere che il tabletid viene passato nell’header della comunicazione, di seguito la medesima applicazione attiva su due device distinti contemporaneamente.
L’uso non appropriato del certificato SSL mette a rischio pericolo anche tutte le comunicazioni tra applicativo e server, non è solo possibile vedere in chiaro le credenziali di autenticazione ma anche l’archivio dei clienti e ipotizzando di sfruttare un Fake Access Point durante una riunione/meeting aziendale potrei ottenere le credenziali di diversi colleghi senza che loro si accorgano di nulla.