OWASP: Mobile Top 10 Risks 2014

OWASP to organizacja, który kojarzy nam się z projektami związanymi z bezpieczeństwem aplikacji webowych. Mniej znanym jest 4 letni projekt poświęcony zagrożeniom platform mobilnych – OWASP Mobile Security Project. Celem artykułu jest zapoznanie Was z tymi zagrożeniami oraz z  różnicami w stosunku do klasyfikacji z roku 2012. Jednocześnie jest to wstęp do artykułów poświęconych testom penetracyjnym aplikacji napisanych na platformę Android.

M1: Weak Server Side Control

Na szczyt listy TOP 10 wskoczyło z miejsca  drugiego ryzyko związane ze słabymi mechanizmami zabezpieczeń po stronie serwerowej. Punkt M1 silnie łączy zagrożenia mobilne ze typowymi problemami bezpieczeństwa będącymi w zainteresowaniu OWASP. Aplikacje mobilne nie funkcjonują w próżni i w większości przypadkowych oprogramowanie to komunikuje się za pomocą webserwisów z aplikacją serwerową.  Pomimo tego, że problemy te są dobrze rozpoznane w kontekście zagrożeń www,  to w świecie mobilnym są wciąż aktualne i bardzo powszechne.

Zagrożenia M1:

• Słabe zabezpieczenie webserwisów (błędy logiczne, słabe uwierzytelnianie, zarządzanie sesją);
• Wstrzyknięcia (SQLi, XSS, RCE);
• Zła konfiguracja serwerów (ustawienia fabryczne, publiczne interfejsy administracyjne);
• Kontrola dostępu;
• Zdalne i lokalne dodawanie plików.

M2 : Insecure Data Storage

Na miejscu drugim znajduje się problem  ściśle już związany z aplikacjami mobilnym – niezabezpieczone przechowywanie danych na urządzeniu. Aplikacje przechowują dane lokalnie w różnych postaciach: bazy danych SQLite, pliki XML, pliki tekstowe, Plist, logi itp.

Zagrożenia M2:

• Brak szyfrowania danych na urządzeniu;
• Przechowywanie danych wrażliwych lokalnie a nie po stronie serwerowej (np. hasła w plikach, numery kart kredytowych);
• Zasoby dostępne do odczytu dla innych aplikacji;
• Krytyczne dane umieszczone w kodzie aplikacji (np. klucze (de)szyfrujące).

M3: Insufficient Transport Layer Protection

Niewystarczające zabezpieczenie danych w warstwie transportowej to numer 3 na podium listy zagrożeń. Spora część aplikacji mobilnych jest podatna na podsłuch przesyłanych do serwera danych z powodu braku  lub słabej implementacji mechanizmów szyfrujących.  Często spotykanymi błędami w aplikacjach jest akceptowanie wszystkich certyfikatów:

Android:

TrustManager[] trustAllCerts = new <własny menadżer akceptujący wszystkie certyfikaty>

SSLContext sc = SSLContext.getInstance(“TLS”);

sc.init(null, trustAllCerts, new java.security.SecureRandom());

Na iPhone należy zwrócić uwagę, czy wywołania setAllowsAnyHTTPSCertificate  nie akceptują niepoprawnych certyfikatów. Na Android należy zwrócić uwagę na metodę checkServerTrusted z klasy fabrykującej SSLSocketFactory oraz na stosowane przez deweloperów metody AllowAllHostnameVerifier z pakietu org.apache.http.conn.ssl lub SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER.

Inne zagrożenia to przesyłanie danych takimi kanałami jak SMS, MMS, itp. Programiści rzadko stosują też praktykę Certificat Pinning, czyli weryfikacji otrzymanego certyfikatu z listą kluczy zapisaną w aplikacji.

M4: Unintended Data Leakage

Wcześniej nazwane Side Channel Data Leakage i plasujące się na dalekim 8. miejscu ryzyko zostało przemianowane na – „niezamierzony wyciek danych”.  Zagrożenie to wiąże się z wewnętrznymi procesami przetwarzania danych przez system lub frameworki w kontekście cachowania zapytań i odpowiedzi HTTP,  schowka, logów, przyciskanych klawiszy, ciasteczek, danych HTML5, wrażliwe dane dostępne dla API stron trzecich.

Szczególnie istotne jest sprawdzenie logu systemowego za pomocą takich narzędzi jak logcat (Android).

Logi mogą również posłużyć do wyszukowanie informacji o cachowanych ciasteczkach:

adb logcat | grep “cookie”

Mimo, że w przypadku Androida od wersji 4.1 zablokowano dla tworzonych aplikacji możliwość stosowania uprawnienia READ_LOGS, jednak testerzy bezpieczeństwa mogą skorzystać ze „zrootowanych” urządzeń lub ich emulatorów.

Często spotyka się też aplikacje, które zostały opublikowane do ściągnięcia z ustawioną flaga  DEBUG.

M5: Poor Authorization and Authentication

Niezmiennie na pozycji nr 5 pozostał problem związany z słabymi mechanizmami uwierzytelniania i autoryzacji. Złudne przekonanie, że można zastosować mechanizmy uwierzytelniania po stronie aplikacji mobilnej, zostało już dawno obalone w przypadku aplikacji webowych i przeglądarek stron www. Dane aplikacyjne powinne być dostępne wyłącznie po przeprowadzeniu poprawnego uwierzytelniania użytkownika po stronie serwerowej. Jeśli wymagane jest, aby dane były przechowywane na urządzeniu, to zaleca się, aby były zaszyfrowane za pomocą klucza opartego na poświadczeniach do logowania użytkownika i dostępne po prawidłowym zalogowaniu. Należy zwrócić uwagę, aby proces uwierzytelniania nie opierał się na danych łatwych do podmiany np. id urządzenia (IMEI,IMSI,UUID) lub lokalizacja.

Podkreśla się, że często spotykane funkcjonalność zapamiętywania poświadczeń była opcjonalna i nie powinna umożliwiać przechowywania hasła lokalnie, a była zaimplementowana po stronie serwerowej.

Przykład uruchomienia na platformie Android dowolnej klasy Aktywności w celu zmiany zaprojektowanego przez programistę przepływ logiczny aplikacji, co może pozwolić pominąć etap weryfikacji kodu autoryzującego:

#am start –a android.intent.action.MAIN –n .StartAfterAuthenticationActivity

M6: Broken cryptography

Ryzyko związane z przełamaniem mechanizmów kryptograficznych zostało przesunięte z odległego 9. miejsca do środka stawki na pozycję 6. W tym punkcie wyróżnia się cztery grupy problemów:

• Bazowanie wyłącznie na wbudowanych mechanizmach danej platformy. OWASP zwraca uwagę, że pomimo faktu szyfrowania każdej aplikacji na iOS, co ma zabezpieczyć kod przed inżynierią wsteczną, problem deszyfracji okazuje się trywialny. W tym celu stosowane są narzędzia (ClutchMod, GDB) pozwalające wykonać zrzut binarny aplikacji już odszyfrowanej w pamięci urządzenia (konieczny „jailbreak”);
• Złe zarządzanie kluczami szyfrującymi (przechowywanie lokalne kluczy wraz z danymi, klucze zaszyte w kodzie aplikacji, przechwytywanie komunikacji);
• Wykorzystanie własnych algorytmów szyfrujących zamiast stosowania sprawdzonych i rzetelnych mechanizmów kryptograficznych.
• Użycie słabych i przestarzałych algorytmów (RC2, MD4,MD5, SHA1,base64)

M7: Client Side Injection

Wstrzyknięcia po stronie klienckiej to klasyk i w przypadku świata mobilnego nie ma tu specjalnej różnicy w stosunku do układu przegladarka- serwer www. Przykłady spotykanych wstrzyknięć to:

• SQL injection – w dużej liczbie przypadków aplikacje mobilne wykorzystują bazy danych SQLite, często zapytanie wpierw trafia do serwera aplikacyjnego skąd pośrednio trafia do lokalnej bazy danych;
• XSS – interfejs wielu aplikacji oparty jest na silniku mobilnej przeglądarki stąd niefiltrowane dane wprowadzane przez użytkownika mogą doprowadzić do uruchomienia kodu Javascript służącego do wykradania ciasteczek sesji. (domyślnie Javascript jest włączony);
• Wstrzyknięcia XML lub dołączanie lokalnych plików;
• Aplikacja na iOS mimo, że w większości pisane Objective C to niektóre funkcje mogą być podatne na ataki Format String (m.in. stringWithFormat, initWithFormat, appendFormat) i standardowo należy unikać niebezpiecznych funkcji takich jak strcat, strcpy, gets

M8: Security Decision via Untrusted Inputs

• Na pozycji 8. jest punkt dość słabo opisany na stronie OWASP, a zagadnienie dotyczy odbioru danych z innych źródeł, głównie komunikacji między procesami, głównie wymiany danych z innym aplikacjami (IPC).

Aplikacje, które wykorzystują IPC powinny wykorzystywać wszelkie mechanizmy bezpieczeństwa jakie zostały do tego zaprojektowane. W przypadku platformy Android został opracowany model uprawnień, za pomocą których programista może w dość granularny sposób kontrolować, co i w jaki sposób aplikacja udostępnia innych procesom. W większości przypadków programiści nie stosują tych ograniczeń umożliwiając zewnętrznym procesom na odczyt i modyfikację przetwarzanych danych w aplikacji. O tym jak ograniczać i jak stosować te mechanizmy można przeczytać w prezentacji Jefffa Sixa jaka została umieszczona przez OWASP w odnośnikach do tego punktu. O książce tego autora pisaliśmy wcześniej na Sekuraku.

Podobne zalecenia stosowane są dla iOS jednak tu ich jakość jest dość uboga – autorzy zwracają uwagę na jedną niebezpieczną metodę handleOpenURL i przestrzegają przed korzystaniem z iOS Pasteboard do IPC, ponieważ inne zainstalowane aplikacją mogą odczytać z niego dane.

M9: Improper Session Handling

Sekcja ta koncentruje się na znanym z świata webaplikacji zagadnieniu zarządzania sesjami użytkowników. Problemy zatem pozostają te same, tj.:

•  zakończenie sesji użytkownika np. po wylogowaniu tylko po stronie aplikacji mobilnej a nie na serwerze;
• brak unieważnienia sesji w przypadku długiej nieaktywności użytkownika i generalna tendencja do wydłużania tego okresu, co zwiększa ryzyko przejęcia sesji przez atakującego;
• brak wymuszenia zmiany ciasteczek sesyjnych w momencie zmiany stanu uwierzytelnienia, np. przejście ze stanu anonimowego gościa do stanu zalogowanego użytkownika, lub użytkownika uprzywilejowanego;
• generowanie tokenów, które nie są w wystarczający sposób losowe.

M10: Lack of Binary Protection

Ostatni punkt na liście największych zagrożeń w aplikacjach mobilnych – to nowo dodana pozycja i ryzyko ściśle związane z aplikacjami mobilnymi.

OWASP zwraca uwagę na szereg zagadnień jakie powinny być elementami dobrych praktyk w procesie wytwarzania oprogramowania:

• wykrycie, czy urządzenie jest “zrootowane”/”zjailbreakowane”;
• wykorzystanie sum kontrolnych;
• stosowanie mechanizmu przypinania certyfikatów;
• wykrywanie użycia debuggera.

Tym zagadnieniem zajmuje się szerzej inny projekt OWASP – Technical Risks of Reverse Engineering and Unauthorized Code Modification

Znajdziemy tu również metody i narzędzia do badania podatności w aplikacjach pisanych na dwie najpopularniejsze platformy mobilne:

iOS

• Disabling Code Encryption (ClutchMod);
• Jailbreak Detection Evasion (xcon);
• Class Dumping (class-dump-z);
• Method Swizzling (Mobile Substrate);
• Runtime Code Injection (cycript);
• Runtime Monitoring (Snoop-It);
• Runtime Analysis (GDB);
• Reverse Engineering (IDA Pro; Hopper)

Android

• Bytecode Conversion (apktool; dex2jar);
• Runtime Analysis (ADB);
• Reverse Engineering (IDA Pro; Hopper);
• Disassembly (baksmali);
• Code Injection (Mobile Substrate).

–j23