# Module #5

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

В случае с iOS это просто валидация тех данных, которые пользователь заполняет в формы для формирования запросов на сервер.

Примеры возможных запросов можно найти [здесь](https://github.com/swisskyrepo/PayloadsAllTheThings).

Как данные попадают в приложение:

- IPC вызовы
- Кастомные URL схемы
- QR коды
- Файлы, которые получены через Bluetooth, NFC и т.д.
- Pasteboards
- Пользовательский интерфейс

# Как понять к чему может привести узявимость

Уязвимости в программном обеспечении известны достаточно давно, чтобы понимать к чему они могут привести, можно обратиться к вот [этому](https://cwe.mitre.org/data/definitions/699.html) ресурсу.

Мини практика:

- необходимо рассмотреть [примеры](https://github.com/sania454/iOS-Insecure-Samples) исходных кодов и обнаружить уязвимости
- уязвимости нужно классифицировать по CWE или OWASP Top 10

# Внедрение кода (инъекции)

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

Примеры:

- Serialization
- SSTI

## Log injection

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

## Predicate Injection

Уязвимости, которые в первую очередь касаются методов класса NSPredicate. Такие уязвимости схожи с SQL Injection и NoSQL Injection. Пример кода:

NSString *pin = [self getPinFromUser];
NSPredicate *predicate = [NSPredicate predicateWithFormat:@"pin LIKE %@", pin];

let pin = getPinFromUser();
let predicate = NSPredicate(format: "pin LIKE '\(pin)'", argumentArray: nil)

Атаку можно произвести используя просто символ *.

## SQL injection

Уязвимость возникающая вследствии недостаточной фильтрации данных от пользователя при составлении динамического запроса к БД. Осуществляется путем добавления специальных символов в параметры запроса.

[Вариант](https://github.com/microsoft/fluentui-apple) противодействия

## XML Injection

Уязвимости, которые обнаруживаются вследствии неверной настройки парсеров при работе с XML. Основная проблема - цункции `Document Type Declaration`. За счет этой функции большинство атак возможно впринципе.

В SOAP парсерах эта функция отключена по-умолчанию.

## XSS и HTML injection

Уязвимости, которые позволяют добавлять собственный javascript код или html разметку. Обнаруживается обычно в динамически собираемых приложениях. Работает только на FrontEnd приложений.

Примеры:

- https://hackerone.com/reports/1483
- https://hackerone.com/reports/575562
- https://hackerone.com/reports/805073

Узявимость может быть из-за неверного использования элементов:

- UIWebView(Deprecated)
- JavaScript включен по-умолчанию, нельзя отключить
- нельзя контроллировать используемый протокол
- WKWEbView
- JS включен по-умолчанию, но можно отключить программно
- можно контроллировать протокол для загрузки данных
- SFSafariViewController
- JS не может быть отключен
- приложение не может контроллировать действия
- использует куки и данные из Safari

## Уязвимость форматной строки

Относительно "древняя" уязвимость, как утверждало большое количество источников. Не так давно была обнаружена уязвимость в iOS:

На картинке представлена уязвимая функция.

Особенность уязвимости заключается в том, что для работы с форматной строкой iOS использует `[NSString stringWithFormat:]`, что сразу отметает традиционную эксплуатацию уязвимости через использование %n, %s, %x специальные символы.

Что подвело iOS? При создании "безопасной" версии форматной строки, забыли исключить спец символ %@, который используется для показа данных об объекте в памяти.

Использование уязвимости в итоге можно перевести в другой класс ->UAF->Double Free->RCE

Примеры:

- https://hackerone.com/reports/784676

## Objective-C и C

Язык программирвания, который был создан с добалением SmallTalk. Поэтому конструкции языка получились очень необычными с точки зрения синтаксиса. Однако, все проблемы и особенности языка C сохранились.

Все уязвимости, которые существуют для приложений написанны на C++/C так же актуальны и для Objective-C.

## Buffer overflow/underflow

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

- strcat
- strcpy
- strncat
- strlcat
- strncpy
- strlcpy
- sprintf
- snprintf
- gets

Для эксплуатации уязвимости в современных приложениях исползуются ROP цепочки.

## Integer Overflows/Underflow

Целочисленное переполнение, возникает при неверном выборе типа данных для контроллирования размеров объектов или выделяемой памяти.

Может быть использовано для модификации алгоритма приложения или проведения атаки на выполнение команд.

Противодействовать переполнениям можно через использвоание стандартных врапперов из "os/overflow.h"

#include <os/overflow.h>
 
if (os_mul_overflow(m, n, &bytes)) {
    /* Overflow occured.  Handle appropriately. */
} else {
    /* Allocate "bytes" space. */
}

## Swift

Язык программирования, который был создан для более удобного написания приложений. Так же он включает механизмы по санитизации работы с памятью и поэтому атаки, которые были возможны на приложения Objectiove-C. Могут быть неактуальны.

Однако, в 2020 году в Swift для более удобной работы с памятью и нативными библиотеками была добавлена возможность снова использовать указатели на низкоуровневые структуры оперативной памяти. Unsafe Swift - так называется набор возможностей.

Работать этот набор возможностей в приложениях будет скорее всего:

- С Core Foundation С API;
- Оптимизация работы приложения

Все существует 13 типов указателей. Все 13 типов разделяются на подгруппы:

- Buffer
- mutable
- immutable
- raw
- unsafe <= самый опасный вариант.
- managed

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

## Практика

1. Протестировать приложение на SQLi
2. Протестировать работу приложения на известные уязвимости платформы