„Bardzo się zdziwię, jeśli to wyjdzie na jaw”, czyli wyrzućcie Maxthona

dodał 14 lipca 2016 o 14:55 w kategorii Prywatność, Wpadki  z tagami: • • • •
„Bardzo się zdziwię, jeśli to wyjdzie na jaw”, czyli wyrzućcie Maxthona

Nasi Czytelnicy z firmy Exatel odkryli, że przeglądarka Maxthon, z której korzysta część internautów, wysyła na chińskie serwery całkiem sporo informacji naruszających prywatność użytkowników. Wyrzućcie zatem Maxthona i przeczytajcie.

Poniższy tekst przedstawia wyniki raportu z analizy technicznej, przeprowadzonej przez analityków trzeciej linii Centrum Operacji Bezpieczeństwa (SOC) Exatel SA. Raport ten powstał na bazie incydentu, jaki pod koniec marca zidentyfikowała grupa reagowania na incydenty, działająca w ramach SOC Exatel, w trakcie wdrażania systemu detekcji zagrożeń Fidelis w jednej z lokalizacji.

Dzięki informacjom pozyskanym w trakcie analizy przeprowadzonej z użyciem inżynierii odwrotnej kodu, grupie reagowania na incydenty SOC Exatel udało się dotrzeć do funkcjonalności, którą autorzy dość popularnego narzędzia próbowali zaszyć w oprogramowaniu, celem przesyłania do swoich serwerów treści, o której przesyłaniu użytkownik nie tylko nie został poinformowany przez producenta, ale i został mylnie przeświadczony, że tego typu treść nie opuści jego komputera jeśli nie da na to wyraźnej zgody.

Wkrótce po podłączeniu do monitorowania przez system Fidelis wewnętrznej sieci LAN organizacji, grupa reagowania na incydenty z SOC Exatel rozpoczęła rejestrować od kilkunastu do kilkudziesięciu razy dziennie alarm o naruszeniu reguły DLP.sendfiles.exfiltration, którą specjaliści z Exatel wbudowali do tego systemu w celu monitorowania, czy dokumenty (w ogólności szerokorozumiane dane) nie są przesyłane na zewnątrz sieci przy pomocy protokołu HTTP i metody POST. W taki właśnie sposób przeglądarki internetowe przesyłają różnego typu dane do zdalnych serwerów, w tym np. pliki załączników do wiadomości, wysyłanych z użyciem poczty webmail’owej. Okazało się, że z 3 komputerów znajdujących się w wewnętrznej sieci korporacyjnej, tym właśnie protokołem, regularnie, wysyłany jest do serwera w Pekinie, niewielki, kilkusetbajtowy plik o nazwie ueipdata.zip.

maxthon01

System Fidelis, wdrożony w Exatel, posiada moduł pamięci sieciowej gromadzącej nie tylko metadane, ale też szczegóły transmisji, która w jakikolwiek sposób narusza polityki bezpieczeństwa. Jest on w stanie zapamiętać i analizować w głąb – z użyciem DPI (Deep Packet Inspection) – zarówno protokoły komunikacyjne, jak i zróżnicowane metody kodowania zagnieżdżonych w nich plików. Dzięki temu eksperci od bezpieczeństwa z Exatel dysponują pełną wiedzą o incydentach.

maxthon02

Powyższy zrzut ekranu z konsoli monitoringu zdarzeń systemu Fidelis przedstawia szczegóły dotyczące pojedynczego alarmu, wygenerowanego na skutek naruszenia wspomnianej wcześniej reguły, opisującego potencjalną eksfiltrację danych do serwera w Chinach.

To, co rzuciło się najpierw w oczy specjalistom z SOC to fakt, że przesyłany plik ueipdata.zip zawiera spakowany pojedynczy plik dat.txt, który w rzeczywistości nie jest plikiem tekstowym, lecz zawiera dane o dużej entropii, będące albo wyjściem z generatora losowego, albo wynikiem szyfrowania. Ponadto typ przesyłanego pliku – identyfikowany polem content-type protokołu HTTP – został oznaczony jako image/pjpeg, czyli… obrazek:

maxthon03

Jednak najbardziej zadziwiała fraza, pojawiająca się kilkukrotnie w treści wysyłanego pakietu HTTP, zawierająca łańcuch tekstowy IllBeVerySurprisedIfThisTurnsUp.

maxthon04

Pierwszym, i chyba najbardziej oczywistym w tych okolicznościach, podświadomym tłumaczeniem frazy było: „bardzo się zdziwię, jeśli to wyjdzie na jaw”. A zważywszy na fakt, że zbliżał się akurat 1 kwietnia, eksperci z SOC Exatel początkowo pomyśleli, że być może któryś z ich kolegów testuje, czy nowo nowo zainstalowany w sieci system Fidelis będzie w stanie takie zdarzenie wykryć.

Okazało się to jednak błędnym tłumaczeniem tej frazy

Dalsza analiza zbieżności nazwy docelowego serwera w Chinach i identyfikatora user-agent, zapamiętanego przez Fidelis (identyfikatora, którym identyfikuje się zwykle klient HTTP) umożliwiła ekspertom z Exatel dotarcie do prawdziwego winowajcy (i właściwego tłumaczenia tej frazy).

maxthon05

Winowajcą, stojącym za alarmami systemu Fidelis, okazała się przeglądarka internetowa Maxthon, stworzona i rozwijana przez Chińczyków.

maxthon06

Zgodnie z serwisem StatsMonkey w 2014 zajmuje ona szóstą pozycję pod względem popularności, zarówno w Polsce, jak i w Chinach.

maxthon07 maxthon08

To przeglądarka Maxthon, zainstalowana na komputerach 3 pracowników firmy, wysyłała pliki, które zauważył system Fidelis. Co dodaje ironii całej sprawie, autorzy przeglądarki informują na swojej stronie, że jest ona stworzona z myślą o zapewnieniu bezpieczeństwa i prywatności użytkowników, w świetle skandali z łamaniem prywatności przez amerykańską agencję NSA. Jak można przeczytać w opiniach na temat Maxthona, również użytkownicy darzą szczególną sympatią tę przeglądarkę, ze względu na fakt, iż… jej autorzy nie dzielą się danymi z amerykańską agencją wywiadu elektronicznego NSA:

maxthon09

Wracając do łańcucha tekstowego „IllBeVerySurprisedIfThisTurnsUp”, który nakierował uwagę ekspertów z SOC, jego pojawienie się w transmisji było wynikiem zarówno zbiegu okoliczności, jak i poczucia humoru jednego z chińskich programistów. Użył on takiego właśnie statycznego łańcucha tekstowego w kodzie biblioteki C++ (opartej o framework MFC), by separować nim pliki zagnieżdżone w transmisji HTTP (w naszym przypadku instruując serwer Maxthona jak zdekodować plik ZIP w pakiecie HTTP (przekazując string zakresu o takiej właśnie wartości w nagłówku HTTP, w zmiennej boundary pola content-type).

Napisana przez niego jeszcze w 2007 roku biblioteka implementująca klienta protokołu HTTP:

maxthon10

została użyta przez twórców Maxthon do stworzenia części funkcjonalności przeglądarki, (funkcjonalności o której napiszemy dalej), a prawidłowe tłumaczenie wspomnianej frazy powinno brzmieć „bardzo się zdziwię, jeśli ta sekwencja znaków pojawi się gdzieś w załączonym pliku, przesyłanym przez program”.

No dobrze… ale zatrzymaliśmy się na pliku ueipdata.zip, który w dziwnych okolicznościach (i formie) opuszcza komputery, na których zainstalowano przeglądarkę. Otóż po krótkim dochodzeniu udało się rozszyfrować skrót UEIP jako „User Experience Improvement Program”. Taką nazwę nosi program, który – jak zapewniają na stronie przeglądarki autorzy – jest dobrowolny i anonimowy, a jego celem jest pomoc autorom w ulepszaniu przeglądarki poprzez dzielenie się informacjami na temat sprzętu, na którym zainstalowano przeglądarkę oraz danymi dotyczącymi systemu operacyjnego oraz ew. błędów w trakcie działania przeglądarki.

maxthon11

Jak też zapewniają jej autorzy, z programu UEIP można w każdym momencie zrezygnować, a „prywatność użytkownika jest respektowana”.

Eksperci od bezpieczeństwa z Exatel postanowili więc to sprawdzić. Na swojej testowej maszynie zainstalowali przeglądarkę Maxthon, upewniając się, że na ekranie startowym instalatora odznaczyli opcję uczestniczenia w programie UEIP:

maxthon12

Efekt? Niestety brak.
Nasłuch ruchu TCP na interfejsie sieciowym maszyny w trakcie użytkowania przeglądarki, pokazał regularną komunikację z tym samym serwerem Maxthon (u.dcs.maxthon.com), zawierającą w swojej treści plik ueipdata.zip.

Specjalistów z SOC zaintrygowało kilka kwestii.

Po pierwsze: dlaczego dane programu UEIP – pomimo wyraźnego braku zgody użytkownika – są wysyłane do producenta Maxthon?
Po drugie: dlaczego plik ueipdata.zip, który zawiera pozornie tekstowy plik out.txt jest wysyłany dalej, pod postacią pliku zdjęciowego?
I po trzecie: co właściwie przekazuje do serwerów Maxthon przeglądarka w pliku ZIP?

Eksperci od bezpieczeństwa z Exatel postanowili zbadać całą sprawę. W tym celu zlokalizowali miejsce w kodzie procesu głównego przeglądarki Maxthon, w którym wydawany jest rozkaz zaszyfrowania danych (dane te są zapisywane w pliku out.txt, spakowane do pliku ueipdata.zip i wysłane do serwera Maxthon). Jak szybko zauważyli, dane są szyfrowane symetrycznym algorytmem Rijndael (AES), z użyciem stałego, statycznie wkompilowanego w kod przeglądarki, 16 bajtowego klucza eu3o4[r04cml4eir bez użycia żadnej obfuskacji.

maxthon13

Klucz, wraz z buforem danych do zaszyfrowania i jego wielkością (zaraz przed zbudowaniem nowego pliku ueipdata.zip i wysłaniem go do serwera Maxthon) jest przekazywany do funkcji Encode, znajdującej się w pliku biblioteki dynamicznej Maxthona o nazwie MxEncode.dll, odpowiedzialnej za szyfrowanie danych UEIP przesyłanych między przeglądarką, a zdalnym serwerem Maxthon i zawartych w plikach ZIP.

maxthon14

Do stworzenia biblioteki MxEncode użyto biblioteki kryptograficznej Crypto++, co można zauważyć, analizując tablicę symboli pliku wykonywalnego.

AVlogic_error@std@@
 AVlength_error@std@@
 AVout_of_range@std@@
 AVtype_info@@
 AVbad_exception@std@@
 AV?$BlockCipherFinal@$0A@VEnc@Rijndael@CryptoPP
 AV?$BlockCipherImpl@URijndael_Info@CryptoPP@@VBlockCipher@2
 AVexception@std@@
 AV?$FixedBlockSize@$0BA@@CryptoPP@@
 AVEnc@Rijndael@CryptoPP@@
 AV_Iostream_error_category@std@@
 AV_Generic_error_category@std@@
 AURijndael_Info@CryptoPP@@
 AVNotImplemented@CryptoPP@@
 AVAlgorithm@CryptoPP@@
 AVDec@Rijndael@CryptoPP@@
 AV?$TwoBases@VBlockCipher@CryptoPP@@URijndael_Info@2@@CryptoPP@@
 AV?$BlockCipherFinal@$00VDec@Rijndael@CryptoPP@@@CryptoPP@@
 AVNameValuePairs@CryptoPP@@
 AVNullNameValuePairs@CryptoPP@@
 AVInvalidKeyLength@CryptoPP@@
 AVInvalidArgument@CryptoPP@@
 AVbad_alloc@st

Dalsza analiza pokazała, że biblioteka MxEncode jest również odpowiedzialna za szyfrowanie i deszyfrowanie lokalnych plików konfiguracyjnych Maxthon, znajdujących się na dysku użytkownika, których to treść producent przeglądarki chroni przed możliwością swobodnego podejrzenia.

W związku z powyższym eksperci z SOC Exatel postanowili założyć nasłuch na komunikacji między przeglądarką Maxthon, a jej modułem szyfrującym MxEncode.dll i przeprowadzić atak Man-In-The-Middle na bibliotekę szyfrującą Maxthon.

Wykorzystali fakt, że w klasycznym przypadku przeglądarka – chcąc wysłać zaszyfrowane dane UEIP do serwera w Chinach – załaduje najpierw znajdującą się w swoim instalacyjnym katalogu bibliotekę MxEncode.dll, wyśle do niej dane do zaszyfrowania wraz z kluczem szyfrującym, wywołując jej funkcję eksportową Encode, a biblioteka – po zaszyfrowaniu danych – zwróci zaszyfrowany bufor wyjściowy do procesu Maxthon, który następnie już zaszyfrowane dane wyśle.

maxthon15

Eksperci z SOC stworzyli więc własną biblitekę DLL, imitującą oryginalną bibliotekę MxEncode, umieszczając w niej tak samo jak w oryginale dwie funkcje eksportowe: szyfrującą Encode i deszyfrującą Decode.

#include 
#include 
extern "C" {
char mxEncodeDLLFile[] = "MxEncodeOrig.dll";
char encFile[] = "enc.dat";
char decFile[] = "dec.dat";
typedefint (*MxDecodePtr)(char *outBuf, char *inBuf, 
	intbufSize, unsigned char *key);
typedefint (*MxEncodePtr)(char *outBuf, char *inBuf, 
	intbufSize, unsigned char *key);
__declspec(dllexport) intMxEncode(char *outBuf, 
	char *inBuf, intbufSize, 
	unsigned char *key)
{
	HMODULE lib = LoadLibrary(mxEncodeDLLFile);
	void *ptr = GetProcAddress(lib, "MxEncode");
	MxEncodePtrMxEncode = (MxEncodePtr) ptr;
	FILE *f=fopen(encFile, "ab");
	fprintf(f, "[ENC.KEY] %s\r\n", key);
	fprintf(f, "[ENC.SIZ] %d\r\n", bufSize);
	fprintf(f, "[ENC.BUF] ");
	fwrite(inBuf, 1, bufSize, f);
	fprintf(f, "\r\n");
	fclose(f);
	return MxEncode(outBuf, inBuf, 
		bufSize, key); 
} 
__declspec(dllexport) intMxDecode(char *outBuf, 
	char *inBuf, intbufSize, unsigned char *key)
{
	HMODULE lib = LoadLibrary(mxEncodeDLLFile);
	void *ptr = GetProcAddress(lib, "MxDecode");
	MxDecodePtrMxDecode = (MxDecodePtr) ptr;
	int ret = MxDecode(outBuf, inBuf, 
		bufSize, key);
	FILE *f=fopen(decFile, "ab");
	fprintf(f, "[DEC.KEY] %s\r\n", key);
	fprintf(f, "[DEC.SIZ] %d\r\n", bufSize);
	fprintf(f, "[DEC.BUF] ");
	fwrite(outBuf, 1, bufSize, f);
	fprintf(f, "\r\n");
	fclose(f);
	return ret;
}
BOOL APIENTRY DllMain(HINSTANCE hModule, 
	DWORD ul_reason_for_call, 
	LPVOID lpReserved)
{
	return TRUE;
}
}

W obu funkcjach umieścili kod zapisujący na dysku dane (do wyznaczonego przez nich pliku), których zaszyfrowania w dowolnym momencie przeglądarka może od swojej biblioteki zażądać. Po otrzymaniu żądania zaszyfrowania (i zapisaniu danych na dysk), biblioteka podstawiona przez expertów Exatel powinna załadować właściwą bibliotekę szyfrującą Maxthona, wywołując właściwą funkcję szyfrującą, a zaszyfrowane dane zwrócić do przeglądarki Maxthon, która następnie dane prześle do serwera Maxthon.

maxthon16

W ten sposób pozwolili oni Maxthonowi przepuścić przez swoją bibliotekę całość danych, których zaszyfrowania zażąda przeglądarka przed ich wysłaniem do Chin. Specjaliści z SOC w Exatel otrzymali tą metodą nie tylko całą zdeszyfrowaną już transmisję UEIP do serwerów w Pekinie, ale również dodatkowo pozwolili Maxthonowi rozszyfrować pliki konfiguracyjne, przechwytując do tego klucze deszyfrujące i dane zwracane przez funkcję Decode oryginalnej biblioteki MxEncode.

Następnie uruchomiono przeglądarkę, aby sprawdzić efekt.

Zaraz po uruchomieniu Maxthona, załadował on bibliotekę MxEncode i zażądał zaszyfrowania pierwszych danych przed ich wysłaniem, przekazując ekspertom z Exatel klucz szyfrujący, pozyskany w trakcie wcześniejszej analizy z wykorzystaniem inżynierii odwrotnej.

maxthon17

Jak widać, zaszyfrowane i wysłane do serwera zostały: wersja Service Pack systemu Windows, wersja przeglądarki Maxthon, rozdzielczość ekranu wirtualnej maszyny, typ i częstotliwość procesora oraz ścieżka w jakiej zainstalowano Maxthona na dysku. Wysłane również zostały wartości zmiennych konfiguracyjnych: czy włączono adblock, liczbę już zablokowanych reklam oraz adres WWW ustawionej strony startowej.

Można uznać, iż powyższe dane zgadzają się z listą informacji o których wysyłaniu autorzy piszą w opisie programu UEIP (abstrahując od faktu iż użytkownik nie wyraził zgody na przystąpienie do programu).

Następnie specjaliści SOC Exatel skupili się na tym jakie operacje szyfrowania z użyciem biblioteki MxEncode wykonuje przeglądarka Maxthon w momencie otwarcia nowej strony. Po wejściu na pierwszą stronę (akurat Onet) okazało się, że… fakt wejścia na tę stronę został również odnotowany i przekazany do serwera Maxthon.

maxthon18

maxthon19

Podobnie jak informacja o każdej, kolejno odwiedzanej stronie.

Logowanie do poczty:

maxthon20

Odwiedziny na stronie sejmu:

maxthon21

Wejście na stronę banku:

maxthon22

Tak więc wszystkie zapytania metodą GET protokołu HTTP były przesyłane do serwera Maxthon.

Co to oznacza w skrócie?

Cała historia przeglądania użytkownika trafia do serwera autorów w Pekinie, wraz ze wszystkimi wpisywanymi zapytaniami w Google.

Kontynuując przeglądanie Internetu z użyciem Maxthona „na podsłuchu”, eksperci z Exatel zauważyli, że raz na około 5 wysłanych plików ueipdata.zip, przekazywana jest również pełna lista oprogramowania zainstalowanego na komputerze, wraz z dokładnymi numerami wersji.

maxthon23

W rzeczywistości: taka ilość informacji, jaka jest przesyłana bez wiedzy użytkownika do serwerów Maxthon otwiera furtkę do przeprowadzenia bardzo precyzyjnego ataku targetowanego. Posiadając wiedzę na temat preferencji przeglądania stron WWW, informację na temat wyszukiwań Google oraz pełną listę zainstalowanego na komputerze użytkownika oprogramowania – atakującemu brakuje tylko adresu email – pod który prześle uwiarygodnioną swoją treścią wiadomość, zawierającą w załączniku uzbrojony exploit zdalnego wykonania kodu.

Dodatkowo, ze względu na kolejny błąd, jaki popełnili autorzy (tym razem jest to błąd w architekturze kryptograficznej) – dane, które płyną bez autoryzacji użytkownika mogą być w każdym momencie podsłuchane i zdeszyfrowane przez każdego potencjalnego atakującego. Wystarczy, że stanie on pomiędzy przeglądarką użytkownika, a serwerem Maxthon, by podsłuchać komunikację. Podsłuchaną transmisję UEIP można zdeszyfrować, używając symetrycznych kluczy algorytmu AES, wydobytych z kodu binarnego Maxthon przy zastosowaniu inżynierii odwrotnej.

Tak więc eksperci z SOC słusznie mieli wątpliwości co do bezpieczeństwa użytkowania przeglądarki Maxthon, podobnie jak inni jej użytkownicy, którzy zauważyli na swoich dyskach tworzone pliki ueipdata.zip.

maxthon24

Od producenta uzyskano tylko wymijającą odpowiedź, że istnieją… dwa różne typy programu UEIP.

maxthon25 maxthon26

Natomiast kolejna prośba użytkownika, trochę do autorów, a trochę do innych użytkowników, o pomoc w ujawnieniu dokładnej zawartości plików ueipdata.zip, którego utworzenie na swoim dysku zarejestrował użytkownik:

maxthon27

zakończyła się skierowaniem do użytkownika informacji, iż odpowiedzi na swoje pytania znajdzie w opisie polityki prywatności.

Reasumując powyższe: przeglądarka Maxthon nie jest bezpieczna.

Umożliwia przeprowadzenie ataku targetowanego na wybranego użytkownika, wysyłając do autorów przeglądarki pełną listę dokładnych wersji programów podatnych na atak, zainstalowanych na maszynie użytkownika.

Użycie symetrycznej kryptografii i wkompilowanych w kod statycznych kluczy szyfrujących do zabezpieczenia transmisji danych UEIP, umożliwia tak naprawdę dowolnemu atakującemu przeprowadzenie ataku Man-In-The-Middle i rozszyfrowanie przechwyconych między przeglądarką, a pekińskim serwerem Maxthon danych UEIP.

Warto również podkreślić fakt, że Exatel skontaktował się z autorami przeglądarki Maxthon, przesyłając szczegółowy raport techniczny z prośbą o reakcję, np. w postaci poinformowania użytkowników o typie danych wysyłanych z ich przeglądarek do serwerów Maxthon w Pekinie, czy wypuszczenia poprawki, która umożliwiałaby zaniepokojonym użytkownikom efektywne wyłączenie przesyłu plików UEIP do ich serwerów. Prośba ta została zignorowana.

Najnowsza wersja przeglądarki (wersja 4.9.2.1000), pobrana ze strony autorów, została także przetestowana przez ekspertów Exatel i wciąż wysyła dane UEIP, nie respektując w żaden sposób wyboru użytkownika dot. uczestnictwa w tym programie. Do momentu przekazania tych treści do publikacji, nic się nie zmieniło…

Podobne wpisy