Nowy atak na uwierzytelnienie Dropboxa i omijanie 2FA

W Waszyngtonie trwa właśnie konferencja USENIX. W trakcie „warsztatu technologii ofensywnych” dwóch badaczy (w tym Polak) przedstawiło wyniki analizy kodu źródłowego Dropboxa, prowadzące do wykrycia kilku interesujących problemów.

Dropbox, ze względu na niesamowita popularność oraz zamknięty kod źródłowy, stanowił już cel kilku analiz bezpieczeństwa. Program prawie w całości napisany w Pythonie i udostępniany jako binarne pliki skompilowane i zaszyfrowane nie jest jednak wdzięcznym obiektem do badania. Istniejące metody inżynierii wstecznej skompilowanych plików Pythona w tym przypadku nie działają, ponieważ twórcy Dropboxa wprowadzili autorskie metody zabezpieczenia kodu źródłowego. Stanowiło to wystarczające wyzwanie dla dwójki badaczy – znanego m.in. z projektu John the Ripper Dhiru Kholi oraz naszego rodaka, Przemysława Węgrzyna z firmy CodePainters.

Daleko nam do uważania się za ekspertów kwestii związanych z inżynierią wsteczną, dlatego ograniczymy się poinformowania, że obaj panowie opracowali nową metodę odzyskiwania kodu źródłowego skompilowanych i zaszyfrowanych aplikacji Pythona (szczegóły znajdziecie w pracy ukrytej pod linkiem). Za jej pomocą udało im się odpakować, odszyfrować i zdekompilować najnowszą wersję Dropboxa i na tej podstawie odtworzyć i przeanalizować jego funkcjonalność. Udało im się także podsłuchać komunikację SSL klienta i serwera aplikacji, dzięki czemu odtworzyli nieudokumentowane API Dropboxa i mogli napisać jego uproszczoną wersję open source. Przy okazji odkryli także kilka problemów z uwierzytelnieniem użytkownika.

Standardowo dostęp do konta użytkownika Dropboxa wymaga podania nazwy użytkownika oraz hasła. Te same dane niezbędne są by powiązać z kontem użytkownika nowe urządzenie. W trakcie tego procesu urządzenie otrzymuje od serwera unikatowy ciąg host_id, który w dalszej komunikacji zastępuje login i hasło. Klient Dropboxa nie przechowuje loginu i hasła użytkownika, a jedynie host_id, które nie zmienia się w razie zmiany hasła. W starszych wersjach aplikacji host_id zapisywany był otwartym tekstem w bazie SQLite, w wersji od 1.2.48 baza ta jest zaszyfrowana. Klucz szyfrujący składa się jednak jedynie z informacji zapisanych na urządzeniu, zatem jego odtworzenie jest trywialne.

Klient Dropboxa posiada „magiczną” umiejętność otwarcia strony www serwisu z od razu zalogowaną sesją użytkownika. Używa w tym celu dwóch wartości, przesyłanych do serwera: host_id oraz host_int (otrzymywanego od serwera w trakcie inicjalizacji konta). Wartość host_int można podsłuchać w sieci lokalnej, ale okazało się, że znając host_id oraz odpowiednie zapytanie do API, można je otrzymać również od serwera. Posiadając zarówno wartości host_id jak i host_int, można otworzyć sesję użytkownika w interfejsie www, zatem bez znajomości jego loginu i hasła przejąć kontrolę nad jego kontem. Najnowsza wersja Dropboxa usunęła już możliwość wywołania sesji z menu, więc należy się spodziewać, że wkrótce ta funkcjonalność zostanie wyłączona.

Dropbox ma zaszyte w kodzie aplikacji akceptowane certyfikaty SSL, zatem aby podsłuchać jego komunikację i wywołania API badacze musieli wykorzystać inną metodę niż prosty atak MiTM. Udało im się to dzięki wstrzyknięciu kodu do procesu Dropboxa oraz załataniu odpowiednich obiektów, dzięki czemu mogli zobaczyć zapytania przed ich zaszyfrowaniem i odpowiedzi po ich odszyfrowaniu. Przy okazji okazało się także, że korzystając z API można ominąć dwuskładnikowe uwierzytelnienie oferowane przez Dropboxa – wystarczy znać wartość host_id by uzyskać pełen dostęp do konta użytkownika. Badacze napisali prosty kod, dzięki któremu mogli zarówno przesyłać, pobierać jak i modyfikować pliki użytkownika. Nie stworzyli pełnej wersji aplikacji, jednak ich odkrycia powinny znacząco ułatwić i przyspieszyć powstanie pełnej wersji open source.

Dropbox posiada również mechanizm pełnego logowania wszystkich procesów, jednak jest on aktywowany w sprytny sposób – wystarczy ustawić odpowiednią wartość zmiennej DB-DEV. Aplikacja nie weryfikuje jednak wartości zmiennej, a jej hasz. W starszej wersji był to hasz MD5, który został złamany (magicznym ciągiem było „a2y6shya”). Obecnie włączenie trybu logowania wymaga złamania haszu SHA256 o treści

e27eae61e774b19f4053361e523c771a92e838026da42c60e6b097d9cb2bc825

Prezentacja, praca naukowa oraz użyte i stworzone narzędzia zostały opublikowane na Githubie.