Проверка безопасности приложения

Самая частая ошибка — забыть проверить, прошла ли аутентификация. Бывает, что аутентификация реализуется только в клиентской программе, а сервер полагает: «если запрос пришёл — значит, всё в порядке». Бывает, что в протокол добавляют много повышающих безопасность дополнительных параметров, которые не проверяются или проверяются неправильно.

Часто обходы заметны при визуальном просмотре исходного текста. Если ПО небольшое — удобнее всего сгенерировать каждый поддерживаемый запрос сторонней программой и посмотреть, что будет. Если ПО большое, а протокол не очень сложный — пишется простой сканер:

for (перебор по параметрам запросов)
  { Send (текущий вариант);
    Error = Receive ();
    if (Error != NOT_IMPLEMENTED && Error != ACCESS_DENIED)
      cout << параметры запроса;
  }

Любой ответ, отличный от «не реализовано» или «доступ запрещён», — повод копнуть глубже. Псевдокод применим к протоколам с явной семантикой кодов ответа (HTTP, gRPC, SOAP). Для бинарных протоколов признак «эта команда что-то сделала» — таймаут или disconnect vs. структурированный ответ; критерий определяется по конкретному протоколу.

По документам для хеширования паролей применяется только ГОСТ Р 34.11-2012 (хеш-функция «Стрибог»), а реально — как повезёт. Или отечественная криптография вообще отсутствует, хотя должна присутствовать.

Реальный кейс: в одной отечественной сборке Linux отечественная криптография отсутствовала из-за ошибки при сборке — прилинковали не ту библиотеку.

Что делает эксперт: ищет по исходникам и бинарникам строки наподобие gost, crypt; смотрит экспортируемые символы через nm или strings; проверяет, какие библиотеки реально подгружены — ldd для ELF, dumpbin /dependents для PE; проверяет OID-ы алгоритмов в выпускаемых сертификатах. Версии заимствованных библиотек могут быть устаревшие, с неустранёнными уязвимостями.

Часто для хеширования паролей применяют слабые хеш-функции (например, MD5) без марканта/соли. В таких случаях сразу обращает на себя внимание необычно короткий хеш. Для проверки, используется ли соль, достаточно создать две учётные записи с одинаковыми паролями и сравнить хеши. Алгоритм шифрования/подписи в большинстве случаев проще всего установить с помощью одного из многочисленных онлайн-калькуляторов.

Попадались случаи, когда секретный ключ хранился в общедоступном файле (см. кейс №1 ниже).

Базовые ошибки, которые ловятся одним tcpdump или Wireshark:

• пароль передаётся по сети в открытом виде;
• по сети передают не пароль, а незашифрованный хеш — это позволяет перехватить его и передать повторно (pass-the-hash);
• для идентификации сетевого соединения используется легкоугадываемое значение, например порядковый номер.

Эксперт обязательно перехватывает трафик пары «клиент — сервер» во всех штатных сценариях: вход, выход, смена пароля, восстановление сессии. Странности видны сразу.

Включаем максимальное количество функций драйвера/модуля и запускаем SyzKaller, либо пишем простейший «фаззер»:

for (;;)
  for (i = 0; i < MAX_SYSCALL; i++)
    { if (NonFuzzable (i))
        continue;
      r1 = rand (); r2 = rand ();
      r3 = rand (); r4 = rand ();
      r5 = rand (); r6 = rand ();
      syscall (i, r1, r2, r3, r4, r5, r6);
    }

Результат предсказуем: BSOD на Windows, kernel oops на Linux, паника ядра — за минуты. Драйвер, который не выживает после такой проверки, не должен попадать в продукт.

Корректный код IOCTL-обработчика выставляет размер выходного буфера после валидации параметров каждой команды:

switch (code)
  { case CODE1:
      if (!CheckParameters1 ()) return ошибка;
      SetOutBufferSize (как хочет клиент);
      return DoRequest1 ();
    case CODE2:
      if (!CheckParameters2 ()) return ошибка;
      SetOutBufferSize (как хочет клиент);
      return DoRequest2 ();
    default:
      return ошибка;
  }

На каком-то этапе автор делает «безобидный» рефакторинг — выносит общий вызов SetOutBufferSize наружу. А спустя пару релизов добавляет команду без параметров:

SetOutBufferSize (как хочет клиент);
switch (code)
  { case CODE1: if (!CheckParameters1()) return ошибка; return DoRequest1 ();
    case CODE2: if (!CheckParameters2 ()) return ошибка; return DoRequest2 ();
    case CODE3_NO_PARAMETERS:
      return DoRequest3 ();   // нет CheckParameters — буфер уже выставлен!
    default:  return ошибка;
  }

В результате при обработке запроса с кодом CODE3 клиент получает до OutputBufferLength байт неинициализированной части системного буфера — фактически утечка содержимого соседних аллокаций ядра. Реальный кейс — драйвер промышленного ПО под Windows через METHOD_NEITHER (прямой пользовательский указатель, без ограничения page-aligned аллокацией) отдавал до мегабайта памяти ядра одной командой.

Часто забывают ограничить права непривилегированных пользователей к самописным устройствам. Эксперт смотрит листинг /dev/ или \\.\, ищет устройства с правами 666 / FILE_ANY_ACCESS и пробует обращаться к ним от имени обычного пользователя.

1. Какие запросы к серверу доступны без аутентификации? Достаточно ли ограничен перечень таких запросов? Как это проверялось — визуальным просмотром кода, вводом тестовых запросов вручную, созданием автоматического сканера на основе системы тестов?
2. Допустимо ли, если сервер получает пакеты не от штатной клиентской программы, а от сторонней программы? Если нет — каким образом реализуется запрет подключения таких клиентов? Если да — точно ли это не приводит к нарушениям безопасности (например, если функция безопасности реализована не на сервере, а только в клиентской программе)?
3. Какой протокол аутентификации применяется? Если самописный — кто его разрабатывал и тестировал? Если стандартный — точно ли он подходит к данной конкретной ситуации?
4. Есть ли в протоколе дополнительные параметры, повышающие безопасность (ограничения по адресам подключения, времени подключения, сроку действия ключей и т. п.)? Они точно используются? Как это проверялось?

5. Как сервер устанавливает длины буферов с передаваемыми клиенту данными? Нет ли HeartBleed-подобных уязвимостей?
6. Какие криптосистемы применяются? Точно ли реальность соответствует документации? Как это проверялось? Проверялись ли особые случаи (например, в Linux-совместимой ОС самый первый пользователь, создаваемый при установке)? Не применяются ли самописные криптоалгоритмы?
7. Какой заимствованный код используется в проекте? Какие в нём известны уязвимости? Проводилась ли работа по анализу заимствованного кода как минимум на уровне мониторинга открытых источников? Проводится ли такая работа на регулярной основе? Какая реакция предусмотрена в случае обнаружения в заимствованной библиотеке критической уязвимости?
8. Применяются ли в проекте устаревшие криптосистемы наподобие DES, MD5, RC4? Если да — безопасно ли это?
9. При хешировании паролей используется ли маркант (соль, salt, seed)? Если нет — почему? Проверялось ли это прямым сравнением хешей одинаковых паролей у разных пользователей?
10. Как вводятся ключи шифрования? Если они хранятся внутри системы — как реализовано это хранение? Кому могут быть доступны эти данные в каких ситуациях?
11. Передаются ли пароли по сети в открытом виде? Проверялось ли это перехватом и анализом трафика?
12. Передаются ли по сети хеши аутентификации в открытом виде? Проверялось ли это перехватом и анализом трафика?
13. Если защита трафика полагается на полное его шифрование сторонним протоколом (например, SSL) — как обрабатывается ситуация, когда шифрование по каким-то причинам невозможно? Не пойдёт ли трафик в открытом виде?
14. Как сервер идентифицирует сетевые соединения клиентов? Не используются ли легкоугадываемые идентификаторы (например, порядковые номера), передаваемые прямо в пакете с данными?
15. Какие генераторы случайных чисел применяются в проекте? Не применяются ли для криптографических задач линейные рекурренты или другие неподходящие алгоритмы?

16. Проводились ли проверки кода на наличие SQL-инъекций? Какие средства формирования SQL-запросов применяются в проекте? Не формируются ли SQL-запросы вручную (sprintf и т. п.)? Если подавать на вход непарные кавычки, апострофы и т. п. — не появляются ли в ответах сервера ошибки SQL?
17. Проводились ли проверки кода на предмет наличия XSS-уязвимостей? Как сервер реагирует на вручную сформированные пакеты, похожие на штатные, но с необычными заполнениями полей? Как сервер реагирует на команды JavaScript, размещаемые внутри пакета? Может ли нарушитель добиться их некритичного размещения внутри веб-системы? Если имитировать ввод в формы непарных кавычек, апострофов и т. п. — не появляются ли в ответах ошибки веб-интерфейса? Насколько корректно сервер принимает пакеты с текстом в необычных кодировках?
18. Как обрабатываются ситуации, когда клиент указывает имя файла вместе с путём? Не пытается ли сервер применить этот путь к своей файловой системе? Как при этом обрабатываются подстроки .., строки, начинающиеся с \ в Windows и т. п.? Если делается санитизация — можно ли её обойти необычными кодировками текста или какими-то другими ухищрениями?

19. Драйверы и модули ядра, содержащиеся в проекте, проверялись ли SyzKaller-подобными фаззерами?
20. Как ограничиваются права доступа к файлам приложения? Что может сделать с файлами приложения непривилегированный пользователь, используя предоставленные права? Если приложение работает в Windows — те же вопросы задаются в отношении ключей реестра и объектов корневой файловой системы (\??\* и т. п.).
21. Как ограничиваются права доступа к устройствам, обслуживаемым исследуемым драйвером? Драйвер полностью полагается на права доступа, заданные в ОС, или дополнительно реализует собственные проверки? Что может сделать с драйвером непривилегированный пользователь?
22. Как ограничивается доступ к реализованным в проекте сервисам D-Bus или интерфейсам COM/DCOM? Что может делать непривилегированный пользователь, используя предоставленные права?
23. Принимаются ли в проекте специальные меры, блокирующие доступ сторонних приложений через отладочные интерфейсы операционной системы? Не стоит ли их принять?
24. Принимаются ли в проекте специальные меры, блокирующие доступ сторонних приложений через графический интерфейс операционной системы? Не стоит ли их принять?
25. Не создаёт ли анализируемое ПО на общем рабочем столе окна, обслуживаемые высокопривилегированным процессом? Могут ли такие окна создаваться непредумышленно — например, при запуске справки или после аварийного завершения Windows Explorer? Что может сделать непривилегированный пользователь, направляя в эти окна специально подобранные комбинации сообщений? Не стоит ли избавиться от таких окон?

26. Поддерживает ли анализируемое ПО мандатное управление доступом? Если да — все ли функции работают в секретных сессиях? Как это проверялось? Возможны ли утечки информации, помеченной как секретная, через поисковые индексы, журнальные файлы, графические интерфейсы, привилегированные системные процессы, внешние накопители информации, другими путями?
27. Поддерживает ли анализируемое ПО изолированную (замкнутую) программную среду? Если да — блокированы ли типичные пути обхода через файлы-исключения, скрипты, эксплойт 38473 из ExploitDB, ярлыки на рабочем столе, файлы конфигурации, перенаправление ввода-вывода, журнальные файлы и т. д.? Распространяются ли правила ЗПС на интерпретируемый и динамически генерируемый программный код, COM-подобные интерфейсы и т. д.? Не вызывают ли правила ЗПС сбоев при доступе к принтерам, внешним накопителям, сети и т. д.?
28. Скомпилирован ли проект с поддержкой рандомизации распределения адресных пространств (ASLR)? Насколько качественна эта рандомизация — устранены ли типичные недостатки? Может ли нарушитель игнорировать ASLR, используя злоупотребление средствами обработки исключений?
29. Проводился ли статический анализ исходных текстов проекта? Проводится ли он на регулярной основе? Как организовано реагирование на предупреждения статического анализатора?
30. Какие принимаются меры для защиты от переполнений буфера? Используются ли в коде проекта небезопасные функции обработки строк? Присутствуют ли в программе переполнения буферов?
31. Какие принимаются меры для защиты от обращений к освобождённой памяти? Присутствуют ли в программе ошибки обращения к освобождённой памяти?
32. Какие принимаются меры для защиты от ошибок двойного освобождения памяти? Присутствуют ли в программе ошибки двойного освобождения памяти?
33. Используются ли в проекте форматные строки (printf и т. п.)? Какие принимаются меры для защиты от ошибок в работе с форматными строками? Присутствуют ли в программе ошибки работы с форматными строками?
34. Какие принимаются меры для защиты от утечек памяти? Присутствуют ли в программе утечки памяти?
35. Какие принимаются меры для обеспечения корректной многопоточности (недопущение race conditions и deadlocks)? Присутствуют ли в программе ошибки обеспечения корректной многопоточности?
36. Построена ли для приложения поверхность атаки? Предпринимались ли попытки её построить? Полностью ли она покрыта вышеперечисленными вопросами?
37. Проводилось ли фаззинг-тестирование приложения? Планируется ли его проводить? Учитывалась ли перспектива проведения фаззинг-тестирования при проектировании архитектуры и в ходе разработки приложения?
38. Работает ли приложение с чувствительными данными (пароли, ключи шифрования, идентификаторы банковских счетов и т. п.)? Какими? Проводилось ли для приложения автоматизированное выявление утечек чувствительных данных? Были ли выявлены утечки и какие?