Domanda:
Come indagare su un file sconosciuto da 1,5 GB denominato "sudo" nella mia home directory di Linux?
Karlo Licudine
2019-08-29 05:56:33 UTC
view on stackexchange narkive permalink

Ho trovato un file nella mia home directory chiamato "sudo". Ha una dimensione di 1,5 GB e non ho idea da dove provenga. 

  -rw-r - r-- 1 foo foo 1598296064 9 agosto 11:22 sudo

Qualcuno ha qualche suggerimento su come procedere investigando questo file? Temo che il mio computer possa essere compromesso, ma voglio comunque sapere con cosa ho a che fare.

Ecco cosa ho fatto finora:

  • Esecuzione di file sudo mostra "sudo: data".
  • L'esecuzione di stringhe sudo ha mostrato una grande quantità di dati casuali.
  • Esecuzione di which sudo punta al file sudo in /usr/bin/sudo

Se è un binario eseguibile Ho intenzione di eseguirlo ma potrei trasferirlo su una macchina virtuale prima di farlo. Ho una conoscenza limitata di gdb quindi almeno posso esaminarlo.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/98125/discussion-on-question-by-karlo-licudine-how-to-investigate-an-unknown-1-5gb-fil).
Nota che `which sudo` non fa _qualcosa_ con il file nella directory corrente chiamato` sudo` e darà quel risultato da _any_ cartella.Cerca solo tutte le diverse posizioni del tuo percorso e ti dice quale userebbe se eseguissi il comando `sudo` in questo momento.
Basta aprirlo in un visualizzatore "più visivo", come quello integrato in Midnight Commander o qualcosa di simile e scorrere.È probabile che riconoscerai l'output di "comando fallito" dalla risposta seguente.
Sette risposte:
Conor Mancone
2019-08-29 06:59:33 UTC
view on stackexchange narkive permalink

Probabilmente l'hai fatto per caso con un comando di shell fallito. Ho fatto cose del genere anch'io. Di conseguenza è probabilmente pieno di dati innocui. Ecco alcuni motivi per cui suppongo che non sia dannoso:

  1. 1,5 GB sarebbe un virus estremamente grande. Poiché i virus vengono solitamente trasmessi su una rete, più piccoli è meglio.
  2. Non è eseguibile.
  3. Il malware in genere si nasconde molto meglio di questo.
  4. file pensa che sia solo un file di dati.

Ovviamente niente di tutto ciò dimostra che non sia dannoso (ovvero i virus non hanno essere piccolo, solo perché non è eseguibile non significa che potrebbe non essere parte di un payload dannoso, e talvolta non si preoccupano di nascondersi), ma sospetto che sia innocuo. Probabilmente è troppo vecchio, ma vorrei vedere se la cronologia di bash va al giorno / ora in questione.

Mi rendo conto di non averti dato alcun suggerimento su come analizzare il file, ma tu " abbiamo già raggiunto gli helper principali ( file e strings ) e non hanno aiutato! Un file riempito con dati casuali da un comando errato spiegherebbe ciò che stai vedendo e probabilmente ha maggiori possibilità di generare un file chiamato sudo nella tua home directory rispetto al malware, IMO.

Sono per lo più d'accordo, tranne che `which` troverà solo gli eseguibili nelle directory in` $ PATH` - che non dovrebbe includere né la cartella home né `.` (la directory corrente).Ma in questo caso, `ls -l` mostra che non è contrassegnato come eseguibile.
Probabilmente avevi intenzione di fare `un comando |sudo tee -a something` e finì per eseguire `somecommand> sudo tee -a something`
@ThoriumBR che ha senso.Non ricordo se ho fatto qualcosa del genere però, ma è una possibilità.Ho provato a cercare la mia cronologia bash come suggerito da ConorMancone ma non è andata così lontano.
@KarloLicudine Dovresti essere in grado di controllare la cronologia dei comandi se questa era recente.
@GordonDavisson, grazie, hai ragione sul fatto che "che" non è utile qui.
Non deve nemmeno essere colpa tua.Dopo aver eseguito uno degli script forniti, la mia cartella overpass contiene le seguenti directory vuote: "2", "file", "File_Error", "No", "o" e "tale".
@James Apparentemente è stato 3 settimane fa, guarda l'ora della modifica.
storia |grep "> sudo"
@Jeffrey Da non confondere con history |grep> sudo, che non farebbe che peggiorare il problema.
@Ray lol, questo mi ha fatto impazzire tremendamente
Fortunatamente `storia |grep> sudo` non funzionerebbe effettivamente perché `grep` non verrà eseguito senza un termine di ricerca, ma lo userò.La prossima volta che vedo qualcuno eseguire un comando senza sudo, ma che richiede i permessi di root, suggerirò di eseguire `history |sudo` come soluzione rapida ... MUWAHAHA
@Jeffrey: Supponendo che stiano usando una shell come bash configurata normalmente, control-r per la ricerca inversa interattiva.È una semplice ricerca di testo quindi puoi usare una stringa come `> sudo`.Se stai usando grep potresti voler cercare `>. * Sudo` per trovare quantità variabili di spazi bianchi.
Dopo aver provato tutti i suggerimenti di tutti, ora credo che potrebbe essere stato davvero un comando fallito.Non ricordo esattamente cosa ho fatto, non è inverosimile considerando le attività che ho svolto di recente con la mia macchina.
@Ray `storia |grep> sudo` sembra un'idea terribile.Meglio fare `storia |grep >> sudo`.Quindi, almeno non stai cancellando il contenuto precedente del file che vuoi analizzare ... :-)
@Alderath Sarà più divertente quanto più lo proverai.
@ConorMancone Troncerà il file, rendendolo non investigabile
@Izkata cosa troncherà quale file?
@ConorMancone Nel tuo commento precedente su grep non in esecuzione senza un termine di ricerca, è la shell che esegue il reindirizzamento dell'output e `>` tronca il file indipendentemente dall'errore di grep
@Alderath * Ho * detto che avrebbe peggiorato il problema.:-)
hft
2019-08-29 08:05:41 UTC
view on stackexchange narkive permalink

Qualcuno ha qualche suggerimento su come procedere con la ricerca di questo file?

Poiché file non riconosce i "dati" come eseguibili , sarà difficile provare ad analizzare dinamicamente (eseguendolo) a meno che non si riesca a trovare il punto di ingresso corretto.

Un altro strumento Linux standard che potresti provare è: 

  stat

Questo ti darà un po 'più di informazioni sui metadati rispetto a quello che puoi vedere solo con l'elenco delle directory.

Un altro strumento che potresti provare è: 

  binwalk

che può fornire analisi di file binari come le immagini del firmware. Ad esempio, se il file binario contiene un file system binwalk potrebbe riconoscerlo.

Un altro strumento disponibile gratuitamente su Linux è "The Sleuth Kit". Se il file binario è un'immagine del disco grezzo o dati del file system, puoi provare a elaborarlo con "The Sleuth Kit".

Puoi anche provare a rilasciare il binario in IDA (il " Interactive Disassembler "da Hexrays - è disponibile una versione freeware) per vedere se IDA riesce a capirlo. Ma se file non lo riconosce, non spero troppo che IDA lo faccia.

Ho sentito parlare bene di Ghidra (https://www.nsa.gov/resources/everyone/ghidra/), un analizzatore binario abbastanza buono (e open source).
Ghidra è un'altra buona opzione.È disponibile gratuitamente e può analizzare diversi tipi di file binari.Potrebbe essere in grado di gestire alcune cose che la versione IDA Free non può.L'opzione migliore sarebbe usare l'IDA Pro commerciale, ma è piuttosto costoso.
Dark Matter
2019-08-29 21:56:19 UTC
view on stackexchange narkive permalink

Inizierei con history | grep sudo dal terminale e guarda i comandi sudo più recenti per vedere se ce ne sono di malformati.

  • È la tua directory home.
  • Non hai ha detto che ha una proprietà speciale, quindi presumo che tu lo possieda.
  • È quasi certamente un comando di shell fallito, quindi probabilmente lo hai fatto dal terminale.
  • Potrebbe essere qualcosa creato da uno script ma è piuttosto raro mettere i comandi "sudo" in uno script.
  • Si mostra apertamente e ovviamente quindi probabilmente lo avresti notato se non l'avessi creato di recente.
`storia |grep sudo |wc -l` -> `8343`: p
@ConorMancone Suggerirei "history | grep sudo | tail" ma dubito che ne abbia bisogno.
spyr03
2019-08-29 17:11:28 UTC
view on stackexchange narkive permalink

Penso che le altre risposte coprano già quasi tutto (e abbiano già risolto il mistero). Un'altra cosa da provare se non sei ancora sicuro di eliminarlo è fare un test di urlo. Non otterrai necessariamente una risoluzione per quanto riguarda l'origine del file, ma puoi essere certo che sia sicuro rimuoverlo.

Rinomina il file in qualcos'altro e vedi se succede qualcosa. Alcune cose a cui prestare attenzione sono

  1. Il file viene ricreato. Ciò significa che è stato creato qualcosa di recente e potrebbe essere più facile scoprire cosa attraverso la cronologia oi log di bash.
  2. Qualcosa si blocca. A seconda della frequenza con cui i programmi si bloccano, questo potrebbe essere una falsa pista, ma potrebbe anche essere un suggerimento sulla fonte del file.

Altri metodi per eseguire un test di urlo potrebbero essere rimuovere tutti i permessi di accesso così nessuno può leggere o scrivere nel file o corrompere il file.

MODIFICA

Come sottolinea Daniel, rinominare il file non funzionerà se il processo ha ancora il file aperto. Se il file è aperto puoi vedere tutti i file aperti con lsof , oppure puoi trovare gli id ​​di processo di quei processi che hanno il file aperto usando fuser . ps fornirà quindi ulteriori informazioni sui processi. 

  > fuser sudo / home / bob / sudo: 3132 7070> ps 3132 7070 PID TTY STAT TIME COMMAND 3132? R 203: 50 pdflatex 7070? Sl 0:45 evince
Le app con un handle di file aperto manterranno il file aperto attraverso la ridenominazione, si sposteranno e non si preoccuperanno finché non chiuderà l'handle.
@DanielHill Buon punto.`lsof |grep sudo` in soccorso.Lsof riporterà il nome corrente del file o il nome del file quando è stato aperto?
Se qualcosa lo ha creato di recente, perché il suo tempo di modifica dovrebbe essere quasi 3 settimane fa?
@Barmar Presumo che questo sia un file creato accidentalmente che non è utilizzato.Ma non c'è motivo per cui non possa ancora essere tenuto aperto dal processo che lo ha creato, se il processo dura a lungo e il computer non è stato spento da allora.
Mi stavo solo chiedendo se 3 settimane fa contano come "recentemente".
Penso che tu abbia frainteso.Se un altro file chiamato anche sudo viene creato dopo che l'originale è stato "cancellato" (che è ciò che intendo per ricreato), allora quello sarebbe il file creato di recente da indagare.
Rinominarlo non ha fatto nulla di evidente.Il che significa che non è niente di particolarmente importante?
La modifica delle autorizzazioni è efficace quanto la ridenominazione: non influirà sui descrittori di file aperti, ma solo sui nuovi tentativi di aprire il file.Dovresti essere in grado di usare "lsof" per identificarli, però.
Sam
2019-08-29 22:44:27 UTC
view on stackexchange narkive permalink

Potresti provare "hexdump -C -n 512" per vedere se ti viene fuori qualcosa nel dump binario o ascii. Potrebbe essere una combinazione di dati binari e dati di testo. Come il wget di uno script che hai digitato male, hexdump potrebbe consentirti di vedere parte dello script.

d-b
2019-08-29 19:05:04 UTC
view on stackexchange narkive permalink

Puoi anche provare head e vedere le prime righe del file. I primi caratteri potrebbero rivelare qualcosa sul tipo di file. Vedi numero magico per ulteriori informazioni.

Se il numero magico di questo file fosse noto, file avrebbe indovinato il tipo di file.
Inoltre, rilasciando l'output di `head` nel tuo terminale nudo su un file probabilmente binario ha un'alta probabilità di rovinare il tuo terminale.Ricorda che "head" cerca un certo numero di "righe", che si aspetta siano separate da caratteri di nuova riga.Se non capita di trovare nuove righe nei primi cento MB circa, a `head` non interessa;lascerà cadere tutto quell'output sul tuo terminale, e quali sono le probabilità che non ci siano uscite di terminale lì dentro che potrebbero fare cose come rovinare il tuo prompt dei comandi?Basso. Invece, prova `xxd |meno ».Guarda la discarica esadecimale.
Puoi anche usare head con un conteggio di caratteri, per i binari.
-1
I comandi @d-b al terminale vengono trasmessi in linea.Nessuna quantità di "miglioramento" risolverà questo problema, perché è lo standard.Se scarichi i codici di controllo direttamente nel tuo terminale, il tuo terminale li interpreterà giustamente.
@Score_Under Non ho approfondito questo, ma quando ho usato Digital Unix con CDE negli anni '90 i terminali erano costantemente incasinati mentre questo non accade mai nel terminale Mac OS X.
@d-b Il problema più comune è con sequenze che cambiano il set di caratteri del terminale, quindi forse il terminale Mac OS non supporta il cambio del set di caratteri.Se si `printf '\ 033 (0'`, indica al terminale di cambiare il set di caratteri G0 in caratteri di disegno a linee. Se questa sequenza è in un file ti capita di` cat`, accade la stessa cosa (motivo per cui ilIl modo "strettamente corretto" è usare `less` o qualche altra utilità destinata a visualizzare i file).
@Score_Under printf '\ 033 (0' "ha incasinato" il mio terminale.
Radu Murzea
2019-08-30 18:26:11 UTC
view on stackexchange narkive permalink

Potresti seguire il vecchio metodo semplice: installare un antivirus e scansionare il file. Non è una soluzione perfetta, ma è un punto di partenza e almeno ti darebbe almeno un po 'di tranquillità al riguardo.

In realtà sono un po' sorpreso che nessuno lo abbia suggerito.

Non sono sicuro di quale distribuzione tu stia utilizzando, ma sono sicuro che ci sono molte soluzioni antivirus che funzionerebbero. A prima vista, proverei ClamAV per qualcosa di simile, sembra facile da installare.



ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...