Błąd w ścieżce certyfikacji MS IE 6
Siódmego sierpnia 2002 roku na liście Bugtraq pojawił się artykuł niejakiego
Mike Benhama [1], opisujący interesujący błąd MS Internet Explorera,
ujawniający się podczas ładowania stron z bezpiecznych serwerów,
posiadających certyfikat SSL. Przyjrzyjmy się bliżej tej dziurze i
przenalizujmy, jakie mogą być jej konsekwencje, wykorzystując to
jako pretekst do omówienia ataków typu man-in-the-middle.
Pomimo, że temat ten był już na łamach WSM poruszany, przypomnijmy
pokrótce jak działa SSL i jaka jest w nim rola certyfikatów. Protokół
SSLv3 (Secure Sockets Layer v3) jest protokołem kryptograficznym,
który działa pomiędzy wartstwą TCP a aplikacyjną, tunelując w sposób
bezpieczny protokoły wyższych warstw, przy czym w codziennej praktyce
najczęściej jest to HTTP. Można śmiało powiedzieć, że protokół SSL
stanowi obecnie podstawę bezpieczeństwa transakcji dokonywanych
przez Internet, ponieważ obsługują go wszystkie liczące się przeglądarki
WWW oraz wszystkie serwery, sklepy internetowe itd.
Idea działania SSL jest prosta i opiera się o połączenie kryptografii
z kluczem publicznym z konwencjonalnym szyfrowaniem symetrycznym (z jednym
tajnym kluczem):
- strona A łączy się z B, po czym A i B wymieniają się swoimi
kluczami publicznymi
znaną tylko im, stanowiącą klucz do szyfrowania symetrycznego
Jednak kryptografia - która w SSL została pozytywnie zweryfikowana
na przestrzeni ostatniego dziesięciolecia - to tylko połowa sukcesu.
SSL stanowi w tym wypadku tylko cegiełkę rozbudowanego systemu bezpieczeństwa,
który w ostatecznym rozrachunku ma zagwarantować, że dane naszej
karty kredytowej wysyłane do internetowej księgarni nie zostaną
po drodze podsłuchane. Albo, bo i taki atak można sobie wyobrazić,
wysłane co prawda bezpiecznie, ale nie tam gdzie trzeba. Rezultat
będzie w obu przypadkach jednakowy.
Prostym i bardzo skutecznym atakiem, przed którym nie da się
zabezpieczyć za pomocą najlepszej nawet kryptografii jest tzw. atak
man-in-the-middle, który oznacza dosłownie atak prowadzony
przez kogoś, kto znajduje się pomiędzy dwoma stronami, próbującymi
nawiązać bezpieczną komunikację - na przykład Alicją i Bankiem.
Atakujący, nazwijmy go Mallorym, ma dostęp do lokalnej sieci
Alicji - pracuje w tej samej firmie, chodzi do tej samej kafejki
internetowej albo jest podpięty to tej samej sieci blokowej.
Za pomocą pewnych metod, które opiszemy dokładnie dalej, Mallory
potrafi spowodować że przeglądarka Alicji zamiast z Bankiem
połączy się z jego serwerem, będącym sprytnym pośrednikiem.
Teraz przeglądarka Alicji wymieni klucze publiczne z Mallorym
i uzgodni z nim bezpieczny klucz symetryczny. Mallory tymczasem
działa na dwa fronty - uzgadnia klucz symetryczny z Bankiem
i wszystko co otrzyma od banku bezpiecznym kanałem przeszyfruje
kluczem Alicji i do niej wyśle. Analogicznie, wszystko co wysyła
Alicja Mallory również wyśle do Banku. Oczywiście, notując podane
przez Alicję dane karty kredytowej.
Złudzenie jest niemal doskonałe - Alicja myśli że rozmawia z Bankiem,
Bank że z Alicją. Wszelkie dodatkowe hasła i kody wymagane do
realizacji przelewu oczywiście również trafią do Mallory'ego, który
wyśle je do Banku, modyfikując jedynie kwotę przelewu oraz
numer konta adresata uznania.
Nawet najlepsza kryptografia nie zabezpieczny nas przed tym
atakiem - skąd bowiem Alicja ma wiedzieć, że klucz publiczny
który otrzymuje od rzekomo bankowego serwera faktycznie
należy do Banku? Jedyne rozwiązanie to dystrybuowanie kluczy
publicznych wszystkich banków razem z przeglądarkami WWW,
co ze względów praktycznych jest oczywiście pozbawione sensu.
Problem ten rozwiązana wyznaczając kilkaset (w skali
świata) instytucji zajmujących się potwierdzaniem autentyczności
kluczy publicznych różnych podmiotów i certyfikowaniem ich.
[Globalny urząd certyfikujący CA1]
|
|
v
[Regionalny urząd certyfikujacy CA2]
|
|
v
[Serwer]
Rysunek 1. Ścieżka certyfikacji.
Przeglądarka musi tym momencie zawierać tylko kilkaset stałych
kluczy publicznych tzw. urzędów certyfikujących (CA, Certifying
Authorities) i jest to praktycznie jedyny element, który
musi być zainstalowany "fabrycznie". Rysunek 2. przedstawia
taką listę w MSIE. Cała reszta odbywa się w sposób automatyczny:
- Bank chce w wiarygodny sposób udostępniać swoje
usługi przez Internet, więc:
- występuje do CA z kluczem publicznym swojego
serwera, - urząd sprawdza wiarygodność Banku, inkasuje gotówkę
za tę usługę i podpisuje klucz banku swoim certyfikatem, - Bank instaluje podpisany klucz na swoim serwerze
i organizuje kampanię reklamową za 0,5 mln zł.
- łączy się z serwerem Banku i otrzymuje jego
klucz publiczny, - sprawdza podpis złożony przez urząd na klucz Banku -
może to zrobić, ponieważ jej przeglądarka ma wbudowany
klucz urzędu, - jeśli wszystko gra, to Alicja wie że połączyła się
z serwerem Banku, a nie jakiegoś technicznie
uzdolnionego nicponia z osiedla.
Rysunek 2. Klucze publiczne urzędów CA w przeglądarce.
W powyższym schemacie wszystko nosi oczywiście odpowiednie nazwy - i
tak klucz publiczny plus informacje do kogo należy plus złożony na nim
podpis urzędu to certyfikat X509. Certyfikat serwera (najniższy
poziom) może być podpisany przez urzędu certyfikującego. Co więcej,
certyfikat tego urzędu może być podpisany przez Jeszcze Wyższy Urząd,
na przykład po to by nie umieszczać w przeglądarce kilku tysięcy kluczy
publicznych każdego regionalnego urzędu z Koziej Wólki,
a tylko kilkaset, urzędów szczebla krajowego.
[CA1]
/ | \
/ | \
[CA2] [CA3] [CA4]
/ | | \ / | \
/ |
[serwer] [serwer] . . .
Rysunek 3. Urząd CA1 certyfikuje wiele urzędów regionalnych. Urzędy
regionalne certyfikują serwery.
Jak wygląda weryfikacja autentyczności klucza publicznego
w prawdziwym SSL?
- Alicja łączy się z Bankiem i otrzymuje jego klucz publiczny,
- przeglądarka Alicji sprawdza, kto podpisał klucz Banku,
czy podpis jest poprawny i ważny (w sensie czasowym),
podpisał klucz Banku; jeśli tak, to uznaje że wszystko
jest w porządku
podpisał jakiś wyższy urzad (CA1), który zna
Jak wygląda w praktyce weryfikacja takiej ścieżki certyfikacji?
Na rysunku 4. zobaczymy komunikat, jaki MS Internet Explorer
wyświetla użytkownikowi, próbującemu się połączyć z serwerem,
który co prawda udostępnia SSL, ale jego klucz publiczny nie
jest podpisany przez znanego przeglądarce wystawcę
(urząd). Ostrzeżenie jest jak widać czytelne. Taki sam komunikat
zobaczy Alicja, jeśli Mallory znów spróbuje swoich sztuczek
z serwerem pośredniczącym - jej podejrzliwość powinien wzbudzić
fakt, że szacowna instytucja jaką jest Bank nie posiada potwierdzonego
certyfikacją klucza publicznego i na przykład postanowi zweryfikować
to telefonicznie.
Rysunek 4. Przeglądarka ostrzega przed podejrzanymi serwerami.
System certyfikacji X.509 posiada również inne zabezpieczenia -
jednym z najprostszych ataków na ten system byłoby przecież
postępowanie następujące:
- kupujemy w renomowanym urzędzie certyfikat naszego legalnego
serwera,
podpisanymi przez urząd, podpisujemy drugi, nielegalny serwer
udający Bank,
ścieżka certyfikacji kończy się na zaufanym urzędzie!
[zaufany urząd]
|
|
v
[legalny serwer]
|
|
v
[serwer-pułapka]
Rysunek 5. Ścieżka nielegalnej ale poprawnej certyfikacji.
System X.509 oczywiście posiada zabezpieczenie przed takim
postępowaniem - urząd wydający certyfikat serwera zaznacza
w nim wyraźnie, że klucz ten służy do stwierdzania
autentyczności serwera, a nie do certyfikowania innych
serwerów. Gdzie zatem leży problem? To zastrzeżenie trzeba
sprawdzać!
Tymczasem zgodnie z opublikowaną na Bugtraq informacją
MS Internet Explorer do wersji 6 pomija to zastrzeżenie,
co jest ewidentnym błędem projektowym lub programistycznym.
Dzięki temu odkrywca błędu był w stanie stworzyć stronę,
która udaje stronę www.amazon.com i prezentuje na pozór
zupełnie legalny klucz dla tej domeny:
Certificate chain 0 s:/C=US/ST=California/O=Amazon/OU=software/CN=www.amazon.com i:/C=US/ST=California/L=San Francisco/O=Michael Benham/OU=ThoughtCrime/CN=www.thoughtcrime.org 1 s:/C=US/ST=California/L=San Francisco/O=Michael Benham/OU=ThoughtCrime/CN=www.thoughtcrime.org i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Server CA/Email=server-certs@thawte.com Rysunek 6. Ścieżka certyfikacji dla fałszywego www.amazon.com.
Klucz ten został rzekomo podpisany przez firmę ThoughtCrime, która
reprezentuje w San Francisco urząd certyfikujący Thawte (na rysunku
2. widzieliśmy, że jest on "fabrycznie" znany przeglądarce). Jednak
łatwo się przekonać, jak zachowają się różne przeglądarki łącząc
się z adresem https://www.thoughtcrime.org/:
- Mozilla 1.1 zwróci enigmatyczny komunikat Error establishing
encrypted connection to www.thoughtcrime.org. Error code: -8183.,
ale nie umożliwi połączenia.
parser Mozilli).
library has encountered an improperly formatted DER-encoded message.
rysunku 7.
Rysunek 7. Ostrzeżenie MSIE.
Ale czego dowie się użytkownik na pierwszym miejscu? Że certyfikat
pochodzi od zaufanego dostawcy! Przyjrzyjmy się bliżej - rysunek
8. przedstawia ścieżkę certyfikacji, w pełni zaakceptowaną przez
IE.
Rysunek 7. Ścieżka certyfikacji fałszywego serwera widziana przez MSIE.
Nazwa nie zgadza się oczywiście dlatego, że w certyfikacie figuruje
nazwa www.amazon.com, pod którą chcemy się podszyć, a tymczasem
wpisaliśmy www.thoughtcrime.org. Czy można spowodować, by
podstęp był całkowicie przezroczysty? Odpowiedź brzmi: tak, i to całkiem
łatwo jeśli mamy dostęp do sieci ofiary.
Autor tego artykułu przeprowadził z powodzeniem tego rodzaju atak na
samym sobie, korzystając z ogólnodostępnego oprogramowania. Tak na
prawdę wystarczyło zrobić tylko jedno - spowodować, by po wpisaniu
do przeglądarki www.amazon.com połączyła się ona z adresem
IP należącym do www.thoughtcrime.org. Trudne? Wprost przeciwnie.
Przeglądarka prosi bowiem o rozwiązanie nazwy na adres IP serwer DNS,
leżący w tej samej lub innej sieci. W tej samej sieci działa nasz
system, na którym działa mała aplikacja - jej jedynym zadaniem jest
oczekiwanie aż ktoś spyta o adres Amazon i momentalne odesłanie
w odpowiedzi adresu podstawionego serwera. Na rysunku 8. widać wyraźnie,
że mu się to udaje - prawdziwy Amazon ma adres 207.171.184.16, tymczasem
pierwsza przychodzi odpowiedź z adresem 66.93.78.63, należącym do
Thoughtcrime. Wynika to z faktu, że znalezienie prawdziwego adresu
Amazon zajmuje kilka milisekund, podczas gdy fałszywa odpowiedź jest
już przygotowana do wysłania.
Rysunek 8. Fałszowanie odpowiedzi DNS.
Rezultat jest taki, jak widać na rysunku 9. - w okienku figuruje
adres www.amazon.com, certyfikaty się zgadzają a połączenie
jest bezpieczne. Tylko że nie do tego serwera co trzeba... Benham
na stronie demonstracyjnej umieścił statyczny plik z ostrzeżeniem,
ale mógł umieścić tam wspomniane już wcześniej proxy
pośredniczące w przezroczystym połączeniu z prawdziwym Amazonem.
Rysunek 9. Rezultat ataku.
To samo można osiągnąć zresztą na inne sposoby, na przykład stosując
ARP spoofing lub transparentne proxy na serwerze nieuczciwego
dostawcy Internetu. W tym wypadku autor wykorzystał gotowy program
dnsspoof z pakietu dsniff autorstwa Dug Songa [2].
Pakiet ten zawiera również gotowe narzędzie do wykonywania ataków
man-in-the-middle na serwery HTTP i HTTP/SSL noszące nazwę
webmitm. Przy jego pomocy autor przeprowadził symulację pełnego
ataku tego typu, która trzeba przyznać robi wrażenie - użytkownik
pracowicie wypełnia formularze na stronie banku (posiadającego certyfikat
renomowanego urzędu), a atakujący spokojnie ogląda to na konsoli
programu webmitm. Ten ostatni wymagał tylko jednej poprawki,
związanej z obsługą ścieżek certyfikacji, ale ponieważ program
jest dostarczany ze źródłami, modyfikacja była trywialna.
Nie potrzeba wybujałej wyobraźnie, żeby zauważyć że konsekwencje
tego jednego drobnego błędu w MSIE przekreślają praktycznie całkowicie
bezpieczeństwo SSL w zakresie ochrony przed atakami man-in-the-middle
dla użytkowników tej przeglądarki. Wyjścia z tej sytuacji są dwa -
wymienić miliony przeglądarek lub wymienić miliony certyfikatów serwerów
(prawdopodobnie określona ich modyfikacja może spowodować, że MSIE jednak
wykryje nieprawidłowość w razie nadużycia), oba złe. Trudno powiedzieć
jak zareaguje gigant z Redmond, bo firma o błędzie dowiedziała się
zapewnie z Bugtraq. Odkrywca dziury nie postąpił bowiem tak jak się
to robi zwykle w takich przypadkach i nie poinformował producenta
z wyprzedzeniem, argumentując to tym że zirytowały go wykręty
Microsoftu w reakcji na wcześniej zgłoszoną dziurę.
Bibliografia
- [1] Mike Benham ,,Internet Explorer SSL Vulnerability'' http://online.securityfocus.com/archive/1/286290/2002-08-04/2002-08-10/0
- [2] dsniff http://www.monkey.org/~dugsong/dsniff/
| Załącznik | Rozmiar |
|---|---|
| mitm20.png | 41.11 KB |
| mitm21.png | 34.41 KB |
| mitm22.png | 33.28 KB |
| mitm23.png | 26.46 KB |
| mitm24.png | 25.03 KB |
English
Odpowiedzi
Dodaj nową odpowiedź