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):

  1. strona A łączy się z B, po czym A i B wymieniają się swoimi
    kluczami publicznymi

  • przy wykorzystaniu tych kluczy A i B obliczają tajną liczbę,
    znaną tylko im, stanowiącą klucz do szyfrowania symetrycznego
  • A i B wymieniają dane szyfrując je uzyskanym kluczem

    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:

    1. Bank chce w wiarygodny sposób udostępniać swoje
      usługi przez Internet, więc:

    1. występuje do CA z kluczem publicznym swojego
      serwera,

    2. urząd sprawdza wiarygodność Banku, inkasuje gotówkę
      za tę usługę i podpisuje klucz banku swoim certyfikatem,
    3. Bank instaluje podpisany klucz na swoim serwerze
      i organizuje kampanię reklamową za 0,5 mln zł.
  • Alicja chce w sposób bezpieczny wysłać przelew, więc:
    1. łączy się z serwerem Banku i otrzymuje jego
      klucz publiczny,
    2. sprawdza podpis złożony przez urząd na klucz Banku -
      może to zrobić, ponieważ jej przeglądarka ma wbudowany
      klucz urzędu,
    3. 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?

    1. Alicja łączy się z Bankiem i otrzymuje jego klucz publiczny,
    2. przeglądarka Alicji sprawdza, kto podpisał klucz Banku,
      czy podpis jest poprawny i ważny (w sensie czasowym),

  • jeśli tak, to przeglądarka patrzy czy zna urząd (np. CA3), który
    podpisał klucz Banku; jeśli tak, to uznaje że wszystko
    jest w porządku
  • jeśli nie, to patrzy czy przypadkiem klucza urzędu nie
    podpisał jakiś wyższy urzad (CA1), który zna

  • ostatnie dwa kroki są powtarzane do sukcesu lub niepowodzenia
  • 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:

    1. kupujemy w renomowanym urzędzie certyfikat naszego legalnego
      serwera,

  • certyfikatem tym - czyli kluczem publicznym i prywatnym,
    podpisanymi przez urząd, podpisujemy drugi, nielegalny serwer
    udający Bank,
  • nielegalny serwer zyskuje poprawną certyfikację, ponieważ
    ś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.

  • Galeon zachowa sie identycznie (nic dziwnego, jest oparty o
    parser Mozilli).

  • Netscape 4.78 zwróci równie enigmatyczny komunikat The security
    library has encountered an improperly formatted DER-encoded message.
  • MS Internet Explorer wyświetli również ostrzeżenie, przedstawione na
    rysunku 7.

    <

    p>
    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.

    <

    p>



    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.

    <

    p>



    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.

    <

    p>



    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/
  • AttachmentSize
    mitm20.png41.11 KB
    mitm21.png34.41 KB
    mitm22.png33.28 KB
    mitm23.png26.46 KB
    mitm24.png25.03 KB