Przeskocz do treści

Nie chce Ci się czytać? Więc na szybko: o czym jest ten wpis

Przeraziło mnie jak łatwo można podsłuchać dane w sieci, szczególnie powalająca jest prostota z którą można wyciągnąć czyjeś hasło. Testowo podsłuchałem sam siebie w momencie logowania do admin1 (Worpress) i sam sobie wykradłem hasło. Poniżej jest opisane jak to zrobiłem.

W drugim etapie zająłem się zabezpieczeniem transmisji, wykorzystując certyfikat z nazwa.pl. Po zainstalowaniu i skonfigurowaniu certyfikatu, ponownie spróbowałem siebie podsłuchać - tym razem się nie udało. Oczywiście omówiłem krok po kroku wszystkie wykonane czynności, które miały na celu zabezpieczenie WordPressa.

Treść właściwa, czyli dużo czytania

Do wykorzystania certyfikatu z nazwa.pl nakłoniły mnie dwie rzeczy:

  • dostałem go prawie za darmo,
  • zdarzało mi się logować do admin1 z wykorzystaniem publicznych sieci.

Z tym "za darmo" to nie tak do końca, bo jak nie patrzeć, wystarczająco dużo płacę za hosting w nazwa.pl (tak, możecie mnie potępiać) by tego typu "prezent" mieć za jedyne 1 zł (pewnie netto, jeszcze nie sprawdzałem).

Założenia przyjęte do realizacji tego zadania:

  • sprawdzam, jak w prosty sposób można przechwycić hasło przy wykorzystaniu Kali Linux,
  • przechwytuję hasło,
  • instaluję certyfikat,
  • ponawiam test z uruchomionym ssl, starając się ponownie przechwycić hasło.

Środowisko testowe to dwie maszyny postawione na VMware:

  • wspomniany wcześniej Kali uzbrojony w Ettercap 0.8.2,
  • Ubuntu.

Doskonale zdaję sobie sprawę z faktu, że tego doświadczenia już tysiące razy pojawiły się na setkach strony i kanałach YT, ale wychodzę z założenia, że gdy sam przepracuję ten temat, to więcej zostanie mi w głowie.

Zaczynamy.

Namierzenie Ubuntu w sieci (sprawdzam IP)

Żeby nie skanować całego ruchu, identyfikuję maszynę z Ubuntu, która później będzie podsłuchiwana.

Jak widać ifconfig ładnie poinformował, że będę się pastwić nad 192.168.172.134. Nie pozostaje nic innego, jak w Kalim namierzyć wspomnianą maszynę i rozpocząć nasłuchiwanie.

Namierzenie i podsłuch Ubuntu przez ettercap

Uruchamiam ettercap, wybierając z menu Sniff pozycję Unify Sniffing:

Automatycznie EtterCap poprosi o wskazanie sieci, która będzie nasłuchiwana. W moim przypadku zarówno Kali jak i Ubuntu stoją na eth0. Po jej wskazaniu rozpoczyna się nasłuchiwanie:

By ograniczyć ilość danych do analizy, jak już wcześniej wspominałem ograniczę się do podsłuchiwania jednego hosta. Z menu Hosts wybieram Hosts list.

Jako, że nie widzę na liście hostów interesującego mnie adres ip, uruchamiam skanowanie (menu Hosts -> Scan for hosts)

Po zakończonym skanowaniu interesujący host pojawia się na liście:

Kolejnym krokiem jest ustawienie adresu Ubuntu jako jako cel. By to zrobić, należy wybrać adres maszyny i kliknąć Add to Target 1. System potwierdzi dodanie hosta jako celu (Target 1).

Kolejny krok: w Mitm -> ARP poisoning pozostaje do ustawienia Sniff remote connections.

Wybór wystarczy potwierdzić przez OK.

Środowisko jest gotowe do nasłuchu.

Ettercap już cichutko pracuje.

Nie pozostaje nic innego, jak spróbować logowania z poziomu Ubuntu. W ramach testu zostają wpisane do formularza logowania: testowylogin i testowehaslo.

W momencie wysłania danych przez formularz, ettercap wyłapuje przechodzące dane, wyświetlając ich wartość.

Jak widać, w przypadku ogólnodostępnych sieci wewnątrz których ktoś może podsłuchiwać, logowanie bez ssl`a stało się kiepskim pomysłem.

Zabezpieczenie, czyli certyfikat ssl z nazwa.pl

Po zalogowaniu do swojego panelu klienta w nazwa.pl, wybieram odpowiednią usługę (certyfikat ssl) i dokonuję zakupu realizując kupon rabatowy (certyfikaty za złotówe dajo! Tak bardzo cebula!).

Już na etapie zamawiania usługi, należy wskazać domenę dla której będzie przeznaczony certyfikat. Co ważne: bez problemu można wskazać domenę "spoza nazwa.pl", czyli wykupioną u innego dostawcy domen. W moim przypadku domena z ovh jest przypięta do hostingu na nazwie.

Po potwierdzeniu płatności, certyfikat pojawia się w panelu klienta. Trwało to w moim przypadku kilkanaście minut.

Konfiguracja ograniczyła się do wskazania odpowiedniego serwera w panelu Nazwy.

Po kolejnych kilku minutach otrzymałem email z odnośnikiem pozwalającym na weryfikację adresu email oraz domeny przypisanych do certyfikatu.

Dosłownie minutę później już można było korzystać z https://

Co ważne (w przypadku WordPressa): gdy już zadziałał certyfikat, należało ręcznie poprawić adres witryny w panelu administracyjnym (Ustawienia -> Ogólne -> Adres WordPressa (URL) + Adres witryny (URL)).

Testy powdrożeniowe, czyli sprawdzenie czy to naprawdę działa

Chcąc sprawdzić, czy faktycznie skuteczne zabezpieczenie logowania w WordPress to taka łatwa sprawa, jeszcze raz rzucam okiem na ettercapa. Żeby mieć porównanie, autoryzuję się w innej aplikacji online bez wykorzystania ssl`a, po czym odpalam formularz logowania admin1 sprawdzając, czy udało się przechwycić dane przy włączonym https.

Podane (w wersji bez https) przy logowaniu testlogin//testpass momentalnie zostaje przechwycone przez ettercapa. Próbuję się zalogować do admin1 wykorzystującego certyfikat:

Etterpap nic nie znajduje. Wygląda na to, że formularz logowania do WordPressa został zabezpieczony. Oczywiście certyfikatem objęta jest cała witryna, nie tylko logowanie do admin1. Można powiedzieć, że możecie teraz bezpiecznie nawrzucać mi w komentarzach. Nikt tego nie podsłucha 😉