Szyfrowanie według Microsoftu

Po odkrytych dwa lata temu roku atakach na protokół RDP Microsoft wprowadził do niego nowe zabezpieczenia. Jednak mogą one co najwyżej służyć jako przykład dla studentów - jak NIE pisać oprogramowania kryptograficznego.

Problemem dawno znanym w protokole RDP (Remote Desktop Protocol) była jego podatność na ataki man-in-the-middle. RDP co prawda od dawna posiadało szyfrowanie danych oraz mechanizm wymiany klucza sesyjnego przy pomocy kluczy publicznych. Jednak w 2003 roku Erik Forsberg wskazał na poważny błąd projektowy - klucze publiczne co prawda są, ale... żadna ze stron ich nie sprawdza.

Normalne protokoły aby zabezpieczyć się przed ulokowanym pośrodku 'podsłuchiwaczem' weryfikują klucze publiczne każdej ze stron - temu służy cała hierarchiczna infrastruktura klucza publicznego (PKI). Protokół Microsoftu wykorzystywał klucze publiczne tylko w celu ustalenia klucza sesyjnego, ale nie sprawdzał czy klucze te należą faktycznie do stron połączenia.

Po wypuszczeniu SP2 (a dokładniej SP2 5.1.2600.2180) Microsoft ogłosił że problem został rozwiązany i że obecnie klient sprawdza podpis cyfrowy pod kluczem serwera.

W tym momencie pojawia się jednak pytanie - jeśli jest podpis, to jakim kluczem jest on składany? Postanowił na niego odpowiedzieć Włoch Massimiliano Montoro. Odpowiedź spowodowała że specjalistom od bezpieczeństwa po raz kolejny opadły ręce, a wykładowcy uniwersyteccy mają co pokazywać studentom jako przykład złego zrozumienia kryptografii.

Microsoft podpisuje klucz publiczny serwera kluczem prywatnym, który... jest na stałe zaszyty w jednej z bibliotek systemowych Windows (mstlsapi.dll). Oznacza to że klucz ten nie jest kluczem prywatnym, ponieważ jego kopia jest udostępniana tysiącom ludzi wraz z każdą sprzedawaną kopią Windows. Czyżby jakaś nowa forma kryptografii z kluczem publicznym? Coś w rodzaju Public Private Key? - ironizuje Montoro.

W momencie gdy ten klucz został ujawniony (a został przedstawiony w artykule Włocha), "zabezpieczenie" Microsoftu diabli wzięli. Atak został już zaimplementowany w popularnym narzędziu Cain & Abel, rozwijanym przez Montoro.

Problem ten nie jest nowy, każdy z protokołów szyfrujących ruch między dwoma odległymi lokalizacjami musiał jakoś rozwiązać zagadnienie dystrybucji kluczy prywatnych między nimi. Protokół SSH dokonuje wymiany klucza przy pierwszym połączeniu i pamięta raz pobrany klucz serwera, ostrzegając jeśli się on zmieni. Stosowany w przeglądarkach SSL wykorzystuje wbudowane w program klucze publiczne (a nie prywatne, jak Microsoft!) urzędów certyfikujących by weryfikować autentyczność przedstawionego przez serwer klucza.

Microsoft jeszcze raz postanowił zrobić szyfrowanie po swojemu - i jeszcze raz zrobił to całkiem źle.

Więcej informacji: http://www.oxid.it/downloads/rdp-gbu.pdf

Aktualizacja: 01 czerwca 2005 10:42

Windows 2003 Server umożliwia podpięcie do Terminal Servera dowolnego certyfikatu z bazy certyfikatów zamiast opisanego "publicznego klucza prywatnego" wbudowanego w bibliotekę. Procedura ta jest opisana w Knowledge Base:

http://support.microsoft.com/default.aspx?scid=kb;en-us;895433

Według naszych informacji nie jest to jednak możliwe w Terminal Server dostępnych z Windows XP. Dlaczego Microsoft nie zastosował od razu certyfikatów generowanych przecież w Windows 2003 Server "z pudełka"? Nie wiadomo.


Zobacz również