Sposoby zhakowania i ochrony sesji przed kradzieżą

Większość witryn w Internecie jest otwarta na zewnętrzne wpływy hakerów. Nawet duże, drogie projekty internetowe są hackowane: pozostawiają ślady lub zabierają bazę danych. W rezultacie cierpi właściciel zasobu, a także odwiedzający.

Aby uniknąć problemów hakerskich, podczas opracowywania wymagane jest szereg środków. Niektóre działania zapobiegawcze należy przeprowadzić podczas działania witryny.

W poprzednich artykułach pokazywałem, jak działają serwery, a także serwery. Dzisiaj porozmawiamy o przechwytywaniu i ochronie sesji przez hakerów.

Sesja witryny

PHP jest prawdopodobnie najpopularniejszym językiem programowania po stronie serwera dla stron internetowych. W php sesja strony internetowej jest uruchamiana za pomocą polecenia session_start(). Przed rozpoczęciem możesz określić Dodatkowe opcje. Sesja zazwyczaj przechowuje ważne dane osobowe o użytkowniku: login, imię, hasło, ..

Przejmowanie sesji

Identyfikator sesji można przechowywać na 2 sposoby: w plikach cookie oraz w pasek adresu. Pierwsza opcja jest bezpieczniejsza niż druga, ale obie można w różnym stopniu zhakować. Ten typ Włamanie nazywa się przejęciem sesji.

Niech identyfikator będzie przechowywany w adresie URL witryny. Zalogowany gość, przechadzając się po stronach Twojej witryny, decyduje z kimś. Publikując link, podaje link ze swoim identyfikatorem sesji. Jeżeli strona nie posiada żadnych dodatkowych metod ochrony, to klikając w taki link, nowy odwiedzający będzie już zalogowany jako pierwszy użytkownik, o ile sesja jeszcze się nie zakończyła. Następnie rób, co chcesz na stronie, w granicach dozwolonych przez zasady.

Sprawy są bardziej skomplikowane z plikami cookie, ale wszystko jest również dość łatwe do przechwycenia. Wiele witryn nie filtruje skryptów przeglądarki, gdy użytkownicy publikują informacje. Potencjalny haker umieszcza taki skrypt na stronie. Zalogowany użytkownik odwiedza stronę... Skrypt odczytuje wartość pliku cookie lub pasek adresu i przekazuje identyfikator sesji do innej witryny. Druga strona należy do hakera. Co więcej, wszystko jest proste. Plik cookie jest sfałszowany lub wprowadzany jest adres strony witryny z żądanym identyfikatorem sesji.

Hakowanie sesji

Po rozpoczęciu sesji pliki sesji są tworzone w katalogu tymczasowym. Te pliki przechowują informacje. Jeśli jest używany, zwykle folder tymczasowy do przechowywania sesji jest współdzielony przez wszystkie witryny na serwerze. Ponadto, w pewien sposób, dane sesji są odczytywane przez własny skrypt. Aby to zrobić, atakujący musi mieć konto na tym samym serwerze. W rezultacie, jeśli hasło ze strony lub numer karty kredytowej z kodem cvv jest przechowywane w sesji, to wszystko to przydatna informacja wpaść w ręce napastnika.

Ochrona przed włamaniem do danych sesji

  • Przechowuj sesję w plikach cookie. Trudniej wziąć.
  • Powiąż sesję z adresem IP komputera. Podczas wchodzenia z innego adresu IP tworzona jest nowa sesja w zależności od ustawień skryptu.
  • Powiąż sesję z klientem użytkownika przeglądarki. Gdy logujesz się z innej przeglądarki, sesja jest resetowana do zera.
  • Zaszyfruj parametry przekazywane do sesji. Jeśli atakujący otrzyma plik sesji, nie będzie mógł go odczytać. Chociaż jeśli masz pewne umiejętności, możliwe jest również odszyfrowanie sesji.
  • Przechowuj identyfikatory sesji w osobnym folderze. W php jest do tego polecenie session_save_path($path_to_dir). To samo ustawienie można zapisać w pliku php.ini. Parametr nazywa się session.save_path.
  • Użyj session_set_save_handler() w php, aby nadpisać sposób przechowywania sesji. A od PHP 5.4 możesz przekazać obiekt typu SessionHandlerInterface do session_set_save_handler().

Wielu użytkowników nawet nie zdaje sobie sprawy, że wpisując login i hasło podczas rejestracji lub autoryzacji w zamkniętym zasobie internetowym i naciskając ENTER, dane te można łatwo przechwycić. Bardzo często są one przesyłane przez sieć w formie niezabezpieczonej. Dlatego jeśli witryna, na której próbujesz się zalogować, korzysta z protokołu HTTP, bardzo łatwo jest przechwycić ten ruch, przeanalizować go za pomocą Wireshark, a następnie użyć specjalnych filtrów i programów do znalezienia i odszyfrowania hasła.

Najlepszym miejscem do przechwytywania haseł jest rdzeń sieci, gdzie ruch wszystkich użytkowników trafia do zamkniętych zasobów (na przykład poczty) lub przed routerem w celu uzyskania dostępu do Internetu podczas rejestracji na zasobach zewnętrznych. Ustawiamy lustro i jesteśmy gotowi poczuć się jak haker.

Krok 1. Zainstaluj i uruchom Wireshark, aby przechwytywać ruch

Czasami do tego wystarczy wybrać tylko interfejs, przez który planujemy przechwytywać ruch i kliknąć przycisk Start. W naszym przypadku przechwytujemy bezprzewodowo.

Rozpoczęło się przechwytywanie ruchu.

Krok 2. Filtrowanie przechwyconego ruchu POST

Otwieramy przeglądarkę i próbujemy zalogować się do dowolnego zasobu przy użyciu nazwy użytkownika i hasła. Po zakończeniu procesu autoryzacji i otwarciu strony przestajemy przechwytywać ruch w Wireshark. Następnie otwórz analizator protokołów i zobacz dużą liczbę pakietów. Na tym etapie większość specjalistów IT rezygnuje, ponieważ nie wiedzą, co dalej. Ale wiemy i interesują nas konkretne pakiety zawierające dane POST, które są generowane na naszej lokalnej maszynie podczas wypełniania formularza na ekranie i wysyłane do zdalny serwer po kliknięciu przycisku „Zaloguj się” lub „Autoryzacja” w przeglądarce.

Wprowadź w oknie specjalny filtr, aby wyświetlić przechwycone pakiety: http.żądanie.metoda == "POCZTA"

I zamiast tysiąca paczek widzimy tylko jedną z danymi, których szukamy.

Krok 3. Znajdź nazwę użytkownika i hasło

Szybkie kliknięcie prawy przycisk myszką i wybierz z menu Obserwuj TCPSteam


Następnie w nowym oknie pojawi się tekst, który w kodzie przywraca zawartość strony. Znajdźmy pola „hasło” i „użytkownik”, które odpowiadają hasłu i nazwie użytkownika. W niektórych przypadkach oba pola będą łatwe do odczytania, a nawet nie zaszyfrowane, ale jeśli próbujemy przechwycić ruch podczas uzyskiwania dostępu do bardzo znanych zasobów, takich jak: Mail.ru, Facebook, Vkontakte itp., to hasło będzie zakodowane:

HTTP/1.1 Znaleziono 302

Serwer: Apache/2.2.15 (CentOS)

X-Powered-przez: PHP/5.3.3

P3P: CP="NOI ADM DEV PSAi COM NAV NASZ OTRO STP IND DEM"

Ustaw-Cookie: hasło= ; wygasa=Czw, 07-XI-2024 23:52:21 GMT; ścieżka=/

Lokalizacja: login.php

Długość treści: 0

Połączenie: zamknij

Content-Type: text/html; zestaw znaków=UTF-8

A więc w naszym przypadku:

Nazwa użytkownika: networkguru

Hasło:

Krok 4 Określ typ kodowania do odszyfrowania hasła

Wchodzimy np. na stronę http://www.onlinehashcrack.com/hash-identification.php#res i wpisujemy nasze hasło w okienku identyfikacyjnym. Dostałem listę protokołów kodowania w kolejności priorytetów:

Krok 5: Odszyfruj hasło użytkownika

Na tym etapie możemy skorzystać z narzędzia hashcat:

~# hashcat -m 0 -a 0 /root/wireshark-hash.lf /root/rockyou.txt

Na wyjściu otrzymaliśmy odszyfrowane hasło: simplepassword

Tym samym z pomocą Wireshark możemy nie tylko rozwiązywać problemy w działaniu aplikacji i usług, ale także spróbować swoich sił jako haker przechwytując hasła, które użytkownicy wpisują w formularzach internetowych. Możesz również znaleźć hasła do skrzynki pocztowe użytkownicy używający prostych filtrów do wyświetlania:

  • Protokół i filtr POP wygląda tak: pop.request.command == "USER" || pop.request.command == "PASS"
  • Protokół i filtr IMAP to: imap.request zawiera "login"
  • Protokół SMTP i musisz wprowadzić następujący filtr: smtp.req.command == "AUTH"

i bardziej poważne narzędzia do odszyfrowywania protokołu kodowania.

Krok 6. Co jeśli ruch jest szyfrowany i korzysta z protokołu HTTPS?

Istnieje kilka możliwości odpowiedzi na to pytanie.

Opcja 1. Połącz się z rozłączeniem między użytkownikiem a serwerem i przechwyć ruch w momencie nawiązania połączenia (SSL Handshake). W momencie nawiązywania połączenia klucz sesji może zostać przechwycony.

Opcja 2: Możesz odszyfrować ruch HTTPS za pomocą pliku dziennika kluczy sesji napisanego przez Firefox lub Chrome. Aby to zrobić, przeglądarka musi być skonfigurowana do zapisywania tych kluczy szyfrowania w pliku dziennika (przykład oparty na FireFox) i musisz otrzymać ten plik dziennika. Zasadniczo musisz ukraść plik klucza sesji za pomocą twardy dysk innego użytkownika (co jest nielegalne). Cóż, przechwyć ruch i zastosuj otrzymany klucz, aby go odszyfrować.

Wyjaśnienie. Mówimy o przeglądarce internetowej osoby, której hasło zostało skradzione. Jeśli mamy na myśli odszyfrowywanie własnego ruchu HTTPS i chcemy ćwiczyć, ta strategia zadziała. Jeśli próbujesz odszyfrować ruch HTTPS innych użytkowników bez dostępu do ich komputerów, to nie zadziała — do tego służy szyfrowanie i prywatność.

Po otrzymaniu kluczy zgodnie z opcją 1 lub 2 należy je zarejestrować w WireShark:

  1. Przejdź do menu Edycja - Preferencje - Protokoły - SSL.
  2. Ustaw flagę „Ponownie składaj rekordy SSL obejmujące wiele segmentów TCP”.
  3. „Lista kluczy RSA” i kliknij Edytuj.
  4. Wprowadź dane we wszystkich polach i wpisz ścieżkę w pliku klawiszem

W ostatnie lata nastąpiła zmiana trendu w strategii ataków służb specjalnych na najważniejszy protokół bezpieczeństwa dla Internetu TLS/SSL. Od teraz bezpośredni atak kryptograficzny i hakowanie nie jest już tylko ekstremalne, ale często niepotrzebne w ramach nowoczesny światśrodek, w którym pieniądze i zyski finansowe stają się główną siłą napędową.

Ze względu na wagę tego zagadnienia, w ramach cyklu publikacji, serwis oferuje przegląd bezpieczeństwa stosu protokołów TLS/SSL, przy jednoczesnym uwzględnieniu spójnych i systematycznych strategii osłabiania tych protokołów przez agencje wywiadowcze.

Generowana jest jedna trzecia bezpiecznego ruchu na świecie środki kryptograficzne z celowo osłabionym PRNG?

Usunięto z kanału

Jako materiał siewny zwróćmy się do przykładu rosyjskiego – ostatniej rozprawy sądowej w sprawie byłego właściciela system płatności Chronopay Pavel Vrublevsky, oskarżony o atak DDoS na Aeroflot.

Istota kluczowego wątku sprowadzała się do tego, że sąd zażądał korespondencji wewnętrznej między uczestnikami tego procesu karnego, który prowadzili za pośrednictwem konta osobiste na Facebooku. Pomimo tego, że zawierał najważniejsze informacje obciążające, podstępny Amerykanin… sieć społeczna nie uwzględnił wniosku rosyjskiego wymiaru sprawiedliwości i odmówił dostępu do prywatnej korespondencji obywateli Federacji Rosyjskiej. I wtedy następuje bardzo dramatyczny punkt zwrotny w tej historii – FSB, wykonując decyzję sądu, samodzielnie „wydobywa” korespondencję tych obywateli.

„Centralne Biuro Informacyjne FSB, zgodnie z ustawą „O działalności operacyjno-śledczej”, samodzielnie pozyskiwało informacje z kanałów komunikacyjnych tych osób i nagrywało je na płycie DVD”.

Rzeczywiście, później strona obrony była w stanie zweryfikować, że niezbędna korespondencja osobista została „usunięta z sieci w całości i w zakresie” wbrew woli Facebooka. Jednocześnie sami oskarżeni w tej sprawie odmówili udostępnienia śledztwu swoich haseł i korespondencji samoobciążającej. W RuNet można znaleźć krzykliwe nagłówki wiadomości, takie jak „Rosyjskie serwery Facebooka zhakowane przez FSB”, ale nie powinieneś tak daleko wyciągać wniosków.

Po pierwsze, wszystkie sesje komunikacyjne z Facebookiem odbywają się wyłącznie za pośrednictwem bezpiecznego protokołu komunikacyjnego HTTPS. Po drugie, od czasu ostatnich kontaktów oskarżonych i ta decyzja sądowi (a co za tym idzie czynnościom śledczym FSB w celu wykonania tej decyzji) minęło sporo czasu. Z jakiego „kanału” można „usunąć” te „dane z przeszłości”, jeśli sami oskarżeni nie weszli do sieci od tego czasu, będąc przedmiotem dochodzenia?

Zignorowali te bezpośrednie pytania zadawane przedstawicielom FSB podczas procesu. Najbardziej oczywista wersja odpowiedzi sugerowała się sama: ruch HTTPS z tą korespondencją został wcześniej sniffowany / przechowywany przez FSB, a następnie w jakiś sposób zhakowany.

Ciekawe, że prawie podobny przypadek został wcześniej odnotowany w materiałach tego samego przypadku. CIB FSB, powołując się na protokół śledztwa, „zapisując i analizując ruch połączenia internetowego jednego z oskarżonych, odzyskał login i hasło z panelu kontrolnego botnetu” (fizycznie znajdującego się na serwerze w Stanach Zjednoczonych), po który przejął zdalną kontrolę nad tym botnetem. Tak więc, dostęp do tego samego panelu internetowego został przeprowadzony przez oskarżonych ponownie wyłącznie za pośrednictwem szyfrowanego połączenia HTTPS z zachowaniem środków bezpieczeństwa (na przykład bez zapisywania haseł na swoim komputerze lokalnym).

Tym samym stwierdzamy istnienie problemów z bezpieczeństwem HTTPS, powołując się na niesamowite przypadki przełamania „ochrony” TLS/SSL przez rosyjskie służby specjalne.

modus operandi

Aby złamać zaszyfrowaną sesję HTTPS, musisz rozwiązać dwa główne zadania: być w stanie nasłuchiwać (przechwycić) ruch, a także być w stanie odszyfrować dane zawarte w tak bezpiecznym pakiecie.

Nie będziemy się rozwodzić nad pierwszym punktem, ponieważ służby specjalne mają fizyczny dostęp do niemal każdego kanału. Ci, którzy śledzą najnowsze wiadomości z SORMomostroenia, wiedzą już, że zgodnie z nowym prawem, od 1 lipca 2014 r. wszyscy rosyjscy dostawcy są zobowiązani do zainstalowania w swoich sieciach specjalnego sprzętu do rejestrowania i przechowywania ich tranzytowego ruchu internetowego w całości przez pewien czas. okres co najmniej 12 godzin. Ponadto siły bezpieczeństwa będą miały bezpośredni dostęp do wszystkich przechowywanych i tranzytowych tablic danych.

Jeśli mówimy o słuchaniu sesji HTTPS, to od razu zauważamy ważny punkt- konieczność nasłuchiwania w "trybie aktywnym" w niektórych przypadkach, ponieważ zapisany ruch nie zawsze może zostać później zhakowany. Mówimy o tzw. trybie progresywnego tajności (forward secrecy, FS) dla protokołu HTTPS, który uniemożliwia odzyskanie danych po zakończeniu sesji komunikacyjnej (nawet jeśli atakujący może później uzyskać ważne klucze strony). Obecność takiego trybu zobowiązuje atakującego do „wykuwania żelazka na gorąco” – czyli łamania danych w czasie rzeczywistym, co w zdecydowanej większości przypadków jest technicznie mało możliwe.

Zła wiadomość jest taka, że ​​Facebook, podobnie jak większość innych głównych portali internetowych, nie korzysta z trybu utajniania przekazywania, ponieważ powoduje dodatkowe poważne obciążenie i tak już przeciążonej maszyny społecznościowej. Ponadto zastosowanie tak zaawansowanych algorytmów DH może niekorzystnie wpłynąć na kompatybilność z niektórymi popularnymi przeglądarkami. Teraz łatwo zrozumieć, dlaczego według statystyk Netcraft z lata 2013 r. około 70-99% połączeń SSL zaobserwowanych w tym monitoringu w ogóle nie korzystało z FS.

Oznacza to, że w ogromnej większości przypadków atakujący może bezpiecznie przechowywać ruch HTTPS w celu późniejszego pobrania i zhakowania (na przykład, gdy klucz serwera prywatnego stanie się znany).

Powyżej przedstawiono pomiar spadku wydajności na 6-rdzeniowym procesorze serwera WWW z odpowiednio włączonym i wyłączonym DHE. DHE została wybrana jako najpopularniejsza i przykładowa implementacja Perfect Forward Secrecy. Na przykład Google, którego usługi obsługują prawie wszystkie kryptoinnowacje i środki ochrony swoich użytkowników (jest to uderzający wyjątek od ogólnej praktyki internetowej), wdraża krótkotrwałe („efemeryczne”) klucze sesji PFS oparte na ECDHE_RSA. I uwierz mi, to bardzo, bardzo drogie!

Biorąc pod uwagę tę uwagę, założymy, że wszystko jest mniej więcej jasne w przypadku przechwytywania ruchu. Zastanówmy się teraz, co dalej zrobić z zapisanym zaszyfrowanym strumieniem.

Wygląda na to, że ogólny algorytm w tym przypadku będzie wyglądał mniej więcej tak: przechwytując ruch zainteresowania, sesję HTTPS przechwytują hipotetyczne służby specjalne System informacyjny otrzymuje żądanie wyszukiwania odpowiedniego klucza serwera do swojej bazy danych. Jeśli taki klucz nie zostanie odnaleziony, jest on umieszczany w kolejce do dalszych obliczeń (złamania). Biorąc pod uwagę uwagę o faktycznej niedostępności opcji FS, zawsze ma sens po cichu gromadzić (zapisywać) ruch będący przedmiotem zainteresowania, nie czekając na odpowiedź systemu o gotowości/dostępności klucza do odszyfrowania w czasie rzeczywistym.

W odniesieniu do wspomnianej bazy danych z klucze serwera, a następnie latem 2013 r. Cnet opublikował informacje i przykładowy dokument wniosku NSA do dużej firmy internetowej, która chciała pozostać anonimowa. Według tego źródła okazało się, że inne duże strony internetowe (Google, Microsoft, Apple, Yahoo, AOL, Verizon, AT&T itp.) otrzymały te same żądania. Cnet oficjalnie skontaktował się z tymi organizacjami w celu uzyskania komentarza. podobna prośba, ale w zdecydowanej większości przypadków firmy odmówiły potwierdzenia lub zaprzeczenia takich interakcji z NSA.

„Po raz kolejny ocieram się o mit, że open source to droga do niezawodności. Ten błąd w Debianie OpenSSL miał prawie dwa lata."

Rzeczywiście, udało się zamknąć tę lukę dopiero po wrzawie w prasie. Sam projekt Debian nazwał sytuację z długotrwałym błędem w swoim repozytorium OpenSSL „dość dziwną historią”.

Jeśli mówimy o osławionych „zakładkach” sprzętowych, to ostatnio rozkwitły one w brutalnym kolorze już w najbardziej nieoczekiwanych miejscach: od żelazek po ekspresy do kawy. Tak więc według Spiegla, specjalnego wydziału NSA „Special Access Operations” (Tailored Access Operations, TAO) przez długi czas przeprowadził masowe przechwycenie zakupionych najczęściej różne firmy oraz kraje sprzętu komputerowego (i nie tylko) w drodze od dostawcy do adresata. W tym samym czasie przechwycony sprzęt, wysłany do klienta będącego przedmiotem zainteresowania NSA, szybko przeszedł przez tajną „fabrykę” TAO, gdzie wprowadzono do niego zmodyfikowane oprogramowanie lub „błędy”. Taka interwencja w łańcuch dostaw dla własnych celów, określana specjalnym terminem „zakaz”, została oceniona przez samą NSA jako jeden z „najskuteczniejszych rodzajów nowoczesnych operacji”.

Po włączeniu Cały ruch (szyfrowany i nieszyfrowany) lub Tylko zaszyfrowane agent używa technologii fałszowania certyfikatu SSL do przechwytywania danych przesyłanych w bezpiecznych sesjach internetowych. Nawiązując bezpieczne połączenie z serwerem, agent zastępuje oryginalny certyfikat serwera certyfikatem o tej samej nazwie, ale wystawionym przez certyfikat główny agenta. System pozwala na użycie zarówno preinstalowanego certyfikatu, jak i ręcznie utworzonego certyfikatu z urzędem podpisywania jako rootem.

System umożliwia ręczne zainstalowanie określonych certyfikatów w celu podmiany podczas przechwytywania sesji odpowiednich serwerów (stron internetowych, programów) poprzez powiązanie certyfikatu z serwerem.

W niektórych przypadkach użycie nieoryginalnego certyfikatu może uniemożliwić nawiązanie szyfrowanego połączenia z serwerem. W takim przypadku konieczne jest wyłączenie odpowiednich serwerów z przechwytywania, tj. zabronić zastępowania certyfikatów SSL podczas łączenia się z takimi serwerami. Przywróci to funkcjonalność takich witryn lub programów, ale nie będą one przechwytywać zaszyfrowanego ruchu.

Aby skonfigurować przechwytywanie ruchu SSL:

  1. W oknie zakładki Profil ustawień agentaw obszarze edycji profilu wybierz kartę Kontrola ruchu sieciowego.
  2. Naciśnij przycisk Opcje przechwytywania SSL i postępuj zgodnie z zaleceniami obecnego paragrafu.

Wybór trybu fałszowania certyfikatu SSL

W oknie ustawień wybierz akceptowalny tryb przechwytywania:

  • Do automatycznego generowania agent Główny certyfikat SSL podczas instalacji do komputera użytkownika, wybierz opcję Tryb automatyczny . Wygenerowany certyfikat główny zostanie umieszczony w bazie zaufanych wystawców certyfikatów i automatycznie wykorzystany przez agenta do wystawienia certyfikatów podrzędnych podpisanych domyślnie nazwą wystawcy Falcongaze SecureTower.

Aby zmienić nazwę wystawcy certyfikatu, która będzie wskazana w informacjach o bezpieczeństwie połączenia, podaj żądaną nazwę w polu Imię w Certyfikat SSL .

  • Aby użyć niestandardowego certyfikatu SSL jako certyfikatu głównego podczas przechwytywania zaszyfrowanego ruchu, Wybierz opcję Tryb użytkownika. Certyfikat użytkownika musi być wstępnie wygenerowany i dodany do bazy danych systemu. Aby określić certyfikat z bazy danych systemu, wybierz jego nazwę z listy rozwijanejCertyfikat użytkownikalub kliknij przyciskCertyfikaty użytkownika dladodawanie plików certyfikatów i kluczy prywatnych do bazy danych systemu.

W oknie, które się otworzy, kliknij przycisk Dodaj certyfikat i określ certyfikat i pliki kluczy w jeden z następujących sposobów:

  1. Aby wygenerować nowy certyfikat, kliknij przycisk Wygeneruj certyfikat. W oknie, które zostanie otwarte, wprowadź nazwę nowego certyfikatu, okres jego ważności oraz określ ścieżki, w których będą przechowywane nowo utworzone pliki certyfikatu (*.cer) i klucza prywatnego (*.pvk). Kliknij przycisk Generuj.

  1. Jeśli chcesz dodać certyfikat, który został wcześniej wygenerowany w formacie PFX, kliknij przycisk Konwertuj z certyfikatu w formacie PFX. Określ ścieżkę i hasło do pliku certyfikatu w formacie PFX, a także ścieżkę do plików certyfikatu (*.cer) i klucza prywatnego (*.pvk), na które chcesz przekonwertować oryginalny plik. Kliknij przycisk Konwertuj, aby zakończyć konwersję.

Kliknij Dalej w oknie Dodawanie certyfikatów użytkownikakontynuować procedurę wzbogacenie . W oknie, które się otworzy, wpisz unikalną nazwę, którą będzie podpisany dodany certyfikat oraz komentarz (opcjonalnie).

Kliknij Gotowe aby zakończyć proces. Certyfikat zostanie dodany do bazy certyfikatów użytkownika systemu SecureTower. Kliknij OK aby zakończyć dodawanie.Dodano niestandardowe certyfikat zostanie automatycznie umieszczony przez agenta w bazie zaufanych twórców (jeśli nie zrobił tego wcześniej administrator sieci) i będzie następnie używany do wystawiania certyfikatów podrzędnych.

Notatka.

Podczas korzystania z trybu użytkownika zaleca się, aby administrator sieci rozpowszechniał certyfikat użytkownika na wszystkie komputery w sieci za pomocą zasady grupy lub ręcznie. Zapewni to pomyślne uwierzytelnienie certyfikatu. W przeciwnym razie certyfikat zostanie automatycznie dodany przez agenta do zaufanego magazynu certyfikatów.

Powiązanie certyfikatu SSL z serwerem

Aby określić zgodność „certyfikat serwera”, kliknij przycisk Wiązania certyfikatówi postępuj zgodnie z poniższymi wytycznymi:

  • Aby połączyć się z określonym głównym serwerem certyfikatów na karcie Certyfikaty główne, naciśnij przycisk Dodaj certyfikat witryny. Wpisz nazwę hosta ( Nazwa domeny), do którego będą wystawiane certyfikaty podrzędne i z którym certyfikat główny będzie powiązany w polu Nazwa hosta (adres IP). Wybierz jeden z preinstalowanych certyfikatów głównych z listy rozwijanej pól Certyfikat główny lub kliknij przycisk Certyfikaty użytkownika aby dodać i określić pliki certyfikatu i klucza prywatnego na komputerze użytkownika.
  • Aby powiązać już istniejący certyfikat z określonym serwerem, wybierz zakładkę Certyfikaty użytkownika. Agent nie wygeneruje nowych certyfikatów podrzędnych dla serwerów określonych w tej zakładce, ale użyje certyfikatów określonych przez użytkownika do procedur podstawiania. W oknie, które zostanie otwarte, w polu Nazwa hosta (adres IP) wprowadź nazwę hosta (nazwę domeny), z którą będzie powiązany certyfikat. Wybierz jeden z certyfikatów z listy rozwijanej pola Certyfikat : (jeśli certyfikaty zostały już wcześniej dodane) lub kliknij przycisk Certyfikaty użytkownika aby wybrać certyfikaty użytkownika z listy lub dodać i określić pliki certyfikatów i kluczy prywatnych na komputerze użytkownika.

Notatka.

Aby wypełnić pole Nazwa hosta (adres IP) użycie adresu IP hosta jest dozwolone, ale tylko w przypadkach, gdy nazwa hosta nie została ustalona podczas połączenia i znany jest tylko adres IP.

Wykluczenie serwerów z przechwytywania zaszyfrowanego ruchu

Aby pracować z wyjątkami od procesu fałszowania certyfikatu, kliknij przyciskWyjątki serwera SSL.

Okno menedżera wykluczeń wyświetla listę serwerów (hostów) domyślnie wykluczonych z procesu zastępowania. Aby dodać nowe wykluczenie, kliknij przycisk Dodaj wyjątek.

W polu wejściowym w otwartym oknie dialogowym wprowadź nazwę serwera (hosta) (na przykład accounts.google.com) z uwzględnieniem wielkości liter i kliknij przycisk Dodaj. System pozwala na używanie zamaskowanych nazw (czy znaki ? i * są dozwolone, na przykład użycie *.microsoft.* pozwoli uniknąć zduplikowanych zasobów Microsoft na liście wykluczeń) w celu wykluczenia zasobów z tej samej rodziny. Wprowadzona nazwa pojawi się na liście wykluczeń.

Następnie musisz wybrać tryb wykluczenia: Fałszywe certyfikaty tylko dla serwerów SSL wymienionych powyżej, lub Zastępczy SSL - certyfikaty dla wszystkich serwerów poza wymienionymi powyżej. W pierwszym przypadku system będzie fałszował certyfikaty tylko dla serwerów wymienionych na liście wykluczeń (a zatem będzie mógł przechwycić odpowiedni ruch). W przypadku wszystkich innych certyfikaty nie zostaną sfałszowane, a przechwycenie odpowiedniego zaszyfrowanego ruchu będzie niemożliwe. W drugim przypadku system zastąpi certyfikaty dla wszystkich serwerów, z wyjątkiem wymienionych na liście wyjątków.

Aby wykonać inne operacje z wyjątkami, postępuj zgodnie z odpowiednimi zaleceniami w paragrafie

Pokażę i powiem, jak używać narzędzia sslstrip do przechwytywania danych przesyłanych przez bezpieczne połączenie SSL.
Narzędzie sslstrip w moim przykładzie (po wykonaniu ataku ARP-spoofing na ofiarę) przechwyci żądanie klienta internetowego ofiary, aby ustanowić bezpieczne połączenie SSL i zmusi go do użycia niezabezpieczonego protokołu HTTP. Następnie przyjrzę się temu, co robi ofiara, nie zwracając uwagi na fakt, że czyta pocztę nie przez HTTPS, ale przez HTTP.

Zobaczysz, jak łatwo zorganizować ataki wpisz MITM na SSL przy użyciu techniki arp-spoof i programu sslstrip.

W moim przykładzie ofiarą jest maszyna wirtualna z adresem IP 10.10.11.163 (zwykły samochód z systemem Windows), komputer z którego atakuję to 10.10.11.85 z zainstalowanym Kali OS i sslstrip (to narzędzie jest preinstalowane w pentester Kali\BackTrack dystrybucje Linuksa). Między nami jest brama z IP 10.10.11.1.

1. Gdy ofiara wchodzi na gmail.com, zostaje wysłana na adres https://gmail.com i jest to normalne. Oczywiście nie widzimy haseł i loginów do poczty ofiary w sposób przejrzysty.

2. Włączam routing ruchu na PC z Kali:

echo "1" > /proc/sys/net/ipv4/ip_forward

i skonfiguruj iptables tak, aby cały ruch http był kierowany na port 81:

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j PRZEKIEROWANIE --to-port 81

arpspoof -i eth0 -t 10.10.11.163 10.10.11.1

teraz ruch ofiary przechodzi przez mój samochód i (zgodnie z moją zasadą iptables) jest przekazywany do portu 81.

3. Uruchom pasek ssls

sslstrip -a -l 81 -w /root/Desktop/ssllog.txt

to utworzy plik dziennika bezpośrednio na pulpicie i zacznie zapisywać w nim przechwycony ruch http (właściwie HTTPS zostanie przechwycony, ale zostanie usunięty).Cóż, ogólnie zaczynam oglądać ten plik na konsoli:

tail -f /root/Desktop/ssllog.txt

4. Ofiara idzie na swoją pocztę

Aby przeczytać pocztę, ofiara jak zwykle wspina się do MS Explorera (hehe) i wchodzi tam na gmail.com. Ale z jakiegoś powodu przeglądarka nie przekierowuje ofiary na https (w pasku adresu http)! Poniższy rysunek pokazuje, co ofiara zobaczy w ostatniej chwili, zanim poznam jej hasło i login.

Ofiara klika „Zaloguj się”… i w moim oknie, w którym wyświetlany był przechwycony ruch, widzę:

Jak widać hasło 1q2w3e4r5t6y...

Aby uniknąć zagrożeń związanych z przechwyceniem początku połączenia SSL, musisz:
- nie używaj gadżetów w niezaufanych sieciach, nawet jeśli jest to bardzo konieczne (złoczyńca może zorganizować MITM ze znacznie większym prawdopodobieństwem, powiedzmy na lotnisku, instalując nieuczciwy bezprzewodowy punkt dostępowy niż łamiąc sieć korporacyjna Twoja organizacja);
- szyfruj pocztę protokołami szyfrowania symetrycznego (piszę i myślę o PGP);
- wypłacać administratorowi normalną pensję, aby nie miał ochoty szpiegować w ten sposób Twoich pracowników;
- śledź tabelę ARP i używaj sprzętu / oprogramowania monitorującego podbny atak;
- regularnie aktualizować oprogramowanie z zaufanych legalnych źródeł.

Należy pamiętać, że ten artykuł ilustruje, co jest zabronione przez prawo, a podane w nim przykłady pokazują, jak łatwo jest zaatakować SSL wyłącznie w celach edukacyjnych.