www.hakin9.org

28

Hakin9 Nr 5/2004

A

ta

k

www.hakin9.org

29

Hakin9 Nr 5/2004

Atak na szyfrowane połączenie Jabbera

P

opularne komunikatory, takie jak Gadu-
Gadu, do przesyłania wiadomości uży-
wają nieszyfrowanego tekstu. Z tego po-

wodu są niezwykle łatwe do podsłuchania. Więk-
szy poziom bezpieczeństwa oferują aplikacje ko-
rzystające z otwartego protokołu Jabber (patrz
Artykuł Paranoja w świecie komunikatorów
– Hakin9 3/2004). Wynika to z faktu, że z Jabbe-
ra można korzystać za pośrednictwem warstwy
SSL, zapewniającej poufność połączenia.

Człowiek w środku

Zastosowanie sprawdzonych algorytmów
szyfrowania z wykorzystaniem długich (512-
i 1024-bitowych) kluczy, renegocjowanych co
pewną ilość danych, skutecznie zabezpiecza
nas przed wyciekiem informacji z nawiązanego
połączenia. Nietrudno jednak wyobrazić sobie
sytuację, w której ktoś stanie na drodze nasze-
mu połączeniu z serwerem, podszywając się
pod niego (patrz Rysunek 1). Klient nawiąże
więc szyfrowane połączenie, tyle że nie – jak by-
śmy się spodziewali – z serwerem, lecz z innym
komputerem. Komputer ten natomiast połączy
się z pierwotnym celem i od tego momentu sta-
nie się pośrednikiem przesyłającym informacje
w obie strony (od serwera do klienta i odwrot-

Atak man in the middle na

szyfrowane połączenie Jabbera

Piotr Tyburski

Użytkownicy komunikatorów

sieciowych chcą mieć pewność,

że przesyłane przez nich dane

pozostaną poufne. Aby osiągnąć

ten cel, sięgają po wyrafinowane

narzędzia kryptograficzne. Czy

to wystarczy do zapewnienia

pełnego bezpieczeństwa?

nie) – będzie więc mógł podsłuchiwać połącze-
nie. To właśnie jest nazywane atakiem man in
the middle.

Podstawowym warunkiem powodzenia ta-

kiego ataku jest dostęp do komputera pośred-
niczącego w przesyłaniu pakietów IP pomię-
dzy użytkownikiem a serwerem. Najprostszym
przypadkiem jest sytuacja, w której atakują-
cy ma dostęp do bramy w sieci (z prawami ad-

Z artykułu nauczysz się...

• jak za pomocą filtra pakietów oraz progra-

mu socat przechwycić szyfrowane połączenie
Jabbera,

• jak postępować, aby mieć niemal stuprocentową

pewność, że nikt nie podsłucha sesji Jabbera.

Powinieneś wiedzieć...

• znać przynajmniej podstawy administracji syste-

mami uniksowymi,

• zakładamy, że czytelnik posiada podstawową

wiedzę o SSL,

• rozumieć, na czym polegają ataki man in the

middle (polecamy lekturę artykułu Sniffing w
ethernecie z przełącznikami z numeru 2/2003).

www.hakin9.org

28

Hakin9 Nr 5/2004

A

ta

k

www.hakin9.org

29

Hakin9 Nr 5/2004

Atak na szyfrowane połączenie Jabbera

ministratora). Przyjmijmy, że tak wła-
śnie jest. Jeśli atakujący nie ma do-
stępu do maszyny pośredniczącej,
może użyć technik w rodzaju ARP
spoofing lub ARP poisoning (patrz
Artykuł Sniffing w sieciach przełącza-
nych – Hakin9 2/2003).

Atak na szyfrowaną sesję Jabbe-

ra powiedzie się, jeśli agresorowi uda
się przechwycić próby nawiązania po-
łączenia z komputera klienta do por-
tu 5223 serwera i przekierować je do
innego komputera. Na tej maszynie
specjalny program musi przyjąć zaini-

cjowane połączenie i zaraz potem na-
wiązać kolejne, tym razem z właści-
wym adresatem. Spróbujmy więc wy-
konać prawdziwy atak.

Skąd wziąć certyfikat

Aby przechwycenie szyfrowanej sesji
miało jakiekolwiek szanse powodze-
nia, potrzebny będzie spreparowany
certyfikat SSL serwera Jabbera – dzię-
ki temu klient Jabbera uzna, że ma do
czynienia z prawdziwym serwerem.
Podczas jego tworzenia należy oczy-
wiście podać takie dane, jakie znajdują

się na prawdziwym certyfikacie serwe-
ra (patrz Ramka Jak działa SSL).

Za pomocą pakietu OpenSSL

i dołączonego do niego skryptu po-
włoki CA.sh (ewentualnie jego perlo-
wej wersji CA.pl) generujemy certyfi-
kat CA (centrum certyfikującego) oraz
certyfikat serwera wraz z kluczami
prywatnymi. Skrypt CA.sh należy naj-
pierw zlokalizować w systemie:

$ locate CA.sh

Załóżmy, że CA.sh został znaleziony
w katalogu /etc/ssl/misc:

$ /etc/ssl/misc/CA.sh -newca

Po uruchomieniu skryptu należy
jeszcze podać dane identyfikacyj-
ne, które będą zapisane w certyfika-
cie, oraz hasło. Utworzony zostanie
katalog ./demoCA zawierający m.in.
plik cacert.pem (certyfikat naszej in-
stytucji certyfikującej) i cakey.pem
(klucz prywatny tego certyfikatu).

Teraz należy wygenerować certy-

fikat dla naszego serwera. W tym celu
wykonujemy następujące polecenie:

$ /etc/ssl/misc/CA.sh -newreq

Znów trzeba podać kilka informacji
(podobnie jak przy generowaniu ca-
cert) oraz hasło. Zostało nam już tyl-
ko podpisanie wygenerowanego cer-
tyfikatu:

$ /etc/ssl/misc/CA.sh -sign

Po podaniu hasła do klucza prywat-
nego instytucji certyfikującej otrzy-
mujemy podpisany cyfrowo certy-
fikat ./newcert.pem oraz jego klucz
prywatny ./newreq.pem.

Realizacja ataku

Czas na przeprowadzenie właściwe-
go ataku. Wspomnianym specjalnym
programem, który przechwyci dane
szyfrowanej sesji Jabbera, będzie
w tym przypaku socat (patrz Ram-
ka Socat – prawdziwy sieciowy kom-
bajn), który posłuży za pośrednika
między użytkownikiem a serwerem.

W opisie przechwycenia sesji po-

służymy się dla ułatwienia imionami:

Jak działa SSL

Kiedy firma Netscape projektowała standard SSL, chciała rozwiąząć problem ogrom-
nej podatności protokołu TCP/IP na podsłuchiwanie oraz ataki man in the middle. SSL
miał zapewnić zarówno szyfrowanie połączeń, jak i identyfikację obu stron. Tę rolę
spełnia użyta w protokole technika certyfikatów.

Połączenie SSL (Secure Socket Layer) jest tworzone na bazie zwykłego połącze-

nia TCP. Przesyłane nim dane szyfrowane są symetrycznie kluczem, który jest nego-
cjowany na początku sesji. W pierwszej fazie klient wysyła komunikat Client Hello za-
wierający informacje o wersji protokołu, identyfikatorze sesji oraz o obsługiwanych al-
gorytmach kryptograficznych. Serwer odpowiada komunikatem Server Hello, w któ-
rym znajduje się nowy lub istniejący numer sesji oraz informacja o dopuszczalnych al-
gorytmach szyfrowania. W następnej fazie serwer uwierzytelnia się poprzez przesła-
nie swojego certyfikatu. Klient sprawdza prawdziwość trzech warunków:

• certyfikat został podpisany przez znany i zaufany urząd certyfikujący (ang. Certifica-

te Authority – CA); najważniejsze takie urzędy to Verisign, Thawte czy AT&T,

• certyfikat jest prawidłowy i nie stracił ważności (ani nie został odwołany),
• nazwa na certyfikacie odpowiada nazwie domenowej serwera.

Jeśli choć jeden z nich nie jest spełniony, klient zgłasza ostrzeżenie i pozostawia użyt-
kownikowi decyzję o kontynuacji połączenia. Jeśli połączenie nie zostaje przerwane,
serwer może dokonać analogicznego uwierzytelnienia klienta. Następnie obie strony
generują tak zwany klucz master. Klucz ten wykorzystywany jest do utworzenia kluczy
sesji używanych później do szyfrowania i deszyfrowania oraz sprawdzania integralno-
ści danych przesyłanych w ramach sesji SSL. Na koniec przesyłane są zaszyfrowane
wiadomości informujące o zakończeniu działania protokołu powitalnego i może nastą-
pić wymiana danych.

Rysunek 1.

Schemat ataku man in the middle na sesję SSL Jabbera

������

�������

�������

�������

��������������������������������������������������

����������������������������������������������

����������������������������������������������������

�������������������������������������������������

�������

�������������

���

��������

���