B

adacze z SEC Consult, a dokładniej Timo Longin – znany ze swoich ataków na protokół DNS opisał informację o nowej technice ataku o nazwie SMTP Smuggling, która może umożliwiać wysyłanie fałszywych wiadomości e-mail z pominięciem mechanizmów uwierzytelniania. Technika ta wykorzystuje protokół SMTP (ang, Simple Mail Transfer Protocol), w którym atakujący może wykorzystać różnice w sposobie, w jaki wychodzące i przychodzące serwery SMTP interpretują sekwencję wskazującą koniec danych w wiadomości e-mail. Co ciekawe bardzo podobną technikę o nazwie MX Injection opisał Vicente Aquilera Diaz w 2006 roku. Mimo, że jest to znany, długotrwały i dobrze udokumentowany problem, kilka powszechnie używanych serwisów i serwerów świadczących usługi e-mail okazało się podatnych na przeprowadzenie tego ataku.
[ czytaj całość… ]

I

taka jest brzydka prawda. W serwisie IntelTechniques został opublikowany tekst ostrzegający swoich czytelników i użytkowników systemu Ubuntu przed subskrybowaniem usługi Ubuntu Pro. Powierzchowne użytkowanie tego systemu doprowadziło redakcję do fałszywego przekonania, że standardowe oprogramowanie zainstalowane przy użyciu polecenia apt jest “aktualne” i “bezpieczne” pomimo wyświetlania ostrzeżeń dotyczących o dostępnych pakietach aktualizujących ich bezpieczeństwo. Cytat z ich publikacji:

[Wyszczególnione pakiety Ubuntu] “w dostępnej wersji” to dokładnie ten sam produkt, co aktualnie zainstalowane oprogramowanie. Ta aktualizacja nic nie wnosi.

Do całej dyskusji, która rozwinęła się w serwisie HackerNews odniósł się jeden z programistów o imieniu Alex tłumacząc, że to stwierdzenie odzwierciedla szersze nieporozumienie dotyczące aktualnego zarządzania pakietami w systemie Ubuntu. W skrócie można powiedzieć, że problem pojawia się, gdy włączymy repozytorium universe w dystrybucji typu LTS (Long Term Support – typ specjalnych wydań systemu Ubuntu o przedłużonym okresie wsparcia), co może narazić nas na problemy związane z bezpieczeństwem chyba, że jesteśmy zainteresowani subskrypcją usługi “Pro”.
[ czytaj całość… ]

P

olecenie ldd nie jest jedynym programem, który miał problemy z bezpieczeństwem jeśli chodzi walidację danych podczas analizy różnych programów. W 2014 roku Michał Zalewski ostrzegał, że wielu użytkowników zajmujących się informatyką śledczą lub innymi dziedzinami bezpieczeństwa informacji ma zwyczaj uruchamiania programu /usr/bin/strings na plikach binarnych pochodzących z internetu. Skoro narzędzie to po prostu skanuje zawartość pliku w poszukiwaniu ciągów znaków, które można wyświetlić na standardowym wyjściu (stdout) to nie powinno narazić użytkownika na jakiekolwiek ryzyko. Otóż program strings jest integralną częścią GNU binutils – zestawu narzędzi specjalizujących się w manipulowaniu formatami plików wykonywalnych przy użyciu biblioteki o nazwie libbfd (Binary File Descriptor Library).

Jak udowodnił lcamtuf funkcja setup_group w źródłowym pliku bfd/elf.c biblioteki libbfd wchodzącej w skład binutils w wersji 2.24 i wcześniejszych posiadała podatność bezpieczeństwa. Jeśli użytkownik zostałby nakłoniony do analizy programem strings specjalnie spreparowanego pliku, mogłoby to spowodować krach tego narzędzia lub potencjalne wykonanie dowolnego kodu z uprawnieniami użytkownika uruchamiającego proces analizy. Dlatego od wersji 2.26 wydanej 26 stycznia 2014 roku domyślnym wywołaniem strings jest parametr -a, który powoduje skanowanie całego pliku z pominięciem używania biblioteki BFD:

commit 7fac9594c41ab180979bdf5927ff7f7e1d13a9e9
Author: Nick Clifton 
Date:   2014-10-31 10:10:37 +0000

    In response to a public outcry the strings program now 
    defaults to using the --all option which displays text
    from anywhere in the input file(s).  The default used 
    to be --data, which only displays text from loadable
    data sections, but this requires the use of the BFD
    library.  Since the BFD library almost certainly still
    contains buffer overrun and/or memory corruption bugs,
    and since the strings program is often used to examine
    malicious code, it was decided that the --data option
    option represents a possible security risk.

W celu użycia ponownie biblioteki BPD musimy użyć parametru -d (--data), aby wyświetlić ciągi znaków tylko z zainicjalizowanych i załadowanych sekcji danych w pliku. Może to zmniejszyć ilość śmieciowych danych na wyjściu, ale należy pamiętać, że naraża to także program na wszelkie luki w bezpieczeństwie, które mogą być jeszcze obecne w bibliotece BFD używanej do skanowania i ładowania takich sekcji.

Więcej informacji: PSA: don’t run ‘strings’ on untrusted files (CVE-2014-8485), CVE-2014-8485, Scan the whole file commit

S

ystem Linux oferuje różnorodne metody przyznawania uprawnień do plików. Oprócz tradycyjnej, uznaniowej kontroli dostępu (DAC – Discretionary Access Control) obsługuje również listy kontroli dostępu (ACL – Access Control Lists) i obowiązkową kontrolę dostępu (MAC – Mandatory Access Control). Wszystkie te mechanizmy działają na podstawie przyznawania uprawnień, gdy domyślnie nic nie jest dozwolone. To podejście jest również czasami określane jako listy dostępowe (ang. allow list). Analogicznie, jak przy tworzeniu reguł dla zapór sieciowych – blokujemy wszystko i zezwalamy na selektywny ruch. Jednak zarówno DAC i jego rozwinięcie ACL pozwalają na implementację negatywnych uprawnień. Negatyw – występuje tutaj jako pojęcie odwrotności pozytywu – czyli dodawania uprawnień w zupełnie inny sposób niż to przyjęto – odwołując się do poprzedniego przykładu – blokujemy selektywny ruch, ale wszystko inne jest dozwolone. W przypadku dostępu do plików uprawnienia takie uniemożliwiają dostęp określonym użytkownikom lub grupom, gdy wszyscy inni zachowują dostęp. Tego typu praktyka jest raczej rzadkością, za to powszechnie postrzegana jako zła w przypadku uprawnień i ruchu sieciowego.
[ czytaj całość… ]

N

iewiele osób zdaje sobie sprawę z faktu, że polecenie ldd służące do wyświetlania bibliotek współdzielonych wymaganych przez dany program nie jest plikiem binarnym tylko skryptem w języku bash:

agresor@darkstar:~$ whereis ldd
ldd: /usr/bin/ldd /usr/share/man/man1/ldd.1.gz
agresor@darkstar:~$ file /usr/bin/ldd
/usr/bin/ldd: Bourne-Again shell script, ASCII text executable

W dodatku, jeśli przeczytamy stronę manualną tego polecenia natchniemy się na taki zapis:

Należy pamiętać, że w pewnych okolicznościach (np. gdy program określa interpreter ELF inny niż ld-linux.so), niektóre wersje ldd mogą próbować uzyskać informacje o zależnościach, próbując bezpośrednio wykonać program, co może doprowadzić do wykonania dowolnego kodu zdefiniowanego w interpreterze programu ELF, a być może do wykonania samego programu (w wersjach glibc 2.27, implementacja upstream ldd na przykład to robiła, chociaż większość dystrybucji dostarczała zmodyfikowaną wersję, która tego nie robiła).

Dlatego nigdy nie należy używać ldd na niezaufanym pliku wykonywalnym, ponieważ może to spowodować wykonanie dowolnego kodu.

Zapis ten znajduje swoją historię w CVE-2009-5064, czyli luce w sposobie, w jaki narzędzie ldd identyfikowało biblioteki dołączane dynamicznie. Jeśli osoba atakująca mogłaby nakłonić użytkownika do uruchomienia ldd na złośliwym pliku binarnym, mogłoby to spowodować wykonanie dowolnego kodu z uprawnieniami użytkownika uruchamiającego ldd. Przykłady takich aplikacji mogą zostać stworzone np. za pomocą osobnej biblioteki C do tworzenia wbudowanych systemów Linux. Wystarczy zlinkować szkodliwy kod z nowym programem ładującym, z którego usuniemy / zakomentujemy wykrywanie zmiennej LD_TRACE_LOADED_OBJECTS:

/*
   if (_dl_getenv("LD_TRACE_LOADED_OBJECTS", envp) != NULL) {
           trace_loaded_objects++;
   }
*/

Spowoduje to, że szkodliwy program zostanie uruchomiony przez program ładujący nawet, jeśli narzędzie systemowe ustawi taką zmienną. Teraz w samym programie należy wykrywać w/w zmienną, aby uzależnić od niej wersję uruchomionego kodu:

#include <stdio.h>
#include <stdlib.h>

int main()
{
   /* wykrycie uruchomienia ldd */
   if (getenv("LD_TRACE_LOADED_OBJECTS") != 0) {
      printf("szkodliwy kod\n");
      printf("\tlibc.so.6 => /lib/libc.so.6 (0x4001d000)\n");
      printf("\t/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)\n");
      return 0;
   }

   printf("normalny kod\n");
   return 0;
}

Jak widzimy nie do końca jest bezpieczne uruchamianie ldd na niezaufanych plikach binarnych. Skrypt ldd używa dynamicznego linkera do załadowania pliku binarnego i jego zależności do pamięci, a następnie polega na samym dynamicznym konsolidatorze, aby wyświetlić szczegóły w konsoli. Z tego powodu proces ten może być nadużywany w inny sposób niż zgodnie z przeznaczeniem np. do wstrzyknięcia kodu, jak było to w przypadku CVE-2019-1010023. W jaki więc sposób sprawdzać zależności? Oczywiście nieznane pliki binarne powinny być sprawdzane na specjalnie przygotowanym do tego środowisku. Po drugie możemy skorzystać bezpośrednio z linkera systemowego:

agresor@darkstar:~$ /lib64/ld-linux-x86-64.so.2 --verify /bin/ls \
                    && echo 'Plik obsługiwany!' || echo 'Plik nieobsługiwany!'

Jeśli plik jest obsługiwany, możemy go sprawdzić za pomocą składni:

agresor@darkstar:~$ LD_TRACE_LOADED_OBJECTS=1 /lib64/ld-linux-x86-64.so.2 /bin/ls
	linux-vdso.so.1 (0x00007ffe3b1dd000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f4b1111f000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4b10ef7000)
	libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f4b10e60000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f4b11177000)

No i proszę. Otrzymujemy dokładnie taki sam wynik, jaki wytworzyłby skrypt ldd (minus różnice w adresach pamięci pod którymi zostały załadowane biblioteki, ale to ze względu na ASLR).

Więcej informacji: ldd(1) and untrusted binaries, Compromising analysis tools, ldd can execute an app unexpectedly, The GNU C Library version 2.27 is now available

3

lipca odnośnik do eksploita umożliwiającego uzyskanie uprawnień administratora w systemie Linux rozprzestrzenił się w różnych społecznościach na Telegramie i Twitterze. Napisała nawet o tym prasa branżowa. Rzekomy kod dowodu koncepcji (Proof of Concept – PoC) błędu opisanego w CVE-2023-35829 niestety okazał się zupełnie czymś innym niż pierwotnie zakładano. Przed usunięciem fałszywego profilu użytkownika ChriSanders22 z serwisu GitHub kod PoC został oznaczony gwiazdką przez ponad 100 użytkowników, a 25’ciu rozgałęziło go na swoje konta. Kilka osób, które uruchomiło kod bez jego weryfikacji zauważyło dziwne zmiany w plikach konfiguracyjnych powłoki bash – $HOME/.bashrc. Jak to? Co ma wspólnego exploit z dopisywaniem czegoś o plików powłoki? Otóż jeśli przyjrzeć się bliżej procesowi kompilacji to można zauważyć, że plik Makefile odwoływał się do binarnego pliku alocal.m4:
[ czytaj całość… ]

Przeglądając na bieżąco raporty odnośnie szkodliwego oprogramowania przeznaczonego dla systemów Linux – można dojść do wniosku, że wszystkie warianty można połączyć poprzez wykrywanie poleceń curl lub wget ściągających ładunek z publicznego adresu IP:

=~ (curl|wget).*(\b25[0-5]|\b2[0-4][0-9]|\b[01]?[0-9][0-9]?)
   (\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3}(:[0-9]+)?\/.+.*

W celu wykluczenia fałszywych alarmów (szczególnie w centrach danych) można połączyć to z regułą, która wykluczy komunikację w ramach lokalnych sieci:

!=~ (curl|wget).*((127(?:\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3})|
    (10(?:\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){3})|
    (192\.168(?:\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)){2})|
    (172\.(?:1[6-9]|2\d|3[0-1])(?:\.(25[0-5]|2[0-4][0-9]|
    [01]?[0-9][0-9]?)){2}|169\.254\.169\.254|0\.0\.0\.0))(:[0-9]+)?\/.+.*

Więcej informacji: How Malicious Actors Abuse Native Linux Tools in Attacks, Log4j Attack Payloads In The Wild, Triaging a Malicious Docker Container, Attackers exploit CVE-2021-26084 for XMRig crypto mining on affected Confluence servers, Technical Advisory: Zero-day critical vulnerability in Log4j2 exploited in the wild, DreamBus Botnet – Technical Analysis, Threat Alert: Kinsing Malware Attacks Targeting Container Environments

P

ocząwszy od wersji 4.19 jądra systemu Linux możliwe jest uniemożliwienie otwierania FIFO lub zwykłych plików niebędących własnością użytkownika w globalnie zapisywalnych katalogach z ustawionym sticky bit (np. /tmp). Ochronę tę można stosować osobno dla FIFO, zwykłych plików, symlinków / hardlinków poprzez odpowiednie ustawienia z poziomu sysctl. Ustawienia te oparte są na łatce HARDEN_FIFO, która znajdowała się w projekcie Openwall Solar Designera, a ich celem jest utrudnienie ataków polegających na spoofingu danych. Poniżej znajduje się krótka lista starych luk, którym można było zapobiec dzięki tej funkcji (niektóre z nich pozwalają nawet na eskalację uprawnień):
[ czytaj całość… ]

C

lamAV to silnik antywirusowy typu open source, który jest szeroko stosowany na serwerach pocztowych oraz różnych komercyjnych, “zamkniętych skrzynkach”. 15 lutego 2023 roku na blogu programu został opublikowany biuletyn bezpieczeństwa szczegółowo opisujący potencjalną lukę umożliwiającą zdalne wykonanie kodu w swoim parserze systemu plików HFS+ (głównym problemem jest brak sprawdzania rozmiaru podczas kopiowania bloków do bufora węzła). Luce tej nadano CVE: CVE-2023-20032. Co ciekawe podczas analizy poprawek tych luk Jared Stroud natknął się na otwarty pull request wskazujący, że nieuprzywilejowani użytkownicy mogą wyłączyć daemona clamav.
[ czytaj całość… ]

W

biologii symbiont to organizm żyjący w symbiozie z innym organizmem (np. bakterie w jelicie grubym u człowieka, bakterie; które trawią celulozę u przeżuwaczy). Symbioza może być obustronnie korzystna dla obu organizmów, ale czasami może być pasożytnicza, gdy jeden organizm zyskuje, a drugi jest uszkadzany. Kilka miesięcy temu zespoły bezpieczeństwa z firmy Intezer oraz BlackBerry odkryły nowe, dobrze maskujące się złośliwe oprogramowanie dla systemu Linux, które działa właśnie w taki pasożytniczy sposób. Tym, co odróżnia Symbiote od innych złośliwych programów dla systemu Linux, z którymi zazwyczaj można się spotkać, jest fakt, że musi zainfekować inne uruchomione procesy, aby wyrządzić szkody zainfekowanym maszynom. Nie jest to samodzielny plik wykonywalny uruchamiany w celu zainfekowania systemu, ale biblioteka obiektów współdzielonych (.so), która jest ładowana do wszystkich uruchomionych procesów przy użyciu LD_PRELOAD (T1574.006) i pasożytniczo infekuje maszynę. Po zainfekowaniu wszystkich uruchomionych procesów zapewnia aktorowi funkcjonalność rootkita, możliwość zbierania poświadczeń oraz zdalny dostęp.
[ czytaj całość… ]