P

lik lastlog, znajdujący się w ścieżce /var/log/lastlog, jest plikiem typu „niegęstego” (ang. sparse file), który próbuje wykorzystać przestrzeń systemu plików bardziej efektywnie, gdy sam plik jest częściowo pusty. Osiąga się to poprzez zapisywanie krótkich informacji (metadanych) reprezentujących puste bloki na nośniku danych zamiast rzeczywistej „pustej” przestrzeni, która tworzy blok, zużywając w ten sposób mniej miejsca. Pełny blok jest zapisywany na nośniku jako rzeczywisty rozmiar tylko wtedy, gdy blok zawiera „rzeczywiste” (niepuste) dane. Dla codziennego użytkowania systemu Linux oznacza to, że jego zgłaszany rozmiar (np. przez polecenie ls) może być znacznie większy niż rzeczywista przestrzeń, jaką zajmuje na dysku.
[ czytaj całość… ]

P

roces debugowania (ang. debugging) polega na kontrolowanym wykonaniu programu pod nadzorem debugera. Podobnie wygląda proces śledzenia (ang. tracing), który działa zarówno w trybie debugowania, jak i rejestrowania wybranych zdarzeń w czasie rzeczywistym. W systemie Linux często możemy spotkać się z tego typu czynnościami w kontekście podsłuchiwania innych procesów. Zatem pozostaje pytanie, czy istnieje możliwość sprawdzenia czy dany proces jest aktualnie poddawany procesowi śledzenia lub debugowania? Otóż każdy uruchamiany proces może zajrzeć do ścieżki /proc/self/status i sprawdzić, czy klucz TracerPid ma inną wartość niż 0:

agresor@darkstar:~$ cd /proc/self; cat status | egrep -B7 ^TracerPid
Name:	bash
Umask:	0022
State:	S (sleeping)
Tgid:	2998765
Ngid:	0
Pid:	2998765
PPid:	2998764
TracerPid:	0

ponieważ wiersz „TracerPid” z wartością „0” oznacza, że żaden proces nie „śledzi” tego procesu. Za pomocą języka Python możemy napisać prosty skrypt o nazwie show_debbuger.py, który sprawdzi czy aktualnie w systemie jest uruchomiony jakiś proces, który jest śledzony i poda nam jego dane:

#!/usr/bin/env python3
# Debugger detector v0.1

import os
import re

def show_debugger(proc_path: str):
    pid_list, pid_found = [], []
    for pid in os.listdir(proc_path):
        if os.path.isdir(os.path.join(proc_path, pid)) and pid.isnumeric():
            pid_list.append(pid)
    for pid_number in pid_list:
        full_path = os.path.join(proc_path, pid_number, 'status')
        if os.path.isfile(full_path):
            with open(full_path, 'r') as proc_file:
                status_file = proc_file.read()
                tracer_pid = re.search(r'(?P<name>TracerPid.*)\s+(?P<pid>\d+)',
                                       status_file).group('pid')
            if tracer_pid != '0':
                process_name = re.search(r'Name:\s+(?P<name>\w+)',
                                         status_file).group('name')
                tracer_path = os.path.join(proc_path, tracer_pid, 'status')
                with open(tracer_path, 'r') as tracer_file:
                    status_file = tracer_file.read()
                    tracer_name = re.search(r'Name:\s+(?P<name>\w+)',
                                            status_file).group('name')
                print(f'Process: {process_name} with PID: {pid_number} is traced with:'
                      f' {tracer_name} with PID: {tracer_pid}')
                pid_found.append(pid_number)
    if pid_found:
                return True
    else:
        print('No process tracing found!')
        return False


if __name__ == '__main__':
    show_debugger('/proc')

W pierwszej konsoli możemy sprawdzić czysty system:

root@darkstar:~#./show_debbuger.py
No process tracing found!

W drugiej konsoli uruchamiamy strace na dowolnym procesie i uruchamiamy skrypt ponownie:

root@darkstar:~#./show_debbuger.py
Process: sshd with PID: 2055265 is traced with: strace with PID: 2061163

Dokładamy jeszcze gdb ponownie sprawdzając system:

root@darkstar:~#./show_debbuger.py
Process: multipathd with PID: 352 is traced with: gdb with PID: 2061871
Process: sshd with PID: 2055265 is traced with: strace with PID: 2061163

Zawsze też możemy wyłączyć możliwość śledzenia w systemie.

Więcej informacji: Detecting the Presence of a Debugger in Linux, How do you detect that you’re being ptraced?

U

ltimate Packer for Executables (UPX) to program pakujący dla kilku formatów wykonywalnych, takich jak biblioteki DLL systemu Windows, aplikacji macOS oraz Linux ELF. Jak możemy przeczytać na oficjalnej stronie programu UPX: „potrafi zazwyczaj zmniejszyć rozmiar plików programów i bibliotek DDL o około 50% – 70%, redukując w ten sposób miejsce na dysku, czas ładowania w sieci, czas pobierania oraz inne koszty dystrybucji i przechowywania”. Programy pakujące zasadniczo biorą oryginalny plik wykonywalny i dodają mały fragment kodu zwany „odgałęzieniem” (ang. stub) do nowo utworzonego wykonywalnego pliku. Kod pośredniczący zostanie następnie użyty do rozpakowania pliku i „przywrócenia” pliku wykonywalnego do jego pierwotnego stanu. Podczas, gdy niektóre programu pakujące, takie jak wspomniany UPX, tylko kompresują pliki, inne mogą je również szyfrować. Atakujący często używają kompresji, aby ukrywać złośliwe oprogramowanie jako pozornie nieszkodliwe i legalne pliki, co może oszukać silniki antywirusowe oparte na sygnaturach.
[ czytaj całość… ]

J

ako zwykły użytkownik czasami mamy ograniczony dostęp do różnych informacji o sprzęcie maszyny fizycznej lub oprogramowaniu stojącego za maszyną wirtualną. Na przykład korzystanie z polecenia dmidecode to sprawdzony sposób na odczytywanie różnych informacji o pamięci RAM w systemach Linux, takich jak numer modelu, prędkość i inne atrybuty. Ale niestety używanie dmidecode jest ograniczone do praw administracyjnych ze względu na konieczność dostępu do /dev/mem. Okazuje się jednak, że istnieje inny, mniej znany sposób na uzyskanie tych samych informacji o wielu komponentach pamięci i nie tylko. Mianowicie podczas procesu uruchamiania w najnowszych dystrybucjach Linuksa udev wyodrębnia informacje DMI i przechowuje je w swojej „bazie danych”. Dlatego uruchomienie polecenia:

udevadm info -e | grep -e MEMORY_DEVICE -e MEMORY_ARRAY

jako zwykły użytkownik doje dostęp do informacji o pamięci DIMM Np.

E: MEMORY_DEVICE_1_FORM_FACTOR=DIMM
E: MEMORY_DEVICE_1_TYPE=DDR4
E: MEMORY_DEVICE_1_SPEED_MTS=2400
E: MEMORY_DEVICE_1_CONFIGURED_SPEED_MTS=2133
E: MEMORY_DEVICE_1_MANUFACTURER=00AD00B300AD
E: MEMORY_DEVICE_1_PART_NUMBER=HMA82GR7AFR8N-UH
E: MEMORY_DEVICE_1_SIZE=17179869184

Widzimy dostęp do informacji: typu, dostawcy, modelu, rozmiaru, szybkości MT/s i innych wskaźników pamięci. W ten sposób uzyskujemy dostęp do informacji w tych obszarach, gdy nie możemy uruchamiać poleceń jako administrator. Polecenie: udevadm info -e daje nam również dostęp do innych informacji DMI, które w przeciwnym razie byłyby zwykle ograniczone do konta root.

Więcej informacji: A Nifty Way To Access Linux Memory/RAM Information

O

nie! Z powodu dużej ilości pracy przed świętami ktoś zapomniał na serwerze WWW zaktualizować wtyczkę do wykonywania kopii zapasowej w używanym przez św. Mikołaja CMS WordPress. Dzięki temu złośliwe ELFy przedostały się do wewnętrznej sieci i w ramach Lateral Movement „przeskoczyły” do maszyny w fabryce św. Mikołaja odpowiedzialnej za kompilację kodu programów używanych w zabawkach. Jest na niej pełno sekretnych rozwiązań, schematów i innych wrażliwych danych, które można ukraść. Niestety oprócz kompilatorów (gcc) i debuggerów (gdb) maszyna nie posiada żadnych narzędzi (wget, curl itd.), które można wykorzystać do eksfiltracji danych lub ściągnięcia ładunków ze złego C2. Złe ELFy mają dostęp tylko do zwykłego konta dobrego ELFa o imieniu reversek, a dzięki prostemu skanerowi portów w czystej powłoce bash zorientowały już się, że maszyna ma dostęp do internetu tylko na portach HTTP (80) i HTTPS (443). Czy uda im się wykraść zaawansowane patenty i zamienić je w tańsze podróbki ?
[ czytaj całość… ]

C

zy ten plik to malware? Zależy jakiego silnika antywirusowego się spytasz. Podobnie jest w temacie znajdowania lokalizacji adresu IP, ponieważ powiązanie rzeczywistej lokalizacji z adresem IP jest prawie niemożliwe do pewnego poziomu dokładności (np. ulicy, miasta). Wiele osób od razu podniesie głos sprzeciwu odnosząc się do dostawców usług oferujących geolokalizację adresów IP. Tak, istnieją bazy zawierające informacje o lokalizacji geograficznej adresu IP. Niektóre nawet twierdzą, że mają bardzo dokładne informacje, ale czy są one wiarygodne? Rzućmy okiem na adres: 188.130.189.153. W tym celu skorzystamy z serwisów zawartych na stronie: resolve.rs, ponieważ uwzględnia ona bardzo dużo dostawców typu IP2GEO, z którymi możemy sprawdzić wspomniany adres IP. Przechodząc przez poszczególne serwisy i zadając im zapytanie o ten sam adres widzimy wiele różnic w wynikach. W momencie pisania tego wpisu wyniki były, co najmniej mylące nawet na poziomie kraju.
[ czytaj całość… ]

Po aktualizacji do systemu macOS Monterey (12.1) za każdym uruchomieniem komputera pojawia się komunikat: Komputer został wyłączony z powodu problemu. Naprawa polega na usunięciu plików z raportami diagnostycznymi: sudo su -; rm -dRfv /Library/Logs/DiagnosticReports/*.*.

Więcej informacji: You shut down your computer because of a problem upon every single boot

P

o wykonaniu aktualizacji z Elasticsearch z 6.8.14 do 6.8.20 w pliku logu pojawia się ciągle powtarzająca się wiadomość: cannot compute used swap when total swap is 0 and free swap is 0. Dzieje się tak ze względu na tą zmianę. Jeśli na naszej maszynie wirtualnej / fizycznej wyłączony jest plik wymiany oraz włączony monitoring to, co 10 sekund będziemy mieli zapychane logi tym wpisem. W celu wyfiltrowania tego typu wiadomości, należy do pliku /etc/elasticsearch/log4j2.properties dołączyć następujące wpisy w sekcji appender.rolling:

appender.rolling.filter.regex.type = RegexFilter
appender.rolling.filter.regex.regex = cannot compute used swap.*
appender.rolling.filter.regex.onMatch = DENY
appender.rolling.filter.regex.onMismatch = NEUTRAL

Więcej informacji: Log4j RegexFilter

S

ysdiagnose to narzędzie, które znajduje się na większości urządzeń z systemem macOS i iOS. Służy ono do zbierania informacji diagnostycznych dotyczących całego systemu. Obecna wersja – 3.0 zbiera duże ilości danych z szerokiej gamy lokalizacji w systemie. Mogą one być przydatne w informatyce śledczej komputera prowadzonej na żywo. W przypadku poszukiwań złośliwego oprogramowania przechwycone dane mogą pomóc w zidentyfikowaniu zainfekowanego pliku binarnego; mechanizmu persystencji (gdy złośliwe oprogramowanie uzyska dostęp do systemu, często chce zostać tam przez długi czas opracowując metody pozwalające na jego powrót po restarcie systemu; jeśli mechanizm persystencji jest wystarczająco unikalny, może nawet służyć jako świetny sposób na określenie cechy charakterystycznej danego złośliwego oprogramowania) lub połączeń do C2 (serwery Command and Control – nazywane również C&C odnoszą się do sposobu, w jaki atakujący komunikują się i sprawują kontrolę nad zainfekowanym systemem; po zainfekowaniu systemu większość złośliwego oprogramowania komunikuje się z serwerem kontrolowanym przez atakującego, aby przyjmować polecenia, pobierać dodatkowe komponenty lub wykradać informacje).
[ czytaj całość… ]

Nasze maszyny posiadają następujące parametry: 64 GB RAM oraz 32 wątków CPU (z HT). Jest na nich uruchomiony ElasticSearch v5 z złotą zasadą 50% na heap oraz 50% na cache systemu plików. Oczywiście heap jest ustawiony tak, aby nie przekraczał trybu „zero-based”, czyli w tym przypadku 30720 MB:
[ czytaj całość… ]