U

żytkownicy posiadający UID większy od INT_MAX posiadają możliwość wykonania dowolnego polecenia za pomocą systemctl. Błąd nie tkwi w samym systemd, jak mogliśmy się przyzwyczaić, ale w narzędziu pkttyagent, w którym PolicyKit (polkit) podczas wystąpienia błędu twierdzi, że użytkownik jest uprawniony do wykonania polecenia. Przykład działania takiego zachowania:

$ systemctl --version
systemd 239
$ pkttyagent --version
pkttyagent version 0.115
$ id 
uid=4000000000(someuser) gid=100(users) groups=100(users)
$ systemctl stop sshd.service
(pkttyagent:3342): GLib-GObject-WARNING **: 13:28:53.802: value "-294967296" 
of type 'gint' is invalid or out of range for property 'uid' of type 'gint' **
ERROR:pkttyagent.c:156:main: assertion failed: 
(polkit_unix_process_get_uid (POLKIT_UNIX_PROCESS (subject)) >= 0)
$ systemctl is-active sshd.service
inactive

Luka sama w sobie nie jest groźna, ponieważ do stworzenia użytkownika z takim UID są już wymagane prawa administratora. Można ją jednak użyć do zamaskowania użytkownika, który ma podniesione prawa, a nie ma przypisanego UID/GID=0. Do czasu naprawienia luki można użyć obejścia w postaci wyłączenia polkit’a:

systemctl mask polkit && systemctl stop polkit

Więcej informacji: systemd issue, polkit issue, CVE-2018-19788

J

eśli chcemy odbyć krótką rozmowę o wydajności producenta kafki (w kontekście: logstash → kafka ← logstash → elasticsearch) musimy porozmawiać o dwóch rzeczach. Po pierwsze: opóźnieniu – ile czasu upłynęło od czasu wywołania metody send(), dopóki komunikat nie pojawi się na brokerze. Po drugie: przepustowości – ile wiadomości może wysłać producent do brokera na sekundę. Dlaczego musimy obawiać się o te dwie wartości? Jeśli procesowanie wiadomości zajmuje nam 10 milisekund (opóźnienie) to wyraźnie przepustowość jest ograniczona do 100 wiadomości na sekundę. Patrząc na to w ten sposób można dojść do wniosku, że im wyższe opóźnienie tym większa przepustowość. Jednak związek między opóźnieniem, a przepustowością nie jest tak trywialny.
[ czytaj całość… ]

2

7 lutego 2017 badacz bezpieczeństwa Omer Gil opublikował wpis opisujący atak „Web Cache Deception” (Oszukanie Pamięci Podręcznej Strony Internetowej). Wykorzystuje on funkcjonalność buforowania stron internetowych w celu potencjalnego ujawnienia poufnych informacji lub umożliwienia przejęcia konta (ang. Account Takeover). Buforowanie stron (ang. Web Caching) jest często używane w celu zmniejszenia obciążenia serwerów WWW i czasu ładowania treści stron. Atak Web Cache Deception pokazuje sposoby, w których biorąc pod uwagę pewne konfiguracje serwerów funkcja buforowania może być niewłaściwie użyta do udostępnienia treści nieprzeznaczonych do informacji publicznej. Zarówno buforujący serwer proxy, jak i strona źródłowa indywidualnie mogą mieć poprawne konfiguracje. Jednak w połączeniu ich w jeden system może dojść do nieoczekiwanego zachowania w świetle tej nowej metody ataku.
[ czytaj całość… ]

J

eśli powłoka bash zostanie uruchomiona jako rbash (link symboliczny) lub z opcjami --restricted lub -r – to przejdzie w tryb ograniczony. Ograniczona powłoka służy do umieszczania użytkowników w bardziej kontrolowanym środowisku niż jej standardowy wariant. Zachowuje się identycznie jak bash z poniższymi ograniczeniami:
[ czytaj całość… ]

J

eśli interesują nas wcześniejsze dwie części to znajdziemy je tu (1) i tu (2). Przejdźmy teraz do kolejnej części. W ciągu ostatnich lat bezpieczeństwo webaplikacji stało się bardzo ważnym tematem w dziedzinie IT. Zalety, jakie oferuje sieć sprawiły, że bardzo ważne usługi zostają opracowane jako aplikacje internetowe. Wymagania biznesowe związane z bezpieczeństwem wspomnianych aplikacji również uległy przemianie. Oprócz dobrych praktyk programistycznych wymagane są też dobre praktyki bezpieczeństwa. Stosowane są dodatkowe zabezpieczenia takie, jak WAF (ang. Web Application Firewall). Zapory sieciowe aplikacji to transparentne zapory ogniowe warstwy siódmej, które kontrolują ruch sieciowy i „próbują” chronić aplikację przed atakami.
[ czytaj całość… ]

D

laczego nie zawsze można ufać logom serwera WWW przedstawił Andrzej Broński na łamach serwisu sekurak. Podsumowując: jeśli używamy konfiguracji Apache (prefork MPM) + mod_php (która jest przestarzała i nie zalecana przez Apache), pozwalając w dodatku na wywołania niebezpiecznej funkcji exec może dojść do sytuacji, w której wywołanie skryptu PHP nie zostanie nigdzie zalogowane.
[ czytaj całość… ]

W

przeciwieństwie do wielu podstawowych narzędzi systemów Unix i Linux, nazwa polecenia rm nie jest starsza niż sam Unix. W poprzednikach Uniksa – Compatible Time Sharing System (CTSS) i Multics, polecenie używane do usuwania plików nazywało się delete (w Multics opcjonalnie mogło zostać skrócone do dl). W systemie Unix nazwa rm została prawdopodobnie użyta, aby odzwierciedlić filozofię zmiany z usuwania plików na usuwanie wpisów, które prowadziły do ich pozycji.
[ czytaj całość… ]

J

eśli nie używasz dockera z pomocą docker-machine (standardowo na systemie OSX oraz Windows) to może dojść do sytuacji, gdy polecenia dockera doprowadzą do przejęcia hosta na którym zostały uruchomione. Jeśli dodamy naszego użytkownika systemu do grupy dockera lub zmienimy uprawnienia do gniazda sieciowego – to Twój użytkownik lub szkodliwe oprogramowanie będzie mógło uzyskać uprawnienia administratora bez konieczności podawania hasła.
[ czytaj całość… ]

A

ny-IP w Linuksie to możliwość odbierania pakietów i nawiązywania połączeń przychodzących na adresy IP, które nie są jeszcze skonfigurowane na hoście. Umożliwia to skonfigurowanie serwera, aby odpowiadał w określonym zakresie adresacji sieciowej jakby była ona lokalną – bez konieczności konfigurowania adresów na interfejsie. Dla przykładu: chcemy, aby nasza maszyna odpowiadała dla całej adresacji 192.168.0.0/24 bez konieczności konfiguracji każdego adresu IP na interfejsie/sach.
[ czytaj całość… ]

K

iedy wpisujemy URL w pasku adresu nasz komputer wysyła zapytanie DNS do właściwego serwera DNS i otrzymuje odpowiedni adres IP, który służy do osiągnięcia łączności z docelowym systemem. Protokoły takie, jak SSL/TLS, HTTPS zapewniają szyfrowanie komunikacji pomiędzy serwerem, a klientem po fakcie rozwiązania nazwy domeny. A, co jeśli atakujący przejmie komunikację pomiędzy serwerem DNS i jego klientem podczas procesu rozwiązywania domeny? Przekieruje ruch do spreparowanego serwera w celu kradzieży danych lub przeprowadzenia ataku DoS? W tym celu został opracowany mechanizm bezpieczeństwa pod postacią ciasteczka DNS.
[ czytaj całość… ]