Articoli

Schermata 2016-01-09 alle 09.38.02

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.

IMG_0003

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.

IMG_8903

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.

MySql_Root_1v2

In queste ultime settimane una storica editoria Italiana che vanta un fatturato di oltre 500 milioni di euro nel 2014, fonte Wikipedia, ha pubblicato sull’Apple Store e Play Store una nuova applicazione per leggere un celebre fumetto.

Purtroppo la prima versione di questa App sta ricevendo notevoli commenti negativi nei rispettivi store, le criticità riportate sono basate sulla lentezza nell’ottenere i contenuti e sui continui crash durante la lettura del fumetto.

Ricerca

quickstart-zap

A fini di ricerca ho voluto visualizzare il traffico generato dall’Applicazione installata sul mio iPad Mini, ho così provveduto ad aprire BackBox Linux e il software preinstallato ZAP Proxy, proprio come feci tempo indietro rilevando che era possibile leggere più di 20 Quotidiani o Riviste gratuitamente scavalcando il sistema di pagamento.

Directory Listing

L’analisi del traffico attraverso il Proxy Server è durata veramente poco, l’applicazione attraverso uno script PHP autentica l’utente attraverso una richiesta POST in chiaro e ne consegue che l’utente viene autorizzato o meno allo scaricamento dei fumetti. Se non è autorizzato viene invitato ad acquistare il fumetto.

Se l’utente è autorizzato inizia il download del PDF contente le nuove e avvincenti storie del xxxxxx più famoso della storia 😀

Con una semplice analisi del traffico scopro già le prime lacune in termini di sicurezza informatica:

  • Assenza del protocollo SSL per l’invio delle credenziali dell’utente;
  • Invio delle credenziali in chiaro (es. username=andrea.d&password=nonteladico);
  • Server pubblico senza la ben che minima protezione agli accessi;
  • È possibile ottenere illecitamente il fumetto conoscendo la path del file PDF, poiché ad esso non è associato alcun meccanismo di autenticazione.

Nuovamente quindi è possibile leggere il fumetto eludendo il meccanismo di pagamento, con un grosso danno economico alla casa editoriale. È un punto importante e molto critico che favorisce la pirateria ai danni della società, ho già parlato di questi aspetti in passato ed ora non voglio soffermarmi ulteriormente anche perché sono un loro fedele cliente da oltre 20anni e continuerò ad esserlo.

Il secondo dettaglio che mi è saltato all’occhio aprendo il PDF nel mio Browser Firefox è che il server permette il Directory Listing son quindi riuscito a vedere i vecchi e nuovi numeri che usciranno nelle prossime settimane! :O

Vi ricordate il danno di immagine della Sony quando vennero trafugate in anteprima delle pellicole cinematografiche?! Bene e se iniziassi a distribuire i futuri numeri del fumetto prima della loro uscita ufficiale, di quanto diminuirebbero le vendite lecite?

Credenziali di Root

Ho continuato la mia navigazione, lecita, all’interno del server scoprendo uno script in python e un file di configurazione XML che contengono le credenziali del server MySQL, credenziali che riportano come nome utente “root ed è quindi possibile dedurre che le credenziali SSH e MySQL coincidano non essendo presente un utente specifico per MySQL.

Mi sono cadute le braccia, un utente malintenzionato potrebbe quindi accedere con i massimi poteri sul server e “giocarci” a proprio piacimento!

Nessuno Conosce l’URL

Riflettendo sul caso mi è venuto in mente un recente articolo di Paolo, nel quale parla di un Penetration Testing andato a buon fine e delle scusanti che l’Acccount Manager gli ha riportato.

Il server web in questione non ha alcun dominio associato, quindi l’Applicazione accede direttamente all’IP del Server di produzione. Server che probabilmente ha il solo compito di autenticare gli utenti e distribuire i file PDF!

La casa editoriale o lo sviluppatore potrebbe rispondermi “Non vi è alcun riferimento a quel server sul nostro sito Web, perché preoccuparsene!?” la risposta è facile! Quel server è su INTERNET e accessibile a TUTTI, non è stato implementato alcun sistema di autenticazione e non vi è neanche un briciolo di buona volontà nel renderlo sicuro! Ne riparleremo quando Google scansionerà il contenuto del server e le credenziali saranno alla mercé del più infimo lamer che userà il server per diffondere Phishing, Malware, ecc ecc!