[ Pobierz całość w formacie PDF ]

niektóre żądania. Wówczas końcowy serwer zostaje zmylony, ponieważ mu wydaje si,
że pojawiające si komunikaty są pochodzenia lokalnego, a w rzeczywistości pochodzą
skądinąd.
Uwierzytelnianie oparte na adresach zawodzi również, gdy komputer zródłowy nie jest
wiarygodny. Oczywistym tego przykładem są komputery PC. Mechanizm, który został
wymyślony w czasach, kiedy komputery pracujące z podziałem czasu były normą, przestał
si sprawdzać, gdyż każdy może zarządzać własnym komputerem. Oczywiście, opcja
w postaci haseł też nie zapewnia już bezpieczeństwa w sieciach składających si z takich
komputerów, w których podsłuchiwanie haseł stało si łatwe i powszechne.
Czasem uwierzytelnianie nie udaje si, gdyż protokół nie zawiera właściwych informacji.
Ani TCP, ani IP nie identyfikują nigdy nadającego użytkownika (jeżeli w ogóle w kompu-
terach funkcjonuje taka możliwość). Protokoły, takie jak X11 czy rsh, muszą informacj
t zdobyć same lub poradzić sobie bez niej (a jeżeli mogą ją uzyskać, to muszą znalezć
sposób na bezpieczne przeniesienie jej przez sieć).
Nawet kryptograficzne uwierzytelnienie komputera zródłowego może nie być wystarczające.
Jak wspominaliśmy wcześniej, komputer, do którego si włamano, nie może dokonywać
wiarygodnego szyfrowania.
u n n
Podsłuchiwacze mogą łatwo przechwycić zapisane czystym tekstem hasło wysłane w nie-
szyfrowanej sesji, ale mogą też natknąć si na jeden ze schematów haseł jednorazowych2.
Poprawnie działający schemat uwierzytelniania, stosujący hasła jednorazowe dla nastp-
nego logowania, niezależnie od miejsca jego pochodzenia, przeznacza tylko jedno pra-
widłowe hasło. Dobrym tego przykładem jest nastpne hasło na liście OTP, która zostanie
opisana w podrozdziale 7.5, bdące pierwszym znanym celem opisanego tu ataku.
W przykładzie tym założymy, że hasło ma znaną długość i składa si z samych cyfr.
Napastnik inicjuje dziesić połączeń z odpowiednią usługą. Każde połączenie czeka na to
samo nieznane hasło. Prawidłowy użytkownik łączy si i zaczyna wpisywać poprawne
hasło. Program atakujący obserwuje to i przekazuje do dziesiciu swoich połączeń po-
prawne znaki hasła w miar ich wpisywania przez użytkownika. Gdy do wpisania po-
zostaje tylko jedna cyfra, program wysyła dziesić różnych cyfr do wszystkich swoich
2
http://www.tux.org/pub/security/secnet/papers/secureid.pdf  przyp. aut.
Rozdział 5. Klasy ataków 145
połączeń zanim użytkownik zdąży wpisać ostatnią cyfr. Komputer jest szybszy, zatem
wygrywa wyścig i jedno z połączeń napastnika zostanie uznane za poprawne. Takie schematy
uwierzytelniania umożliwiają jedynie jednorazowe zalogowanie si z wykorzystaniem
każdego hasła, wic właściwy użytkownik zostanie odrzucony i bdzie musiał spróbować
jeszcze raz. Oczywiście w takiej sytuacji napastnik bdzie musiał znać długość hasła,
ale zwykle długości te są dobrze znane.
Jeżeli napastnik w czasie uwierzytelniania umieści si midzy klientem a serwerem, może
wygrać uwierzytelnione połączenie z komputerem dziki przekazaniu klientowi wezwania
pochodzącego od komputera i poznaniu od klienta poprawnej odpowiedzi. Atak na jeden
z takich protokołów został opisany w pracy Bellovina i Merritta [1994].
Uwierzytelniający si może zrobić wiele, by udaremnić tego rodzaju atak [Haller et al.,
1998], ale te działania bdą tylko łatami na wrodzoną słabość stosowanego schematu
uwierzytelniania. Uwierzytelnianie metodą wezwanie-odpowiedz zupełnie udaremnia tego
rodzaju atak, gdyż każde połączenie napastnika uzyskuje inne wezwanie i wymaga innej
odpowiedzi.
W poprzednim podrozdziale omówiono przypadek, w którym wszystko działało, tak jak
należy, a niemożliwe było tylko wiarygodne uwierzytelnienie. Teraz wezmiemy pod
uwag odwrotność tamtej sytuacji, czyli warunki, w których działające protokoły zawie-
rają błdy lub są nieodpowiednie, a przez to uniemożliwiają właściwą prac aplikacji.
Omawianym przypadkiem bdzie atak na numer sekwencyjny protokołu TCP, opisany
w rozdziale 2. Z powodu niedostatecznej losowości generowanego początkowego nu-
meru sekwencyjnego połączenia, napastnik może posłużyć si fałszowaniem adresu
zródłowego (ang. spoofing). Trzeba przyznać, że gdy wymyślano numery sekwencyjne
protokołu TCP nie przewidywano konieczności odpierania złośliwych ataków. W za-
kresie, na którym bazuje uwierzytelnienie wykorzystujące adresy, definicja protokołu
jest niewystarczająca. Inne protokoły polegające na numerach sekwencyjnych też mogą
być podatne na ten rodzaj ataku. Lista jest bardzo długa, zawiera protokół DNS oraz
wiele protokołów opartych na RPC.
W świecie kryptografii popularną zabawą jest wynajdywanie luk w protokołach. Czasem
ich twórcy po prostu popełniali błdy. Czstą przyczyną luk są też przyjte, różne założenia.
Udowadnianie poprawności wymian kryptograficznych to trudna sztuka i przedmiot wielu
badań naukowych. Póki co, luki pojawiają si zarówno w rozważaniach akademickich,
jak i w świecie realnym, na co wskazują ponure wskazówki  Tych, którzy wiedzą (ang.
Those Who Know).
Bezpieczne protokoły muszą być zbudowane na bezpiecznych podstawach. Wezmy pod
uwag świetny (mamy nadziej, że świetny) protokół bezpiecznego zdalnego dostpu ssh.
Protokół ssh ma funkcj, dziki której użytkownik może podać wiarygodny klucz pu-
bliczny, przechowując go w pliku authorized_keys. Nastpnie, gdy klient zna prywatny
klucz, użytkownik może zalogować si bez potrzeby wpisywania hasła. W systemie
Unix plik ten zwykle przechowywany jest w katalogu .ssh, w katalogu domowym użyt-
kownika. Rozważmy teraz sytuacj, w której ktoś za pomocą ssh loguje si do komputera
146 Część II Zagrożenia
z zamontowanymi przez protokół NFS katalogami domowymi. W takim środowisku
napastnik może podszyć si pod odpowiedzi NFS i wprowadzić fałszywy plik authori-
zed_keys. Zatem bezpieczeństwo postrzeganego jako wiarygodny protokołu ssh zawodzi
w niektórych dość powszednie stosowanych środowiskach.
Plik authorized_keys charakteryzuje si jeszcze jedną drobną wadą. Kiedy użytkownikowi
w nowym środowisku założone zostanie nowe konto, kopiuje on tam zwykle ze swojego
starego konta wszystkie ważne pliki. Nie jest niczym niezwykłym to, że użytkownik
przekopiuje też cały katalog .ssh, wobec czego wszystkie klucze ssh staną si dostpne
w nowym koncie. Jednak użytkownik może nie zdawać sobie sprawy, że kopiując plik
authorized_keys powoduje, że do nowego konta możliwy bdzie dostp za pomocą kluczy
uwiarygodnionych do korzystania z konta poprzedniego. I chociaż może si to okazać [ Pobierz całość w formacie PDF ]




 

Powered by WordPress dla [Nie kocha się ojca ani matki ani żony ani dzieca, lecz kocha się przyjemne uczucia, które w nas wzbudzają]. Design by Free WordPress Themes.