19:53
10/5/2015

Poniższy tekst obrazuje podstawy analizy aplikacji mobilnej. Jeden z naszych czytelników, krok po kroku demonstruje proces ekstrakcji danych związanych z kursowaniem pojazdów wrocławskiego MPK w oparciu o serwis internetowy i powiązaną z nim aplikację mobilną. Tekst jest przeznaczony dla wszystkich, którzy rozumieją czym jest reverse engineering, ale nigdy nie zabierali się do niego samodzielnie.

Autorem niniejszego artykułu jest Tomasz Zieliński — programista, śpioch i leń. Lider zespołu w firmie PGS Software. Pilot paralotniowy.

Czasem jest w życiu tak, że chcemy pozyskać do dalszej obróbki dane, które widzimy na ekranie, ale których nie da się łatwo wyeksportować z danej aplikacji. Ja na przykład zechciałem przyjrzeć się tematowi punktualności pojazdów wrocławskiej komunikacji miejskiej. Wrocławskie MPK, które od kilkunastu (sic!) lat udostępnia dane rozkładowe, nie publikuje niestety informacji o rzeczywistej realizacji planów przejazdu, czyli spóźnieniach. W serwisie pasazer.mpk.wroc.pl możemy za to obejrzeć mapę pozycji pojazdów:

Aby zobaczyć, jakie dane dostarczane są przez serwis do przeglądarki, użyjemy dodatku do Firefoksa o nazwie Firebug (takie lub podobne narzędzia deweloperskie dostępne są obecnie dla każdej przeglądarki). Jak widzimy, serwis udostępnia tylko informacje o numerze kursu, numerze linii i pozycji pojazdu.

2

3

Aby obliczyć spóźnienie, musielibyśmy pozyskać rozkłady, wyznaczyć planowaną pozycję pojazdu, wziąć poprawkę na kształt trasy, porównać z rzeczywistymi pozycjami i tak dalej. Mamy dostęp do numeru kursu, więc odpada problem ze spóźnieniami większymi niż interwał kursów, ale to nadal mało. Na stronie MPK znajdujemy jednak wzmiankę o aplikacji mobilnej iMPK, która na telefonie z Androidem wygląda tak:

4

Zwracamy szczególną uwagę na pole “Opóźnienie”. Jest smakowicie. Najpierw zobaczmy zasoby, które aplikacja zapisuje w urządzeniu. W zrootowanym telefonie wyciągniemy je po prostu z katalogu “/data/data/pl.wasko.android.mpk”.

Jeśli nie mamy zrootowanego telefonu, możemy posłużyć się emulatorem Genymotion. Tworzymy wirtualne urządzenie (wymagany będzie procesor obsługujący Intel VT-x lub AMD-V), instalujemy aplikacje Google i po uruchomieniu Google Play instalujemy wybrane oprogramowanie, a następnie w załączonym do Genymotion menedżerze plików włączamy dostęp w trybie root do wszystkich zasobów.

Jedynym interesującym plikiem jest baza danych SQLite3, której zawartość obejrzymy np. programem SQLiteStudio autorstwa Pawła Salawy. Widzimy w niej zestaw informacji o pojazdach (numer boczny, model, “wysokopodłogowość”, klimatyzacja) oraz przystankach (nazwa całego węzła oraz współrzędne i identyfikatory poszczególnych słupków).

5

6

Znajdujemy też tabelę properties zawierającą m.in. ustawienia definiowane przez użytkownika.

7

Dane te są w większości pobierane z sieci przy pierwszym uruchomieniu, czas więc przyjrzeć się komunikacji sieciowej aplikacji. W tym celu wyczyścimy ustawienia aplikacji, by wymusić ponowną inicjalizację i połączymy się z lokalnym WiFi, ale w ustawieniach zaawansowanych połączenia zdefiniujemy serwer proxy, podając numer IP komputera pracującego w tej samej sieci lokalnej i 8888 jako numer portu. Na tym porcie nasłuchiwać będzie Fiddler, który pozwoli nam przyjrzeć się żądaniom.

Aby praca z Fiddlerem była wygodniejsza, wyłączamy opcje Act as system proxy, a włączamy Allow remote computers to connect i Decrypt HTTPS traffic. Po uruchomieniu aplikacji iMPK zobaczymy:

8

…komunikat o błędnym certyfikacie. Jego data ważności upłynęła pół roku temu i jest on też samopodpisany. Nie istnieje więc zaufane CA, w którym można byłoby potwierdzić autentyczność certyfikatu i co za tym idzie, upewnić się, że nie ma miejsa atak typu MITM. Może to oznaczać jedną z dwóch rzeczy: albo aplikacja całkowicie ignoruje weryfikację ważności certyfikatu, albo też korzysta z własnej kopii certyfikatu (certificate pinning) i pomija infrastrukturę klucza publicznego. Klikamy “Yes”, zgadzając się na kontynuację, a Fiddler podejmuje próbę przechwycenia ruchu udając serwer HTTP(S). Dla aplikacji mobilnej staje się “serwerem”, a dla serwera MPK klientem.

9

Widzimy treść żądań i odpowiedzi co oznacza, że aplikacja iMPK nie weryfikuje bezpieczeństwa kanału transmisji. Z punktu widzenia naszego zadania jest to dobra informacja, gdyż w przypadku poprawnej implementacji musielibyśmy zainstalować w Androidzie certyfikat wygenerowany przez Fiddlera lub – po natrafieniu na certificate pinning – zmodyfikować binaria programu i rekompilować go, ewentualnie zatrzymywać wykonanie programu i odczytywać z przydzielonej mu pamięci odkodowane dane.

Zaglądając do pozyskanych zasobów widzimy, że tym razem mamy do dyspozycji JSON z nieco większą liczbą pól.

10

Aby poznać ich znaczenie, dekompilujemy plik APK z aplikacją (ścieżka /data/app/…), np. za pomocą usługi www.decompileandroid.com. Pozyskane źródła nie odpowiadają w 100% temu, co stworzył programista, ale sens pozostaje niezmieniony. Szukamy frazy “e” (z cudzysłowem) i znajdujemy metodę Vehicle.fromJSONObject() zawierającą słownomuzyczne opisy pól w obiekcie JSON. Gdyby aplikacja została przepuszczona przez obfuscator (np. ProGuard), musielibyśmy spędzić dodatkowy czas na odtwarzaniu znaczenia zmiennych o losowych, kompaktowych nazwach.

11

Wróćmy do żądań HTTPS wysyłanych przez aplikację. Chcemy pozyskać dane samodzielnie. W nagłówkach widzimy, że w użyciu jest uwierzytelnianie typu Digest, w którym hasło nie jest transmitowane bezpośrednio. Przypominamy sobie zawartość bazy SQLite wyciągniętej z programu, a dokładniej wierszy w tabeli Properties:

12

Czyżby czyżyk? Kopiujemy URL do przeglądarki, potwierdzamy wyjątek bezpieczeństwa dla tego adresu, w okienku logowania podajemy nazwę użytkownika “android-mpk”, hasło “g5crehAfUCh4Wust” i… sukces! Zauważamy przy tym, że data podawana w żądaniu niczemu nie służy, bo zwracane wyniki zawsze dotyczą chwili obecnej. Można spekulować, że był to sposób na wymuszone ominięcie cache’owania danych przez serwer HTTP, proxy lub inny element infrastruktury developerskiej. Z linii komend dane możemy pozyskać komendą:

curl --insecure --digest -u "android-mpk:g5crehAfUCh4Wust" "https://62.233.178.84:8089/mobile?function=getPositions"

Pytania jakie nasuwają się na myśł, to: czy usługodawca nie zablokuje użytkownika lub nie zmieni hasła po wykryciu zbyt dużej liczby żądań? Czy każdy użytkownik aplikacji mobilnej otrzymuje własne dane uwierzytelniania? W poszukiwaniu odpowiedzi, przeszukujemy komunikację przechwyconą przez Fiddlera podając jako klucz znane nam już hasło — bez efektów.

13

W drugim kroku zaglądamy więc do źródeł aplikacji i znajdujemy tam zaszyte na sztywno definicje.

14

Odpowiedź na oba zadane przed chwilą pytania brzmi więc “raczej nie” (chyba, że backend pozwoli na przekazanie nowego hasła które my i tak od razu pozyskamy) i “nie” (dane dostępowe są wpisane na stałe w kodzie).

Podsumowanie

Zazwyczaj reverse engineering pozwalający na przechwycenie i analizę wymiany danych pomiędzy aplikacją a serwerem wymaga nieco więcej pracy, jednak w tym przypadku wszystko poszło gładko. Uzyskaliśmy dostęp do danych, którymi dysponuje jednostka organizacyjna dotowana z budżetu lokalnego. Można domniemywać, że dane te są informacją publiczną i nie podlegają ochronie prawnoautorskiej, więc każdy powinien mieć prawo do ich odczytu i ponownego wykorzystania. Mile widziane byłoby udostępnienie otwartego i udokumentowanego API.

Dowiedliśmy się także, że użycie samopodpisanego certyfikatu po stronie serwera i ufanie wszystkim certyfikatom w aplikacji klienckiej pozbawia nas praktycznie wszystkich korzyści oferowanych przez HTTPS. Skoro nie zależy nam na poufności, do czego miałby służyć protokół HTTPS? Oczywiście do zapewnienia integralności przekazu czyli pewności, że nikt nie modyfikuje danych, które wymieniamy ze zdalnym serwerem (w naszej konfiguracji może robić to Fiddler).

Gdyby twórcy iMPK chcieli zabezpieczyć swój system przed zautomatyzowanym pozyskiwaniem danych, musieliby rozróżniać poszczególne instalacje aplikacji mobilnej, identyfikować wzorce zachowań użytkowników, prowadzić statystyki dostępu itp. ale to już jednak temat na osobny tutorial.

Autorem niniejszego artykułu jest Tomasz Zieliński — programista, śpioch i leń. Lider zespołu w firmie PGS Software. Pilot paralotniowy.

Od Redakcji: Jeśli ktoś z Was chciałby opublikować na łamach Niebezpiecznika swój tekst, zapraszamy do kontaktu. Osoby zainteresowane tematyką analizy bezpieczeństwa aplikacji mobilnych odsyłamy także do naszego taga mobile, a zwłaszcza tekstów takich jak: Ochrona kodu aplikacji mobilnych, Analiza zawartości telefonu komórkowego oraz Darmowego poradnika dot. analizy bezpieczeństwa aplikacji mobilych.

Przeczytaj także:

26 komentarzy

Dodaj komentarz
  1. Wow, niezła robota :D

    Szkoda, że warszawski ZTM jest bardziej niedorozwinięty w kwestii nowych technologii, dobrze, że ostatnio chociaż GTFSRa zrobili dla google maps.

  2. Fajny tekst. Szkoda tylko, że pokazany na takim prostym przykładzie.

    • Chętnie przeczytam twój pokaz na większym poziomie :)

  3. A jak wygląda kwestia legalności takich działań? Można dekompilować aplikacje i podawać rezultaty do publicznej wiadomości? Czy nie powinno to być traktowane jako “niezamówione pentesty”?

  4. “Można domniemywać, że dane te są informacją publiczną i nie podlegają ochronie prawnoautorskiej, więc każdy powinien mieć prawo do ich odczytu i ponownego wykorzystania.”
    W zasadzie można. Ale Krakowski MPK na przykład bardzo stara się rzucać kłody pod nogi:
    http://prawo.vagla.pl/node/9734
    http://prawo.vagla.pl/node/9865
    http://prawo.vagla.pl/node/9890

    Choć z drugiej strony, Alladyna2 podobno nie można było pociągnąć do odpowiedzialności za sam dostęp do kalendarza, bo nie uzyskał dostępu do informacji chronionej, tylko publicznej. Więc jak Cię będą włóczyć po sądach, to masz dość mocną linię obrony. 8-)

  5. No dobrze… ale co to właściwie nam dało?

    • Masz przykład legalnego zastosowania techniki. Z wiadomych przyczyn nielegalnego tutaj Ci nie pokażą. Co z tą wiedzą zrobisz we własnym zakresie już niebezpiecznika nie interesuje.

  6. @stoliczny nie ma szans sprawdzić saty ważności karty miejskiej, a co dopiero takie właśnie fajerwerki…

  7. To Pan Tomasz od Transportoida

  8. O ile mi wiadomo RE oraz dekompilacja nie są chyba zbyt legalne???

    • Art 75 ust 2 ustawy o prawie autorskim: “Nie wymaga zezwolenia uprawnionego: […] obserwowanie, badanie i testowanie funkcjonowania programu komputerowego w celu poznania jego idei i zasad przez osobę posiadającą prawo korzystania z egzemplarza programu komputerowego […]”

    • a jak się to ma to prawo jeżeli w licencji używania programu jest zastrzeżenie co do dekompilacji?

    • @trolo
      Nijak. Windoze OEM też nie możesz se przenieść na nową maszynę, bo licencja, a w Niemcowie możesz, bo prawo.

    • Prawo jest zawsze obligatoryjne w stosunku do umów. Nie bez powodu powstało coś takiego jak prawa człowieka, minimalna płaca, ustawowy czas pracy itp. ;)

  9. Ale API do tego typu zadań JEST dostępne… Powstało od …uja i ciut ciut takich aplikacji ;)

    • A mogę poprosić o wskazanie tego API z informacjami o bieżących pozycjach pojazdów komunikacji miejskiej Wrocławia? Tego z opóźnieniami w stosunku do planowych godzin przejazdu?

    • Sam dostęp do API nigdy mnie nie interesował, trzeba się zwrócić bezpośrednio do UM. Oczywiście wtedy udostępnią, ale publicznie “prewencyjnie” nie ma. Dane są różnych rodzajów i były dodawane z czasem, więc ciężko mi powiedzieć jak to wygląda: i to także np. czas przyjazdu z uwzględnieniem postoju na pętli. Wtedy dane są z rozkładu (podawane przez ITS który podaje również i “surowy” rozkład), ale i tak szału nie ma, bo podawanie najbliższego kursu to po prostu zlokalizowanie wg pozycji i sprawdzeniu, które ma “miejsce w rozkładzie” o czym pewnie wiesz.

      Od samwgo początku “wyznacznikiem” jest ta prosta witryna, która korzysta niemal z surowych danych ITS (tak w rogu po prawej u góry po wybraniu przystanku masz “więcej”):
      http://tram.wroclaw.pl/
      Więcej mnie nie interesowało, więc bardziej nie pomogę ;)

    • W kwestii apek androidowych pozycję pojazdów (i tylko tyle) pokazuje choćby lokomo którego używałem kiedyś.
      Natomiast trasę i pozycję pojazdu, szacowany czas przyjazdu (czyli to co na tablicach jeśli są), oraz rozkład danego przystanku (z tym akurat najłatwiej, a mimo to czasem niepoprawnie działa) udostępnia choćby buslive.pl.
      Obie apki biorą dane z ITSa a ten czasem niestety nie działa, nie każdy pojazd ma też GPSa (lub się nie rozgłasza lub system go nie widzi).

      impk przetestuję.

    • ITS zawsze działa, problemem jest niepoprawne zalogowanie, nie wybranie kierunku (lub wybranie złego kierunku), czasem protestuje KPP-2.
      Niestety, takie błędy skutkują brakiem wykrywania pojazdu, w tym np. priorytetu na skrzyżowaniu czy nie pokazywanie rzeczywistych danych danej brygady (lecz jej czas rozkładowy).

    • @Tomek
      Najważniejsze jest to, że iMPK to NAJNOWSZA aplikacja bazująca na ITS. Przed nią powstały: Lokomo, BusLive.pl. Ostatnio powstała aplikacja “Kiedy pojadę”. To raczej API jest dostępne ;)

  10. Niebezpieczniku, kiedy Ty w koncu bedziesz dolaczal obrazki poprawnie – po httpsie nie dziala!

    • dziala;p

  11. Czy w takim razie (w kontekscie udostepniania danych publicznych) wszystkie przedsiebiorstwa komunikacji miejskiej, ktore kupily system monitoringu GPS TARAN (http://www.taran.com.pl/mybusonline/) winny rowniez udostepniac API?

    Teraz API jest specjalnie ‘zakombinowane’ w taki sposob, ze zwykly programista moze miec problem zeby go uzyc.

    Milo by bylo gdyby wypowiedzial sie w tej kwesji ktos obeznany w sprawach prawnych tego typu tematow.

  12. Do podsłuchiwania ruchu SSL polecam mitmproxy (https://mitmproxy.org/), która w łatwy sposób pozwala na zainstalowanie wygenerowanego CA na urządzeniu – jeśli aplikacja korzysta z systemowego weryfikowania certyfikatów i nie używa pinningu, jesteśmy w domu. BTW, chyba nie wspominaliście – bardzo popularna iOSowa biblioteka AFNetworking miała niedawno spory problem z walidacją certyfikatów https://gist.github.com/AlamofireSoftwareFoundation/f784f18f949b95ab733a

  13. Tutaj coś dla crackerów którzy pamiętają “stare czasy” – napisałem tutorial step-by-step – przełamanie crackme patch’em lub keygen’em z wykorzystaniem W32Dasm – disassemblera wykorzystywanego w latach ’90 – tekst po angielsku, ale jest też wersja po polsku w oparciu o SoftICE’a – legendarnego już debugger’a. Teksty dla początkujących – chcących poćwiczyć na IDA lub Olly’m.

    http://fivewithfour.blogspot.com/2015/05/cracking-fundamentals-based-on-example.html

  14. Dekompilować, deasemblować, zalegalizować! Jak producent software’u nie chce, nie musi publikować kodu źródłowego, ale niech nie zabrania użytkownikom dbania o swoje bezpieczeństwo (i przy okazji innych, którzy są w pobliżu lub których dane są w pamięci urządzenia).

Odpowiadasz na komentarz Seba

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: