Nowe posty

Ostatnie wiadomości

Strony: [1] 2 3 ... 10
1
Inne / Odp: Czy mój ls to malware, czy nie malware
« Ostatnia wiadomość wysłana przez 1709 dnia Wczoraj o 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
2
Inne / Odp: Czy mój ls to malware, czy nie malware
« Ostatnia wiadomość wysłana przez Paweł Kraszewski dnia Wczoraj o 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ł).
3
Inne / Odp: Czy mój ls to malware, czy nie malware
« Ostatnia wiadomość wysłana przez 920806 dnia Wczoraj o 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" :)
4
Inne / Odp: Linux mint na Panasonic CF-53
« Ostatnia wiadomość wysłana przez pavbaranov dnia Wczoraj o 12:24:45 »
W tym systemie, który Ci się uruchamia sprawdź istnienie paczki os-prober, jeśli nie ma, zainstaluj i wygeneruj nowy GRUB (prawdopodobnie masz tam polecenie update-grub, grub-update lub podobne).

PS: Jest już nowszy Mint niż 18.
5
Inne / Linux mint na Panasonic CF-53
« Ostatnia wiadomość wysłana przez Jestem Światłem dnia Wczoraj o 11:16:19 »
Witam serdecznie!

Jestem tu nowy i przygodę z Linux zacząłem od niedawna .
Sprawa polega na tym że kiedy mi padł windows (Win.7 Pro 64 bit OA) na Panasonic CF-53 postanowiłem zainstalować Linux Mint 18.
I jednocześnie obok Mint mam Ubuntu najnowszy.
Przy Mint nawet udało mi się uruchomić obsługę ekranu dotykowego (P CF-53 posiada ekran dotykowy i rysik).
Ale do sedna.
Któregoś dnia Mint przestał się pojawiać na starcie razem z Ubuntu, czyli brak możliwości wyboru systemu. Dobrze że miałem Ubuntu na pokładzie. Teraz nie wiem co z tym Mint zrobić.
Proszę o sugestie i wskazówki jeśli da się jeszcze uratować Mint.

Dziękuję i pozdrawiam!
6
Inne / Odp: Czy mój ls to malware, czy nie malware
« Ostatnia wiadomość wysłana przez pavbaranov dnia Wczoraj o 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.
7
Inne / Odp: Czy mój ls to malware, czy nie malware
« Ostatnia wiadomość wysłana przez 1709 dnia Wczoraj o 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 )

$ 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, ... )
8
Inne / Odp: Czy mój ls to malware, czy nie malware
« Ostatnia wiadomość wysłana przez 920806 dnia Wczoraj o 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
9
Inne / Odp: Czy mój ls to malware, czy nie malware
« Ostatnia wiadomość wysłana przez 1709 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.
10
Inne / Odp: Czy mój ls to malware, czy nie malware
« Ostatnia wiadomość wysłana przez 920806 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
Strony: [1] 2 3 ... 10