Il malware / shell PHP continua a resuscitare [duplicato]

Abiliterei auditd per monitorare le modifiche ai file che ci si aspetta siano backdoor. Sarai in grado di determinare quale account e quale processo è responsabile per queste modifiche.

Dopo aver installato auditd (non installato pr predefinito su tutti i sistemi), è possibile iniziare a monitorare le modifiche nei file. Per fare ciò, esegui semplicemente il comando:

auditctl -w /var/www -p wa

Questo comando registrerà tutte le modifiche ai file nel file di registro auditd. Di solito lo trovi in / var / log / audit /, ma dipende dal sistema.

Se sei preoccupato che l'autore dell'attacco possa notare questo (e magari rimuovere la regola), puoi bloccarlo eseguendo il comando:

auditctl -e 2

Non è possibile apportare ulteriori modifiche alle regole di controllo fino al riavvio del sistema. Prima di fare ciò, assicurati che la regola di controllo sopra non generi una quantità folle di log.

Infine, i registri di audit sono un po 'criptici. Una volta rilevato che il sistema è di nuovo in modalità backdoor, è possibile cercare la traccia di controllo, utilizzando il comando:

ausearch -f /var/www/backdoored_file.php

Spero che questo ti fornisca gli indizi su cosa sta succedendo. Buona fortuna!

Ulteriori:

Per far sopravvivere le regole di controllo, devi definirle in /etc/audit/audit.rules

Originariamente l'ho postato come commento, ma penso che questo potrebbe fare con una piccola spiegazione.

Dalla mia esperienza con gli scenari di acquisizione del sito Web, quando una shell viene caricata su un sito Web, l'hacker riesce a sfruttare una vulnerabilità nel server, ottenere l'accesso root, backdoor il tuo SSH e compromettere tutti gli altri siti sul server, oppure semplicemente non gestisce questo e fa con una semplice shell. Penso che, nel tuo caso, sia il secondo scenario, dato che dici che solo un sito web sul VPS è stato infettato.

Ora come fa la conchiglia a "ressurare". Se il tuo server non è stato "rootato", questo lascia solo altre quattro opzioni a cui posso pensare:

1. a "bindport" backdoor
2. a "backconnect" backdoor (raro)
3. una backdoor personalizzata o un "downloader" in uno dei tuoi file PHP
4. un account MySQL compromesso con accesso ai file e privilegi di accesso remoto.

Parliamo dei primi due e di come affrontarli per primi. "bindport" e "backconnect" sono due piccoli programmi, in genere script Perl, tradizionalmente forniti con shell Web. Di solito vengono creati in (e eseguiti da) la cartella /tmp , che è scrivibile per tutto. Per trovarli, puoi monitorare tutti i tuoi processi per script o programmi strani e avere una buona occhiata nella cartella /tmp . Inoltre, è consigliabile impostare un firewall.

"Bindport" apre una nuova porta per le connessioni in entrata e fornisce l'accesso alla shell Unix a tutti gli utenti che effettuano il blocco (di solito è protetto da password). Per trovarlo, cerca strane porte aperte (molti hacker hanno appena aperto la porta 31337 o qualcosa del genere).

"Backconnect" fa esattamente quello che viene chiamato: apre una connessione a un server remoto, garantendo anche l'accesso alla shell. È usato più raramente di "bindport", principalmente perché la maggior parte degli hacker è troppo pigra per preoccuparsi di usarla. Solitamente fanno ricorso a questo metodo solo se "bindport" fallisce per qualche motivo (come le impostazioni del firewall).

Ora, sulle backdoor personalizzate e sui "downloader" . Questi sono usati raramente, perché l'hacker ha bisogno di conoscere almeno un po 'di PHP per usarlo (e la maggior parte dei siti-jackers oggi non sono altro che skriptkiddies o bot mal fatti). Sono per lo più file stand-alone come shell semplicistiche, o un paio di linee extra di codice iniettate in uno dei tuoi script. Eseguono comandi impartiti (codice PHP, comandi shell) o eseguono una semplice scrittura di file con i dati passati (che possono essere un'altra backdoor). Puoi provare a cercare file con codice PHP come eval , preg_replace con e modificatore, exec , system , fopen / fwrite e altre funzioni di file, ecc. Tuttavia, il il migliore e il modo più sicuro per gestire questa roba è semplicemente ripristinare l'intero sito web da un backup . Se decidi di farlo, assicurati di cancellare tutti gli altri file del sito dal server in anticipo, nel caso in cui tu abbia perso una shell o una backdoor autonoma.

E l'ultimo caso altamente improbabile, ma ancora possibile. Se hai eseguito WordPress con l'utente root MySQL (o solo con un utente con diritti di scrittura file), o semplicemente con un utente con diritti sufficienti per visualizzare l'hash della password di un altro utente con diritti di scrittura file e quell'utente con file i diritti di scrittura hanno il privilegio di connettersi al database da qualsiasi luogo, beh ... hai capito. Ti consiglio di cambiare tutte le tue password MySQL.

Da adesso a perché solo un determinato set di directory viene infettato . Ci sono due possibili casi: o l'hacker, non avendo "rootato" il server, si accontenta della quantità limitata di directory a loro disposizione (probabilmente tutte le directory del tuo sito web), o hanno accesso ad altre directory ma semplicemente don ' li uso.

Se è quest'ultimo caso, scommetterei che o hai a che fare con un idiota, o con qualcuno estremamente pigro. O con un bot. Sì, questo potrebbe deluderti, ma dubito che il tuo sito sia davvero abbastanza importante per un hacker esperto: potrebbe essere usato per afferrare qualche clic dai tuoi utenti, per ospitare malware o semplicemente sfornare una tonnellata di spam un paio di volte. Hai a che fare con uno scriptkiddie o un pazzo inesperto che prova a grattare un paio di centesimi di click-trading e spam, o con un bot. Tuttavia, penso che sia più probabile una persona vivente: questo spiegherebbe l'irregolarità delle "ressurezioni" della conchiglia.

Ho avuto una cosa molto simile a un sito che gestisco. Dopo molte frustrazioni sull'eliminazione del codice dannoso e dopo circa 2 settimane dopo, ho scoperto questo:

Ho preso nota del timestamp di quando tutti i file sono stati modificati, quindi ho cercato il log di accesso per quel minuto. Ho visto che una certa pagina è stata richiesta che sembrava sospetta, poiché era un 404.php di un tema wordpress che non era attivo. Ho controllato quella pagina e ho visto una riga che era fondamentalmente% cod_de% codificata in base64.

Quindi non ho cancellato il codice, invece l'ho cambiato salvando un log di tutto ciò che viene inviato al post di quella pagina. Certamente 2 settimane dopo, il mio sito è rimasto al sicuro, ma un file di registro ha registrato un codice interessante inviato ad esso.

Sembra che gli aggressori abbiano installato un rootkit sul tuo server. Un rootkit può fornire una backdoor anche se tutto sembra pulito.

L'approccio migliore ora secondo me sarebbe quello di cancellare il server e reinstallarlo da zero. Patch i siti Web per eliminare la vulnerabilità. Se è necessario ripristinare dal backup (si dispone di backup, giusto? :)) assicurarsi che sia pulito.

Configura uno script per cercare le tracce di infezione (ad esempio l'utente ID 10001) nel caso in cui vi siano altre vulnerabilità in aggiunta al problema MailPoet.

Se non sai come sei stato infettato in primo luogo, allora la mia ipotesi sarebbe che la resurrezione provenga da te colpito dallo stesso scanner di vulnerabilità che ti ha colpito la prima volta - se questo è il caso, il consiglio di @ scrollup di confrontare i timestamp dei file con il traffico web dovrebbe trovarti lo script vulnerabile, oltre a darti alcuni IP validi da bloccare dal tuo sito.

In base alla mia esperienza, almeno per quanto riguarda il targeting di Apache, gli script di modifica della pagina saranno indirizzati a un sottoinsieme molto specifico delle cartelle sul computer: quelli che possono trovare nella cartella /etc/httpd/conf/httpd.conf. Avevo alcune altre cartelle Web definite nei file inclusi, ma lo script che cercava le cartelle da iniettare era chiaramente interessato solo a estrarre le cartelle da un file.

Quindi, vedi se c'è qualcosa di significativamente diverso nella tua configurazione di Apache tra quei siti che sono stati interessati e quelli che non lo sono stati. Potrebbe darti un buon approccio per proteggere la maggior parte dei tuoi siti da esso in futuro, lasciando un sito "canary" o "honeypot" che puoi monitorare per le ricorrenze.

Questa potrebbe sembrare una semplice domanda, ma hai controllato qualcosa di sospetto nella tua directory /tmp ? Mentre diverse varianti di malware sono dappertutto, molti comunemente sfruttano i bug di accesso al sistema, come il bug di bash shellshock, per installare il codice eseguibile direttamente nella directory /tmp .

Se non sei sicuro di cosa dovrebbe / non dovrebbe essere in /tmp/ , c'è una cosa facile, ma estrema, che puoi fare per eliminare le cose cattive. Basta eseguirlo online nella riga di comando:

rm -rf /tmp && mkdir /tmp && chown root:root /tmp && chmod 1777 /tmp

Oppure esegui ogni comando singolarmente in questo modo:

sudo rm -rf /tmp 
sudo mkdir /tmp
sudo chown root:root /tmp
sudo chmod 1777 /tmp

Quindi riavvia il server per vedere se questo risolve le cose. Se lo fa, congratulazioni! Ma non sei ancora fuori dai guai dato che qualsiasi cosa abbia causato l'infezione del sistema originale potrebbe penetrare nel tuo sistema, è solo una questione di tempo prima che ti reinfetti nuovamente. Significa, si spera che questo ripulisca il casino causato da una debolezza del sistema che, si spera, abbia già inserito. Ma devi essere sicuro di scoprire che cosa potrebbe essere stato quel punto debole e assicurarti di indurirlo.

Raccomando anche di controllare le voci crontab per l'utente root tramite un semplice crontab -l come questo:

sudo crontab -l

E forse anche esegui lo script di bash tratto da questa risposta su Stack Overflow che ti darà un bel rapporto generale di tutti crontabs installato sul sistema:

#!/bin/bash

# System-wide crontab file and cron job directory. Change these for your system.
CRONTAB='/etc/crontab'
CRONDIR='/etc/cron.d'

# Single tab character. Annoyingly necessary.
tab=$(echo -en "\t")

# Given a stream of crontab lines, exclude non-cron job lines, replace
# whitespace characters with a single space, and remove any spaces from the
# beginning of each line.
function clean_cron_lines() {
    while read line ; do
        echo "${line}" |
            egrep --invert-match '^($|\s*#|\s*[[:alnum:]_]+=)' |
            sed --regexp-extended "s/\s+/ /g" |
            sed --regexp-extended "s/^ //"
    done;
}

# Given a stream of cleaned crontab lines, echo any that don't include the
# run-parts command, and for those that do, show each job file in the run-parts
# directory as if it were scheduled explicitly.
function lookup_run_parts() {
    while read line ; do
        match=$(echo "${line}" | egrep -o 'run-parts (-{1,2}\S+ )*\S+')

        if [[ -z "${match}" ]] ; then
            echo "${line}"
        else
            cron_fields=$(echo "${line}" | cut -f1-6 -d' ')
            cron_job_dir=$(echo  "${match}" | awk '{print $NF}')

            if [[ -d "${cron_job_dir}" ]] ; then
                for cron_job_file in "${cron_job_dir}"/* ; do  # */ <not a comment>
                    [[ -f "${cron_job_file}" ]] && echo "${cron_fields} ${cron_job_file}"
                done
            fi
        fi
    done;
}

# Temporary file for crontab lines.
temp=$(mktemp) || exit 1

# Add all of the jobs from the system-wide crontab file.
cat "${CRONTAB}" | clean_cron_lines | lookup_run_parts >"${temp}" 

# Add all of the jobs from the system-wide cron directory.
cat "${CRONDIR}"/* | clean_cron_lines >>"${temp}"  # */ <not a comment>

# Add each user's crontab (if it exists). Insert the user's name between the
# five time fields and the command.
while read user ; do
    crontab -l -u "${user}" 2>/dev/null |
        clean_cron_lines |
        sed --regexp-extended "s/^((\S+ +){5})(.+)$/${user} /" >>"${temp}"
done < <(cut --fields=1 --delimiter=: /etc/passwd)

# Output the collected crontab lines. Replace the single spaces between the
# fields with tab characters, sort the lines by hour and minute, insert the
# header line, and format the results as a table.
cat "${temp}" |
    sed --regexp-extended "s/^(\S+) +(\S+) +(\S+) +(\S+) +(\S+) +(\S+) +(.*)$/\t\t\t\t\t\t/" |
    sort --numeric-sort --field-separator="${tab}" --key=2,1 |
    sed "1i\mi\th\td\tm\tw\tuser\tcommand" |
    column -s"${tab}" -t

rm --force "${temp}"

Per quanto complesse possano sembrare le infezioni da malware, una volta che sai dove si trovano i punti deboli comuni, puoi concentrare i tuoi sforzi per eliminare definitivamente il tuo sistema da quella spazzatura.

Nel tuo post non ci sono abbastanza informazioni per determinarne la causa. Dovrai fare delle indagini. La prima cosa da verificare è il tempo di creazione / modifica dei file e quindi confrontarli con i log di accesso e ftp nello stesso momento per determinare come sono stati modificati i file. Spero che questo ti porti ad un file /plugin/.shell.php che è la backdoor sinistra dell'infezione iniziale. Se i tuoi log non sembrano contenere nulla di utile, è possibile che sia stato creato un account backdoor nella tua installazione di WP e ciò che stai vedendo è il risultato di "normali operazioni" da parte di un utente malintenzionato.

Perché non impostare un orologio sulla creazione del nuovo utente? E una volta che ciò accade, invii una mail offsite per informarti della creazione.