Jak sprawdzić, czy klucz prywatny pasuje do wydanego certyfikatu? Powinny posiadać identyczny skrót SHA256:

openssl rsa -noout -modulus -in kluczdomeny.key 2> /dev/null | sha256sum -

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -

openssl x509 -noout -modulus -in certyfikat.crt 2> /dev/null | sha256sum -

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -

Jeśli jest inaczej to znaczy, że coś poszło nie tak w procesie generowania certyfikatu lub pomyliliśmy pliki.

A

więc firma, na którą dostaliśmy zlecenie audytu posiada na swojej stronie listę kilku pracowników z imienia i nazwiska, a jej rekordy DNS typu MX sugerują, że używa Google Apps dla firmowej domeny. Jak potwierdzić fakt, że dany pracownik posiada adres w formacie: imie.nazwisko@startup.pl i jest istniejącym kontem w usłudze Gmail? Oczywiście możemy wysłać wiadomość e-mail z jakiegoś jednorazowego konta e-mail i oczekiwać na zwrotkę w przypadku pomyłki, ale równie dobrze możemy trafić na jakiś adres typu catch-all lub alias prowadzący do innego odbiorcy, a to już komplikuje nam nasze intencje.
[ czytaj całość… ]

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