www-data sta inviando mail canaglia tramite sendmail. Come trovo la fonte?

2

Quindi ho un server Ubuntu che ospita un sito Web basato su PHP per me. Alcuni dei servizi si basano sulla configurazione di sendmail . L'ho configurato per inviare tramite il mio account GMail.

A partire da ieri ~ 19: 00 CET, la mia cartella "inviato posta" di GMail si è improvvisamente travolta dai rapporti di consegna della posta restituiti da Sottosistema di consegna della posta . Ho visto che qualcuno sta tentando di inviare e-mail in uscita (spam) dal mio sistema usando www-data . Fortunatamente per me, stavano anche tentando di modificare il campo From, che è stato negato da (AFAIK) Google. Ecco una trascrizione (sensored) da mail.log :

Feb  4 18:58:10 ip-xxxxx sendmail[740]: s14IwAHQ000740: Authentication-Warning: ip-xxxxx.ec2.internal: www-data set sender to [email protected] using -f
Feb  4 18:58:10 ip-xxxxx sendmail[740]: s14IwAHQ000740: [email protected], size=464, class=0, nrcpts=1, msgid=<[email protected]>, relay=www-data@localhost

Ho "chiuso" sendmail chmodando l'eseguibile a 000.

Quindi la cosa è che mi piacerebbe far funzionare di nuovo sendmail mentre si chiude il buco della sicurezza. Sono un po 'una perdita di dove cominciare. Non sono un esperto di Linux anche se sono riuscito a impostare questo sistema.

Gestisco un totale di 5 siti web (host virtuali) sul sistema, e sono abbastanza sicuro che uno di loro, e quale uno di loro, è compromesso. Nel registro sopra, ho scambiato il vero dominio di uno dei miei 5 siti con "mydomain.com". Quindi sono abbastanza sicuro che sia quel particolare dominio ad essere attaccato. Tuttavia, non riesco a trovare attività sospette nel registro di accesso di Apache. Dove vado da qui?

edit1: Qualcuno ha qualche suggerimento su come posso scoprire se un utente ha il pieno controllo del mio account www-data o se passa attraverso le chiamate HTTP a un file PHP?

Modifica2: trovato questo nugget di un file durante la ricerca di file PHP modificati nelle ultime 48 ore (I aveva modificato personalmente zero).

sistema:

  • Ubuntu 12.04 LTS in esecuzione su Amazon EC2
  • Versione PHP: 5.3.10-1ubuntu3.2 con Suhosin-Patch (cli) (compilato: 13 giugno 2012 17:19:58)
  • Versione di Apache2: 2.2.22
  • Sito Web che esegue il sistema PHP Fusion CMS v7.01.01
posta Nilzor 04.02.2014 - 20:34
fonte

2 risposte

3

Dal tuo aggiornamento direi che la fusione PHP è il problema qui. Sembra che ci sia una vasta gamma di vulnerabilità per le versioni più recenti di quella che include SQL Injection e altre cose piuttosto ad alto rischio (informazioni di esempio qui ), quindi è ragionevole presumere che anche quello che stai usando sia vulnerabile ...

Quindi è probabile che i tuoi aggressori abbiano accesso al tuo server in questo modo con almeno i privilegi dell'utente del server web.

A questo punto devi veramente ricostruire il server poiché è molto difficile pulire in modo efficace qualcuno dal tuo sistema senza sapere esattamente cosa hanno fatto (ad esempio, mettere i rootkit sul sistema)

Se hai dei backup da prima che il problema si avvii, potresti lavorare da quello, anche se potrebbe essere difficile dire esattamente quando hanno avuto accesso.

Il punto chiave sarebbe garantire di avere versioni completamente aggiornate di tutto il software che si utilizza e assicurarsi di mantenere aggiornato il CMS in quanto possono essere punti di attacco comuni.

Sembra anche che ci siano dei consigli sulle pagine di php fusion ( qui ) sul recupero da questo tipo di attacco

    
risposta data 04.02.2014 - 20:56
fonte
1

Sono riuscito a rintracciare i file senza ricostruire l'intero server che sono  invio di email di spam. Questo probabilmente sta accadendo a causa di qualsiasi script PHP che sia in esecuzione sul tuo server. Di solito gli hacker stanno implementando questi script che sono usando i metodi eval () per eseguire il codice di posta php in modo casuale.

Ho trovato file con nome come

  • db.php
  • functions90.php
  • page35.php
  • start.pgp
  • system31.php
  • template.php
  • title.php

Come ho trovato questi file? Ho abilitato l'opzione Debug per ssmtp aggiungendo una riga nel file ssmtp.config DEBUG = YES . Poi sono passato a /var/logs/mail.log e ho trovato alcuni contenuti come:

<[email protected]>
Jun 21 10:22:54 megatron sSMTP[19726]: To: [email protected]
Jun 21 10:22:54 megatron sSMTP[19726]: Subject: I've been thinking of you
Jun 21 10:22:54 megatron sSMTP[19726]: X-PHP-Originating-Script: 1002:db.php(1965) : eval()'d code
Jun 21 10:22:54 megatron sSMTP[19726]: Date: Tue, 21 Jun 2016 10:22:54 +0100
Jun 21 10:22:54 megatron sSMTP[19726]: Message-ID: <[email protected]>
Jun 21 10:22:54 megatron sSMTP[19726]: X-Priority: 3
Jun 21 10:22:54 megatron sSMTP[19726]: MIME-Version: 1.0
Jun 21 10:22:54 megatron sSMTP[19726]: Content-Type: multipart/alternative;#015#012#011boundary="b1_a27900aabf9e492a7f0f180afaa7902f"
Jun 21 10:22:54 megatron sSMTP[19726]: Content-Transfer-Encoding: 8bit
Jun 21 10:22:54 megatron sSMTP[19726]: 
Jun 21 10:22:54 megatron sSMTP[19726]: --b1_a27900aabf9e492a7f0f180afaa7902f
Jun 21 10:22:54 megatron sSMTP[19726]: Content-Type: text/plain; charset=us-ascii
Jun 21 10:22:54 megatron sSMTP[19726]: 
Jun 21 10:22:54 megatron sSMTP[19726]: Wanna play with my vibrator in my bedroom?
Jun 21 10:22:54 megatron sSMTP[19726]: 
Jun 21 10:22:54 megatron sSMTP[19726]: Don't break my heart, sweetie!
Jun 21 10:22:54 megatron sSMTP[19726]: 
Jun 21 10:22:54 megatron sSMTP[19726]: Aren't you going to ignore me?
Jun 21 10:22:54 megatron sSMTP[19726]: 

Ora se guardi da vicino la quarta riga del registro di debug X-PHP-Originating-Script: mostra che db.php sta eseguendo questo script usando eval()'d code .

Soluzione:
Ho annotato tutti i file trovati nei log e li ho trovati usando %codice% ed elimina tutti i file effettuando un backup. Dopo aver eliminato i file nel registro di ricerca dei file, ho ricontrollato tutte le autorizzazioni delle mie cartelle.

Devi controllare di nuovo tutte le autorizzazioni della cartella www e conservare la maggior parte di esse in 755 o 644. Se stai caricando file utilizzando il sito Web, ti preghiamo di non caricare file eseguibili di php, sh o sul lato server.

    
risposta data 21.06.2016 - 14:04
fonte

Leggi altre domande sui tag