NFsec Logo

Robot numer trzy

19/03/2024 w Hackultura Możliwość komentowania Robot numer trzy została wyłączona

P

orządkując akta w archiwum Kosmopolu natrafiłem na starą wytartą teczkę, wypchaną mnóstwem protokołów i fotografii. Może nie zwróciłbym na nią uwagi, gdyby nie to, że rzuciłem okiem do wnętrza i natrafiłem na słowo GRAWAX…

To mi coś przypominało… Nie wiedziałem jednak, z czym powiązać to słowo; dopiero po przejrzeniu kilku stron maszynopisu przypomniałem sobie, że słyszałem je kiedyś na wykładzie starego Barela, który swego czasu wykładał nam Historię Techniki. Instytut Kosmiki ukończyłem jednak na tyle dawno, aby zapomnieć, co to było.

Zacząłem czytać. To już niestety taka moja nieuleczalna wada: kiedy robię porządki w starych szpargałach, kartotekach czy archiwach, wcześniej czy później natrafiam na coś tak bardzo absorbującego, że godzinami siedzę na podłodze wśród rozrzuconych skoroszytów, segregatorów i teczek, aż przeczytam wszystko od „a” do „z”.
[ czytaj całość… ]

Hartowanie (sub)domen nieużywanych do wysyłki i odbioru poczty

14/03/2024 w Administracja, Bezpieczeństwo Możliwość komentowania Hartowanie (sub)domen nieużywanych do wysyłki i odbioru poczty została wyłączona

W

internecie możemy być właścicielem wielu domen, a w ramach nich rejestrować wiele subdomen. Nasze (sub)domeny mogą być używane do bardzo wielu zastosowań: obsługi strony (aplikacji) internetowej, poczty, serwera plików, serwera DNS, ochrony marki, działalności w wielu krajach itd. Wiele z tych (sub)domen będzie uniwersalna – zawierając pod sobą większość z wymienionych usług, a jeszcze większa ilość (licząc z subdomenami) będzie ukierunkowana na świadczenie konkretnej usługi. Jeśli nasza (sub)domena nie jest przeznaczona do obsługi poczty e-mail, niezależnie od tego, czy jest to poczta przychodząca (chcemy ją odbierać), czy wychodząca (chcemy ją wysyłać), również musimy zadbać o jej prawidłową konfigurację, aby zapobiec wykorzystywaniu tej (sub)domeny do nieuczciwych działań w internecie (czyt. podszywaniu się i wysyłaniu phishingu).
[ czytaj całość… ]

Pliki w chmurze – Reditus Necronomicon

08/03/2024 w Bezpieczeństwo Możliwość komentowania Pliki w chmurze – Reditus Necronomicon została wyłączona

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ść… ]

SSHFP – ministerium DNS na rzecz SSH

02/03/2024 w Bezpieczeństwo Możliwość komentowania SSHFP – ministerium DNS na rzecz SSH została wyłączona

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ść… ]

Magika: identyfikacja plików za pomocą głębokiego uczenia

22/02/2024 w Bezpieczeństwo Możliwość komentowania Magika: identyfikacja plików za pomocą głębokiego uczenia została wyłączona

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ść… ]

MacOS: masowa konwersja HEIC do JPEG

19/02/2024 w CmdLineFu Możliwość komentowania MacOS: masowa konwersja HEIC do JPEG została wyłączona

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>]

Snap command-not-found i złośliwe pakiety

17/02/2024 w Bezpieczeństwo Możliwość komentowania Snap command-not-found i złośliwe pakiety została wyłączona

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

Nieszczelne naczynka w Dockerze

07/02/2024 w Bezpieczeństwo Możliwość komentowania Nieszczelne naczynka w Dockerze została wyłączona

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ść… ]

Tworzenie i usuwanie plików zaczynających się od myślników

25/01/2024 w CmdLineFu Możliwość komentowania Tworzenie i usuwanie plików zaczynających się od myślników została wyłączona

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?

Wykrywanie skażonych modułów jądra

15/01/2024 w Administracja, Bezpieczeństwo Możliwość komentowania Wykrywanie skażonych modułów jądra została wyłączona

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