Luka Janus umożliwia atakującym modyfikowanie aplikacji bez wpływu na ich podpisy. Zostało to odkryte przez GuardSquare i zostało naprawione przez Google.
Android jest zainstalowany na ogromnej liczbie urządzeń, co czyni go celem złośliwych atakujących. Luki w mobilnym systemie operacyjnym Google są odkrywane co miesiąc, ale dobra wiadomość jest taka, że Google zazwyczaj przykłada dużą wagę do naprawiania ich w formie regularnych poprawek zabezpieczeń, które są następnie oferowane producentom OEM, którzy następnie je wysyłają urządzenia.
Niedawno badacze bezpieczeństwa odkryli lukę w zabezpieczeniach co nakłoniło użytkowników do umożliwienia atakującym nagrania ekranu ich urządzenia. Ten konkretny exploit został naprawiony w Androidzie Oreo, ale analitycy: Plac Strażniczy Niedawno zgłoszono kolejną poważną lukę, która dotyczy aplikacji na Androida podpisanych starszymi schematami podpisów.
Plac Strażniczyz raportu wynika, że Janussłaby punkt (CVE-2017-13156) w systemie Android umożliwia atakującym modyfikowanie kodu w aplikacjach bez wpływu na ich podpisy. Z raportu wynika, że przyczyną luki jest to, że plik może być jednocześnie prawidłowym plikiem APK i DEX.
Janus wykorzystuje fakt, że dodatkowe bajty pozostają niezauważone w plikach APK i plikach DEX. The Plac Strażniczy raport wyjaśnia, że plik APK jest archiwum ZIP, które może zawierać dowolne bajty na początku, przed i pomiędzy wpisami ZIP. Schemat podpisu JAR uwzględnia jedynie wpisy ZIP, ignorując dodatkowe bajty podczas obliczania lub weryfikacji podpisu aplikacji.
Następnie wyjaśnia, że plik DEX może zawierać na końcu dowolne bajty – po zwykłych sekcjach ciągów znaków, klas, definicji metod itp. Dlatego plik może być jednocześnie prawidłowym plikiem APK i prawidłowym plikiem DEX.
Plac Strażniczy wspomina również, że kluczowym elementem luki jest „nieszkodliwa” funkcja maszyny wirtualnej Dalvik/ART. Z raportu wynika, że teoretycznie środowisko wykonawcze Androida ładuje plik APK, wyodrębnia jego plik DEX, a następnie uruchamia kod. Jednak w praktyce maszyna wirtualna (VM) może ładować i wykonywać zarówno pliki APK, jak i pliki DEX. Problem polega na tym, że gdy maszyna wirtualna otrzymuje plik APK, nadal sprawdza magiczne bajty w nagłówku, aby zdecydować, jaki to typ pliku: DEX czy APK. Po znalezieniu nagłówka DEX ładuje plik jako plik DEX. Jeśli nie znajdzie nagłówka, ładuje plik jako plik APK zawierający wpis zip z plikiem DEX. Dlatego może błędnie interpretować podwójne pliki DEX/APK.
Plac Strażniczy twierdzi, że osoba atakująca może wykorzystać tę funkcję dualności maszyny wirtualnej, aby dodać złośliwy plik DEX do normalnego pliku APK bez wpływu na jego podpis. Środowisko wykonawcze systemu Android zaakceptuje plik APK jako prawidłową aktualizację legalnej wcześniejszej wersji aplikacji, ale maszyna wirtualna Dalvik załaduje kod z pliku DEX, do którego wstrzyknięto złośliwy kod.
Zwykle za każdym razem, gdy użytkownik instaluje zaktualizowaną wersję aplikacji, środowisko wykonawcze Androida sprawdza jej podpis, aby upewnić się, że jest zgodny ze starszą wersją. Po pozytywnej weryfikacji zaktualizowana aplikacja otrzymuje uprawnienia, które posiadała aplikacja pierwotna. W ten sposób osoby atakujące mogą wykorzystać lukę Janus do ominięcia procesu weryfikacji podpisu i zainstalowania niezweryfikowanego kodu na urządzeniach niczego niepodejrzewających użytkowników.
Co gorsza, ten niezweryfikowany kod może uzyskać dostęp do potężnych uprawnień. Rodzi to pewne poważne możliwości. Plac Strażniczy stwierdza:
„Osoba atakująca może zastąpić zaufaną aplikację z wysokimi uprawnieniami (na przykład aplikację systemową) zmodyfikowaną aktualizacją w celu nadużycia jej uprawnień. W zależności od docelowej aplikacji może to umożliwić hakerowi dostęp do poufnych informacji przechowywanych na urządzeniu lub nawet całkowite przejęcie urządzenia. Alternatywnie osoba atakująca może przekazać zmodyfikowany klon wrażliwej aplikacji jako legalną aktualizację, która może wyglądać i zachowywać się jak oryginalna aplikacja, ale wprowadzać złośliwe zachowanie.
Firma dodała, że jak dotąd nie widziała żadnych aplikacji wykorzystujących Janusa na wolności. Kolejną dobrą wiadomością jest to, że luka wymaga od użytkownika zainstalowania złośliwej aktualizacji ze źródła spoza sklepu Google Play. Dlatego użytkownicy, którzy ograniczają instalację aplikacji do Sklepu Play, są chronieni.
Luka Janus dotyczy urządzeń z systemem Android 5.0+. Dotyczy to aplikacji podpisanych przy użyciu schematu podpisu APK v1. Pliki APK podpisane przy użyciu schematu podpisu v2 są chronione przed tą luką. Wymaga to, aby pliki APK działały na urządzeniach obsługujących najnowszy schemat podpisu (Android 7.0 i nowsze). Schemat v2 jest chroniony, ponieważ w przeciwieństwie do schematu v1 uwzględnia wszystkie bajty w pliku APK.
„Starsze wersje aplikacji i nowsze aplikacje działające na starszych urządzeniach pozostają podatne. Programiści powinni przynajmniej zawsze stosować schemat podpisu v2.” Plac Strażniczy stwierdza.
Plac Strażniczy zgłosiłem ten problem firmie Google 31 lipca 2017 r. i tego samego dnia otrzymałem potwierdzenie. Z raportu firmy wynika, że Google wypuściło łatkę dla swoich partnerów w listopadzie, a błąd (CVE-2017-13156) opublikował w Biuletynie Bezpieczeństwa Androida 4 grudnia 2017 r. Luka ma zostało naprawione w poprawce zabezpieczeń Androida z grudnia 2017 r. Osobno potwierdzono, że aplikacje F-Droid z ich oficjalnego repozytorium są bezpieczne. Wreszcie potwierdzono, że luka została załatana APKMirror.
Źródło: GuardSquare