Bo do komunikatora trzeba dwojga

W ostatnim czasie nie pisałem za dużo na tematy związane z bezpieczeństwem. Czas wypełnić tę lukę, oto pierwsza część cyklu poświęconego mobilnemu komunikatorowi Usecrypt Messenger. Jest to produkt generujący cyklicznie falę pochlebnych artykułów w tych tytułach prasowych, których redakcje zwykły publikować przekazane materiały marketingowe. Ha, redakcja czasopisma Informatyk Zakładowy działa inaczej.

Analizę Usecrypt Messengera rozpoczniemy od pewnego małego detalu, funkcji zapraszania znajomych do instalacji komunikatora. Zobaczymy, że decyzja, która oszczędziła autorom dwa kwadranse pracy, wystawiła na ryzyko oszustwa tysiące osób otrzymujących takie zaproszenia.

Aby zbudować odpowiednie tło, najpierw przywołam garść cytatów:

„Usecrypt Messenger to polski komunikator, który uznawany jest za jeden z lepszych, bezpiecznych komunikatorów internetowych. Renoma ta została właśnie potwierdzona przez Ministerstwo Obrony Izreala, które zarekomendowało ją jako bezpieczny komunikator dla tamtejszych instytucji publicznych.” Spider’s Web, 2020

„W 2018 roku gen. Waldemar Skrzypczak, były dowódca wojsk lądowych i podsekretarz stanu w resorcie obrony, wystawiał pozytywne oceny komunikatorowi Usecrypt Messenger, chwaląc m.in. jego wyjątkowe zabezpieczenia przed cyberatakami.” PAP, 2020

„Do nocnych rozmówek „trzy po trzy” z kolegami można używać darmowego Signala. UseCrypt Messenger jest bezkonkurencyjny tam, gdzie wymaga się bezkompromisowej poufności i tajności rozmów, zarówno podczas transmisji, jak i na urządzeniu.” CRN.pl, 2019

„Dobór wszystkich parametrów operacyjnych dla algorytmów kryptograficznych UseCrypt Messenger został przeprowadzony przez specjalistów odpowiedzialnych za wytwarzanie wojskowych systemów łączności.” Defence24.pl, 2018

Skoro na przestrzeni lat tyle osób wypowiadało się o przewagach Usecrypt Messengera, to nabieramy przekonania, że jego kod źródłowy trzyma najwyższe standardy bezpieczeństwa i był audytowany przez specjalistów, prawda? Zapamiętajmy to pytanie.

Zapraszamy znajomych do korzystania z Usecrypt Messengera

Opisywany komunikator nie jest zbyt popularny, więc nowy użytkownik najprawdopodobniej zaprosi do niego swoich znajomych. Odpowiedni ekran aplikacji wygląda tak:

Gdyby ktoś nie dostrzegł komizmu, poniżej fragment screenshota z adekwatnymi podkreśleniami:

Sytuacja wygląda więc tak – korzystacie z hiper-bezpiecznego komunikatora a ten nagle w zaproszeniach wysyła link do strony WWW dostępnej przez nieszyfrowane połączenie. Gdy zaproszona osoba kliknie w taki link, każdy system pośredniczący w transmisji danych będzie mógł dowolnie modyfikować zawartość pobieranej strony. Potencjalne następstwa? Choćby przekierowanie użytkownika do instalacji złośliwie zmodyfikowanej kopii komunikatora, kradnącej wszystkie dane.

Taka usterka, obecna w aplikacji przez wiele lat, podważa wszystkie cytowane uprzednio autorytety. Każdy, absolutnie każdy audyt bezpieczeństwa powinien natychmiast wskazać tę usterkę jako krytyczną. Tak naprawdę problem powinien natychmiast spostrzec nawet początkujący tester, nie mówiąc o osobach odpowiedzialnych za techniczną realizację projektu.

Domyślacie się zapewne, że na tym artykuł się nie kończy, bo o co halo, o literówkę? Dokładamy „s”, będzie bezpieczne połączenie, problem z głowy.

A jednak nie. Postanowiłem pokazać Wam realne zagrożenie.

Co to jest autofwd.com?

Serwis autofwd.com jest, a w zasadzie był usługą pozwalającą na przekierowanie użytkownika pod adres zależny od urządzenia, z którego ów użytkownik przegląda internet. W przypadku Usecrypt Messengera było to przekierowanie do App Store, sklepu Play albo strony WWW – przy wejściu na link autofwd.com/ucmessenger z (odpowiednio) iOS, Androida lub peceta.

W dzisiejszych czasach istnieją tylko dwie liczące się platformy mobilne a takie przekierowanie załatwia się jedną linijką. Autofwd.com powstawał jednak około roku 2011 i obsługiwał także BlackBerry, Windows Mobile, czytniki Kindle, Nook i Kobo a także Windows i Linuksa. Pod koniec 2014 serwis wyglądał mniej więcej tak. Kilka lat później – tak. Jak łatwo odgadnąć, ostatnie pięć lat było jazdą na pełnym autopilocie.

Pomyślałem więc sobie, że tak stary kod źródłowy może zawierać jakieś zaszłości, które pozwolą na przejęcie odsyłacza autofwd.com/ucmessenger i przekierowanie go w jakieś niepożądane miejsce. Autorzy Usecrypt Messengera najwyraźniej skorzystali z pierwszego lepszego narzędzia, na które trafili. Zignorowali ryzyka, jakie wiążą się z powierzeniem funkcji zaproszeń zewnętrznemu dostawcy.

Ale by było, gdyby ktoś zhackował autofwd.com, prawda? Ciekawe, czy byłoby trudne, nie?

Potrzymajcie mi piwo.

Jak przejąłem odsyłacz autofwd.com/ucmessenger

Opiszę w skrócie proces przejęcia kontroli nad serwisem autofwd.com

Rekonesans

Zarejestrowałem nowe konto, dodałem nową aplikację, zacząłem rozglądać się po serwisie. Spostrzegłem, że na niektórych stronach pojawiają się komunikaty błędu a w nich pełna ścieżka do katalogu zawierającego aplikację webową.

Przeskanowałem domenę pod kątem interesujących katalogów, pomogło w tym narzędzie dirsearch. Interesujących znalezisk nie było wiele: katalog z obrazkami, z ikonami wysłanymi przez użytkowników, z templatkami, ze starymi wersjami jQuery i Bootstrapa.

Katalog ikonek dawał się wylistować, co pozwoliło określić łączną liczbę istniejących projektów (przekierowań) na około 150. Istotne mogło być też to, że serwer WWW miał prawa zapisu do tego katalogu.

Pierwszy wektor ataku – i od razu sukces

Gdy skończyłem rozglądanie, zacząłem od próby wykonania najprostszego ataku XSS:

Mimo wszystko byłem zaskoczony, gdy po zapisaniu zmian zobaczyłem efekt:

Czy da się wywołać podobny efekt na stronie dostępnej dla wszystkich użytkowników?

Da się.

Ponieważ cookies były pozbawione atrybutu httponly, już ta jedna podatność pozwala na przejęcie sesji innego zalogowanego użytkownika, jeśli tylko zwabimy go pod konkretny adres. Jest nieźle.

Drugi wektor ataku – sukces

Podczas przeglądania stron odnotowałem, że w pasku URL pojawiają się liczbowe identyfikatory oglądanych zasobów. Co stanie się, jeśli identyfikator taki zmienimy na ekranie statystyk?

Mimo błędu widzimy statystyki wskazanego projektu nawet, gdy należy on do innego użytkownika. Na obrazku… no nieważne. Jakiś tam projekt, na rzecz którego autofwd.com wykonywał czasem i po tysiąc przekierowań miesięcznie.

To nie wszystko, na innych podstronach możemy zaobserwować więcej błędów, w tym debugowe komunikaty z zapytaniami SQL.

Wektory nr 3, 4, 5 – bez sukcesu

Skoro w żądaniu GET przekazujemy liczbę trafiającą do zapytania bazodanowego, może da się zrobić SQL Injection? Niestety, moduł modsecurity obcina wszystkie próby, nie jestem w stanie wstrzyknąć żadnego przecinka czy nawiasu – takie żądanie zostaje zablokowane.

Przypominam sobie, że autofwd.com przysyła maile aktywujące lub resetujące hasło. W nagłówkach znajduję nazwę biblioteki wysyłającej maile. Jest to PHPMailer w wersji z roku 2014, w którym czai się soczysty błąd CVE-2016-10045 dający RCE (możliwość zdalnego wykonania kodu).

Próbuję dwóch gotowych exploitów, ale nie działają – prawdopodobnie dlatego, że nie byłem w stanie kontrolować treści wysyłanej wiadomości. W mailu powitalnym mógłbym wprawdzie próbować wstrzykiwać kod PHP w adresie użytkownika, ale po drodze jest kilka walidacji e-maila, więc tę ścieżkę – jako kłopotliwą – zostawiłem sobie na później.

Kolejny pomysł to funkcja uploadu obrazków. Manipulacja nazwami wysyłanych obrazów nic nie dała, zawsze kończyły w odpowiednim katalogu pod odpowiednią nazwą. Serwis autofwd.com jest stary, więc miałem nadzieję na podatność ImageTragick, ale biblioteki serwera ktoś najwyraźniej aktualizował, usterka pozwalająca na RCE nie występowała.

Udało mi się za to wysyłać na serwer pliki o dowolnej zawartości, jednak nie kontrolowałem ich nazwy ani lokalizacji. Aby doprowadzić do końca tę ścieżkę, potrzebowałbym zmienić rozszerzenie pliku albo zaincludować jego zawartość przez kod PHP.

Ponownie wektor nr 3 – tym razem sukces

Wróciłem do SQL injection, bo po zmianie typu żądania z GET na POST udało się całkowicie ominąć zabezpieczenia mod_security. Aplikacji z kolei nie robiło żadnej różnicy, jakiego typu żądanie przetwarza.

Spędziłem chwilę próbując wyexploitować stronę ze statystykami, bo tam w odpowiedzi z serwera od razu widziałem efekt zapytania. Chciałem podmienić argument numeryczny np. na jakieś wyrażenie arytmetyczne, potem na inne konstrukcje, ale nic nie działało, serwer parsował cyfry i ignorował wszystko od pierwszego znaku nie będącego cyfrą.

Przesiadłem się na wstrzykiwanie treści do wpisu z aplikacją, bo tam do dyspozycji miałem pola stricte tekstowe. Już pierwsza próba pokazała, że kod przetwarzający zapis danych jest podatny na atak.

Za pomocą Postmana wysyłałem spreparowany napis zawierający dowolne podzapytanie SQL – na obrazku powyżej sprawdzam nazwy kolumn z tabeli przechowującej dane użytkowników.

Wynik tak wstrzykniętego podzapytania wpadał do jednego z pól tekstowych, które mogłem oglądać w panelu użytkownika. Gdy poznałem strukturę tabeli, mogłem zajrzeć do danych użytkowników.

Zabawny fakt – w polu o nazwie „password_hash” znajdowało się… hasło zapisane otwartym tekstem. Gdyby nawet jakiś hipotetyczny 😉 wydawca mobilnych komunikatorów używał silnych haseł odpornych na łamanie haszy, w przypadku autofwd.com hasło takie nie było bezpieczniejsze od klasycznego dupa1234.

Na tym etapie mogłem przejąć kontrolę nad kontem dowolnego użytkownika, więc przestało mi zależeć na RCE. Co zrobiłem? Czy przestawiłem odsyłacz autofwd.com/ucmessenger na witrynę Informatyka Zakładowego? A może przekierowałem zaproszenia tutaj? Czy też zachęcałem do instalacji klona aplikacji Usecrypt Messenger, który wyśle mi kopię wszystkich plików i wszystkich wiadomości?

Zatrzymajmy się na chwilę, niech ten dylemat trochę się utrwali.

Zrobiłem, co zrobiłem, ale co Wy byście zrobili? Oto wyniki ankiety na Twitterze:

Jeśli przejmiesz kontrolę nad funkcją "zaproś kontakt" w mocno reklamowanym komunikatorze mobilnym, dokąd przekierujesz zapraszanych użytkowników?

— Informatyk Zakładowy (@InfZakladowy) October 16, 2020

Jasne, że do linku pobrania Signala. Jeśli oczekiwali najlepszego, niech dostaną najlepszy 🙂

— Niebezpiecznik (@niebezpiecznik) October 17, 2020

Pal licho to, że ja przełamałem te zabezpieczenia w roku 2020. W bazie danych znalazłem ślady ataków zaczynające się około roku 2016 i naprawdę nie ma sensownego argumentu za tym, że byłem tam pierwszym „odwiedzającym”. Kto wie, może twórcy Usecrypt Messengera zakładali konto w już shackowanym serwisie?

Historia zgłoszenia problemu

Wy ustawilibyście przekierowanie do Ricka. Ja zgłosiłem problem autorowi serwisu. Sekwencja działań wyglądała następująco:

14-15.10.2020	odkrycie podatności
15.10.2020	próba kontaktu z autorem serwisu autofwd.com
15.10.2020	autor odpowiada
15.10.2020	przekazanie autorowi listy podatności wraz z sugestią, że z powodu fundamentalnych błędów bezpieczeństwa serwis wymaga zamknięcia lub napisania od nowa
15.10.2020	autor dziękuje za zgłoszenie i proponuje bug bounty
15.10.2020	prośba do autora o zgodę na opisanie podatności
15.10.2020	autor udziela zgody i usuwa serwis autofwd.com z internetu

Jak widać z powyższego zestawienia, rzeczy działy się szybko. Autor potwierdził, że był to hobbystyczny projekt który się nie przyjął, więc od wielu lat nikt nic przy nim nie zrobił. Autor zdziwił się też, że SQL Injection zadziałał, bo podobno w użyciu były zapytania parametryzowane. Cóż, widocznie raz na rok nawet takie zapytanie poddaje się wstrzyknięciom.

I co teraz?

W bieżącej wersji Usecrypt Messengera funkcja zapraszania użytkowników przestała działać. Technicznie rzecz biorąc zaproszenia nadal da się wysłać, ale witryna autofwd.com jest obecnie zaparkowana.

Czy wydawca komunikatora może mieć do kogoś pretensje? Odpowiedzi poszukajmy w regulaminie świadczenia usług autofwd.com. Haha, pewnie już się domyślacie – ten serwis nigdy nie miał żadnego regulaminu, stał całkowicie w poprzek RODO i wszystkich innych regulacji. Oczywiście nie pojawia się też w polityce prywatności Usecrypt Messengera.

Co powinien zrobić wydawca komunikatora? Przede wszystkim postarać się jak najszybciej odkupić domenę autofwd.com, by ochronić istniejących użytkowników. Po drugie – natychmiast wydać aktualizację programu, w której zaproszenie nowego użytkownika będzie kierowało do własnej witryny. Dodam, że władze spółki V440, wydawcy Usecrypt Messengera, wiedzą o temacie od minionego wtorku.

Podsumowanie

Jak pokazałem, autorzy komunikatora Usecrypt Messengera poszli na skróty i nie skończyło się to dobrze. Prawidłowo przeprowadzona analiza ryzyka pokazałaby, że oszczędność czasu i kosztów pracy była bardzo mała zaś zagrożenie wynikające z przejęcia linków odsyłających – wysokie lub bardzo wysokie.

Wróćmy do cytatu: „Usecrypt Messenger to polski komunikator, który uznawany jest za jeden z lepszych, bezpiecznych komunikatorów internetowych. Renoma ta została właśnie potwierdzona przez Ministerstwo Obrony Izreala, które zarekomendowało ją jako bezpieczny komunikator dla tamtejszych instytucji publicznych.”

Co dokładnie zawiera rzeczona rekomendacja? Miesiąc temu poprosiłem wydawcę aplikacji o przekazanie jej kopii i upewniłem się, że e-mail z prośbą został odebrany i przeczytany. Do chwili publikacji niniejszego artykułu nie dostałem odpowiedzi. Takie trochę ignorowanie prasy, Informatyk Zakładowy jest zarejestrowanym czasopismem.

[Aktualizacja – 22.10.2020]

Spotkałem się z zarzutem, że nie podałem testowanej wersji aplikacji, tymczasem nie wszystkie wersje korzystały z usługi autofwd.com. Sprawdziłem więc, że w przypadku Androida są to wszystkie wersje co najmniej od wydania 2.3.5 z 18.10.2018 (nie dotarłem do wcześniejszych), zaś przekierowanie do Usecrypt Messengera na stronie autofwd.com zostało zarejestrowane przez archive.org ponad rok wcześniej czyli 12.09.2017.

Pierwszą wersją, która odsyła przez HTTPS do domeny get.usecryptmessenger.com, jest wersja 2.12.1 wydana 19.10.2020, czyli dwa dni po opublikowaniu niniejszego artykułu.

W następnym odcinku…

… znajdziecie takie cytaty:

„UseCrypt Messenger wykrywa i uniemożliwia nieautoryzowany dostęp do aplikacji zabezpieczając ją przed atakami hakerów i malwarem.” Spider’s Web

„UseCrypt Messenger […] opiera się wszelkim atakom hakerskim“ oraz „atakujący po przełamaniu zabezpieczeń systemowych musiałby jeszcze przełamać zabezpieczenia UseCrypt, a do tej pory coś takiego się nie wydarzyło“ ccnews.pl

Nie usłyszycie ode mnie, czy to prawda. Wtedy musielibyście wybrać, komu wierzyć. Zrobimy inaczej – wskażę wam narzędzia i przekażę wiedzę, dzięki której wy sami zweryfikujecie prawdziwość reklam Usecrypt Messengera.

"Szedł pieszo, a objuczonego Postmana prowadził za uzdę. Było późne popołudnie i redirecty oraz XSS-y były już zamknięte a injectiony puste." https://t.co/BitJBg6Ko6

— Informatyk Zakładowy (@InfZakladowy) October 17, 2020