Trovato 0000 File di autorizzazione su un server compromesso

0

È stata una lunga settimana a provare, a volte quando posso, a capire cosa sta succedendo su un server / sito web che sto mantenendo. Il sito è stato precedentemente compromesso, presumibilmente ripulito dai precedenti proprietari, e al momento del trasferimento, entro poche ore, è stato nuovamente compromesso.

Ad ogni modo, la domanda: se ci sono 0000 file di permessi sul server, posso supporre che l'hacker abbia accesso root?

(Non ho nemmeno accesso root ...)

Per chiarezza da un commento qui sotto: "Ma quello che intendevo era, perché un intruso avrebbe creato un file 0000? Immagino che a un certo punto volessero accedere al file. Quindi, se facessero questo file, lo farei immagina che sarebbe sicuro supporre di avere accesso root? "

[UPDATE] Nel caso in cui non fosse chiaro, questo sito è stato pubblicato da un altro server all'incirca a metà maggio. Sono tornato indietro e ho controllato i log, e poche ore dopo che il sito è andato in diretta ho visto un POST sospetto su un URL di un'applicazione che avrebbe dovuto restituire un 404. Dopo aver controllato, quel file era una backdoor; era timestamped allo stesso tempo del resto dei file. Quindi è lecito ritenere che il sito sia arrivato a noi in backdoor (altre backdoor avevano timestamp più recenti). Quindi ho trollato i file di log e scansionato le directory e trovato le backdoor.

Creeremo un nuovo account per questo sito e sposteremo i file puliti. Sto ancora confermando con i vecchi amministratori, ma sembrerebbe che pensassero che l'hack fosse limitato al "blog" (WP) e non aveva controllato l'app del sito principale per malignità ...

    
posta Mike 03.06.2016 - 18:15
fonte

1 risposta

5

Se il tuo server è stato compromesso, allora presume che abbiano accesso root . Anche se sembra che tu abbia rimosso gli script di shell offensivi (che molte volte è tutto ciò che comporta "ripulire"), è del tutto possibile per loro scavare più a fondo nel sistema. Non hai idea di quali exploit esistono per il software server, quindi è del tutto possibile che caricare un semplice script di shell php possa portare a un compromesso completo del sistema operativo o peggio.

Sei corretto che 000 permessi permettano solo a un superutente (root è, di default, un superutente) di apportare modifiche a quel file. Tuttavia, tieni presente che un utente non superutente può eliminare il file e caricare la propria copia al suo posto, purché disponga delle autorizzazioni di scrittura + esecuzione nella directory che lo contiene.

Per quanto riguarda il motivo per cui potrebbero farlo, dipende molto dal contesto del file in questione. In gran parte, potrebbe essere suddiviso in due categorie:

  • Il file è pensato per essere bloccato e lasciato solo.
    • Questo probabilmente causerebbe un Denial-of-Service a qualsiasi cosa dipenda da quel file.
    • Questo potrebbe anche essere un tentativo di mettere in quarantena il file, senza necessariamente eliminarlo. Quindi, il superutente potrebbe aprire il file in modo sicuro (leggi) per esaminarlo, inviarlo a un altro servizio per analisi, ecc ...
  • Il file deve essere bloccato per ora .
    • Con i diritti di superutente, l'utente malintenzionato potrebbe successivamente modificare le autorizzazioni per eseguire il file.
    • Senza i diritti di superutente, l'autore dell'attacco potrebbe successivamente eliminare il file e sostituirlo con il proprio.

Realisticamente parlando, ho dei dubbi sul fatto che ti reingoccheranno nello stesso modo ovvio se avessero una penetrazione più profonda del tuo server. D'altra parte, non abbiamo idea di quale tipo di intrigo gli abbiano a disposizione sul secondo go-around, o in futuro mentre hanno ancora accesso. Pertanto è più sicuro assumere lo scenario peggiore fino a prova contraria.

Mentre possiamo indovinare il motivo per cui stiamo osservando questo comportamento specifico, non ritengo che valga la pena dedicare il tuo tempo a investigarlo personalmente. Contatta il tuo fornitore di servizi di hosting, fai sapere loro cosa è successo (ovvero ciò che ci hai descritto qui), e fagli analizzare il problema. Potrebbero disporre di un ulteriore logging / auditing a loro disposizione, e se tutto il resto fallisce, potrebbero adottare l'approccio LOIC standard ai sistemi compromessi.

    
risposta data 03.06.2016 - 20:43
fonte

Leggi altre domande sui tag