Another client side: безопасность мобильных приложений глазами атакующего

Привет, Хабр! Сегодня я хочу рассказать про безопасность мобильных приложений со стороны атакующего.

Мобильные приложения активно используют данные, а значит, нуждаются в грамотной защите. Поэтому за последние несколько лет значительно выросло количество проектов, связанных с анализом их защищенности. Заинтересованность компаний в безопасности мобильных приложений можно заметить и на рынке багбаунти. Например, на BI.ZONE Bug Bounty мобильные приложения есть в 19 публичных программах.

Давайте рассмотрим подробнее, какие уязвимости встречаются в мобильных приложениях

Этот текст написан по мотивам моего выступления на VolgaCTF. 

---

Пример уязвимости

Дальше речь пойдет именно про Android, так как он более доступный для исследования безопасности.

Критичность client-side-уязвимостей меньше, чем server-side, так как они касаются конкретного пользователя, а не сервис. Но есть главная особенность, из-за которой уязвимости в мобильных клиентах могут быть лакомым кусочком для злоумышленников. В отличие от веб-приложений, они напрямую взаимодействуют с операционной системой устройства, а значит, имеют куда больше возможностей.

Мобильные приложения могут напрямую взаимодействовать:

• с файловой системой девайса,

• ОС через системные вызовы,

• sh-оболочкой,

• камерой, микрофоном, гироскопом и другими периферийными устройствами,

• другими приложениями на девайсе.

Давайте поэкспериментируем и посмотрим, до чего сможем дотянуться на устройстве при помощи RCE. Для эмуляции наличия RCE на устройстве я использовал AndroRAT и эмулятор девайса от Android Studio.

Возможности Interpreter AndroRAT из коробки уже удивляют.

С RCE на устройстве мы получаем доступ к следующим данным:

• Информация о девайсе.

  

• Информация о IP- и MAC-адресе устройства.

  

• Камера (из-за особенностей эмулятора не удалось к ней подключиться).

• История сообщений, входящих и исходящих звонков.

  

• Геопозиция устройства.

  

• Информация о сим-карте и провайдере.

  

• Микрофон.

  

• Буфер обмена.

  

Часто приложения имеют доступ к SD-карте, где может храниться много интересного: от кеша приложений до фотографий пользователя.

Ничто не мешает злоумышленнику загружать свои утилиты и в дальнейшем использовать их для постэксплуатации и закрепления. Для демонстрации я скомпилировал и загрузил свою версию URL, с ее помощью получил доступ к ресурсу из внутренней сети.

Таким же образом злоумышленник может скомпилировать и загрузить на устройство:

• утилиты для разведки и сканирования сети,

• утилиты для проксирования трафика через устройство,

• вредоносное ПО: майнеры, беконы для создания ботнета и т. п.

Далеко не каждое RCE даст столько возможностей. Все зависит от гибкого механизма настройки permission в Android или указания property в iOS. Благодаря этому можно указать, к чему приложение должно иметь доступ, а к чему нет.

Со строгой политикой можно свести импакт от RCE примерно к нулю, максимально ограничив доступ приложения вплоть до взаимодействия по сети. Но в этом случае приложение будет урезано в функциях, что не всегда удобно.

Например, приложение «Хабра» на Android запрашивает не так уж много разрешений.

При обнаружении теоретического RCE максимум, что мы сможем, — записывать и исполнять произвольные файлы в директорию приложения (вне зависимости от разрешений), а также взаимодействовать с сетью устройства. На этом все.

Но если посмотреть, сколько разрешений запрашивает условный Telegram, не хватит одного скриншота, чтобы уместить все.

И Telegram не исключение. По статистике от Cybernews легко заметить, что 3 из 4 приложений запрашивают доступ к внешнему хранилищу данных, а каждое третье — просит доступ к микрофону и камере. Приложения часто запрашивают права, которые им не нужны. Это связано с тем, что некоторые разработчики просят по умолчанию давать расширенные права для приложения. Так что исключением служит скорее приложение «Хабра» с относительно небольшим набором прав.

Импакт от уязвимостей действительно существует, но он зависит от вида уязвимости, а также от установленных для приложения разрешений. Но в среднем критичность в мобильных приложениях будет выше, чем у client-side-уязвимостей в веб-приложениях.

Классификация уязвимостей

Есть несколько мнений, как можно классифицировать уязвимости в мобильных приложениях. Рассмотрим такие.

По вектору эксплуатации

• 0-click. Для эксплуатации уязвимости от пользователя не требуется никаких действий, будь то любое взаимодействие или установка дополнительных приложений. Достаточно отправить пользователю сообщение с полезной нагрузкой, которая будет обработана приложением без дополнительного взаимодействия с человеком.

  

• 1-click. Для эксплуатации необходимо, чтобы пользователь совершил одно действие: перешел по ссылке, открыл вложение и т. п.

  

• Malware app. Для эксплуатации необходимо, чтобы пользователь установил вредоносное приложение, которое использует уязвимость, связанную с межпроцессорным взаимодействием в другом приложении.

  

• MITM. Для эксплуатации необходимо, чтобы злоумышленник реализовал атаку man-in-the-middle и мог контролировать сетевой трафик.

  

• Физический доступ. Для эксплуатации уязвимости необходим физический доступ к устройству.

Первые три типа имеют реальный вектор для массовой эксплуатации, поэтому их можно считать наиболее критичными. За такие уязвимости в большинстве случаев можно получить баунти в багбаунти-программах, где есть мобильные приложения.

Последние два хоть и кажутся безобидными, все равно могут нести серьезные риски. Вряд ли кто-то захочет увидеть уведомление о списании средств со своего банковского счета после того, как ненадолго забыл телефон на кухне в офисе или подключился к общедоступному Wi-Fi.

Инъекции

Инъекция — это уязвимость, при которой злоумышленник вводит вредоносные данные в приложение, чтобы изменить его поведение, обойти защиту или выполнить нежелательные команды.

В отличие от веб-приложений, где в client-side можно внедрять CSS, HTML и JS, здесь список значительно шире.

В некоторых местах мобильного приложения используется WebView, который по сути является внутренним браузером, так что в нем мы можем обнаружить такие же client-side-уязвимости, что и в веб-приложении.

Чтобы допустить XSS, достаточно включить поддержку javascript в WebView. По опыту он включен в 99 случаев из 100. Когда в последний раз вы видели веб-страницу без JS?

webView.getSettings().setJavaScriptEnabled(true);

Недостаточно экранировать пользовательский ввод: тут все, как в веб-приложении.

Из интересных особенностей: в некоторых случаях разработчики могут реализовать javascript-интерфейс, который позволит вызвать java-код из javascript и тем самым получит возможность взаимодействовать с ОС.

Так, можно написать простой интерфейс, где будут реализованы функции getDeviceInfo и getBatteryLevel:

public class WebAppInterface { private Context mContext;  private LocationManager locationManager; private LocationListener locationListener;  public WebAppInterface(Context context) { mContext = context;  locationManager = (LocationManager) mContext.getSystemService(Context.LOCATION_SERVICE);  }  @JavascriptInterface  public String getDeviceInfo() {  return "Device: " + Build.MODEL + ", OS Version: " + Build.VERSION.RELEASE;  }  @JavascriptInterface  public String getBatteryLevel() {  BatteryManager batteryManager = (BatteryManager) mContext.getSystemService(Context.BATTERY_SERVICE);  int batteryLevel = batteryManager.getIntProperty(BatteryManager.BATTERY_PROPERTY_CAPACITY);  return "Battery Level: " + batteryLevel + "%";  }

Затем подключить его к WebView:

webView.addJavascriptInterface(new WebAppInterface(this), "os");

В этом случае мы сможем использовать эти функции из javascript, что особенно интересно, когда есть XSS.

Так может быть выполнен любой реализованный разработчиком код, в котором тоже могут быть уязвимости.

SQLi

Мобильные приложения могут быть уязвимы к SQL-инъекциям из-за использования SQLite для хранения данных и некорректной фильтрации входных данных от пользователя.

Пример уязвимого кода:

public void search(View view) {   EditText srchtxt = (EditText) findViewById(R.id.ivi1search);   try {   Cursor cr = this.mDB.rawQuery("SELECT * FROM sqliuser WHERE user = '" + srchtxt.getText().toString() + "'", null);

Импакт от SQLi значительно меньше, чем от уязвимости в серверной части, но может быть ощутим.

С помощью этой инъекции могут быть украдены персональные данные пользователя, выполнены подмена данных, обход локальной проверки или отказ в обслуживании клиента приложения за счет порчи или удаления данных.

Path traversal

Приложение напрямую взаимодействует с файловой системой устройства, поэтому при наличии path traversal появляется возможность чтения и перезаписи произвольных файлов, для доступа к которым у приложения есть права.

По умолчанию обычный пользователь не может посмотреть содержимое директории приложения и, как следствие, получить доступ к хранящимся там данным без наличия root-прав. Так что, если мы обнаружили path traversal, позволяющий читать любые файлы от имени приложения, это уже достаточно серьезная уязвимость.

Пример уязвимого кода:

public String readFileContent(String fileName) throws IOException {  String BASEDIR = getFilesDir().getAbsolutePath();  File file = new File(BASEDIR + "/notes/"+ fileName);  StringBuilder content = new StringBuilder();    try (BufferedReader reader = new BufferedReader(new FileReader(file))) {  String line;  while ((line = reader.readLine()) != null) {  content.append(line).append(System.lineSeparator()); }  }  return content.toString().trim();  } 

Однако критичность значительно увеличивается, если это path traversal при записи файла, так как она напрямую может привести к RCE на устройстве. Для этого достаточно перезаписать одну из библиотек, используемую приложением, на свою, которая будет содержать необходимый код.

Если интересно, как это применяется в реальной жизни, советую посмотреть репорт на Hackerone, посвященный RCE в Android-клиенте Evernote.

Insecure deserialization

При разработке большинства Android-приложений используют Java/Kotlin, и при недостаточной проверке входных данных там можно обнаружить небезопасную десериализацию данных.

Пример уязвимого кода:

private void deserialize(InputStream inputStream) throws IOException, ClassNotFoundException {  ObjectInputStream ois = new ObjectInputStream(inputStream);  MyObject obj = (MyObject) ois.readObject();  TextView outputTextView = findViewById(R.id.deserOutput); outputTextView.setText(obj.toString());  }

В этом случае потенциальный злоумышленник сможет воздействовать на серилизуемый объект, изменить его свойство или реализацию метода, как в примере:

private static void Exploit() throws IOException {  MyObject hackedObject = new MyObject("OriginalName") {  @Override  public String toString() {  return "hacked " + UUID.randomUUID().toString();  }  };  ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("/tmp/exploit.bin"));  oos.writeObject(hackedObject);  oos.close();  }

В примере я изменил реализацию toString так, чтобы она возвращала значение «hacked + UID», сгенерированный случайным образом.

Хотя таким образом можно внедрить любой другой код и получить его удаленное выполнение на устройстве.

Более детальный разбор уязвимости выходит за рамки этой статьи. Для глубокого понимания рекомендую почитать, что собой представляет сериализация в java, а также — как устроен инструмент для генерации полезных нагрузок с использованием цепочки гаджетов ysoserial.

Code Execution

Возможны и стандартные уязвимости, связанные с выполнением кода.

Пример уязвимого кода:

private String executeCommand(String command) { try {  Process process = Runtime.getRuntime().exec(command);  ...

Такое встречается редко, так как современный SDK содержит достаточно опций, чтобы полностью отказаться от использования exec.

Inter-process communications (IPC)

В Android есть множество встроенных функций для взаимодействия между приложениями. С одной стороны, это дает большую гибкость разработчикам при построении архитектуры приложения, с другой — значительно увеличивает поверхность атаки для злоумышленников.

Объяснение всех механизмов IPC не относится к основной теме статьи, так что расскажу лишь про основные сущности, которые используются при эксплуатации уязвимостей с IPC:

• Intent — это механизм межпроцессного взаимодействия в Android, который позволяет компонентам приложения, таким как Activity, Service или BroadcastReceiver, общаться между собой или с другими приложениями.

• Broadcast receivers — это компонент Android, который позволяет приложениям реагировать на системные широковещательные сообщения, например на события вроде получения SMS или смены состояния сети.

 Инициировать широковещательные сообщения можно при помощи утилиты am:

 am broadcast -n com.test.package/.NotificationReceiver -a package.newnotification --es "text" "YOU HAVE BEEN HACKED"

• Content provider — это компонент для управления доступом к структурированным данным приложений, например к базам данных или файлам внутри директории приложения.

• Deeplink — это схемы, которые позволяют приложениям открывать определенные действия через обработку ссылок, например приложение может быть запущено через ссылку типа myapp://open?param=value.

Эту категорию сложно однозначно разбить на подгруппы, как инъекции, поэтому я приведу несколько примеров уязвимостей, связанных с IPC.

Exported content provider

Одна из часто встречающихся уязвимостей в Android-приложениях — неправильно настроенные права доступа к сущностям приложения. В пример приведу Content Provider.

Когда Content Provider помечается как exported, он становится доступен для других приложений. А значит, внешние приложения могут запрашивать и модифицировать данные, если нет правильной системы контроля доступа.

В моем случае провайдер предоставлял доступ к базе данных приложения, поэтому я написал proof of concept (POC) приложения, которое обращалось к провайдеру и доставало пароли из базы данных пользователя.

Пример функции, реализующей обращение к стороннему контент-провайдеру:

public static List<Map<String, String>> getPassword(Context context) {     Uri parse = Uri.parse("content://com.test.app.contentprovider/pwds");     ArrayList arrayList = new ArrayList();     Cursor query = context.getContentResolver().query(parse, null, null, null, null);     if (query != null && query.moveToFirst()) {         do {             try {                 HashMap hashMap = new HashMap();                 String string = query.getString(query.getColumnIndex("pwd"));                 hashMap.put("name", query.getString(query.getColumnIndex("name")));                 hashMap.put("pwd", string);                 arrayList.add(hashMap);             } finally {                 query.close();             }         } while (query.moveToNext());     }     return arrayList; }

При поиске похожих кейсов в багбаунти я наткнулся на репорт в программе Nextcloud. Правда, тут данные доставались с использованием ПО drozer, но смысл примерно тот же.

Local auth bypass via deeplink

Deeplink используется для обработки действия в приложении при переходе по определенному типу ссылок. Часто этим действием бывает запуск активности приложения. В некоторых случаях при обработке deeplink упускается проверка безопасности приложения, например локальная проверка авторизации пользователя.

В уязвимом приложении реализовали авторизацию по ПИН-коду:

protected void onCreate(Bundle savedInstanceState) {  super.onCreate(savedInstanceState);  if (!isPinCodeVerified()) {  Intent intent = new Intent(this, PinCodeActivity.class);   startActivity(intent); finish();  } else {  setContentView(R.layout.activity_main);   }  }

Однако приложение позволяло обращаться при помощи ссылки к другим активностям, в частности к просмотру профиля пользователя.

<activity android:name=".ProfileActivity">   <intent-filter>   <action android:name="android.intent.action.VIEW" />   <category android:name="android.intent.category.DEFAULT" />   <category android:name="android.intent.category.BROWSABLE" />   <data android:scheme="https" android:host="www.example.com" android:path="/profile" />   </intent-filter>  </activity>

Причем в .ProfileActivity проверку isPinCodeVerified() забыли реализовать. Для обхода локальной авторизации достаточно открыть в браузере ссылку `https://host[.]com/account`.
Или запустить приложение через deeplink с использованием утилиты am:

am start –n com.package.example –d "https://host.com/account”

Information leak via URL-scheme

Еще одна уязвимость связана с URL-схемами — когда приложение передает чувствительную информацию в открытом виде при помощи URL-scheme.

Проблема в том, что любое приложение может зарегистрировать обработку любой URL-cхемы. Мы можем написать свое приложение, которое будет обрабатывать необходимую URL-схему, например testapp://createtask:

<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.evil.app"> <application  android:allowBackup="true"  ...   >  <activity android:name=".MailtoAppActivity">   <intent-filter>   <action android:name="android.intent.action.VIEW" />   <category android:name="android.intent.category.DEFAULT" />   <category android:name="android.intent.category.BROWSABLE" />   <data android:scheme="testapp" android:host="createtask" />   </intent-filter>   </activity>

И оно позволит перехватить данные при обращении по URL-схеме от исходного приложения.

Так, на Hackerone наткнулся на account takeover в приложении Shopify c использованием данной уязвимости. C подробностями можете ознакомиться в самом репорте.

Binary vulns

Мобильные приложения под капотом могут использовать нативные библиотеки, зачастую написанные на языках C/C++, небезопасных с точки зрения работы с памятью.

Это открывает дорогу к появлению таких уязвимостей, как:

• Buffer Overflow Integer Overflow.

• Use-After-Free.

• Double-free.

Так что любители pwn-категории непременно должны оценить.

Для полноценного погружения в эту категорию вряд ли хватит и нескольких статей, поэтому лучше приведу примеры обнаруженных in-the-wild-уязвимостей:

• How a double-free bug in WhatsApp turns to RCE.

• Instagram_RCE: Code Execution Vulnerability in Instagram App for Android and iOS.

Начало работы

Читая про уязвимости, большую поверхность атаки и другие особенности, кто-то мог решить, что начать исследовать мобилки сложно. Я же думаю, что тут главное — начать. Поэтому собрал то, что может помочь на старте.

Чтоб получить начальные знания и изучить теорию, стоит посмотреть на OWASP и их MASTG и MASVS. Также я бы советовал обратить внимание на бесплатный курс от Mobile hacking lab. На GitHub можно найти подборки ресурсов с разборами заданий, репортов с багбаунти и другим контентом, который сможет помочь в обучении (AST, one more repo).

После получения базовых знаний стоит перейти к практике.

Первое, что нужно для тестирования на безопасность мобильных приложений, — это устройство. На физическом устройстве смотреть приложения в разы удобнее, но начинать проверку Android-приложений можно и с Android-эмулятора, чего не скажешь про iOS.

Из опыта могу посоветовать:

• Genymotion — легкий и быстрый эмулятор, которого за глаза хватает для теста приложения.

• Android studio — полноценная среда для разработки и отладки. Встроенный эмулятор — лишь малая часть его возможностей, так что этот софт гораздо тяжелее и требует больше вычислительных ресурсов. Подойдет, если вы захотите писать POC для уязвимости с вектором malware app.

Если вы планируете использовать физическое устройство, на нем предварительно нужно получить root-доступ и включить Android Debug Bridge через настройки разработчика.

При работе с мобильными приложениями стоит обратить внимания на эти утилиты:

• JADX — инструмент для декомпиляции Android-приложений (APK-файлов), который преобразует байт-код Dalvik / ART (DEX) обратно в читаемый исходный код на Java, а также позволяет исследовать структуры приложений.

• Frida — инструмент для динамического анализа и отладки, который позволяет интерцептировать и модифицировать выполнение кода в реальном времени на устройствах.

• Objection — фреймворк на основе Frida, который упрощает процесс обхода защиты мобильных приложений.

• AM (activity manager) — это Android-команда для управления активностями и другими компонентами приложений. Она позволяет через командную строку на устройстве запускать, останавливать приложения и взаимодействовать с ними.

• ADB (Android debug bridge) — это командная утилита, которая позволяет взаимодействовать с Android-устройством из компьютера, выполняя отладку, установку приложений, управление файловой системой и выполнение команд в терминале.

• MobSF — opensource (SAST/DAST) сканер уязвимостей для мобильных приложений. Что-то серьезное он вряд ли найдет, но подсветить узкие моменты может.

После того, как запаслись стартовым инструментарием и девайсом, идем набивать руку. В этом помогут всякого рода лабораторные и СrackMe:

• Frida Labs.

• SecureNote.

• OWASP CrackMe.

Попробовать свои силы на реальных приложениях помогут багбаунти-программы. Отточить навыки можно на платформе BI.ZONE Bug Bounty, ведь там достаточно публичных программ, в скоупе которых есть мобильные приложения.

Исследование безопасности мобильных приложений открывает возможности для карьеры и помогает бизнесу создавать качественные и надежные продукты. Надеюсь, эта статья поможет кому-то из читателей обратить внимание на направление мобильных приложений и даст толчок к исследованиям в этой сфере.

---

Автор: Сергей Арефьев, специалист отдела анализа защищенности приложений