NFsec Logo

Utrzymanie stałego dostępu poprzez menedżery pakietów Linuksa

13/04/2021 w Bezpieczeństwo, Pen Test Możliwość komentowania Utrzymanie stałego dostępu poprzez menedżery pakietów Linuksa została wyłączona

W

yobraźmy sobie taki scenariusz – jesteś członkiem zespołu Red Team, który ma kompetencje w zakresie systemu Linux. Twoim zadaniem jest opracowanie ćwiczenia, w którym musisz zachować dostęp do skompromitowanego systemu przez jak najdłuższy czas. Posiadając uprawnienia administratora myślisz o dodaniu jakiegoś zadania w cron lub innej klasycznej lokalizacji (np. rc.local), ale wiesz że Blue Team je systematycznie sprawdza. Przez chwilę myślisz o doczepieniu tylnej furki jakieś binarce, tylko problem w tym, że dostęp ma być utrzymany jak najdłużej, a skompromitowana maszyna jest ustawiona na regularną aktualizację łatek bezpieczeństwa, więc wszelkie pliki wykonawcze lub inne krytyczne komponenty systemu mogą zostać nadpisane wersjami domyślnymi.
[ czytaj całość… ]

Ściągawka z informatyki śledczej w wykrywaniu włamań za pomocą linii poleceń Linuksa

16/04/2020 w Bezpieczeństwo Możliwość komentowania Ściągawka z informatyki śledczej w wykrywaniu włamań za pomocą linii poleceń Linuksa została wyłączona

C

raig H. Rowland na konferencji Purplecon 2018 opowiedział o szybkiej ocenie kompromitacji systemu Linux. Jak zauważył, 90% wdrożeń opartych na publicznych chmurach obliczeniowych odbywa się na systemie operacyjnym Linux. Nawet jeśli nie mamy z nim bezpośrednio do czynienia z powodu wysokich poziomowo abstrakcji i wywołań (np. API) – prędzej czy później natchniemy się na niego, a jako przyszły administrator dobrze posiadać wiedzę o jego działaniu oraz czy jego zachowanie nie budzi jakiś zastrzeżeń. Jeśli posiadamy podejrzenie, że doszło do naruszenia jego bezpieczeństwa – nie panikujmy. Podstępując pochopnie możemy tylko pogorszyć sytuację poprzez zniszczenie krytycznej informacji z punktu widzenia analizy pozwalającej ustalić główną przyczynę włamania.
[ czytaj całość… ]

Kroniki Shodana: Kibana

26/10/2019 w Pen Test Możliwość komentowania Kroniki Shodana: Kibana została wyłączona

2

1 października został opublikowany eksploit wykorzystujący już załataną lukę w komponencie GUI do wizualizacji danych Elasticsearch o nazwie Kibana. Elasticsearch i Kibana są częściami popularnego stosu narzędzi o nazwie Elastic Stack (znanego również jako ELK Stack) – serii otwartych aplikacji służących do scentralizowanego zarządzania logami i nie tylko. CVE-2019-7609 to luka w zabezpieczeniach umożliwiająca wykonywanie dowolnego kodu w rozszerzeniu Kibany – Timelion. Luka została naprawiona w lutym 2019. Zgodnie z poradą firmy Elastic dotyczącą luki osoba atakująca, które ma dostęp do aplikacji Kibana oraz rozszerzenia Timelion „może wysłać żądanie, które spróbuje wykonać kod JavaScript”, co może spowodować, że zostanie wykonane dowolne polecenie na hoście o tych samych uprawnieniach, na których jest uruchomiony silnik nodejs Kibany.
[ czytaj całość… ]

Słonie leżą na betonie, czyli kolejne strzały do Hadoopa

05/10/2017 w Pen Test Możliwość komentowania Słonie leżą na betonie, czyli kolejne strzały do Hadoopa została wyłączona

W nawiązaniu do przeglądania danych na Hadoopie poprzez „ukryty” URL – /browseDirectory.jsp spróbujmy dzisiaj dostać się do jego serwerów. Podobnie, jak Mesos Hadoop jest frameworkiem do rozproszonego przetwarzania zadań… więc po prostu rozprasza zadania do wykonania na klastrze. W prostym modelu uwierzytelniania bez żadnego filtrowania sieciowego dla wystawionych usług możemy dowolnie wykonać polecenia na węzłach klastra za pomocą zadań MapReduce. Nie musimy nawet potrafić pisać poprawnego kodu w języku Java.
[ czytaj całość… ]

Kroniki Shodana: Framework Mesosphere

29/10/2016 w Pen Test Możliwość komentowania Kroniki Shodana: Framework Mesosphere została wyłączona

P

ozostańmy jeszcze przy shodanie. Tym razem po to, aby przyjrzeć mu się z punktu widzenia pewnych mechanizmów, środowiska rozproszonego i – bardziej niebezpiecznego. Kilka dni temu, pojawiła się wiadomość, że DC/OS stał się dostępny w chmurze obliczeniowej Azure. W praktyce oznacza to, że uruchamiając X maszyn wirtualnych w tej usłudze, będziemy w stanie spiąć je w jeden klaster, oferujący wspólne zasoby obliczeniowe, pamięciowe i dyskowe. Zyskamy także możliwość dowolnego dzielenia tych zasobów, wedle naszych potrzeb i rodzajów aplikacji, które będziemy chcieli uruchomić.
[ czytaj całość… ]

Hack Hacker Hacking

15/10/2009 w Hackultura Możliwość komentowania Hack Hacker Hacking została wyłączona

Hacker z miłości robi to,
czego inni nie zrobiliby dla pieniędzy.
– /usr/games/fortune

[ czytaj całość… ]

Polecenie ldd i niezaufane pliki binarne

29/07/2023 w Bezpieczeństwo Możliwość komentowania Polecenie ldd i niezaufane pliki binarne została wyłączona

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

Podpisywanie plików za pomocą kluczy SSH

09/05/2023 w Administracja, Bezpieczeństwo Możliwość komentowania Podpisywanie plików za pomocą kluczy SSH została wyłączona

O

podpisywaniu commitów przez SSH już wiemy. Ale czy wiesz, że możesz użyć polecenia ssh-keygen do podpisywania i weryfikowania podpisów na dowolnych danych, takich jak pliki w wypuszczane wersje oprogramowania? Funkcja ta została dodana wraz w wersją OpenSSH 8.0, dlatego jeśli używasz Debian Bullseye / Ubuntu 20.04 lub nowsze – masz już zainstalowaną wystarczająco nową wersję SSH, aby korzystać z tej funkcjonalności. W dodatku jeśli korzystasz z serwisu GitHub lub jakiejkolwiek innej usługi, która używa kluczy SSH do uwierzytelniania to pewnie masz już klucz SSH, którego można użyć do generowania podpisów (jeśli nie to zajmiemy się tym później). Dystrybucja kluczy SSH jest łatwa, ponieważ publiczne klucze SSH to krótkimi jednowierszowymi ciągami, które łatwo skopiować. W dodatku możemy użyć wspomnianego serwisu GitHub jako dystrybutora kluczy – możesz pobrać klucze publiczne SSH dla dowolnego użytkownika odwiedzając adres URL w postaci: https://github.com/$nazwa_użytkownika.keys np. NFsec.
[ czytaj całość… ]

Jak GootLoader zamienia WordPress w zombie SEO

07/07/2022 w Ataki Internetowe, Bezpieczeństwo Możliwość komentowania Jak GootLoader zamienia WordPress w zombie SEO została wyłączona

G

ootloader, czyli usługa wstępnego dostępu do (firmowych) sieci dla cyberprzestępców ostatnio rozszerzyła swój zakres działalności o różne cele na całym świecie. Przypomnijmy: w 2014 roku po raz pierwszy został zauważony trojan bankowy o nazwie Gootkit. Od tego czasu ewoluował, aby stać się bardziej złodziejem poufnych informacji obsługiwanym przez grupę aktorów. Nazwa 'Gootkit’ jest często używana zamiennie – zarówno w odniesieniu do złośliwego oprogramowania, jak i do samej grupy. W marcu 2021 roku firma Sophos jako pierwsza zidentyfikowała szersze możliwości tego oprogramowania i nazwała go GootLoader. Ten oparty o Javascript framework pierwotnie przeznaczony do infekcji Gootkitem w coraz większym stopniu zaczął dostarczać szerszą gamę złośliwego oprogramowania (w tym ransomware). Wczesna aktywność kampanii platformy Gootloader została po raz pierwszy zauważona przez analityka zagrożeń z firmy Proofpoint pod koniec 2020 roku, a następnie zbadana i opisana przez ASEC, Malwarebytes i TrendMicro.
[ czytaj całość… ]

Tunele ICMP i powłoki zwrotne

18/09/2016 w Ataki Internetowe, Bezpieczeństwo Możliwość komentowania Tunele ICMP i powłoki zwrotne została wyłączona

P

rotokół UDP nie jest jedynym, który umożliwia „ukrytą” komunikację. Równie popularnym, jak i rzadko blokowanym jest ICMP. Niestety i on może zostać wykorzystany przez napastników do kontroli nad skompromitowanym systemem. Idea enkapsulacji danych oraz poleceń w ruchu sieciowym za pomocą ICMP w celu stworzenia niewidzialnych kanałów komunikacji została spopularyzowana przez narzędzie Loki opisane w 49 wydaniu Magazynu Phrack z 1996 roku. W 1999’tym botnet Tribe Flood Network (TFN) służący do ataków DDoS po analizie Davida Dittricha ujawnił badaczowi, że używał podobnego schematu komunikacji do zdalnego kontrolowania zainfekowanych systemów. Wśród nowszych narzędzi można wymienić backdoora icmpsh. Tunelowanie ICMP jest możliwe, ponieważ w RFC 792, czyli dokumencie regulującym pakiety ICMP przewiduje się możliwość zawarcia dodatkowych danych dla każdego komunikatu typu 0 (echo replay) oraz 8 (echo request). Zresztą inne komunikaty ICMP mogą również służyć do infiltracji sieci. Standardowym postępowaniem jest ograniczenie łączności tylko do zaufanych (monitorujących) serwerów.

Więcej informacji: Wyciek przez ping, ICMPsh, ICMP Tunnel, Bypassing Firewalls Using ICMP-Tunnel