Paweł Goleń, blog

Gdybym był autorem malware, który ma za zadanie atakować klientów bankowości elektronicznej (jeszcze raz powtórzę klientów, a nie banki), zadbałbym o to, by użytkownik nie zauważył, że coś jest nie tak. Czyli przede wszystkim zadbałbym, by adres strony wyglądał tak, jak należy, a i by połączenie odbywało się po protokole HTTPS a serwer dysponował zaufanym certyfikatem.

Przypominam, mowa o malware, a nie o zrobieniu jakiejkolwiek, byle podobnej strony i rozesłanie tysięcy maili zachęcających do wejścia na wspomnianą stronę. Skoro mogę uruchomić swój kod na czyimś komputerze, to w zasadzie osoba ta nie może już wierzyć w to, co jego komputer pokazuje. W mniejszym lub większym stopniu to, co użytkownik tego komputera widzi, jest tym, co ja chcę, by zobaczył.

Sprawienie, by użytkownik trafiał na mój serwer po wpisaniu adresu bankowości elektronicznej jest trywialnie proste. Wystarczy zmodyfikować plik hosts. W pliku tym znajdują się mapowania między nazwami i adresami IP. Jeśli szukana nazwa znajduje się w pliku hosts, system (Windows) nie zapyta już DNS. Wspominałem o tym w serii o moim tamagotchi, gdzie analizowany malware wykorzystywał plik hosts do blokowania aktualizacji antywirusów, oraz do walki z konkurencją. W rozważanym wypadku wystarczy wpisać do pliku nazwę DNS bankowości, z której korzystają atakowani klienci i podać adres IP podstawionego serwera. Co prawda sprawdzenie, czy taka sytuacja ma miejsce, jest trywialna. Wystarczy sprawdzić zawartość pliku hosts, który domyślnie znajduje się w ścieżce %systemroot%\system32\drivers\etc\. Przy okazji warto zapoznać się z artykułem Host Name Resolution.

Przy okazji należy pamiętać, że DNS nie jest bezpiecznym protokołem. W rezultacie nie można polegać, że adres IP podany przez DNS, jest adresem prawdziwym. Dlatego też tak ważny jest protokół HTTPS i weryfikacja certyfikatu serwera, który to certyfikat ma potwierdzać jego autentyczność.

Walidacja certyfikatu serwera jest jednak w praktyce zbyt skomplikowana dla przeciętnego użytkownika. Trzeba sprawdzić między innymi:

• czy certyfikat nie został odwołany (listy CRL),
• czy certyfikat jest już/jeszcze ważny (daty ważności certyfikatu),
• przez kogo certyfikat został wystawiony,
• czy certyfikat jest używany zgodnie z przeznaczeniem,
• czy nazwa podana w certyfikacie zgadza się z nazwą serwera,

Na szczęście użytkownik nie musi robić tego sam, robią to (częściowo) za niego przeglądarki (w przypadku Internet Explorer nawet sam Windows). Jeśli chodzi o Windows i Internet Explorer, to jakiś czas temu rzeczywiście były błędy w mechanizmie walidacji certyfikatów, w tej chwili można jednak założyć, że mechanizm ten działa poprawnie. W szczególności realizuje sprawdzenie wyżej wymienionych punktów.

Część banków umieszcza na swoich stronach informacje o tak zwanym odcisku wykorzystywanego certyfikatu. Jest to również przydatna informacja, którą można wykorzystać przy weryfikacji autentyczności serwera, problem jednak leży w dystrybucji tej informacji. W szczególności warto zastanowić się, czy umieszczanie informacji o prawidłowym certyfikacie na serwerze, którego autentyczności ten certyfikat ma dowodzić jest sensowne. Jeśli ktoś nie widzi jeszcze absurdu - mogę podstawić swój serwer, ze swoim certyfikatem, a na stronach informacyjnych (na nim) zamieścić informację, że prawidłowy certyfikat wygląda tak, jak wygląda certyfikat wykorzystywany przez ten właśnie serwer... W PKI problem ten został rozwiązany przez istnienie zaufanej strony trzeciej. Po prostu ufamy określonym wystawcom certyfikatów, jeśli certyfikat pochodzi od określonego wystawcy, traktowany jest jako zaufany. Tak naprawdę, to zwykle jest realizowane w ten sposób, że zaufane Główne Urzędy Certyfikacji wystawiają certyfikaty dla innych urzędów certyfikacji, które wystawiają certyfikaty dla użytkowników końcowych (choć tych poziomów pośrednich może być więcej). Przy weryfikacji certyfikatu budowana jest ścieżka, jednym z testów jest to, czy ścieżka prowadzi do zaufanego głównego urzędu certyfikacji. Warto jeszcze wspomnieć, że niektóre certyfikaty są lepsze od innych, konkretnie chodzi mi tu o certyfikaty Extended Validation SSL. Są one prezentowane inaczej w GUI (co pokazał już Tomek), a w założeniu mają być wystawiane po dokładnym sprawdzeniu podmiotu ubiegającego się o certyfikat. Jak zwykle najsłabszym ogniwem okazują się użytkownicy, większość z nich nie widzi różnicy miedzy normalnym certyfikatem a certyfikatem EV SSL. W rezultacie wbrew oczekiwaniom skuteczność certyfikatów EV SSL w walce z phishingiem jest dość niska.

Dalej będę pisał już o konkretnej implementacji, jaka jest dostępna w Windows. Z niej korzysta Internet Explorer. Firefox korzysta z własnych mechanizmów, jak jest w przypadku Opery - nie wiem.

Skąd system wie, które certyfikaty są zaufane? Certyfikatowi można zaufać bezpośrednio (lepiej tego nie robić), lub można dodać CA, które wystawiło dany certyfikat do listy zaufanych głównych urzędów certyfikacji (tu się warto zastanowić, czy chce się to robić). Lista zaufanych certyfikatów jest regularnie aktualizowana: http://support.microsoft.com/kb/931125. Problemem jest jednak to, że przeciętny użytkownik nie ma prostej metody na sprawdzenie, czy w jego systemie na liście zaufanych certyfikatów nie znalazło się jakieś obce CA. Certyfikat tego CA może być dodawany do listy zaufanych certyfikatów przez wspominane przez mnie hipotetyczne malware. Autorzy tego malware mogą sprzedawać autorom innego malware wystawione przez to CA certyfikaty. Na komputerach osób zainfekowanych tym pierwszym malware, certyfikaty będą uznawane za prawidłowe (bo ich ścieżka kończy się w zaufanym CA). Ups...

Podsumowując: mając możliwość uruchomienia swojego kodu na cudzym komputerze mogę:

• zmodyfikować plik hosts i przekierować go na swój serwer (pod warunkiem, że pracuje na koncie z prawami do modyfikacji wspomnianego pliku),
• dodać własny certyfikat zaufanego urzędu certyfikacji,

W rezultacie sprawdzenie, czy jest kłódeczka i czy adres zaczyna się od https:// nic nie daje. Prawdopodobnie w przypadku większości użytkowników sprawdzanie certyfikatu też nic nie da... Taki optymistyczny akcent na koniec.