Pytanie:
Jak zbadać nieznany plik 1,5 GB o nazwie „sudo” w moim katalogu domowym Linuksa?
Karlo Licudine
2019-08-29 05:56:33 UTC
view on stackexchange narkive permalink

W moim katalogu domowym znalazłem plik o nazwie „sudo”. Ma 1,5 GB i nie mam pojęcia, skąd się wzięło. 

  -rw-r - r-- 1 foo foo 1598296064 9 sierpnia 11:22

Czy ktoś ma jakieś wskazówki, jak kontynuować badanie tego pliku? Obawiam się, że mój komputer może zostać zagrożony, ale nadal chcę wiedzieć, z czym mam do czynienia.

Oto, co zrobiłem do tej pory:

  • Uruchamianie plik sudo pokazuje `sudo: data '.
  • Uruchomione ciągi sudo pokazały dużą ilość losowych danych.
  • Uruchomienie które sudo wskazuje na plik sudo w /usr/bin/sudo

Jeśli jest to wykonywalny plik binarny Planuję go uruchomić, ale mogę przenieść go na maszynę wirtualną, zanim to zrobię. Mam ograniczoną wiedzę na temat gdb , więc przynajmniej mogę to sprawdzić.

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (https://chat.stackexchange.com/rooms/98125/discussion-on-question-by-karlo-licudine-how-to-investigate-an-unknown-1-5gb-fil).
Zauważ, że `which sudo` nie robi _czegokolwiek_ z plikiem w bieżącym katalogu o nazwie` sudo` i da ten wynik z _dowolnego_ folderu.Po prostu przeszukuje wszystkie twoje różne lokalizacje twojej ścieżki i mówi ci, której z nich użyje, jeśli uruchomisz teraz polecenie `sudo`.
Po prostu otwórz go w jakiejś „bardziej wizualnej” przeglądarce, np. Wbudowanej w Midnight Commander lub podobnej i przewiń.Jest szansa, że rozpoznasz wynik „nieudanego polecenia” z odpowiedzi poniżej.
Siedem odpowiedzi:
Conor Mancone
2019-08-29 06:59:33 UTC
view on stackexchange narkive permalink

Prawdopodobnie zrobiłeś to przez przypadek, używając nieudanego polecenia powłoki. Sam robiłem takie rzeczy. W rezultacie jest prawdopodobnie wypełniony nieszkodliwymi danymi. Oto kilka powodów, dla których sądzę, że jest on nie złośliwy:

  1. 1,5 GB byłby bardzo dużym wirusem. Ponieważ wirusy są zwykle przesyłane przez sieć, mniejsze oznacza lepsze.
  2. To nie jest plik wykonywalny.
  3. Złośliwe oprogramowanie zazwyczaj ukrywa się znacznie lepiej niż to.
  4. plik uważa, że ​​to tylko plik danych.

Oczywiście nic z tego nie dowodzi, że nie jest złośliwy (czyli wirusy nie mają jest mały, tylko dlatego, że nie jest wykonywalny, nie oznacza, że ​​może nie być częścią złośliwego ładunku, a czasami nie zawracają sobie głowy ukrywaniem), ale podejrzewam, że jest to nieszkodliwe. Jest to prawdopodobnie za stare, ale chciałbym sprawdzić, czy twoja historia bash idzie do danego dnia / godziny.

Zdaję sobie sprawę, że nie dałem ci żadnych wskazówek, jak analizować plik, ale ty już trafiliśmy do głównych pomocników ( file i strings ) i nie pomogli! Plik wypełniony losowymi danymi z błędnego polecenia wyjaśniłby, co widzisz, i prawdopodobnie ma większą szansę na wygenerowanie pliku o nazwie sudo w twoim katalogu domowym niż robi to złośliwe oprogramowanie, IMO.

W większości się zgadzam, z wyjątkiem tego, że `który` znajdzie pliki wykonywalne tylko w katalogach w` $ PATH` - który nie powinien zawierać ani katalogu domowego, ani `.` (bieżącego katalogu).Ale w tym przypadku, `ls -l` pokazuje, że nie jest oznaczony jako wykonywalny.
Prawdopodobnie zamierzałeś wykonać `jakąś komendę |sudo tee -a something` i zakończyło się uruchomieniem `somecommand> sudo tee -a something`
@ThoriumBR, to ma sens.Nie pamiętam, czy zrobiłem coś takiego, ale jest taka możliwość.Próbowałem przeszukać moją historię basha, zgodnie z sugestią ConorMancone, ale to nie idzie tak daleko.
@KarloLicudine Powinieneś być w stanie sprawdzić historię poleceń, jeśli było to niedawne.
@GordonDavisson, dzięki, masz rację co do tego, że argument „który” nie jest tutaj pomocny.
Nie musi to być nawet twoja wina.Po uruchomieniu jednego z dostarczonych skryptów mój folder overpass zawiera następujące puste katalogi: „2”, „file”, „File_Error”, „No”, „lub” i „such”.
@James To było podobno 3 tygodnie temu, spójrz na czas modyfikacji.
historia |grep "> sudo"
@Jeffrey Nie mylić z historią |grep> sudo, co tylko pogorszyłoby problem.
@Ray lol, to bardzo mnie złamało
Na szczęście `historia |grep> sudo` w rzeczywistości nie zadziała, ponieważ `grep` nie będzie działać bez wyszukiwanego hasła, ale zamierzam z nim działać.Następnym razem, gdy zobaczę, jak ktoś uruchamia polecenie bez sudo, ale które wymaga uprawnień roota, zasugeruję tylko, aby uruchomił `history |sudo` jako szybka naprawa ... MUWAHAHA
@Jeffrey: Zakładając, że używają powłoki takiej jak bash skonfigurowanej normalnie, control-r do interaktywnego wyszukiwania wstecznego.Jest to proste wyszukiwanie tekstowe, więc możesz użyć ciągu, takiego jak `> sudo`.Jeśli używasz grep, możesz chcieć wyszukać `>. * Sudo`, aby znaleźć zmienne ilości białych znaków.
Po wypróbowaniu wszystkich sugestii od wszystkich, teraz uważam, że mogło to być naprawdę nieudane polecenie.Nie pamiętam dokładnie, co zrobiłem, to nie jest przesadne, biorąc pod uwagę czynności, które ostatnio wykonywałem na mojej maszynie.
@Ray `historia |grep> sudo` wydaje się okropnym pomysłem.Lepiej zrobić `historię |grep >> sudo`.W takim razie przynajmniej nie usuwasz poprzedniej zawartości pliku, który chcesz przeanalizować ... :-)
@Alderath Im więcej spróbujesz, tym będzie fajniej.
-1
-1
@ConorMancone W twoim poprzednim komentarzu o tym, że grep nie działa bez wyszukiwanego hasła, to powłoka wykonuje przekierowanie wyjścia i `>` obcina plik niezależnie od tego, czy wystąpiły błędy grep
@Alderath * Powiedziałem *, że to pogorszy problem.:-)
hft
2019-08-29 08:05:41 UTC
view on stackexchange narkive permalink

Czy ktoś ma jakieś wskazówki, jak kontynuować badanie tego pliku?

Ponieważ plik nie rozpoznaje „danych” jako pliku wykonywalnego , trudno będzie spróbować przeprowadzić analizę dynamiczną (uruchamiając ją), chyba że znajdziesz odpowiedni punkt wejścia.

Innym standardowym narzędziem Linuksa, które możesz wypróbować, jest: 

  stat

To da ci trochę więcej informacji o metadanych niż co możesz zobaczyć tylko z listą katalogów.

Innym narzędziem, które możesz wypróbować, jest: 

  binwalk

, które umożliwia analizę plików binarnych, takich jak obrazy oprogramowania sprzętowego. Na przykład, jeśli plik binarny zawiera system plików, binwalk może go rozpoznać.

Jeszcze innym darmowym narzędziem w Linuksie jest „The Sleuth Kit”. Jeśli plik binarny jest nieprzetworzonym obrazem dysku lub danymi systemu plików, możesz spróbować przetworzyć go za pomocą „The Sleuth Kit”.

Możesz także spróbować upuścić plik binarny do IDA („ Interactive Disassembler ”firmy Hexrays - dostępna jest darmowa wersja), aby sprawdzić, czy IDA może to zrozumieć. Ale jeśli plik go nie rozpoznaje, nie mam nadziei, że IDA to zrobi.

Słyszałem dobre rzeczy o Ghidrze (https://www.nsa.gov/resources/everyone/ghidra/), całkiem niezłym (i otwartym źródle) analizatorze binarnym.
Ghidra to kolejna dobra opcja.Jest dostępny bezpłatnie i może analizować wiele różnych typów plików binarnych.Może poradzić sobie z niektórymi rzeczami, których wersja IDA Free nie może.Najlepszą opcją byłoby użycie komercyjnego IDA Pro, ale jest to dość drogie.
Dark Matter
2019-08-29 21:56:19 UTC
view on stackexchange narkive permalink

Zacząłbym od history | grep sudo z terminala i spójrz na najnowsze polecenia sudo, aby sprawdzić, czy któreś z nich nie jest zniekształcone.

  • To twój katalog domowy.
  • Nie masz powiedział, że ma specjalną własność, więc zakładam, że jesteś jego właścicielem.
  • Prawie na pewno jest to nieudane polecenie powłoki, więc prawdopodobnie zostało wykonane z terminala.
  • Może to być coś stworzonego przez skrypt, ale dość rzadko umieszcza się polecenia „sudo” w skrypcie.
  • Wyświetla się otwarcie i oczywiście, więc prawdopodobnie byś to zauważył, gdybyś nie tworzył ostatnio.
`historia |grep sudo |wc -l` -> `8343`: p
@ConorMancone Proponuję "history | grep sudo | tail", ale wątpię, żeby tego potrzebował.
spyr03
2019-08-29 17:11:28 UTC
view on stackexchange narkive permalink

Myślę, że inne odpowiedzi obejmują już prawie wszystko (i już rozwiązały zagadkę). Jedną dodatkową rzeczą do wypróbowania, jeśli nadal nie masz pewności co do usunięcia, jest wykonanie testu krzyku. Niekoniecznie uzyskasz rozdzielczość co do źródła pliku, ale możesz mieć pewność, że można go bezpiecznie usunąć.

Zmień nazwę pliku na inną i zobacz, czy coś się stanie. Należy zwrócić uwagę na

  1. Plik został odtworzony. Oznacza to, że coś niedawno się udało i może być łatwiej dowiedzieć się, co za pomocą historii basha lub dzienników.
  2. Coś się zawiesza. W zależności od tego, jak często programy się zawieszają, może to być czerwony ślad, ale może to być również wskazówka co do źródła pliku.

Inną metodą wykonania testu krzyku byłoby usunięcie wszystkich uprawnień dostępu więc nikt nie może czytać ani zapisywać w pliku ani go uszkodzić.

EDYTUJ

Jak zauważył Daniel, zmiana nazwy pliku nie zadziała jeśli proces nadal ma otwarty plik. Jeśli plik jest otwarty, możesz zobaczyć wszystkie otwarte pliki za pomocą lsof lub możesz znaleźć identyfikatory procesów tych procesów, które mają otwarty plik za pomocą fuser . ps poda wtedy więcej informacji o procesach. 

  > 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
Aplikacje z otwartym uchwytem pliku utrzymają plik otwarty przez zmianę nazwy, przenoszenie i nie będą się tym przejmować, dopóki nie zamknie uchwytu.
@DanielHill Słuszna uwaga.`lsof |grep sudo` na ratunek.Czy lsof poda aktualną nazwę pliku lub nazwę pliku w momencie jego otwarcia?
Jeśli coś go niedawno stworzyło, dlaczego czas jego modyfikacji miałby być prawie 3 tygodnie temu?
@Barmar Zakładam, że jest to przypadkowo utworzony plik, który jest nieużywany.Ale nie ma powodu, dla którego proces, który go stworzył, nie mógł go nadal utrzymywać w stanie otwartym, jeśli proces jest długotrwały, a komputer nie został od tego czasu zamknięty.
Właśnie się zastanawiałem, czy 3 tygodnie temu liczy się jako „niedawno”.
Myślę, że źle zrozumiałeś.Jeśli inny plik, również nazywany sudo, zostanie utworzony po „usunięciu” oryginału (co mam na myśli przez odtworzenie), będzie to nowo utworzony plik do zbadania.
Zmiana nazwy nie dała nic zauważalnego.Co oznacza, że nie jest to nic szczególnie ważnego?
Zmiana uprawnień jest tak skuteczna, jak zmiana nazwy - nie wpłynie to na żadne otwarte deskryptory plików, a jedynie na nowe próby otwarcia pliku.Powinieneś być jednak w stanie użyć lsof, aby je zidentyfikować.
Sam
2019-08-29 22:44:27 UTC
view on stackexchange narkive permalink

Możesz spróbować "hexdump -C -n 512", aby zobaczyć, czy coś wyskoczy na ciebie w binarnym lub ascii. Może to być mieszanka danych binarnych i danych tekstowych. Podobnie jak wget skryptu, który błędnie wpisałeś, zrzut heksowy może pozwolić ci zobaczyć część skryptu.

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

Możesz także wypróbować head i zobaczyć kilka pierwszych wierszy pliku. Kilka pierwszych znaków może ujawnić coś na temat typu pliku. Zobacz magiczną liczbę, aby uzyskać więcej informacji.

Gdyby magiczna liczba tego pliku była dobrze znana, plik odgadłby typ pliku.
Ponadto upuszczenie wyjścia `head` do czystego terminala w prawdopodobnie pliku binarnym ma duże prawdopodobieństwo zepsucia terminala.Pamiętaj, że nagłówek „head” szuka pewnej liczby „linii”, które według oczekiwań będą oddzielone znakami nowej linii.Jeśli nie znajdzie żadnych nowych linii w pierwszych stu MB lub więcej, argument „head” to nie obchodzi;po prostu upuści wszystkie te dane wyjściowe na twoim terminalu i jakie są szanse, że nie ma tam żadnych znaków ucieczki terminala, które mogłyby zepsuć twój wiersz poleceń?Niska. Zamiast tego wypróbuj `xxd |mniej ".Spójrz na zrzut heksa.
Możesz także użyć head z liczbą znaków dla plików binarnych.
Zepsucie terminali @guenthmonstr było czymś, czego doświadczyłem w latach 90.Zdobądź lepszego klienta.
Polecenia @d-b do terminala są przesyłane w linii.Żadna „lepszość” tego nie naprawi, ponieważ jest to standard.Jeśli zrzucisz kody kontrolne bezpośrednio do swojego terminala, to Twój terminal słusznie je zinterpretuje.
@Score_Under Nie zagłębiałem się w to, ale kiedy używałem cyfrowego Unixa z CDE w latach 90-tych, terminale były stale pomieszane, podczas gdy to nigdy się nie zdarza w terminalu Mac OS X.
@d-b Najczęstszym problemem są sekwencje, które zmieniają zestaw znaków terminala, więc być może terminal Mac OS nie obsługuje przełączania zestawu znaków.Jeśli wykonasz `printf '\ 033 (0'`, to instruuje terminal, aby zmienił zestaw znaków G0 na znaki rysowania linii. Jeśli ta sekwencja znajduje się w pliku, zdarza się, że dzieje się tak samo (dlatego„ściśle poprawnym” sposobem jest użycie „less” lub innego narzędzia przeznaczonego do wyświetlania plików).
@Score_Under printf '\ 033 (0' "pomieszane" w moim terminalu.
Radu Murzea
2019-08-30 18:26:11 UTC
view on stackexchange narkive permalink

Mógłbyś pójść w prosty, stary sposób: zainstalować program antywirusowy i przeskanować plik. To nie jest idealne rozwiązanie, ale jest to miejsce, od którego można zacząć i przynajmniej dałoby ci to przynajmniej trochę spokoju.

Właściwie jestem trochę zaskoczony, że nikt tego nie zasugerował.

Nie jestem pewien, na jakiej dystrybucji się znajdujesz, ale jestem pewien, że istnieje wiele rozwiązań antywirusowych, które będą działać. Nie mogę się doczekać, aby ClamAV spróbował czegoś takiego, wydaje się łatwe do zainstalowania.



ⓘ
To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 4.0, w ramach której jest rozpowszechniana.
Loading...