P

odczas ostatnich testów na SSL Labs zauważyłem nowy wpis, jaki pojawił się na tablicy wyników: DNS CAA: No. O, co chodzi z tym wsparciem dla DNS CAA? CAA jest nowym typem rekordu DNS, który określa, jaki CA (Certificate Authority – określenie organizacji bądź firmy zajmującej się wydawaniem i obsługą elektronicznych certyfikatów) jest uprawniony do wystawienia certyfikatu dla danej domeny. CAA został opisany w RFC 6844 w 2013 roku w celu poprawy siły ekosystemu PKI (Public Key Infrastructure). Niestety przez ostatnie 4 lata pozostawał on tylko w statusie propozycji standardu. Jednak za sprawą ostatniego głosowania CA/Browser Forum ma to się zmienić od 8 września 2017 roku. Po tym czasie standard wydawania certyfikatów zostanie wzbogacony o sprawdzanie rekordów CAA.
[ czytaj całość… ]

W

pierwszej części poznaliśmy prostą metodę przejęcia domeny wraz z jej pozycją SEO oraz reputacją. W dzisiejszym poście omówimy technikę zwaną domain fronting. Na czym ona polega? Dla przykładu spójrzmy na jeden z adresów IP używanych przez frontowy serwer obsługujący domenę www.google.es:

host www.google.es

www.google.es has address 216.58.210.163
www.google.es has IPv6 address 2a00:1450:4003:808::2003

[ czytaj całość… ]

J

ak w środowisku, które jest poddawane dokładnej filtracji sieciowej stworzyć obejście i tunel do własnych serwerów C2? Istnieje wiele dróg, aby ominąć monitoring oraz restrykcje przepływu informacji z jednej sieci do drugiej. W niektórych przypadkach sprawdzą się takie narzędzia, jak ICMPsh lub DNScat. Jednak w tym wpisie zajmiemy się przypadkiem filtrowania przez proxy sieci wewnętrznej odwiedzanych stron internetowych. Coraz częściej firmy nie tylko blokują szkodliwe strony, ale także blokują dostęp do witryn, które zostały niezakwalifikowane do żadnej kategorii ( np. zakupy, finanse, sport itd.) lub posiadają wątpliwą / niską reputację.
[ czytaj całość… ]

W

pierwszej części poznaliśmy podstawowe opcje konfiguracyjne uniemożliwiające wykorzystanie naszego serwera jako open resolver oraz pozyskania plików stref. W tej części zajmiemy się blokowaniem informacji, które mogą dostarczyć atakującemu niezbędnej wiedzy podczas rekonesansu. Serwery BIND (oraz wiele innych) potrafią zwracać “ukryte” informacje, gdy zostanie wysłane do nich specjalne zapytanie DNS. Zazwyczaj nie jest to pożądana ekspozycja dlatego należy ją zablokować.
[ czytaj całość… ]

H

unter Gregal napisał proste narządzie do zrzucania haseł użytych w sesji logowania bieżącego użytkownika na stacji roboczej Linuksa. Skrypt był wzorowany na podstawie popularnego narzędzia dla systemu Windows o nazwie mimikatz. Wykorzystuje on zapisane czystym tekstem dane uwierzytelniające, które są zrzucane razem z pamięcią procesu. Plik z zawartością pamięci jest później przeszukiwany pod kątem linii, które mają wysokie prawdopodobieństwo przechowywania haseł.

Więcej informacji: mimipenguin

P

upilki – na początku nadajesz im nazwę. Później na tych serwerach instalujesz serwisy. Jeśli któryś zostaje zepsuty lub pojedynczy komponent zawodzi musimy go naprawić. Wymienić dysk twardy, odbudować uszkodzony system pliku i tak długo kontynuować opiekę aż wróci do zdrowia. Później pozostaje standardowe dbanie o pupilka – aktualizacje i nakładanie poprawek. Niektóre aplikacje do dzisiaj potrzebują takich pupilków, ale wiele stworzonych w tej dekadzie już nie! Dzisiaj wszystko się zmieniło. Za pomocą RESTowego API możemy stworzyć infrastrukturę i zbudować ją od zera aż do pełnej gotowości w ciągu kilku minut.

Bydło – w dobie chmur obliczeniowych jesteśmy w stanie robić bardziej dynamiczne rzeczy. Możemy łatwo zbudować szablon maszyny wirtualnej (tzw. “golden image“) wraz z uruchomioną aplikacją (od podstaw lub za pomocą migawki) i użyć jej w autoskalowalnym środowisku. Przy użyciu takich narzędzi, jak Ansible, Puppet, Salt oraz Chef możemy zbudować wcześniej przetestowaną infrastrukturę i ją odpalić w dowolnym momencie. 100 serwerów uruchomionych jednym poleceniem. Zamiast nazw operuje się liczbami. Wszystkie te serwery są zasadniczo identyczne. Jeśli jeden umiera wystarczy parę wywołań API (lub nawet nie – jeśli używamy automatycznego skalowania) i następuje zastąpienie wadliwej sztuki. Jeśli krowa jest poważnie chora lub konająca – zabijasz ją i kupujesz kolejną.

Więcej informacji: Pets vs Cattle

P

ierwszym korkiem w każdej ocenie bezpieczeństwa aplikacji mobilnych w Androidzie jest posiadanie pliku .APK, który reprezentuje aktualną wersję aplikacji mobilnej. W większości przypadków to klient (firma, osoba prywatna) jest odpowiedzialna za dostarczenie nam tego pliku – szczególnie w sytuacji, gdy aktualna wersja aplikacji nie jest publicznie dostępna. Chyba, że chcemy lub zlecono nam ocenę czarnej skrzynki (ang. black box) to wówczas w naszym interesie jest pozyskanie takiego pliku. Poniżej znajduje się prosty przykład, jak z publicznie dostępnej aplikacji wyciągnąć developerskie i testowe adresy, które przez zaniedbanie mogły zostać pozostawione w kodzie takiej aplikacji.
[ czytaj całość… ]

W poprzedniej części poznaliśmy teoretyczne przesłanki, na które należy zwrócić uwagę podczas przygotowania się do wdrożenia mechanizmów szyfrowania SSL/TLS. W tej części postaramy się skupić na konfiguracji, która gwarantuje nam poprawne prezentowanie odwiedzającym naszą stronę stosowanych zabezpieczeń i szyfrów kryptograficznych.
[ czytaj całość… ]

C

iekawe demo oraz słuszność swojego pomysłu przedstawił N.J. Hartwell. Pokazuje on, że niektóre znaki zachęty szczególnie te, którym dołożono wyświetlanie nazwy brancha git mogą być podatne na wykonanie dowolnego kodu. Można oszukać naszą, lokalną powłokę, aby wykonała polecenie lub skrypt, jeśli nazwiemy nasz branch na przykład tak: $(./skrypt.sh). Jak sprawdzić czy nasz prompt jest podatny? Wystarczy, że ściągniemy to repozytorium i wejdziemy do niego za pomocą polecenia cd. Jeśli prompt naszej powłoki niepoprawnie przeprowadzi interpretację zestawu znaków $(..) to wykona skrypt ./pw3n i wyświetli (na szczęście) tylko odpowiedni komunikat.

W

parę tygodni po ukazaniu się błędu w protokole DCCP – Andrey Konovalov ponownie odkrywa możliwość eskalacji uprawnień i lokalne uzyskanie praw administratora w sterowniku drivers/tty/n_hdlc.c. Sterownik zapewniający wsparcie dla HDLC występuje jako moduł jądra w wielu dystrybucjach, które mają w konfiguracji ustawioną opcję CONFIG_N_HDLC=m. Standardowo błąd jest obecny w systemie Linux od 2009 roku i również został znaleziony przy pomocy syzkallera. Łatanie systemu jest szybkie i proste, jak w przypadku podatności DCCP – poniżej dla rodziny RedHat:

echo "install n_hdlc /bin/true" >> /etc/modprobe.d/disable-n_hdlc.conf

Więcej informacji: Linux kernel: CVE-2017-2636: local privilege escalation flaw in n_hdlc