K

iedy używamy serwisów zapewniających anonimowość i prywatność w internecie, bardzo ważne jest, aby cały ruch sieciowy pochodzący z naszego komputera, był przesyłany poprzez sieć zapewniającą taką właśnie usługę. Jeśli jakikolwiek ruch (przez dowolny protokół) wycieka – czyli – nie używa bezpiecznego połączenia z internetem, to każdy, kto (np. ISP) będzie monitorować aktywność Twojego komputera, jest w stanie wychwycić ten ruch sieciowy.
[ czytaj całość… ]

D

awid Golunski w formie. Serwer MySQL oraz jego odmiany (MariaDB, Percona) są podatne na eskalację uprawnień poprzez możliwość wygrania sytuacji wyścigu. Podatność pozwala lokalnemu użytkownikowi systemu na eskalację uprawnień i dowolne wykonanie kodu jako użytkownik bazy danych – najczęściej „mysql” – za pomocą dostępu zwykłego konta do bazy danych z podstawowymi uprawnieniami (CREATE/INSERT/SELECT). Eksploatacja zakończona sukcesem pozwala atakującemu na uzyskanie dostępu do wszystkich baz danych przechowywanych na podatnym serwerze. Wraz z połączeniem z innymi błędami może dojść nawet do pełnej kompromitacji systemu poprzez uzyskanie praw administratora. Wystarczy, że atakujący stworzy bazę danych w tymczasowym katalogu i wykona na niej operację REPAIR, która pozwoli mu na wygranie wyścigu przed operacją chmod(). W oknie atakujący może zamienić plik bazy danych na symlink do katalogu /var/lib/mysql. W ten sposób wcześniej ustawione prawa dostępu bazy np. 777 zostaną przeniesione na katalog, na który wskazuje symlink. Inne wykorzystanie tej luki umożliwia uzyskanie powłoki systemowej z uprawnieniami użytkownika, z którymi został uruchomiony serwer MySQL. Podatne są wersje:

MariaDB: 
	< 5.5.52
	< 10.1.18
        < 10.0.28
MySQL:
	<= 5.5.51
	<= 5.6.32
	<= 5.7.14
Percona Server:
	< 5.5.51-38.2
	< 5.6.32-78-1
	< 5.7.14-8
Percona XtraDB Cluster:
	< 5.6.32-25.17
	< 5.7.14-26.17
	< 5.5.41-37.0

Więcej informacji: PoC oraz Exploit wraz z szczegółowym opisem podatności

B

oty skanują Internet 24 godziny na dobę, 365 dni w roku. Niektóre są dobre, niektóre złe, a jeszcze inne neutralne. Mnie osobiście podobnie, jak innych użytkowników zaczęło zastanawiać dlaczego ktoś pyta o adres /testproxy.php szukając otwartych serwerów proxy? Szczególnie, że podszywa się pod host: testX.pospr.waw.pl lub testX.piwo.pila.pl. Większość zwrotnych adresów IP prowadzi do polskiej firmy hostingowej. Nie należy od razu pochopnie wydawać opinii, że za całym tym incydentem stoi owa firma, ponieważ każda platforma hostingowa, która posiada slogan „Testuj bezpłatnie przez X dni” może paść ofiarą osób, które cyklicznie korzystają z takiej oferty, a przez ten czas instalują szkodliwe oprogramowanie, aby skanować Internet w poszukiwaniu różnych luk.
[ czytaj całość… ]

B

łąd w programie tar umożliwia pomyślne wypakowanie plików i katalogów do dowolnej lokalizacji, gdy podsunie mu się odpowiednio spreparowany plik archiwum. W przypadku, gdy na systemie zostanie rozpakowane archiwum dostarczone przez atakującego podatność może zostać wykorzystania do nadpisania wrażliwych plików zwykłego użytkownika (np. .ssh/authorized_keys, .bashrc, .bash_logout, .profile, .subversion, czy .anyconnect), a w przypadku użycia tar przez administratora np. podmiany /etc/shadow, wpisów cron użytkownika root, plików binarnych na te zawierające tylną furtkę lub atrybut suid.
[ czytaj całość… ]

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

6 października napisał do mnie mejla Borys Lącki o temacie, który raczej przyciągnął od razu moją uwagę, ponieważ było w nim słowo: „ALAAAAAAAAAAAAAAAAAAAARM”. Gdzie się paliło? Otóż historia jest na tyle ciekawa, że bardziej przypomina dwie osoby patrzące na siebie poprzez dwa ustawione lustra pod kątem 90%. W treści wiadomości były też screenshoty zawierające pełną ścieżkę URL do systemu webalizer, który przelicza liczbę odwiedzin dla NF.sec. Skąd Borys wiedział o tym URL? Przecież adres był w głębokim ukryciu ;). Wyjaśnienie jest proste. Ja na swoim webalizerze zobaczyłem w refererach adres pochodzący z bothunters.pl. Nie otworzyłem nowej karty i wykonałem sekwencji Ctrl+C,Ctrl+V tylko odruchowo kliknąłem w link. W tym momencie mój adres webalizera pojawił się jako referer w systemie statystyk bothunters. Chwila zapomnienia i miejscówka spalona. Ale nie o tym – temat jest na tyle ciekawy w kontekście odkrycia, które udostępnił na Twitterze Kacper Rybczyński.
[ czytaj całość… ]

Z

nowu IofT dał popalić Internetowi. Jak powstrzymać te wszystkie urządzenia przed przejęciem? Hmm… najlepiej je zamknąć przed zewnętrznym dostępem. Ale jak? Co łączy wszystkie te urządzenia? Może protokół? Ale jaki? HTTP. No tak, ale nie wstrzykniemy nim przecież uwierzytelnienia. To musi być coś uniwersalnego… No tak! UPnP. Spójrzmy ile mniej więcej jest wystawionych interfejsów tego protokołu. Według shodana prawie 14 milionów (dokładnie: 13,968,198). To już daje jakieś pole do popisu. Zacznijmy od routerów.
[ czytaj całość… ]

9

letni błąd w jądrze systemu Linux pozwala na lokalne podniesienie uprawień poprzez sytuację wyścigu w sposobie, w jaki podsystem pamięci obsługuje kopiowanie przy zapisie (Copy On Write – COW). Nieuprzywilejowany użytkownik może wykorzystać tę lukę, aby zdobyć dostęp do zapisu zmapowanej pamięci będącej normalnie tylko do odczytu i tym samym podnieść swoje uprawnienia. Skutkuje to możliwością obejścia standardowego mechanizmu uprawnień oraz modyfikacją wrażliwych plików binarnych systemu. Błąd istnieje od 2007 roku, czyli mniej więcej od wersji 2.6.22 i został naprawiony 18.10.2016. Luka nadal mogła zostać w ukryciu, gdyby nie Phil Oester, który przeanalizował włamanie na jeden ze swoich serwerów (przechwytywał cały, przychodzący ruch do swoich webserwerów – jak twierdzi zawsze to pomaga w informatyce śledczej) i odtworzył binarny plik eksploita użytego przez włamywacza. Przeanalizował jego działanie i przekazał oficjalnym opiekunom jądra Linuksa. PoCe znajdują się tutaj.

Więcej informacji: Dirty COW (CVE-2016-5195) is a privilege escalation vulnerability in the Linux Kernel

W

świecie HTTP istnieje wiele nagłówków. Niektóre z nich starają się nas chronić inne – wręcz przeciwnie. Poszczególne urządzenia równoważenia obciążenia, serwery www oraz aplikacje webowe ujawniają informacje odnośnie swoich wersji. Czasami dochodzi również do ujawnienia informacji o wewnętrznych sieciach przed którymi się one znajdują. Poniżej zamieszczam kilka przykładów takich wycieków.
[ czytaj całość… ]

S

pójrzmy na poniższy nagłówek HTTP przechodzący przez urządzenie BIG-IP firmy F5 Networks zawierający ciasteczko powodujące przywiązanie klienta do jednego serwera z backendu:

HTTP/1.1 403 Forbidden
Date: Mon, 17 Oct 2016 07:56:53 GMT
Server: Apache
Content-Type: text/html; charset=iso-8859-1
Set-Cookie: BIGipServerCRM-entryhttps_WAF-Pool=872768522.15168.0000; path=/
Transfer-Encoding: chunked

Zamieńmy liczbę 872768522 na wartość heksadecymalną: 3405640A, rozbijmy ją od tyłu na bloki i ponownie wróćmy do wartości decymalnych:

0A = 10
64 = 100
05 = 5
34 = 52

Hmm… czyżby właście wyciekła informacja o wewnętrznym adresie serwera 10.100.5.52? Zróbmy analogiczną konwersję z liczbą 15168 (3B40), która pewnie oznacza port do komunikacji:

403B = 16443

Finalnie otrzymujemy: 10.100.5.52:16443. Dość ciekawą informacją jest fakt, że samo F5 Networks ujawnia, jak zaszyfrować i rozszyfrować takie dość nieprzemyślane ciasteczko.

Więcej informacji: Overview of BIG-IP persistence cookie encoding