Badacze Google Project Zero poinformowali użytkowników Internetu o znaczącym zagrożeniu. Na atak podatnych jest 500 milionów użytkowników gier online Blizzard Entertainment takich jak World of Warcraft, Diablo III, Hearthstone czy Starcraft II.
Tavis Ormandy odkrył, że moduł aktualizacji (Blizzard Update Agent) jest podatny na tak typu „DNS Rebinding” (ponowne przypisanie adresu w DNS). Tego rodzaju atak pozwala dowolnej stronie zrealizować połączenie pomiędzy zewnętrznym serwerem a usługą lokalną uruchomioną w ramach adresacji wewnętrznej komputera ofiary (najczęściej localhost). Prawdopodobnie możliwość nawiązywania połączenia do adresów lokalnych nie skupiłaby uwagi badaczy na module aktualizacji, gdyby nie możliwość wykonania za jego pomocą niemal dowolnej akcji zagrażającej komputerowi (np. pobranie i wykonanie dowolnego pliku, instalacja biblioteki DLL, transfer danych). Możliwości, jakie daje podatność, sprawiają, że każdy gracz jest łatwym celem i potencjalną ofiarą.
W czym tkwi problem
Program po stronie komputera gracza tworzy lokalny serwer JSON RPC słuchający na porcie 1120. Usługa ta akceptuje polecenia takie jak instalacja, deinstalacja, zmiana ustawień i kilka dodatkowych opcji serwisowych. Producent gier opracował własny protokół komunikacyjny z serwerem zawierający prosty schemat uwierzytelnienia, który weryfikuje jedynie, czy zapytanie pochodzi z uprawnionego adresu źródłowego.
Źródło: https://bugs.chromium.org/p/project-zero/issues/detail?id=1471&desc=2
Komputer lokalny może wykonać takie zapytanie bez uwierzytelnienia, natomiast kolejne zapytania w komunikacji powinny posługiwać się tokenem authorization przekazanym w pierwszej odpowiedzi. Jednak w kolejnych żądaniach token nie jest sprawdzany. W istocie okazuje się, że jedynym weryfikowanym kryterium jest adres źródłowy nadawcy (czy jest to localhost). Takie uproszczenie komunikacji poprzez lokalny serwer JSON RPC sprawia, iż wykorzystując atak typu DNS rebinding można dowolnie przejąć komputer ofiary.
Źródło: https://lock.cmpxchg8b.com/yah4od7N.html
Każda odpowiednio przygotowana strona WWW może wysłać polecenie do lokalnego serwera JSON. Atakujący może wskazać do pobrania na komputer ofiary dowolny program, zainstalować go, ukryć , dołączyć bibliotekę DLL. Wydaje się, że gama akcji jest nieograniczona.
Na czym polega atak typu DNS rebinding
W tego typu ataku ofiara odwiedza specjalnie przygotowaną stronę WWW i w swojej przeglądarce uruchamia skrypt z dowolnej lokalizacji sieci. Reguły same-origin policy ograniczają przeglądarce możliwość dostępu tylko do zawartości na tym samym serwerze, co uruchomiony skrypt. Są one realizowane poprzez porównywanie nazw domen. Ponowne przypisanie nazw w DNS omija tę ochronę, co jest nadużyciem w systemie nazw domen (DNS).
Tego rodzaju atak jest wykorzystywany podczas włamań do sieci prywatnych, zmuszając przeglądarkę ofiary do połączenia z prywatnymi adresami i zwrócenia wyniku atakującemu.
Atakujący rejestruje domenę i deleguje ją na serwer DNS, który jest pod jego kontrolą. Ważnym elementem ataku jest ustawienie bardzo krótkiego „czasu życia informacji” (rekord TTL), by uniemożliwić zapamiętywanie odpowiedzi DNS w pamięci podręcznej przeglądarki lub systemu ofiary. Kiedy ofiara odwoła się poprzez swoją przeglądarkę do domeny atakującego, serwer DNS w pierwszej odpowiedzi zwróci adres IP serwera, utrzymującego spreparowany skrypt do wykonania w przeglądarce ofiary. Gdy ofiara uruchamia skrypt, następuje ponowne zapytanie DNS o domenę, ale teraz ofiara otrzymuje nowy adres IP. Najczęściej kolejne zapytania odwołują się do prywatnych adresów lub wewnętrznego adresu komputera ofiary.
Źródło: https://bugs.chromium.org/p/project-zero/issues/detail?id=1471&desc=2
To nie pierwszy raz
Warto dodać, że kilka dni wcześniej Tavis Ormandy ujawnił niemal identyczną podatność w popularnym kliencie torrentów Transmission BitTorrent. W tym przypadku atak także umożliwiał wykonanie dowolnego kodu na komputerze ofiary.
Scenariusz ataku był niemal taki sam. Klient torrentów nawiązywał komunikację z serwerem JSON RPC (tym razem na porcie 9091), a jedynym zabezpieczeniem transmisji była weryfikacja, czy połączenie pochodzi z adresu lokalnego 127.0.0.1. Badacz wykazał, że taka konfiguracja jest podatna na atak typu DNS rebinding (CVE-2018-5702). Najbliższa aktualizacja oprogramowania ma usunąć ten problem. Podobne błędy odkryto także w portfelach Ethereum – pomyślcie zatem, gdzie jeszcze wystawiony jest lokalny interfejs ufający lokalnym połączeniom.
Komentarze
Na localhost można czasami znaleźć ciekawe usługi. Niektóre AV instalują service z uprawnieniami SYSTEM (mówię o Windows), bez żadnej autentykacji, za to z podatnościami. I mamy piękne RCE i nawet nie wiadomo którędy weszło ;)
Localhostowi takie IE ufa bez granic.
A ile fajnych rzeczy można znaleźć przez przekierowanie portów, z drugą nogą właśnie zaczepioną o localhost.
Z dedykacją dla adminów/userów „ale ten host jest za firewallem i nie ma żadnych publicznych usług”.
Ciekawy opis, dzięki. Brakuje mi jednak informacji dlaczego konieczny jest DNS rebuilding? Rozumiem, że nie musimy mieć dostępu do treści odpowiedzi na zapytanie, dlaczego więc, nie można wykorzystać sztuczki np. https://systemoverlord.com/2016/08/24/posting-json-with-an-html-form.html do wysłania JSON za pomocą formularza? Serwer weryfikuje Content-Type zapytania?
Nie rozumiem, jak to działa. Przecież w ustawieniach karty sieciowej mam wpisane dns=8.8.8.8 (powiedzmy). To jak jakiś program pyta sie o IP gdzieś indziej? Przecież u googli wpisów nie podmieniają.
W uproszczeniu: publiczny resolver DNS jakim jest G nie zna i nie może znać adresów ip wszystkich domen i subdomen. Dlatego każdy kto ma swoją domenę utrzymuje jej DNS na jakimś serwerze. Kiedy sobie utworzy nową subdomenę i ktoś będzie chciał się do niej dostać korzystając z DNSa Google, ten pójdzie do nameservera DNS utrzymującego tą domenę i zapyta go gdzie jest ta subdomena. Odpowiedź skeszuje sobie na TTL sekund. Jako właściciel tej domeny mogę generować ranodmowe subdomeny i co chwilę zmieniać adres IP w moim DNSie (stąd rebinding DNS: najpierw IP mojego random.example.com to 1.1.1.1 a za moment 127.0.0.1).