BackBox_4_screenshot

Martedì 26 Gennaio abbiamo rilasciato la versione 4.5 di BackBox Linux, questo aggiornamento minore permette a tutti gli utenti che scaricano la ISO di avere sempre a disposizione in modalità live le ultime versioni dei principali software dedicati al Penetration Testing.

Novità

Nella versione 4.5 di BackBox sono stati aggiornati i seguenti tools: wpscan, knockpy, nmap, zaproxy, set, guymanager, sqlmap, apktool, hashcat, can-utils, binwalk e openvas che ora è raggiungibile attraverso la porta 4000. Phishing-frenzy è invece un nuovo software disponibili nei repository ufficiali, ma non installato di default.

Purtroppo a causa del poco tempo non sono riuscito a pachettizzare comix, che comunque arriverà a breve assieme all’aggiornamento di dir3arch che è in corso in queste ore.

Download

Il download è possibile eseguirlo attraverso il sito ufficiale di BackBox, oltre ai due soliti Mirror HTTP (il GARR e il server di OverSecurity). Inoltre è possibile sfruttare un nuovo server Torrent con connettività di upload pari a 200Mb/s appositamente pensato per condividere le ISO di BB.

HetZener_Server_Speed

Upgrade

Per chi infine pensa di effettuare un upgrade dalla sua attuale versione alla nuova 4.5, può eseguire da terminale i seguenti comandi:

sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install -f

# For amd64
sudo apt-get install linux-headers-generic-lts-wily linux-image-generic-lts-wily linux-signed-generic-lts-wily linux-signed-image-generic-lts-wily

# For i386
sudo apt-get install linux-headers-generic-lts-wily linux-image-generic-lts-wily linux-signed-generic-lts-wily linux-signed-image-generic-lts-wily

sudo apt-get purge ri1.9.1 ruby1.9.1 ruby1.9.3 bundler
sudo gem cleanup
sudo rm -rf /var/lib/gems/1.*
sudo apt-get install backbox-default-settings backbox-desktop backbox-menu backbox-tools –reinstall
sudo apt-get install beef-project metasploit-framework whatweb wpscan setoolkit –reinstall
sudo apt-get autoremove –purge
sudo apt-get install openvas sqlite3
sudo openvas-launch sync
sudo openvas-launch start
sudo update-rc.d apache2 disable
sudo update-rc.d polipo disable
sudo update-rc.d openvas-gsa disable
sudo update-rc.d openvas-manager disable
sudo update-rc.d openvas-scanner disable

 

 

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.