oggi ho deciso di affrontare un argomento interessante.

La maggior parte dei siti web php based oggi utilizza un CMS (Content Management System) come Joomla, WordPress, phpBB, siti di ecommerce etc.

Questi hanno semplificato di molto la vita degli utenti ma hanno anche aperto le porte ad attacchi di cracker sempre più frequenti.

Molto spesso il nostro sito è sotto attacco e noi non ce ne accorgiamo nemmeno!

Vediamo un po’ come accorgersi se un sito web è stato attaccato e quindi compromesso!

ATTENZIONE: questa guida presuppone che voi possiate accedere ai log del vostro server web e soprattutto al terminale.

Possiamo cominciare.

Per prima cosa si cercano i file .php che sono stati modificati negli ultimi giorni:

Source code

find . -type f -name '*.php' | xargs grep -l "eval *(" --color
find . -type f -name '*.php' | xargs grep -l "base64_decode *(" --color
find . -type f -name '*.php' | xargs grep -l "gzinflate *(" --color

In genere gli autori degli script utilizzati per attaccare i siti li mascherano per evitare eventuali antivirus o software capaci di identificare codice maligno.

In questo modo i file che verranno restituiti saranno al 90% sicuramente compromessi (a meno che non abbiate acquisto un qualche script php che non viene fornito con codice sorgente ma viene mascherato!)

Vediamo un esempio pratico che cerca nella cartella wp-content di WordPress:

Source code

find wp-content -type f -name '*.php' | xargs grep -l "gzinflate *(" --color

In alcuni casi, dove gli script sono in chiaro alcune delle opzioni che usano sono quelle di aprire dei socket oppure lanciare comandi per eseguire operazioni sul server: Ecco come cercare questo tipo di files:

Source code

find . -type f -name '*.php' | xargs egrep -i "(mail|fsockopen|pfsockopen|stream_socket_client|exec|system|passthru|eval|base64_decode) *("

Ma chi attacca i siti queste cose le sa bene, per cui spesso maschera questo tipo di operazioni utilizzando direttamente la codifica Esadecimale (HEX)

In questo modo noi non troveremmo niente eppure il sito rimane compromesso…

Ecco come fare:

Source code

find . -type f -name '*.php' | xargs egrep -i "preg_replace *((['|"])(.).*2[a-z]*e[^1]*1 *," --color

Con il codice che ho scritto sopra si vanno a cercare tutti i preg_replace dove si cerca di inserire del codice esadecimale!

Continuiamo con l’esempio di WordPress.

Mettiamo il caso di avere il sospetto o la certezza che il sito sia stato compromesso.

Possiamo effettuare un upload sul server di una versione “pulita” di wordpress( o un altro cms) in un’altra cartella ed effettuare un diff per notare eventuali differenze (Attenzione perchè in questo caso le versioni del CMS devono essere uguali!)

Source code

diff -r wordpress-ok/ wordpress-hack/ -x wp-content

Inoltre la maggior parte degli attacchi prolificano su server dove vengono concessi (volontariamente o meno) i permessi di scrittura sulle cartelle.

Di seguito un breve script per aiutare a capire i file .php presenti nelle cartelle con permessi 777:

Source code

#!/bin/bash
 
search_dir=$(pwd)
writable_dirs=$(find $search_dir -type d -perm 0777)
 
for dir in $writable_dirs
do
    #echo $dir
    find $dir -type f -name '*.php'
done

Reso eseguibile lo script è possibile verificare i file in questo modo:

Source code

./search_php777 > results.txt

Questo script può essere variato nel seguente modo (in base a quanto abbiamo detto prima):

Source code

#!/bin/bash
 
IFS=$'n'
 
while read php_file
do
    egrep -i "(mail|eval|base64_decode|str_rot13|chmod|fwrite|exec|passthru|shell_exec|system|proc_open|popen|curl_exec|curl_multi_exec|show_source|fsockopen|pfsockopen|stream_socket_client) *(" "$php_file"
done < php_in_writable.txt

Da eseguire in questo modo:

Source code

./find_malicious

Ultima ma non meno importante delle cose da verificare, è la possibilità che del codice php sia “nascosto” dentro una immagine:

Source code

find wp-content/uploads -type f -iname '*.jpg' | xargs grep -i php

Per chi preferisce avere un unico script che fa tutto, può utilizzare NeoPI che racchiunde gran parte delle analisi che vi ho mostrato solo scritte in Python!

Buona analisi a tutti.

Enjoy!

L'articolo Sito Web attaccato? Strategie di Difesa sembra essere il primo su Linux 360° | Italia.

Sempre sviluppata con l’amico Frank al quale vengono le idee…e io poi le realizzo!

La base è quella di voler realizzare un sistema minimale di CDR (Call Detail Recording) ossia uno strumento che permette di visualizzare i dettagli delle chiamate sui centralini Asterisk.

Il sistema classico utilizza MySQL e si trova molto materiale in giro per la rete.

Oggi vi spiego come realizzarlo con SQLite, che è una versione minimal di SQL, da utilizzare su quei dispositivi dove non ci sono molte risorse (vedi centralino asterisk su Raspberry)

Requisiti:

- Asterisk

- Debian (o qualunque altro SO)

- SQLite

- Apache (o un qualunque Web Server)

- Php5 con supporto per SQLite3

Installazione Requisiti:

Per installare SQLite3:

Source code

sudo apt-get install libxml2-dev ncurses-dev libsqlite3-dev sqlite3

Per installare Apache:

Source code

sudo apt-get install apache2

Per installare PHP5-SQLite:

Source code

sudo apt-get install php5-sqlite3

Procedimento:

Per prima cosa è necessario che asterisk sia compilato con SQLite.

Per fare questo bisogna controllare che nella cartella dove sono installati i noduli di asterisk generalmente /usr/lib/asterisk/modules sia presente il file cdr_sqlite3_custom.so.

Se non è installato è necessario ricompilare asterisk aggiungendo il modulo indicato sopra facendo:

Source code

make menuselect

(Non mi soffermo su questo perchè si trovano molte guide in giro)
Fatto questo bisogna modificare il file cdr_sqlite3_custom.conf in /etc/asterisk come nel file in allegato.

Se è già installato SQLite e il master.db è già creato è necessario rimuoverlo per adattarlo alla mia conf.(se non volete basta modificare il file cdr_sqlite.php adattandolo alle vostre esigenze!)

Per verificare se il master.db è già creato bisogna vedere se nel percorso /var/log/asterisk è presente.

Una volta modificato il file cdt_sqlite3_custom.conf è necessario riavviare Asterisk (sudo /etc/init.d/asterisk restart)

Fatto questo basta scompattare i file che vi allego dentro una /var/www o comunque la directory principale del vostro web server.

Se tutto è ok potrete vedere i dettagli delle vostre chiamate digitando nel browser: http://localhost/cdr_sqlite.php

Enjoy!

Dowload Sorgenti

L'articolo Asterisk CDR con SQLite3 e PHP sembra essere il primo su Linux 360° | Italia.

Non sempre però questo funziona realmente: plugin, guide, etc….alla fine c’è sempre qualcosa che non torna.

Ecco ho fatto tornare i conti!

Per gestire le variabili $_SESSION[] all’interno di WordPress, la prima cosa da fare è aprire il file functions.php del vostro tema e inserire subito dopo il tag  di apertura di php:

Source code

if(!session_id()) add_action('init', 'session_start');

Il gioco è fatto!

Adesso potete usare le variabili $_SESSION nel vostro WordPress!

Enjoy!

L'articolo WordPress: Gestire le variabili $_SESSION sembra essere il primo su Linux 360° | Italia.

Sabato ho fatto l’update sui nostri server a TLCWEB ed è andato tutto ok….

Ieri apro una casella per modificarla e… magia! Spunta fuori un bel messaggio di errore:

Invalid query: Unknown column ‘local_part’ in ‘field list’

Please check the documentation and website for more information.

Postfix Admin
Forums

Senza farsi prendere dal panico…

Basta aprire il file edit-mailbox.php, trovare la riga

$formvars['local_part'] = $matches[1];

E commentarla!

Il gioco è fatto…

Enjoy!

L'articolo Postfix Admin update sembra essere il primo su Linux 360° | Italia.