NOTA! Questo sito utilizza i cookie e tecnologie simili.

Se non si modificano le impostazioni del browser, l'utente accetta l' utilizzo dei cookie. Per saperne di piu'

Approvo

Uso dei Cookie

I cookie sono quei pezzi di codice che permettono ad un sito di ricordarsi di un utente visitatore, e quindi delle sue preferenze (colore sfondo,  limite elenchi e quant' altro il gestore dei siti voglia ricordarsi del visitatore) 

In questo sito , i cookie vengono usati lo stretto necessario per la gestione del sito, ivi incluse le pubblicita' che vedete  e le statistiche di visita , quindi analytics e adsense

potete trovare una spiegazione piu' dettagliata di cosa sono i cookie direttamente sul sito di google :

https://support.google.com/adsense/answer/2839090?hl=it

https://developers.google.com/analytics/devguides/collection/analyticsjs/cookie-usage

 

alla data del 24/06/2015 i cookie impostati da questo sito sono :

_ga  , scadenza a 2 anni  , usato da google analytics per distinguere gli utenti

_gat , scadenza 10 minuti , usato da google analytics , usato per regolare la frequenza delle richieste

cookieaccept , usato per memorizzare la vostra preferenza di accettare o rifiutare i cookie in modo da non richiedervelo piu'

a29408bbede9bd5b22e3b9b8a6a35efc , usato per mantenere il vostro utente se decidete di registravi e loggarvi al sito

 

se non siete daccordo con l' utilizzo, uscite dal sito o disattivate l' uso dei cookie sul vostro browser

 

ciao ciao

 davide

Valutazione attuale: 5 / 5

Stella attivaStella attivaStella attivaStella attivaStella attiva
 

***** IN FONDO ALL ARTICOLO GLI AGGIORNAMENTI *****

 

Avendo preso questa telecamera , piu' per giocarci che per effettiva necessita'

https://it.aliexpress.com/item/Aluminum-Metal-Waterproof-Outdoor-Bullet-IP-Camera-720P-960P-1080P-Security-Camera-CCTV-4PCS-ARRAY-LED/32655713613.html?isOrigTitle=true

 

la qualita' video non e' malaccio anche se e' solo una 720P,

 

l' interfaccia grafica accessibile via http necessita dell' installazione di un activix , quindi puo' esser gestita solo da windows , oppure siccome supporta il protocollo onvif , si puo' usare tramite un dvr onvif

 

 

 

ho iniziato a vedere se risponde al telnet , e si, risponde al telnet …

ma con quale user/password??? visto che di solito su internet si trovano queste info ho deciso di dare uno sguardo , ma niente una marea di siti che la vendono e poche info vere, sposto il focus della ricerca sul chipset utilizzato

sicome e' basata sul chipset HI3518 con sensore video OH22

 cercando , e dopo aver visitato vari link arrivo alla pagina

http://www.hlongasia.com/HL_Support.aspx

dove c'e' una raccolta di firmware per telecamere basate su chipset simili con vari sensori video

quello che mi interessa e' :

http://www.hlongasia.com/DOCs/Firmware/General_HZXM_IPC_HI3518E_50H10L_S38_V4.02.R12.Nat.OnvifS.20160615_ALL.bin

 

il file scaricato e' apribile con un qualsiasi unzipper , l' ho fatto direttamente da dentro mc (midnight commander)

all' interno ci sono :

 

custom-x.cramfs.img
Install
InstallDesc
romfs-x.cramfs.img
u-boot.bin.img
u-boot.env.img
user-x.cramfs.img
web-x.cramfs.img

 

quindi abbiamo i file che compongono le varie partizioni MTD dentro la telecamera, vorrei montarlo, non mi ricordo il comando preciso (e' una mia mancanza con i device loop), cerco ed ecco che atterro su

https://lfto.me/reverse-engineering-dvr-firmware/

una vera miniera per cio' che voglio fare

Continuando a seguire quella pagina scopro che dobbiamo eliminare un po di roba all' inizio del file in quanto il comando per creare l' immagine aggiunge 64 byte , e per levarli usiamo dd

dd bs=1 skip=64 if=romfs-x.cramfs.img of=romfs-x.cramfs_dd.img
3088384+0 record dentro
3088384+0 record fuori
3088384 byte (3,1 MB) copiati, 3,03482 s, 1,0 MB/s

 

infatti usando il comando file per identificare il file ,

passiamo dall' originale

file romfs-x.cramfs.img 
romfs-x.cramfs.img: u-boot legacy uImage, linux, Linux/ARM, OS Kernel Image (gzip), 3088384 bytes, Wed Jun 15 13:25:52 2016, Load Address: 0x00040000, Entry Point: 0x003B0000, Header CRC: 0x7412AA49, Data CRC: 0x6A4BF2C5

 

che ci dice essere un' immagine uboot

ad un filesystem compressed

file romfs-x.cramfs_dd.img 
romfs-x.cramfs_dd.img: Linux Compressed ROM File System data, little endian size 3088384 version #2 sorted_dirs CRC 0xcba44757, edition 0, 1074 blocks, 156 files

 

quindi possiamo provare a montarlo e vediamo il contenuto

sudo mount -o loop -t cramfs romfs-x.cramfs_dd.img /media/ciao

ls -l /media/ciao/
totale 5
drwxr-xr-x 1 532 dialout 1276 gen  1  1970 bin
drwxr-xr-x 1 532 dialout   20 gen  1  1970 boot
drwxr-xr-x 1 532 dialout    0 gen  1  1970 dev
drwxr-xr-x 1 532 dialout  344 gen  1  1970 etc
drwxr-xr-x 1 532 dialout    0 gen  1  1970 home
drwxr-xr-x 1 532 dialout  336 gen  1  1970 lib
lrwxrwxrwx 1 532 dialout   11 gen  1  1970 linuxrc -> bin/busybox
drwxr-xr-x 1 532 dialout   68 gen  1  1970 mnt
drwxr-xr-x 1 532 dialout    0 gen  1  1970 opt
drwxr-xr-x 1 532 dialout    0 gen  1  1970 proc
drwxr-xr-x 1 532 dialout    0 gen  1  1970 root
drwxr-xr-x 1 532 dialout  332 gen  1  1970 sbin
drwxr-xr-x 1 532 dialout    0 gen  1  1970 share
drwxr-xr-x 1 532 dialout    0 gen  1  1970 slv
drwxr-xr-x 1 532 dialout    0 gen  1  1970 sys

 

il primo posto dove vado a guardare

 

cat /media/ciao/etc /passwd
root:$1$RYIwEiRA$d5iRRVQ5ZeRTrJwGjRy.B0:0:0:root:/:/bin/sh

 

mi rivela che c'e' un' solo utente configurato e ci dice qual' e' l hash della password

(

con codifica MD5 indicata da $1$

con salt RYIwEiRA

password saltata d5iRRVQ5ZeRTrJwGjRy.B0

infatti se diamo il comando  per generare una password manualmente (con la giusta password e la giusta salt) otterremo la nostra stringa

openssl passwd -1 -salt RYIwEiRA xmhdipc 
$1$RYIwEiRA$d5iRRVQ5ZeRTrJwGjRy.B0

 basta cambiare anche un solo carattere del salt che cambia tutta la password

 openssl passwd -1 -salt RYIwEiRB xmhdipc 
$1$RYIwEiRB$VCzjGpkKjdaOiL.9u0Z17/

 

)

, per prima cosa cerco su google nella speranza che gia' qualcun' altro abbia fatto il lavoro per me...

cercando l' hash RYIwEiRA$d5iRRVQ5ZeRTrJwGjRy.B0 su google mi incuriosisce il secondo risultato

 

 

seguendo un link sul risultato mi ritrovo col sorgente di mirai ….

https://github.com/jgamblin/Mirai-Source-Code

che il browser non vuole farmi scaricare perche' dice che c'e' un virus, quindi andiamo di git clone

picola ricerca per la parola root dentro ai file scaricati e dentro al file

 

Mirai-Source-Code/mirai/bot/scanner.c

trovo varie credenziali

tra le quali

add_auth_entry("\x50\x4D\x4D\x56", "\x5A\x4F\x4A\x46\x4B\x52\x41", 5);// root     xmhdipc

che ha attirato la mia attenzione visto che il modulo della telecamera sembra prodotta da

http://www.xiongmaitech.com/en/index.php/product/product-detail/3/97/218

e da alcume parti nominata IPC

ed effettivamente provando a fare telnet sull' ip della telecamera e usando come credenziali

root
xmhdipc

 

sono entrato dentro …..

# mount
rootfs on / type rootfs (rw)
/dev/root on / type cramfs (ro,relatime)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /dev type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
/dev/mtdblock2 on /usr type squashfs (ro,relatime)
/dev/mtdblock3 on /mnt/web type cramfs (ro,relatime)
/dev/mtdblock4 on /mnt/custom type cramfs (ro,relatime)
/dev/mtdblock5 on /mnt/mtd type jffs2 (rw,relatime)
/dev/mem on /var type ramfs (rw,relatime)
/dev/mem2 on /utils type ramfs (rw,relatime)
usbfs on /proc/bus/usb type usbfs (rw,relatime)
/dev/mtdblock2 on /mnt/custom/data/Fonts type squashfs (ro,relatime)

# netstat -anp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:8899            0.0.0.0:*               LISTEN      1098/Sofia
tcp        0      0 0.0.0.0:34567           0.0.0.0:*               LISTEN      1098/Sofia
tcp        0      0 0.0.0.0:554             0.0.0.0:*               LISTEN      1098/Sofia
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1098/Sofia
tcp        0      0 0.0.0.0:9527            0.0.0.0:*               LISTEN      1093/dvrHelper
tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN      1089/telnetd
tcp        0      0 192.168.111.238:23      192.168.111.2:43630     ESTABLISHED 1089/telnetd
netstat: /proc /net /tcp6: No such file or directory
udp        0      0 0.0.0.0:34568           0.0.0.0:*                           1098/Sofia
udp        0      0 255.255.255.255:34569   0.0.0.0:*                           1087/searchIp
udp        0      0 0.0.0.0:3702            0.0.0.0:*                           1098/Sofia
udp        0      0 0.0.0.0:58249           0.0.0.0:*                           1098/Sofia
udp        0      0 0.0.0.0:35497           0.0.0.0:*                           1098/Sofia
udp        0      0 0.0.0.0:33477           0.0.0.0:*                           1098/Sofia
netstat: /proc /net /udp6: No such file or directory
netstat: /proc /net /raw6: No such file or directory
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node PID/Program name    Path
unix  2      [ ]         DGRAM                        35 633/udevd           @/org /kernel /udev /udevd
unix  3      [ ]         DGRAM                        38 633/udevd           
unix  3      [ ]         DGRAM                        37 633/udevd           
# 

 

 

che dire? sicuramente non e' una telecamera sicura .... ad esempio dahua modifica la password di telnet aggiungendo ad una parte standard la password dell' utente , rendendo di fatto attaccabili da mirai solo le telecamere che sono state lasciate con la password di default (Admin)

la sicurezza con mirai diventa sempre piu' un problema con le connessioni fibra, avendo 20 M di upload , ne bastano veramente poche compromesse per andare a dossare dei siti ....

 

****************************************************

devo dire , che senza molta convinzione ho scritto sia al venditore , che alla casa costruttrice evidenziando il problema ....

 

il giorno dopo ho ricevuto la mail di risposta del venditore, che a questo punto devo pensare esser gia' al corrente della cosa, perche' mi ha mandato un nuovo firmware con sempre le stesse credenziali, ma il demone

 

telnetd

non avviato , cosa che quantomeno mette una pezza al problema

 

dopo circa una settimana ho ricevuto pure una mail di risposta dalla casa costruttrice, o meglio non so da chi ...

perche' chi ha ricevuto la mia mail l' ha girata a un' altro indirizzo mail con dominio diverso, che successivamente l' ha girata ad un terzo indirizzo con un terzo dominio , che e' chi mi ha risposto , e la risposta in un' inglese piu' stentato del mio e' stata della serie:

si , grazie per avercelo fatto sapere , siamo un' azienda giovane in forte crescita e nei nostri piani futuri c'e' in programma di migliorare la sicurezza ....

 

Vai all'inizio della pagina