Nowe posty

Autor Wątek: Czy mój ls to malware, czy nie malware  (Przeczytany 2296 razy)

Offline 920806

  • Users
  • Stały bywalec
  • ***
  • Wiadomości: 130
    • Zobacz profil
Czy mój ls to malware, czy nie malware
« dnia: 2019-11-18, 21:12:40 »
Hej,

Mam taka zagwozdkę. Chciałbym móc jednoznacznie określić, czy np. dany plik/program - załóżmy ls - jest takim ls'em, za jakiego go uważam ;).
Suma kontrolna może być w tym przypadku myląca (jeśli nie miałem jej gdzieś zapisanej tuż po świeżej instalacji systemu z oficjalnego źródła).

Nie biorę pod uwagę analizy ruchu sieciowego , czy jakiegoś RE.
Steve Wozniak nie wiedział .. ~ ~ https://www.youtube.com/watch?v=FG1AQcGGSec ~~ / "Uparty jak nigdy" /P3@CE , L0\/E & rock'|\|'roII

Offline marcin'82

  • Users
  • Prawie jak Guru
  • ****
  • Wiadomości: 402
    • Zobacz profil
Odp: Czy mój ls to malware, czy nie malware
« Odpowiedź #1 dnia: 2019-11-18, 21:16:13 »
Jaki system?
marcin82

Offline 920806

  • Users
  • Stały bywalec
  • ***
  • Wiadomości: 130
    • Zobacz profil
Odp: Czy mój ls to malware, czy nie malware
« Odpowiedź #2 dnia: 2019-11-18, 21:16:49 »
aj, najważniejsze ... Debian :) chcesz wersje ?
Steve Wozniak nie wiedział .. ~ ~ https://www.youtube.com/watch?v=FG1AQcGGSec ~~ / "Uparty jak nigdy" /P3@CE , L0\/E & rock'|\|'roII

Offline pavbaranov

  • Users
  • Guru
  • *****
  • Wiadomości: 878
    • Zobacz profil
Odp: Czy mój ls to malware, czy nie malware
« Odpowiedź #3 dnia: 2019-11-18, 21:42:10 »
Możesz w sposób bardziej jednoznaczny zadać pytanie? Z tego co wątek zapowiada - nic nie wynika.

Offline Paweł Kraszewski

  • Administrator
  • Guru
  • *****
  • Wiadomości: 3047
  • Lenistwo jest matką potrzeby = babcią wynalazku
    • Zobacz profil
Odp: Czy mój ls to malware, czy nie malware
« Odpowiedź #4 dnia: 2019-11-18, 21:50:01 »
Pakiet debsums, choć bardziej zaawansowany malware potrafi dla takich narzędzi pokazać oryginalny pilik.
Paweł Kraszewski
~Arch/Void/Gentoo/FreeBSD/OpenBSD/Specjalizowane customy

Offline 920806

  • Users
  • Stały bywalec
  • ***
  • Wiadomości: 130
    • Zobacz profil
Odp: Czy mój ls to malware, czy nie malware
« Odpowiedź #5 dnia: 2019-11-18, 22:32:49 »
Możesz w sposób bardziej jednoznaczny zadać pytanie? Z tego co wątek zapowiada - nic nie wynika.

Nic nie zapowiada, bo nie ma nic na rzeczy :). Nie robiłem analizy ruchu sieciowego, ani nie zaobserwowałem żadnych podejrzanych zachowań.

Jednoznaczne pytanie: czy jest jakaś JEDNOZNACZNA informacja zaszyta gdzieś w systemie Linux, która potrafiła by wskazać, że program - przykładowy ls- nie jest tym za którego go uważamy. Nie mam pomysłu , na bardziej dokładne pytanie ;)
« Ostatnia zmiana: 2019-11-18, 22:41:56 wysłana przez 920806 »
Steve Wozniak nie wiedział .. ~ ~ https://www.youtube.com/watch?v=FG1AQcGGSec ~~ / "Uparty jak nigdy" /P3@CE , L0\/E & rock'|\|'roII

Offline 920806

  • Users
  • Stały bywalec
  • ***
  • Wiadomości: 130
    • Zobacz profil
Odp: Czy mój ls to malware, czy nie malware
« Odpowiedź #6 dnia: 2019-11-18, 22:45:08 »
Pakiet debsums, choć bardziej zaawansowany malware potrafi dla takich narzędzi pokazać oryginalny pilik.

Wygląda na to, że zostaje nam tylko inżynieria wsteczna lub baczne obserwowanie zachowania programu. Wiem że to nie odpowiednie forum, ale porównując taką hipotetyczną sytuacje , to Windows ma lepsze zabezpieczenia pod tym względem ? czy nie ma sensu porównywać bezp.Windowsa do bezp.Linuxa?

edit:

Jedyne co mi przychodzi do głowy to sprawdzenie ostatniej modyfikacji pliku, przy użyciu stat
« Ostatnia zmiana: 2019-11-18, 22:59:45 wysłana przez 920806 »
Steve Wozniak nie wiedział .. ~ ~ https://www.youtube.com/watch?v=FG1AQcGGSec ~~ / "Uparty jak nigdy" /P3@CE , L0\/E & rock'|\|'roII

Offline 1709

  • Users
  • Guru
  • *****
  • Wiadomości: 2757
  • 1709
    • Zobacz profil
Odp: Czy mój ls to malware, czy nie malware
« Odpowiedź #7 dnia: 2019-11-18, 23:48:10 »
1. Zdanie jest trochę nie jasne
Cytuj
Suma kontrolna może być w tym przypadku myląca (jeśli nie miałem jej gdzieś zapisanej tuż po świeżej instalacji systemu z oficjalnego źródła).
Zgaduje ze myląca masz na mysli zainstalowanie np. rkhunter , AIDE , ...  i stworzenie bazy poczatkowej.
Wtedy masz racje, aczkolwiek nie mam pewności czy któreś z narzędzi nie da Ci ostrzeżenia jeśli suma kontrolna w bazie danych pakietów jest inna niż suma kontrolna pliku w systemie.


2. Wydaje mi się ze nie rozumiesz istoty problemu.

2.1 - md5
Dziewczyna widać już tego nie aktualizuje, ale ta tabelka świetnie pokazuje
* dlaczego md5 nie jest uważane zbyt bezpieczne
* ze algorytmy padają jak muchy :D
http://valerieaurora.org/hash.html

2.2 - kolizje
Jak przeczytasz o wspomnianych kolizjach, to uznasz ze idealne algorytmy nie istnieją,
wiec żeby być pewnym w 100% musisz po prostu pobrać plik i sprawdzić plik bit po bicie.
https://www.dobreprogramy.pl/Dwa-gwozdzie-do-trumny-SHA1-wbite-w-SVN.-Linus-mowi-jednak-bez-paniki,News,79420.html
https://en.wikipedia.org/wiki/Collision_(computer_science)

Wiec wspomniane programy radzą sobie poprzez zbieranie jak największej liczby informacji o pakietach i informują o wszelkich anomaliach.
Poziom bezpieczeństwa prawdopodobnie wybierasz w plikach konfiguracyjnych.

Jeśli założymy ze komenda ls jest już zainfekowana to sprawdzanie z pod tego systemu mija się z celem jak by się on nie nazywał.
Dlatego zainfekowane systemy sprawdza się innym systemem  np. z live-cd.
Możesz np. napisać sobie skrypt w bash-u który pobierze każdy pakiet po kolei, sprawdzając każdy plik hashem lub bit po bicie.

Edytowane
Mogę polecić komendę cmp do sprawdzania pojedynczych plików.
https://www.computerhope.com/unix/ucmp.htm
Co do kontroli wszystkich plików np. poprzez sprawdzanie sum z bazy danych, lub skorzystanie z opcji w systemie która zapewne już istnieje
to w chwili obecnej nie mam pomysłu jak to zrobić inaczej niż wyżej wspomniano.
Możesz spróbować spytać developerów swojego systemu, być może wiedza jak,
bo menadżer plików na pewno sprawdza sumy kontrolne gdy pobierasz pakiet.
Możesz sam tez poczytać np. o apt-cache jakie informacje o pakietach możesz wyciągnąć z bazy danych.
« Ostatnia zmiana: 2019-11-19, 00:13:57 wysłana przez 1709 »
PS: Brak polskiej czcionki, nie jest to brak lenistwa, a jej brak w systemie i brak czasu na reczne poprawki.

Offline 920806

  • Users
  • Stały bywalec
  • ***
  • Wiadomości: 130
    • Zobacz profil
Odp: Czy mój ls to malware, czy nie malware
« Odpowiedź #8 dnia: 2019-11-19, 00:04:55 »
Cytuj
Zgaduje ze myląca masz na mysli zainstalowanie np. rkhunter , AIDE , ...  i stworzenie bazy poczatkowej.

Tak, sugerowałem się troszkę rkhunterem i też moja własna refleksja .

Wiesz co , wszystko co wspomniałeś o md5 jest mi znane. Po prostu zastanawiałem się, czy jest coś ,co umknęło mi na etapie mojej edukacji o Linuxach ;)

Najcenniejsza informacja dla mnie to te zdanie :
Cytuj
Dlatego zainfekowane systemy sprawdza się innym systemem  np. z live-cd.
Możesz np. napisać sobie skrypt w bash-u który pobierze każdy pakiet po kolei, sprawdzajac każdy plik hashem lub bit po bicie.

dzięki za lekkie rozjaśnienie :D
Steve Wozniak nie wiedział .. ~ ~ https://www.youtube.com/watch?v=FG1AQcGGSec ~~ / "Uparty jak nigdy" /P3@CE , L0\/E & rock'|\|'roII

Offline 1709

  • Users
  • Guru
  • *****
  • Wiadomości: 2757
  • 1709
    • Zobacz profil
Odp: Czy mój ls to malware, czy nie malware
« Odpowiedź #9 dnia: 2019-11-19, 07:55:07 »
Pytanie wydaje mi się "w miarę proste" i pewnie oczekiwano także prostej odpowiedzi.
Ale temat bezpieczeństwa systemu jest trochę bardziej rozległy.
Jeśli zanudzam to proszę pominąć mój post ...

Więc gdyby kogoś interesował trochę szerszy zakres tematu to polecam jeszcze trochę poszukać i poczytać, np.
1. Czy skompilowany plik binarny odzwierciedla kod źródłowy?
2. Czy repozytorium główne jest identyczne z innymi repozytoriami?
3. Czy nie dochodzi np. oszukania pakietu w trakcie przesyłania pakietu.

Ad. 1. Czy skompilowany plik binarny odzwierciedla kod źródłowy?
  Chyba najlepiej jest to opowiedziane w temacie " Reproducible builds "
https://www.youtube.com/watch?v=JmHRfT9MeiA

Ad. 2. Czy repozytorium główne jest identyczne z innymi repozytoriami?
Nie posiadam na ten temat wiedzy jak działa system Debian. Ale wspomniałem że pliki można pobrać i zweryfikować bit po bicie.
Znalazłem taki trochę pomocny temat
https://serverfault.com/questions/322518/can-dpkg-verify-files-from-an-installed-package
oraz ciekawą informacje w  https://www.commandlinux.com/man-page/man8/apt-secure.8.html
W linku niżej są linki np. do dokumentacji Debiana https://www.debian.org/doc/manuals/securing-debian-howto/ch7

Przykładowo mogę sprawdzić plik ls na Mincie. ( pomijając że powinienem to zrobić np. z live-cd )
# locate ls | grep "bin/ls"$
/bin/ls
/usr/lib/klibc/bin/ls

##  Sam sie zdziwiłem ze mam dwa pliki ls w systemie :D Wiec dla pewności sprawdziłem który plik uruchamiam.

# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

## Dla pewności sprawdziłem także na koncie użytkownika, więc wpisując ls w terminalu wykonuję komendę tylko  /bin/ls

# dpkg -S /bin/ls
coreutils: /bin/ls

# dpkg -s coreutils
Package: coreutils
...
Architecture: amd64
Version: 8.28-1ubuntu1
...

##  Teraz wiem ze komenda pochodzi z pakietu coreutils
##  W linku wyżej wspomniana jest ścieżka  /var/lib/dpkg/info/

# ls /var/lib/dpkg/info/ | grep ^coreutils
coreutils.list
coreutils.md5sums
coreutils.postinst
coreutils.postrm

# cat /var/lib/dpkg/info/coreutils.md5sums
749bda6cb12341b7c83c5bb45579201a  bin/cat
...
931606baaa7a2b4ef61198406f8fc3f4  bin/ls
...

##  Czyli mam w systemie listę plików i ich hash-e (tylko md5).
##  Nowsze algorytmy znalazłem tylko samych pakietów, w nieskompresowanych bazach danych w ścieżce /var/lib/apt/lists/   (SHA1, SHA256)
##  o czym wspomina inny link

$ grep -ri "Package: coreutils" /var/lib/apt/lists/
...
/var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_bionic_main_binary-amd64_Packages:Package: coreutils

## Choć to nie sugeruje na 100% linku, to znalazłem podobieństwo do http://archive.ubuntu.com/ubuntu/dists/bionic/main/binary-amd64/

# grep -A18 "Package: coreutils" /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_bionic_main_binary-amd64_Packages
Package: coreutils
...
Filename: pool/main/c/coreutils/coreutils_8.28-1ubuntu1_amd64.deb
Size: 1230832
MD5sum: 7d95d8dbaca7e89694e63ea4aa907c55
SHA1: 297d10f91608486816dddfa439a308bb9e3361c8
SHA256: 24541a48e25dfb17c98ce77dda61800e6cd68d74c25725753613fbcc00f2418f

##  Pobieram

$ curl -O http://archive.ubuntu.com/ubuntu/pool/main/c/coreutils/coreutils_8.28-1ubuntu1_amd64.deb
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1201k  100 1201k    0     0  2013k      0 --:--:-- --:--:-- --:--:-- 2010k

##  Moze warto sprawdzic pobrany, czego wczesniej nie zrobilem, w tym celu musze stworzyc hash z pliku

sha256sum coreutils_8.28-1ubuntu1_amd64.deb
24541a48e25dfb17c98ce77dda61800e6cd68d74c25725753613fbcc00f2418f  coreutils_8.28-1ubuntu1_amd64.deb

##  I porównać ten hash z hashem z tym znalezionym w systemie

$ [[ 24541a48e25dfb17c98ce77dda61800e6cd68d74c25725753613fbcc00f2418f == 24541a48e25dfb17c98ce77dda61800e6cd68d74c25725753613fbcc00f2418f ]] && echo OK || echo NOT
OK

##  *Rozpakowuje plik (sprawdzilem wczesniej gdzie on jest)

$ ar vx coreutils_8.28-1ubuntu1_amd64.deb

$ tar -xf data.tar.xz "./bin/ls"

Sprawdzam md5

$ md5sum ./bin/ls
931606baaa7a2b4ef61198406f8fc3f4  ./bin/ls

##  *Info:  " ./bin/ls " to mój rozpakowany plik ls

##  *Info:  Skoro pobraliśmy pakiet, to możemy zamiast md5 użyć dowolnie inny algorytm np. sha256. Ja niżej użyłem md5
##  Generujemy dla /bin/ls

$ md5sum /bin/ls
931606baaa7a2b4ef61198406f8fc3f4  /bin/ls

##  Porownalem oba hashe korzystajac z basha
$ [[ 931606baaa7a2b4ef61198406f8fc3f4 == 931606baaa7a2b4ef61198406f8fc3f4 ]] && echo OK || echo "sa nie jednakowe"
OK

##  Być może nie musiałem pobierać paczki, ale nie wiem czy i gdzie są sumy md5 plików w repozytorium.
##  Gdy chcę porównać pliki ...
##  Niżej ( cmp - compare two files byte by byte  /  diff - compare files line by line )
##  INFO: użyłem komendy diff w przykładzie, ale zasadniczo bardziej polecam cmp.

$ cmp  /bin/ls /home/user/bin/ls
$

$ diff -s  /bin/ls /home/user/bin/ls
Pliki /bin/ls i /home/user/bin/ls są identyczne

Czy klucz GPG zapewnia większe bezpieczeństwo?
Nie mam pewności. Może w internecie będzie coś więcej na ten temat.
Może dłuższy opis lub doklejenie klucza lub czegoś innego może zwiększyć ilość kolizji o jeden bit by ułatwić wstrzyknięcie bardziej złośliwego kodu.
Równie dobrze może przypadkowo utrudnić znalezienie idealnego miejsca na edycję kodu.
Na pewno także suma bitów musi się zgadzać.
Warto poczytać o kolizjach i sprawdzić przykładowo czy suma kontrolna przykładowego pakietu zgadza się z tym podanym w samym pakiecie
oraz może na jakimś przykładzie z bardzo słabym algorytmem.

Ad. 3. Czy nie dochodzi np. do oszukania pakietu w trakcie przesyłania pakietu?
O bezpieczeństwie przesyłania paczek można dowiedzieć się także czytając o błędzie który kiedyś wystąpił
https://thehackernews.com/2019/01/linux-apt-http-hacking.html
oraz https://whydoesaptnotusehttps.com/

Edit: Dla lepszej informacji odrobinę poprawiłem przykład z Mint-em.

Edit.
Zapomniałem tez wspomnieć że można tez poczytać
- o błędach sprzętowych ( np. Spectre, Foreshadow, SPOILER, ZombieLoad, RAMBleed, SWAPGS, NetCAT, TPM-Fail, Meltdown, ...)
- o CVE i błędach w oprogramowaniu ( np. Escalation of Privilege, Denial of Service, Information Disclosure, buffer overflow, integer overflow, ... )
« Ostatnia zmiana: 2019-12-06, 05:28:20 wysłana przez 1709 »
PS: Brak polskiej czcionki, nie jest to brak lenistwa, a jej brak w systemie i brak czasu na reczne poprawki.

Offline pavbaranov

  • Users
  • Guru
  • *****
  • Wiadomości: 878
    • Zobacz profil
Odp: Czy mój ls to malware, czy nie malware
« Odpowiedź #10 dnia: 2019-11-19, 10:15:56 »
Przyszła mi może głupia, ale prosta metoda sprawdzenia do łba.
Wygeneruj sobie md5sums, czy sha256 dla podejrzanego pliku na dysku.
Na "bezpiecznym" (czyli takim, gdzie nie masz żadnych podejrzeń) komputerze ściągnij paczkę zawierającą ten plik, w tej samej wersji, co masz w systemie, rozpakuj ją, wygeneruj taką samą sumę - porównaj. Sumy winny być identyczne.

Offline 920806

  • Users
  • Stały bywalec
  • ***
  • Wiadomości: 130
    • Zobacz profil
Odp: Czy mój ls to malware, czy nie malware
« Odpowiedź #11 dnia: 2019-11-19, 17:45:41 »
Pytanie wydaje mi się "w miarę proste" i pewnie oczekiwano także prostej odpowiedzi.

Niee, nie miałem oczekiwań wobec odpowiedzi. Troszkę w secu już siedzę i nauczyłem się, że nie ma prostej odpowiedzi .

Pisze swojego toola do audytowania Linuxa( teraz na Debiana ) - aktualnie w Pythonie, ale bez C się też nie obejdzie -  i stąd cała ta rozkmina :). Muszę się troszkę dokształcić w konwencji wywołań. Zastanawia mnie, czy jeśli malware jest zaszyty w binarce to po uruchomieniu np. odrębnego wątku, nazwa tej binarki/pid będzie widoczny  np. przy użycia netstat/ss. No bo np. jeśli podejrzewamy, że jest coś nie tak to mogli byśmy bacznie obserwować ruch/port/pid i zobaczyć, czy podejrzany  proces nawiązywał jakieś połączanie do serwera zewnętrznego.

edit:

Cytuj
Przyszła mi może głupia, ale prosta metoda sprawdzenia do łba.
Wygeneruj sobie md5sums, czy sha256 dla podejrzanego pliku na dysku.
Na "bezpiecznym" (czyli takim, gdzie nie masz żadnych podejrzeń) komputerze ściągnij paczkę zawierającą ten plik, w tej samej wersji, co masz w systemie, rozpakuj ją, wygeneruj taką samą sumę - porównaj. Sumy winny być identyczne.

To wcale nie jest głupie :) wydaje się dość skuteczne, ale to już dość duży wysiłek. Kierowałem się założeniami , że da się coś wychwycić hmm.. bardziej "dynamicznie" :)
« Ostatnia zmiana: 2019-11-19, 17:53:03 wysłana przez 920806 »
Steve Wozniak nie wiedział .. ~ ~ https://www.youtube.com/watch?v=FG1AQcGGSec ~~ / "Uparty jak nigdy" /P3@CE , L0\/E & rock'|\|'roII

Offline Paweł Kraszewski

  • Administrator
  • Guru
  • *****
  • Wiadomości: 3047
  • Lenistwo jest matką potrzeby = babcią wynalazku
    • Zobacz profil
Odp: Czy mój ls to malware, czy nie malware
« Odpowiedź #12 dnia: 2019-11-19, 18:39:40 »
1. Na osobnej maszynie ściągasz pakiet coreutils dla swojej wersji Debiana (w nim jest ls).
2. Midnight Commander potrafi otwierać pliki deb. Z jego pomocą wyciągasz plik /DEBIAN/md5sums z pakietu coreutils.
3. Kopiujesz plik na podejrzaną maszynę.
4. Idziesz do katalogu głównego.
5. Odpalasz md5sum -c --quiet /sciezka/do/skopiowanego/md5.
6. Wyświetla ci wszystkie pliki, których suma różni się od oczekiwanej, lub których brakuje na dysku.
7. (albo 0.) Modlisz się do dowolnie wybranego boga, żeby malware nie założył hooków na funkcje open i read, żeby podłożyć oryginalny plik na czas skanowania (dlatego zgodnie ze sztuką skanowanie robi się z zewnętrznego, zaufanego systemu, np z LiveCD/LiveDVD).
8. Zastanawiasz się, czemu w pliku DEB nie ma lepszych sum kryptograficznych (np sha512, ale w sumie za sha256 bym się nie pogniewał).
Paweł Kraszewski
~Arch/Void/Gentoo/FreeBSD/OpenBSD/Specjalizowane customy

Offline 1709

  • Users
  • Guru
  • *****
  • Wiadomości: 2757
  • 1709
    • Zobacz profil
Odp: Czy mój ls to malware, czy nie malware
« Odpowiedź #13 dnia: 2019-11-19, 20:38:44 »
No bo np. jeśli podejrzewamy, że jest coś nie tak to mogli byśmy bacznie obserwować ruch/port/pid i zobaczyć, czy podejrzany  proces nawiązywał jakieś połączanie do serwera zewnętrznego.
Troszkę się tym też ostatnio interesuje. I mogę odrobinę napisać aczkolwiek nie wiem wszystkiego.

1. Generalnie potrzebujesz zainstalować lub stworzyć piaskownicę / sandbox.
I tutaj chcę jeszcze jedno napisać.
Jeśli uważam że komenda /bin/ls jest zainfekowana, to równie dobrze mogę przypuszczać że
ktoś lub coś miało dostęp do dowolnego pliku w systemie.
Uważam że większy sens jest blokowanie / nadzorowanie uruchamiania aplikacji innych niż systemowych,
czyli takich które domyślnie można zapisać np. w /tmp , /home/user/ i uruchomić.
Aczkolwiek fajnie by było nadzorować wszystkie aplikacje zarówno systemowe, jak i od razu pobrane.
-  Przykłady piaskownic to np. Firejail , AppArmor.  To co mnie się rzuciło w oczy to że jedna z nich przy uruchomieniu systemu próbuje ładować gotowe ustawienia,
co wydaje mi się zbędne jeśli chcę śledzić wszystkie aplikacje jednakowo. ( może coś się zmieniło, nie wiem )
-  " Prosty sandbox "
Pierwszy sposób: https://wiki.gentoo.org/wiki/Simple_sandbox
Drugi sposób:
https://www.cyberciti.biz/faq/debian-ubuntu-restricting-ssh-user-session-to-a-directory-chrooted-jail/
https://www.tecmint.com/restrict-ssh-user-to-directory-using-chrooted-jail/
-  Możesz też poczytać o SELinux https://www.linux.com/tutorials/run-applications-secure-sandboxes-selinux/

2.   Zapora iptables.
Iptables pozwala na blokowanie, logowanie i akceptowanie połączeń.
W jednym z linków jest wspomniane o module owner
https://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-7.html
https://www.crybit.com/block-incoming-outgoing-network-access/
Sama dokumentacja wspomina krenela 2.4. Spotkałem się z informacją że może być problem ze znalezieniem tego modułu lub w pełni wykorzystaniem ze względu na jego słabą skuteczność.
Aczkolwiek ciężko mi konkretnie tą informacje teraz znaleźć.

3.  Problemy z komendami.
Komendy pozwalają na wiele, ale nie które z nich nie działają w  czasie rzeczywistym lub ciężko uchwycić zmianę
np. jeśli będę chciał uchwycić nazwę pliku używanego przez dany proces lub wyłapać pakiet internetowy jakąś komendą,
to ta nazwa / informacja może przelecieć szybciej niż będę wstanie wyłapać to innym programem, dlatego istotne jest współpracowanie z kernelem (chyba) aby się tak nie stało. ( albo używać po prostu lepszych komend lub innego sposobu )
Np. użycie jednej komendy pozwala mi wykryć jakiś proces, ale czas procesu może być zbyt krótki zanim użyje/ przefiltruje wynik przy pomocy grep i spróbuje użyć innej komendy.

4.   Problem z kernelem.
Polecam poczytać o komendach nice and renice , ulimit , nproc.
Problem jaki spotkałem to np.  że mogę zatrzymać forkbomb zrobioną przez aplikacje ale nie potrafię zalogować tego zdarzenia.
Podobno jest to możliwe z kernelem grsecurity lub jakimś patchem.
Bardzo fajną rzeczą związaną z kernelem jest także  inotifywait /  inotifywatch
Dzięki tej aplikacji można nadzorować czy jakaś aplikacja nam nie otworzyła lub zmodyfikowała dany plik bez zbędnego obciążania systemu.
I dzięki aplikacji notify-send możemy na pulpicie wyświetlić komunikat że jakiś program próbuje coś robić z naszym obserwowanym plikiem.

5.  Problem z plikami konfiguracyjnymi i zmiennymi środowiskowymi.
Problem jest taki że znajdują się one w katalogu domowym gdzie możemy je modyfikować.
Przykład takiego przypadku  https://www.zdnet.com/article/kde-rips-out-ability-for-kconfig-to-run-shell-code/
Środowisko KDE automatycznie wyszukiwało ikonki do pliku, ale przy okazji jeśli był to skrót to można było tam dodać własną komendę np. instalującego wirusa.
Efekt był taki, że wystarczyło pobrać plik aby system wykonał automatycznie komendy z tego pliku bez naszej wiedzy.
Inny przykład z bash-em.
Wystarczy podmienić zmienną środowiskową $PATH aby przy wpisaniu komendy ls
uruchamiało się /home/user/ls zamiast /bin/ls.
Owy nowy program może też być uruchamiany z plików lokalnych np. ~/.profile , ~/.bashrc
https://wiki-dev.bash-hackers.org/scripting/bashbehaviour
https://access.redhat.com/solutions/65822
Można też próbować uruchomić program w raz ze startem środowiska graficznego np. ~/.config/autostart/
Dlatego jak widzę np. antywirusa który nie sprawdza tak podstawowych rzeczy i jeszcze unika sprawdzić pliku systemowego, to jestem załamany.

Edit
Odnośnie zmiennych warto też przeczytać np. o rbash , " Restricted Linux Shell Escaping Techniques ".

Edit
Możesz jeszcze przeczytać o systemd-run ProtectSystem , aczkolwiek musisz mieć świadomość że nie każdy system używa systemd.
https://endocode.com/blog/2016/11/04/new-sandbox-features-features-in-systemd/

Edit
Gdybyś kiedyś się nudził :D
to odnośnie kernela możesz jeszcze poczytać o ( ewentualnie zatrudnij syntezator mowy do czytania np. google translatora xD )
" Kernel Page Table Isolation " ,  " Forcefully Unmap Complete Kernel With Interrupt Trampolines "
" Linux Kernel Runtime Guard  "  https://zaufanatrzeciastrona.pl/post/linux-kernel-runtime-guard-ochrona-przed-jeszcze-nieznanymi-exploitami/
" Kernel Self Protection Project "  https://linux-magazine.pl/lm171/na-strazy-kernela-projekt-kernel-selfprotection-zamierza-podniesc-bezpieczenstwo-linuksa-422.html
« Ostatnia zmiana: 2019-11-20, 04:13:34 wysłana przez 1709 »
PS: Brak polskiej czcionki, nie jest to brak lenistwa, a jej brak w systemie i brak czasu na reczne poprawki.

Offline 920806

  • Users
  • Stały bywalec
  • ***
  • Wiadomości: 130
    • Zobacz profil
Odp: Czy mój ls to malware, czy nie malware
« Odpowiedź #14 dnia: 2019-11-20, 12:54:51 »
Cytuj
Komendy pozwalają na wiele, ale nie które z nich nie działają w  czasie rzeczywistym lub ciężko uchwycić zmianę
np. jeśli będę chciał uchwycić nazwę pliku używanego przez dany proces lub wyłapać pakiet internetowy jakąś komendą,
to ta nazwa / informacja może przelecieć szybciej niż będę wstanie wyłapać to innym programem, dlatego istotne jest współpracowanie z kernelem aby się tak nie stało.

Zgadza się, ale zauważyłem, że programy z których korzystałem często odwołują się do jakichś plików pomocniczych, pomyślałem, że to cenna informacja z mojego punktu widzenia, bo nie muszę wywoływać innego programu tylko moge się bezpośrednio odwołać do pliku.

Można by zrobić coś takiego jak kwarantanna i wtedy regularnie pobierać próbki i sprawdzać , co tam pod maską się dzieje.. mam kilka pomysłów :D

Cytuj
Jeśli uważam że komenda /bin/ls jest zainfekowana, to równie dobrze mogę przypuszczać że
ktoś lub coś miało dostęp do dowolnego pliku w systemie.

Tutaj też można by zerknąć na czas ostatniej modyfikacji pliku/plików. Ja ostatnio sprawdzałem swojego ls'a i jest z sierpnia ( a regularnie aktualizuje) - wtedy też instalowałem system.

Czy z poziomu C możemy zmodyfikować time-stamp utworzenia pliku ?
Steve Wozniak nie wiedział .. ~ ~ https://www.youtube.com/watch?v=FG1AQcGGSec ~~ / "Uparty jak nigdy" /P3@CE , L0\/E & rock'|\|'roII