W zeszłym tygodniu koleżanka poprosiła mnie o pomoc w odzyskaniu hasła do poczty. Jedyne działające było zapisane w kliencie na telefonie z systemem Android. Konto znajdowało się u jednego z darmowych dostawców kont e-mail, jednak nie zostały z nim skojarzone żadne dane osobowe mogące ułatwić proces odzyskania konta. Pozostał jedynie hacking…
Hacking? Tylko na zamówienie!
Opisana tu sytuacja dotyczyła UPRAWNIONEGO dostępu do danych. Wszystkie działania były podejmowane za zgodą osoby, która zamówiła usługę odzyskania danych.
Nigdy nie przeprowadzaj takich operacji na danych osób, które nie wyraziły na to zgody, jest to przestępstwo!
Idea ataku Man In The Middle
Wedle mojej wiedzy, najpopularniejszy sposób korzystania z poczty e-mail w zastosowaniach domowych to dedykowane oprogramowanie. Aplikacje takie do wysyłania poczty używają rozszerzonego protokołu SMTP z uwierzytelnieniem (czasem nazywanego także Submission) oraz protokołu IMAP4 lub POP3 do odbierania wiadomości e-mail.
W przypadku wysyłania jak i odbierania wiadomości e-mail klient poczty wysyła do serwera informacje uwierzytelniające, najczęściej jest to login i hasło. Na tej podstawie serwer poczty decyduje, czy zezwolić na wysyłanie lub odbieranie wiadomości, czy też nie.
Aby odzyskać zapomniane, ale nadal używane, hasło należało podsłuchać komunikację pomiędzy klientem poczty a serwerem.
Wykorzystanie gotowej aplikacji działającej na poziomie protokołu SMTP pozwoliło maksymalnie usprawnić wykonanie zlecenia. Wybór padł na MITMsmtp. Dlaczego on?
- Jego konfiguracja jest możliwa poprzez parametry linii poleceń.
- Umożliwia szybkie wskazanie różnych plików certyfikatów i kluczy.
- Najważniejsze z mojego punktu widzenia: obsługuje poprawnie STARTTLS.
Problem pierwszy: sieć
Aby atak MITM się powiódł należało tak zmienić ustawienia sieci „ofiary”, żeby jej ruch do Internetu wychodził przez kontrolowaną przez atakującego infrastrukturę.
Należało też tak zmienić ustawienia serwerów DNS aby serwer pocztowy zapamiętany w ustawieniach klienta kierował również do infrastruktury atakującego.
Dlaczego nie dało się zmienić nazwy serwera w ustawieniach klienta? Okazało się, że zostałby usunięty login i hasło – pamiętaj, że nie mogłem sobie na to pozwolić: to było jedyne miejsce, gdzie te dane były zapisane.
Ze względu na to, że odzyskanie danych miało miejsce u „klienta” w domu, nie można było modyfikować jego ustawień sieci. Okazało się jednak, że twórcy systemu Ubuntu wyposażyli go w bardzo przydatną funkcję „hotspot”. Dzięki niej karta WiFi laptopa zamieniła się w punkt dostępowy, do którego podłączył się telefon „ofiary”.
Opcja hotspot zapewniła także serwer DHCP przydzielający urządzeniom adres IP (z podsieci 10.42.0.0/24). Notebook z uruchomioną opcją „hotspot” został bramą Internetową o adresie 10.42.0.1 oraz serwerem DNS. Wszystko to jednym kliknięciem w interfejsie użytkownika…
Aby przejąć ruch pocztowy bez manipulowania kartą sieciową, czy regułami iptables wystarczyło nadpisać adres IP serwera poczty w pliku /etc/hosts.
Problem drugi: certyfikat SSL
Pomimo przechwycenia ruchu SMTP klient poczty odrzuciłby połączenie. Dlaczego? Ruch w sieci Internet jest szyfrowany. Podczas wymiany kluczy szyfrujących klient poczty sprawdził poprawność certyfikatu (klucza publicznego) serwera poczty. Sprawdzone zostały:
- Data ważności: czy certyfikat nie wygasł, lub nie jest użyty za wcześnie.
- Zgodność domeny serwera pocztowego z polem CommonName certyfikatu.
- Zaufanie organu podpisującego certyfikat – instytucja podpisująca certyfikat domeny, lub certyfikat pośredni podpisujący domenę serwera pocztowego musi znajdować się w magazynie zaufanym certyfikatów urządzenia.
Teoretycznie, aby przeprowadzić atak Man In The Middle na szyfrowany protokół SMTP należało utworzyć własny klucz i certyfikat, następnie podpisać go, a certyfikat podpisujący przesłać do „atakowanego” urządzenia i zachęcić użytkownika do jego zainstalowania.
Dodane własnego, spreparowanego certyfikatu do zaufanych w urządzeniu Android do najprostszych nie należy, jednak okazało się, że nie jest to potrzebne.
Akceptuj wszystkie certyfikaty
Programiści aplikacji pocztowych na Androida pozostawili opcję zaakceptowania nieprawidłowych certyfikatów SSL.
Opcja ta jest łatwo dostępna dla użytkownika, co więcej wielu dostawców poczty wprost wymaga jej podczas konfiguracji klientów na urządzeniach mobilnych.
Z opcją akceptowania wszystkich certyfikatów do ataku Man In The Middle może dojść poprzez skorzystanie z niezaufanej sieci WiFi, w której działa atakujący.
Finał zlecenia
W przypadku telefonu będącego przedmiotem zlecenia ustawienia szyfrowania były bezpieczne. Okazało się, że można je zmienić bez konieczności podawania nowego loginu i hasła. Wykorzystanie opcji „akceptuj wszystkie certyfikaty” sprawiło, że klient zaakceptował samopodpisany certyfikat wygenerowany na stacji roboczej z MITMsmtp. Dane udało się odzyskać.
Po co akceptować nieprawidłowe certyfikaty?
Obecność opcji akceptowania nieprawidłowych certyfikatów w aplikacjach klienckich jest dla mnie niezrozumiała. Co więcej zachęcanie użytkowników do jej użycia przez dostawców usług to praktyka zagrażająca bezpieczeństwu danych.
Rozumiem, że w przypadku hostingu współdzielonego z jednego certyfikatu serwera korzysta wiele domen. Nie sądzę, aby wielkim problemem było podanie klientom takiego hostingu prawidłowej, zgodnej z polem CommonName certyfikatu, nazwy domenowej serwera.