Błąd w ścieżce certyfikacji MS IE 6

2002-08-10 00:00:00 +0100


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
  2. przy wykorzystaniu tych kluczy A i B obliczają tajną liczbę, znaną tylko im, stanowiącą klucz do szyfrowania symetrycznego
  3. A i B wymieniają dane szyfrując je uzyskanym kluczem </ol>

    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ł. </ol>
      4. 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. </ol> </ol>


          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),
          3. 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
          4. jeśli nie, to patrzy czy przypadkiem klucza urzędu nie podpisał jakiś wyższy urzad (CA1), który zna
          5. ostatnie dwa kroki są powtarzane do sukcesu lub niepowodzenia </ol>

            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,
            2. certyfikatem tym - czyli kluczem publicznym i prywatnym, podpisanymi przez urząd, podpisujemy drugi, nielegalny serwer udający Bank,
            3. nielegalny serwer zyskuje poprawną certyfikację, ponieważ ścieżka certyfikacji kończy się na zaufanym urzędzie! </ol>
                        [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. </ul>


                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/ </ul>