Wcześniej my o odkrytej luce typu zero-day w przeglądarce Internet Explorer, która umożliwia wykorzystanie specjalnie przygotowanego pliku MHT do pobrania informacji z komputera użytkownika na zdalny serwer. Niedawno tę lukę, odkrytą przez specjalistę ds. bezpieczeństwa Johna Page'a, postanowił sprawdzić i zbadać inny znany specjalista w tej dziedzinie - Mitya Kolsek, dyrektor ACROS Security, firmy audytorskiej bezpieczeństwa i współzałożyciel usługi mikropatch 0patch. On pełną kronikę swojego śledztwa, wskazującą, że Microsoft znacząco nie docenił powagi problemu.
Co dziwne, Kolsekowi początkowo nie udało się odtworzyć ataku opisanego i zademonstrowanego przez Johna, podczas którego za pomocą przeglądarki Internet Explorer działającej w systemie Windows 7 pobrał, a następnie otworzył złośliwy plik MHT. Chociaż jego menadżer procesów pokazał, że plik system.ini, który miał zostać mu skradziony, został odczytany przez skrypt ukryty w pliku MHT, ale nie został wysłany na zdalny serwer.
„Wyglądało to jak klasyczna sytuacja ze znakiem towarowym w sieci” – pisze Kolsek. „Kiedy plik jest odbierany z Internetu, poprawnie działające aplikacje Windows, takie jak przeglądarki internetowe i programy pocztowe, dodają do takiego pliku etykietę w postaci o nazwie Zone.Identifier zawierającej ciąg ZoneId = 3. Dzięki temu inne aplikacje wiedzą, że plik pochodzi z niezaufanego źródła i dlatego powinien zostać otwarty w piaskownicy lub innym ograniczonym środowisku.
Badacz sprawdził, czy IE faktycznie ustawił taką etykietę dla pobranego pliku MHT. Następnie Kolsek próbował pobrać ten sam plik za pomocą Edge'a i otworzyć go w IE, który pozostaje domyślną aplikacją dla plików MHT. Nieoczekiwanie exploit zadziałał.
Najpierw badacz sprawdził „mark-of-the-Web”, okazało się, że Edge oprócz identyfikatora bezpieczeństwa przechowuje także źródło pochodzenia pliku w alternatywnym strumieniu danych, co może rodzić pewne pytania dotyczące prywatności tego pliku metoda. Kolsek spekulował, że dodatkowe linie mogły zmylić IE i uniemożliwić mu odczytanie identyfikatora SID, ale jak się okazało, problem leżał gdzie indziej. Po długiej analizie specjalista ds. bezpieczeństwa znalazł przyczynę w dwóch wpisach na liście kontroli dostępu, które dodały prawo do odczytu pliku MHT określonej usłudze systemowej, które Edge dodał tam po jego załadowaniu.
James Foreshaw z dedykowanego zespołu ds. luk dnia zerowego – Google Project Zero – napisał na Twitterze, że wpisy dodane przez Edge'a odnoszą się do grupowych identyfikatorów zabezpieczeń pakietu Microsoft.MicrosoftEdge_8wekyb3d8bbwe. Po usunięciu drugiej linii identyfikatora SID S-1-15-2 - * z listy kontroli dostępu szkodliwego pliku exploit przestał działać. W rezultacie w jakiś sposób uprawnienie dodane przez Edge pozwoliło plikowi ominąć piaskownicę w IE. Jak zasugerował Kolsek i jego współpracownicy, Edge wykorzystuje te uprawnienia, aby chronić pobrane pliki przed dostępem procesów o niskim poziomie zaufania, uruchamiając plik w częściowo izolowanym środowisku.
Następnie badacz chciał lepiej zrozumieć, co powoduje awarię systemu bezpieczeństwa IE. Dogłębna analiza przy użyciu narzędzia Process Monitor i dezasemblera IDA ostatecznie ujawniła, że ustawiona rozdzielczość Edge'a uniemożliwiała funkcji Win Api GetZoneFromAlternateDataStreamEx odczytanie strumienia pliku Zone.Identifier i zwróciła błąd. W przypadku przeglądarki Internet Explorer taki błąd przy żądaniu etykiety zabezpieczającej plik był zupełnie nieoczekiwany i najwyraźniej przeglądarka uznała, że błąd jest równoznaczny z faktem, że plik nie posiada znaku „mark-of-the-Web”, co automatycznie czyni go zaufanym, po co IE zezwolił na wykonanie skryptu ukrytego w pliku MHT i wysłanie docelowego pliku lokalnego na zdalny serwer.
„Czy widzisz tu ironię?” – pyta Kolsek. „Nieudokumentowana funkcja zabezpieczeń używana przez Edge'a zneutralizowała istniejącą, niewątpliwie znacznie ważniejszą funkcję (znak-of-the-Web) w przeglądarce Internet Explorer.”
Pomimo zwiększonego znaczenia luki, która umożliwia uruchomienie złośliwego skryptu jako zaufanego skryptu, nic nie wskazuje na to, że Microsoft zamierza w najbliższym czasie naprawić błąd, jeśli w ogóle zostanie on naprawiony. Dlatego nadal zalecamy, aby podobnie jak w poprzednim artykule zmienić domyślny program do otwierania plików MHT w dowolnej nowoczesnej przeglądarce.
Oczywiście badania Kolska nie obyły się bez odrobiny autopromocji. Na koniec artykułu zademonstrował małą łatkę napisaną w języku asemblera, która może korzystać z opracowanej przez jego firmę usługi 0patch. 0patch automatycznie wykrywa podatne oprogramowanie na komputerze użytkownika i dosłownie na bieżąco instaluje do niego małe łatki. Przykładowo w opisanym przez nas przypadku 0patch zastąpi komunikat o błędzie w funkcji GetZoneFromAlternateDataStreamEx wartością odpowiadającą otrzymanemu z sieci niezaufanemu plikowi, dzięki czemu IE nie pozwoli na wykonanie żadnych ukrytych skryptów zgodnie z wbudowanym w polityce bezpieczeństwa.
Źródło: 3dnews.ru