www.hakin9.org

Hakin9 Nr 5/2004

www.hakin9.org

Hakin9 Nr 5/2004

Atak na szyfrowane połączenie Jabbera

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

Hakin9 Nr 5/2004

www.hakin9.org

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

��