W

nawiązaniu do „Ściągawki z informatyki śledczej w wykrywaniu włamań za pomocą linii poleceń Linuksa” dzisiaj zajmiemy się maskowaniem procesów, które czasem jest wykorzystywane przez złośliwe oprogramowanie. Z pomocą ponownie przyjdzie nam magia linii poleceń Linuksa, która umożliwi nam zdemaskowanie prawdziwego intruza w systemie. Na początku odpowiedzmy sobie na pytanie: czym jest maskarada procesów jądra Linux? Otóż w systemie Linux jądro posiada wiele własnych wątków utworzonych w celu ułatwienia wykonywania zadań systemowych. Wątki te mogą służyć do planowania obsługi zadań (ang. scheduling), operacji I/O na urządzeniach blokowych, wykonać transakcje księgowania dla systemów plików, okresowej synchronizacji zmodyfikowanych stron pamięci itd.
[ czytaj całość… ]

J

ak możemy sobie przypomnieć atak typu TicketTrick II polega na wykorzystaniu źle skonfigurowanych grup Google. W celu praktycznego przykładu posłużę się jednym ze zgłoszeń, które powędrowało do zespołu Chromium. Żadne wielkie tajemnice nie zostały poznane, ani żadne wielkie restrykcje nie zostały złamane ponieważ:

To join Chromium’s Slack, the organization or person needs to be listed in Chromium’s AUTHOR file. If you have ever contributed a change or belong to one of the active contributor organizations you will be there. Anyone with a @chromium.org address can join directly. Others will have to follow an invite link that you get by mailing a request to chromium-slack-invites (at) chromium.org.

[ czytaj całość… ]

P

isząc i uruchamiając skrypty bash lepiej poczekać z ich edycją do czasu aż zakończą swoje działanie. Dlaczego? W naszym ulubionym edytorze stwórzmy prosty skrypt:

#!/bin/bash
sleep 30
#echo "All your base are belong to us!"
echo "Done!"

Jeśli uruchomimy go teraz w jednym oknie terminala to po 30 sekundach powinniśmy otrzymać tylko i wyłącznie komunikat o treści: Done!. Dobrze, a teraz po uruchomieniu go w pierwszym oknie terminala – z poziomu innego okna edytujmy jego zawartość, gdy ten jeszcze nie przekroczył czasu 30 sekund i usuńmy zero (0) z trzydziestki zostawiając samą trójkę (3), czyli finalnie nasz skrypt powinien mieć postać:
[ czytaj całość… ]

P

odczas słuchania Rozmowy Kontrolowanej z udziałem Michała Purzyńskiego padło narzędzie Observatory od Mozilli. Okazuje się, że w jednym miejscu jesteśmy w stanie sprawdzić konfigurację kilku mechanizmów bezpieczeństwa naszej strony. Od nagłówków HTTP (w tym szczególnie ustawień polityki CSP) poprzez konfigurację TLS, a na opcjonalnych testach dla SSH kończąc. Dodatkowo jeśli interesuje nas wygenerowanie bezpiecznych konfiguracji dla najpopularniejszych serwerów możemy wykorzystać narzędzie Mozilla SSL Configuration Generator.

Więcej informacji: Konfiguracja nagłówków bezpieczeństwa na A+, HTTP Strict Transport Security – wymuszamy SSL na przeglądarkach, Konfiguracja SSL dla Apache na 5+, Konfiguracja SSL dla nginx na 5+, Audytujemy algorytmy szyfrowania SSH

J

eśli interesuje nas stworzenie w naszej sieci firmowej usługi do skracania adresów lub wklejania i udostępniania kawałków teksu – aby nasi użytkownicy nie korzystali z zewnętrznych serwisów i tym samym doprowadzali do wycieków wrażliwych informacji – możemy zainteresować się dwoma projektami. Pierwszy z nich to skracarka anoni.sh, który nie loguje żadnych interakcji użytkownika (tylko anonimowa analityka za pomocą znaczników czasu umożliwiająca śledzenie ogólnego wykorzystania) oraz umożliwia ustawienie własnego (czytaj: odpowiednio długiego i skomplikowanego) klucza. Jego kod dostępny jest na serwisie github, co umożliwia nam własną instalację. Drugim jest minimalistyczny projekt wzorowany na wklejarce pastebin o otwartym kodzie źródłowym, w którym serwer nie posiada wiedzy o wklejanych danych (dane są szyfrowane i deszyfrowane w przeglądarce przy użyciu 256-bitowego AES GCM). Ponadto mamy możliwość ustawienia czasowej retencji, hasła oraz możliwości zniszczenia zawartości od razu po przeczytaniu.

E

ntropia może być wykorzystywana jako miara stopnia losowości. Wiele plików wykonywalnych złośliwego oprogramowania jest spakowana, aby uniknąć wykrycia i utrudnić inżynierię wsteczną (ang. reverse engineering). Twórcy szkodliwego oprogramowania często wykorzystują pakowanie lub zaciemnianie, aby utrudnić wykrycie lub analizę plików. Większość standardowych plików binarnych systemu Linux nie jest spakowanych, ponieważ nie próbują ukryć tego, czym są. Wyszukiwanie plików wykonywalnych o wysokiej entropii to dobry sposób na znalezienie programów, które mogą być złośliwe. Dla danych binarnych wskaźnik 0.0 określa nielosowość, a 8.0 pokazuje zupełną losowość. Dobre szyfrowanie wygląda jak losowy biały szum i będzie bliskie wskaźnika 8.0. Dobra kompresja usuwa zbędne dane sprawiając, że wydają się bardziej losowe niż gdyby kompresja nie miała miejsca i zwykle wynoszą 7.7 lub więcej.
[ czytaj całość… ]

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

A

ppArmor to system obowiązkowej kontroli dostępu (ang. Mandatory Access Control – MAC), który jest rozszerzeniem jądra (ang. Linux Security Modules – LSM) w celu ograniczenia programów do określonego zestawu zasobów. Model bezpieczeństwa AppArmor polega na przywiązywaniu atrybutów kontroli dostępów z programami, a nie z użytkownikami. Ograniczenia są obsługiwane za pomocą profili ładowanych do jądra – najczęściej podczas rozruchu systemu. Profile posiadają zazwyczaj dwa tryby pracy: egzekwowania (ang. enforcement) oraz uskarżania (ang. complain). Profile załadowane w trybie egzekwowania zasad spowodują wymuszanie ograniczeń zdefiniowanych w profilu, a także zgłaszanie prób ich naruszenia za pomocą daemona syslog lub auditd. Profile w trybie składania skarg nie będą egzekwować zasad tylko raportować próby ich naruszenia. Istnieje jeszcze trzeci tryb – audytu (ang. audit), w którym logowane są wszystkie sukcesy i niepowodzenia stosowania zasad z profilu.
[ czytaj całość… ]

W

pierwszej części poznaliśmy możliwości zaatakowania niezabezpieczonych API REST daemonów Docker. W tej części dokończymy kilka aspektów powiązanych z poprzednimi metodami. Po pierwsze nie musimy wykonywać wszystkich poleceń za pomocą stricte żądań HTTP – były one wykonane, aby przekazać Czytelnikowi widzę, jak to wygląda z niższego poziomu. Docker posiada własną wersję klienta przeznaczoną do takiej komunikacji. Dlaczego jeśli wskażemy mu zdalny host możemy wydawać wszystkie polecenia za pomocą lokalnego klienta.
[ czytaj całość… ]

P

odczas raportowania zużycia blokowej pamięci masowej na klastrze Hadoop uruchamiane jest polecenie systemu Linux: du -sk /dysk/pula-bloków. Może to powodować bardzo dużo żądań I/O oraz zwiększone obciążenie na dyskach, które posiadają bardzo wiele plików i są aktualnie utylizowane przez zadania chodzące na klastrze. Nie jest to najbardziej efektywny sposób odpytywania o zajęte miejsce szczególnie kiedy w tym czasie zasoby te powinny być przyznane na inne zadania. W wielu przypadkach może dojść do zakleszczania kiedy przetwarzanie i raportowanie jest opóźnione ze względu nałożenie się czasów wykonania tych operacji na siebie. W przypadku systemu Linux można bardzo prosto podmienić polecenie du na df – jednak w samym oprogramowaniu dystrybucji Hadoop bez aktualizacji do wyższej wersji nie jest to możliwe.
[ czytaj całość… ]