K

ontynuując naszą serię Necronomicon zajmiemy się dzisiaj publicznymi wiaderkami danych, które są umieszczone w chmurze. Bardzo wiele firm i prywatnych osób nadal przeprowadza adopcję chmury publicznej, której flagową usługą jest możliwość taniego przechowywania plików różnej maści. Mimo wielu badań, opracowań i raportów niewielu z tych adeptów zdaje sobie sprawę, że gdy tylko zdecydują się na ustawienie (świadomie lub nie) publicznego dostępu do dowolnego wiaderka (ang. bucket) istnieje duże prawdopodobieństwo, że ich nazwy zostaną odgadnięte, a dane zindeksowane oraz wystawione innym użytkownikom do łatwego przeszukiwania i pobierania. 24 września 2023 roku wyszukiwarka GrayHatWarfare przyznała, że jej baza danych zawiera 416.712 różnych wiaderek danych, 316.00 z S3, 6800.000 z DigitalOcean, 44000 z Google oraz 49.900 otwartych kontenerów z Azure, co daje łącznie 10,4 miliarda publicznie dostępnych plików. Patrząc z perspektywy bezpieczeństwa te wszystkie publiczne magazyny danych zawierają wiele szalonych rzeczy: pliki PST (które można zaimportować do programu Outlook, jako kompletne skrzynki e-mail); paszporty (których zapisywanie jest nielegalne w kilku krajach); certyfikaty urodzin; numery ubezpieczenia społecznego z USA; recepty oraz dane medyczne; rachunki i dane klientów; polisy ubezpieczeniowe; klucze licencyjne; dane dostępowe; klucze dostępowe; tokeny; certyfikaty TLS; pliki konfiguracyjne do narzędzi: WinSCP, FileZilla, Sublime, Menedżery haseł, VPN, Gitlab; Pliki konfiguracyjne PHP…
[ czytaj całość… ]

P

odczas pierwszego łączenia się z wybranym serwerem klient SSH poprosi użytkownika o weryfikację autentyczności tego serwera. Jest to zasada zwana TOFU – Trust On First Use – przy pierwszym połączeniu zakładamy lub weryfikujemy, że jest ono prawidłowe, a jeśli później coś się zmieni w łączności, będzie to podejrzane i wygeneruje ostrzeżenia. Z obserwacji zachowań użytkowników systemów *nix wynika, że wielu z nich po prostu na ślepo odpowiada: "Yes / Tak", nie biorąc pod uwagę potencjalnych zagrożeń bezpieczeństwa. Osoba, która jest w stanie przejąć sieciowo komunikację może przeprowadzić atak man-in-the-middle (MITM) prowadzący do wycieku danych uwierzytelniających lub przejęcia sesji użytkownika. Zgodnie z RFC 4251 istnieje kilka sposobów na weryfikację „odcisku palca” (ang. fingerprint) klucza serwera.
[ czytaj całość… ]

O

d początków informatyki dokładne wykrywanie typów plików miało kluczowe znaczenie przy określaniu sposobu przetwarzania plików. System Linux wyposażony jest w bibliotekę libmagic i narzędzie file, które od ponad 50 lat stanowią de facto standard identyfikacji typów plików. W dzisiejszych czasach przeglądarki internetowe, edytory kodu i niezliczone inne oprogramowanie opiera się na wykrywaniu typu plików w celu podjęcia decyzji o poprawnym przetworzeniu i wyświetleniu zawartości plików. Na przykład nowoczesne edytory kodu wykorzystują wykrywanie typu plików, aby wybrać schemat kolorowania składni, który ma zostać użyty, gdy programista zacznie pisać kod w danym języku.
[ czytaj całość… ]

for i in `echo *.HEIC`; do sips -s format jpeg -s formatOptions best "$i" --out "${i%.*}.jpg"; done;

formatOptions przyjmuje parametry jakości: [low|normal|high|best|<percent>]

B

adacze ds. cyberbezpieczeństwa z firmy Aqua Nautilus zajmującej się bezpieczeństwem rozwiązań chmurowych odkryli słaby punkt wykorzystywania dwóch różnych menadżerów pakietów w dystrybucji Ubuntu. Pakiet command-not-found może zostać użyty do przekazania użytkownikowi systemu informacji, które doprowadzą do rekomendacji zainstalowania złośliwego pakietu. Jak możemy przeczytać w raporcie występuje problem bezpieczeństwa wynikający z interakcji pomiędzy pakietem command-not-found (nie znaleziono polecenia) systemu Ubuntu, a repozytorium pakietów snap.

Wspomniany pakiet dostarcza sugestie dotyczące instalacji pakietów, gdy użytkownicy próbują wykonać dane polecenie w powłoce bash lub zsh, które aktualnie nie jest dostępne w systemie. Problemem jest fakt, że zawiera on rekomendacje zarówno dla pakietów apt, jak i snap. Na przykład, jeśli użytkownik spróbuje uruchomić przestarzałe polecenie: ifconfig, ale nie będzie ono obecne w systemie to zostanie uruchomiona funkcja command_not_found_handle, która zasugeruje instalację pakietu net-tools. Narzędzie korzysta z lokalnej bazy danych znajdującej się w /var/lib/command-not-found/commands.db w celu łączenia poleceń z odpowiadającymi im pakietami apt. Baza ta jest aktualizowana tylko wtedy, gdy aktualizowany jest sam pakiet command-not-found. Natomiast w przypadku pakietów snap opiera się to na poleceniu: snap advise-snap, które odwołuje się do własnej, regularnie aktualizowanej bazy pochodzącej ze sklepu snap. Problem w tym, że wiele nazw pakietów jeśli chodzi o snap nie zostało jeszcze zarezerwowanych / użytych przez tych samych opiekunów pakietów, co w przypadku apt. Dlatego osoba atakująca może przejąć popularną nazwę pakietu apt w snap i stworzyć fikcyjny pakiet wykonujący złośliwy kod na systemie ofiary.

Za przykład został podany pakiet apt: jupyter-notebook, gdzie opiekunowie nie zarezerwowali odpowiedniej nazwy w snap. To przeoczenie pozostawiło atakującemu okazję do przejęcia nazwy i rozprowadzenia złośliwego pakietu o tej samej nazwie. Wydając polecenie o tej samej nazwie możemy zaobserwować, jak pakiet command-not-found sugeruje najpierw pakiet snap, nawet przez oryginalnym pakietem apt. Takie zachowanie może potencjalnie wprowadzić użytkowników w błąd i narazić na atak podobny do tego, jaki znamy z zamieszania w zależnościach pakietów:

agresor@darkstar:~$ jupyter-notebook
Command 'jupyter-notebook' not found, but can be installed with:
sudo snap install jupyter-notebook # version 6.4.9-1ubuntu0.1, or
sudo apt  install jupyter-notebook # version 6.4.8-1ubuntu0.1
See 'snap info jupyter-notebook' for additional versions.

Co więcej, badacze odkryli, że aż 26% powiązanych z pakietami APT (ang. Advanced Package Tool) może być narażonych na podszywanie się pod taką samą nazwę. Dochodzą do tego również ataki typu typosquatting, podczas których atakujący może rejestrować pakiety z błędami typograficznymi (np. ifconfigg / idconfig / ifxonfig zamiast ifconfig). Problemem do zaadresowania jest używanie podwójnego standardu instalacji pakietów w systemie, który ma niespójne bazy oraz sama weryfikacja pakietów dodawanych do sklepu snap, ponieważ atakujący są w stanie naśladować tysiące poleceń z powszechnie używanych pakietów. Luka ta może narazić nie tylko użytkowników Linuksa Ubuntu na zakłócenie łańcucha dostaw pakietów, ale również systemy Windows, które używają WSL.

Więcej informacji: Fake Crypto Apps in Snap, Canonical finds hidden crypto-miners in the Linux Snap app store

P

rzesiąkanie płynu z małych naczyń krwionośnych do otaczających tkanek wymaga natychmiastowego leczenia, aby zapobiec spadkowi ciśnienia krwi i innym poważnym powikłaniom. Identycznie jest w przypadku zespołu podatności o nazwie Leaky Vessels, które wykryto w środowisku wykonawczym kontenerów, w szczególności runC (CVE-2024-21626) oraz w BuildKit (CVE-2024-23651, CVE-2024-23652 i CVE-2024-23653) używanym przez takie projekty jak: Docker, Kubernetes i inne platformy konteneryzacji. Luki te umożliwiają ucieczkę z kontenera, a osobie atakującej, która posiada dostęp do takiego kontenera, wykonanie dowolnego kodu na maszynie hosta, narażając w ten sposób cały system.
[ czytaj całość… ]

Pierwszym sposobem na tworzenie lub usuwanie pliku zaczynającego się od pojedynczego lub podwójnego myślnika jest dodanie ścieżki przed nazwą pliku:

touch ./--hard-to-create
rm ./--hard-to-remove

Drugim sposobem na tworzenie lub usuwanie pliku zaczynającego się od pojedynczego lub podwójnego myślnika jest zasygnalizowanie (--) wydawanemu poleceniu, że następuje koniec procesowania wewnętrznych opcji i wyłączenie interpretacji opcji zaczynających się od myślnika:

touch -- --hard-to-create
rm -- --hard-to-remove

Więcej informacji: How to create, open, find, remove dashed -file_name in Linux, What Does a Double-Dash in Shell Commands Mean?

I

nformację o modułach załadowanych w systemie Linux znajdziemy w kopalni wiedzy o systemie, czyli wirtualnym systemie plików procfs. W celu wyświetlenia aktualnie zarejestrowanych (nie ukrywających się) modułów wystarczy wykonać polecenie: cat /proc/modules. Naszym oczom powinny ukazać się linie zawierające od sześciu do siedmiu kolumn:

x_tables 45056 3 xt_owner,xt_tcpudp,ip6_tables, Live 0xffffffffc044b000

• x_tables – pierwsza kolumna wyświetla tytuł / nazwę modułu,
• 45056 – druga kolumna to wielkość modułu (podana w bajtach) – nie mylić z używaną pamięcią,
• 3 – trzecia kolumna podaje liczbę załadowanych instancji danego modułu – moduł z zerową wartością jest uważany za niezaładowany, a gdy liczba referencyjna modułu jest dodania (różna od zera), zwolnienie go za pomocą rmmod staje się niemożliwe, ponieważ polecenie wyświetli komunikat błędu: rmmod: ERROR: Module x_tables is in use by: xt_tcpudp xt_owner ip6_tables,
• xt_owner,xt_tcpudp,ip6_tables – w czwartej kolumnie znajdują się moduły odwołujące się / zależne, które wymagają tego modułu do swojego funkcjonowania – w przypadku braku odniesień wyświetlany jest znak „-„,
• Live – stan załadowania modułu wyrażony jest w piątej kolumnie, które może przyjmować tylko jedną z wartości: Live (żywy / aktywny), Loading (w trakcie ładowania), Unloading (w trakcie pozbywania się),
• 0xffffffffc044b000 – szósta kolumna wyświetla aktualne przesunięcie pamięci jądra wykorzystywane przez załadowany moduł, co może być przydatne przy procesie debugowania lub profilowania.

W niektórych przypadkach możemy również trafić na wpisy, które będą posiadały siódmą kolumnę – tzw. skażone stany (ang. tainted states) . Kiedyś reprezentowane przez nią symbole znajdowały się w pliku panic.c (aktualnie zostały przeniesione do sekcji dokumentacji kernel.rst):

======  =====  ==============================================================
     1  `(P)`  proprietary module was loaded
     2  `(F)`  module was force loaded
     4  `(S)`  kernel running on an out of specification system
     8  `(R)`  module was force unloaded
    16  `(M)`  processor reported a Machine Check Exception (MCE)
    32  `(B)`  bad page referenced or some unexpected page flags
    64  `(U)`  taint requested by userspace application
   128  `(D)`  kernel died recently, i.e. there was an OOPS or BUG
   256  `(A)`  an ACPI table was overridden by user
   512  `(W)`  kernel issued warning
  1024  `(C)`  staging driver was loaded
  2048  `(I)`  workaround for bug in platform firmware applied
  4096  `(O)`  externally-built ("out-of-tree") module was loaded
  8192  `(E)`  unsigned module was loaded
 16384  `(L)`  soft lockup occurred
 32768  `(K)`  kernel has been live patched
 65536  `(X)`  Auxiliary taint, defined and used by for distros
131072  `(T)`  The kernel was built with the struct randomization plugin
======  =====  ==============================================================

Dlatego, jeśli trafimy na wpis podobny do:

suspicious_module 110592 2 - Live 0xffffffffc0724000 (OE)

Możemy go odczytać, jako załadowanie modułu zewnętrznego (O) – spoza aktualnego drzewa modułów uruchomionego jądra systemu, który w dodatku nie jest podpisany (E). Wszystkie takie „skażone” moduły możemy wyświetlić poprzez polecenie:

grep \(.*\) /proc/modules

Podobnie możemy szukać wyrażenia taint w poleceniu dmesg lub journalctl --dmesg.

Więcej informacji: Tainted kernels, What is OE+ in Linux?, Craig Rowland on Twitter

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

S

króty kryptograficzne, takie jak MD5 i SHA[1/2] są wykorzystywane w wielu zastosowaniach związanych z eksploracją danych i bezpieczeństwem – służąc jako identyfikatory plików wykonywalnych i dokumentów tekstowych. Jednak ich rolą jest oznaczanie unikalności, nie podobieństw – jeśli zostanie zmieniony pojedynczy bajt pliku, wówczas skróty kryptograficzne dają zupełnie inne wartości. Ich działanie jest bardzo przydatne przy wyodrębnianiu, znakowaniu i dzieleniu się wskaźnikami skompromitowania (ang. IoCs – indicators of compromise) dla konkretnych próbek szkodliwego oprogramowania (ang. malware). Jednak w celu identyfikacji zagrożeń pochodzących z tych samych „rodzin” i aktorów (o podobnej binarnej strukturze plików, identyfikacja wariantów wiadomości spamowych / phishingowych) pojawiła się przestrzeń dla skrótów kryptograficznych, które identyfikują podobieństwo plików na podstawie ich wartości skrótu. Społeczność zajmująca się bezpieczeństwem zaproponowała dla tego problemu skróty podobieństwa (ang. similarity digests) takie jak np. sdhash oraz ssdeep.
[ czytaj całość… ]