O

statnio napotkałem na dziwny przypadek. Jeden z systemów HIDS – zablokował mnie na moim własnym serwerze. Po wszczęciu postępowania wyjaśniającego okazało się, że przy okazji wyszukiwania paru informacji powiązanych z NF.sec wszedłem na stronę, która linkowała do kilku już nieistniejących zasobów na mojej stronie. Tym samym wygenerowałem szybką serię kodów 404 na serwerze, która została uznana za próbę skanowania i zablokowana. Zdając sobie sprawę z obrotu sytuacji wpadłem na pewien pomysł. W internecie nie posiadamy kontroli nam tym kto, gdzie i do czego linkuje strony. Nie posiadamy też kontroli nam tym – kto będzie czytał i podążał za tymi linkami. Dla robotów internetowych są to kolejne korytarze, które można / trzeba odwiedzać. Nie znają powodu ani kontekstu, dla którego ktoś postawił tam znak skrętu w lewo. Wiedzą tylko, że to jest znak. Doprowadźmy więc do paru potrąceń w ruchu lądowym.
[ czytaj całość… ]

N

arzędzie to pozwala na podglądanie procesów bez konieczności posiadania uprawnień administratora. Pozwala zobaczyć polecenia uruchamiane przez innych użytkowników, zadania cron w trakcie ich wykonywania itp. Świetnie nadaje się do badania systemów podczas testów penetracyjnych oraz CTFach. Jak to możliwe, że widzimy polecenia innych użytkowników? Dopóki proces trwa wiele informacji jest widocznych w procfs. Jedynym problemem jest to, że trzeba czasem złapać te krótko żyjące procesy w bardzo krótkim czasie. Skanowanie katalogu /proc w poszukiwaniu nowych PIDów w nieskończonej pętli może zdać egzamin, ale tym samym będzie zużywać bardzo dużo zasobów procesora.
[ czytaj całość… ]

J

eśli używasz SSH to Twój klient przechowuje w katalogu domowym listę mapującą nazwy hostów i adresy IP każdego zdalnego hosta, z którym się połączyłeś. Ta „baza danych”, znana jako plik known_hosts może zostać wykorzystana przez atakujących, którzy naruszyli konta użytkowników. Rezultatem odczytania tego pliku jest „obraz” sieci, ujawniający, do których systemów mamy jeszcze połączenie. Może ułatwić to szkodliwemu oprogramowaniu i innym szkodliwym skryptom w rozprzestrzenianiu się na inne systemy, gdy tylko jeden system w sieci został skompromitowany. Plik ten jest dostępny w katalogu ~/.ssh każdego użytkownika, który chociaż raz łączył się jako klient SSH z zdalnym systemem. Jest on na tyle użyteczny, że w przypadku zmiany podpisu serwera – klient SSH będzie chronić użytkownika, powiadamiając go o tej sytuacji komunikatem typu:
[ czytaj całość… ]

W

poprzedniej części – dzięki zmiennej środowiskowej udało nam się przyśpieszyć działanie polecenia grep. Dzisiaj zajmiemy się poleceniem: ls. Jeśli polecenie to zajmuje dłuższy czas dla wylistowania bardzo dużej liczby plików – szczególnie jeśli są one umieszczone na sklastrowanych systemach plików typu Lustre możemy sprawdzić, czy ustawienie zmiennej dla niewyświetlania kolorów podczas listowania przyśpieszy operację:

export LS_COLORS='ex=00:su=00:sg=00:ca=00:'

Czyli prosimy ls o niekolorowanie na listingu plików z bitem setuid/setgid, flagą wykonywalności lub możliwościami opartymi na plikach. Analogicznie możemy przyśpieszyć w określonych warunkach (zależy po jakiej treści sortujemy) sortowanie bardzo dużych plików poprzez ustawienie:

export LC_COLLATE=C
export LANG=C

Tylko musimy liczyć się z faktem, że zmieni się zachowanie sortowania, ponieważ program sort uwzględnia te zmienne przy decydowaniu o jego kolejności. Np. LC_COLLATE o wartości en_US.UTF-8 spowoduje, że małe litery zostaną posortowane przed wielkimi literami.

Więcej informacji: When setting an environment variable gives you a 40x speedup

Z

ałóżmy, że mamy listę 2.036.445 haseł, które są zahaszowane algorytmem md5crypt. Naszym celem nie jest złamanie jak największej liczby haseł w dowolnym czasie, ale chcemy to zrobić jak najszybciej (24h). W tym celu musimy sięgnąć po najniżej wiszące owoce – czyli wykorzystać dane odnoszące się do najczęściej używanych haseł przez użytkowników. Najpopularniejsze hasła to te błyszczące słowa, które od razu pojawiają się w czyimś umyśle, gdy strona internetowa poprosi o utworzenie jednego z nich. Wszystkie są niezwykle łatwe do zapamiętania i dzięki temu dziecinnie proste do odgadnięcia za pomocą ataku słownikowego. Kiedy Mark Burnett przeanalizował 3.3 miliona haseł w 2014 roku w celu określenia tych najczęściej używanych – odkrył, że 0.6 procent to 123456. Dlatego używając 10 najczęstszych haseł – cracker może średnio odgadnąć 16 z 1000.
[ czytaj całość… ]

J

akiś czas temu Inti De Ceukelarie odkrył lukę pozwalającą na przeprowadzenie ataku na przestrzeń nazw w postaci adresów e-mail. Wykorzystanie tego błędu pozwala na uzyskanie dostępu do wewnętrznych systemów, mediów społecznościowych lub wewnętrznej komunikacji atakowanej firmy. Ze względu na skalę błąd nadal jest aktualny dla wielu firm, a w swej prostocie jest bardzo prosty do wykonania.
[ czytaj całość… ]

W

systemach operacyjnych każdy proces ma określony zestaw zasobów dostępnych w czasie jego życia. W przypadku Linuksa obejmują one takie rzeczy jak: ilość otwartych plików, rozmiar pliku z zrzutem pamięci, liczbę wątków, czy rozmiar stosu. Każdy zasób ma dwie granice: miękką (ang. soft) oraz twardą (ang. hard). Wartość graniczna zasobów może wahać się pomiędzy [miękką, a twardą] granicą. Pierwszą można uznać za wartość domyślną, a drugą za wartość maksymalnego pułapu. Zadaniem jądra jest upewnienie się, że te ograniczenia są egzekwowane.
[ czytaj całość… ]

T

a część będzie zupełnie inna od poprzednich trzech (1, 2, 3). Jako użytkownik polecenia sudo na pewno zauważyłeś, że czasami sudo nie prosi o hasło, ponieważ pamięta nas jako użytkownika. Jak to się dzieje, że jesteśmy pamiętani? Czy możemy sfałszować taką tożsamość i uzyskać prawa administratora? Otóż sudo tworzy plik dla każdego użytkownika Linuksa w /var/run/sudo/ts/$USER. Pliki te zawierają udane i nieudane procesy uwierzytelnienia, które są używane przez sudo do zapamiętywania wszystkich uwierzytelnionych procesów.
[ czytaj całość… ]

K

ilka lat temu opisałem, jak w prosty sposób można przyśpieszyć działanie strony za pomocą mechanizmu DNS Prefetch. Zdając sobie sprawę, że usługa DNS, a prywatność to dwie różne ścieżki – okazuje się, że i ten mechanizm z punktu widzenia bezpieczeństwa ma swoje negatywne aspekty. Duża liczba zapytań DNS, które wywołuje ten mechanizm może dać atakującemu przydatne informacje na temat rozwoju potencjalnych ataków. Na przykład możemy wyobrazić sobie złośliwą stronę internetową, która śledzi użytkowników za pomocą łączy do określonych domen na stronach HTML, a także obserwuje żądania rozpoznawania DNS dla tych domen. Jeśli nasza przeglądarka zaczyna „wchodzić” w tle na inne linki, z których nie mamy zamiaru skorzystać buduje to przestrzeń do potencjalnych nadużyć. W ten sposób ktoś może nam podsunąć złośliwe domeny i wykorzystać je do ataków pokrewnych np. DNS rebinding.
[ czytaj całość… ]

J

eśli znaleźliśmy podatność LFI lub SSRF i chcemy odczytać plik /etc/passwd, ale serwer filtruje wszystko, co zaczyna się od /etc możemy spróbować zrobić to za pomocą wirtualnego systemu plików proc, czyli: /proc/self/root/etc/passwd (chcąć pominąć filtry, aby nie wyzwolić ustawionych alarmów lepiej unikać frazy /etc/passwd i wykorzystać np. plik: /proc/self/root/etc/timezone lub inny). Natomiast, jeśli polecenie jest wykonywane w kontekście powłoki bash możemy wykorzystać obfuskację (ang. obfuscation), czyli zaciemnienie, które i tak zostanie zinterpretowane przez powłokę:
[ czytaj całość… ]