Довольно долгое время вероятным нарушителем считался только злоумышленник из интернета. На сегодняшний день компании весьма неплохо научились защищать внешний периметр, по крайней мере, важные активы. Но внешние ИТ-ресурсы — это лишь вершина айсберга. Во внутреннем периметре любой компании существует огромное множество процессов работы с данными и соответствующих ресурсов. Число пользователей таких систем может исчисляться тысячами: в больших ИТ-компаниях работают сотни и тысячи сотрудников, с доступом ко внутренним ресурсам, при этом постоянно происходит множество ротаций. Всё это создаёт риски компрометации продукта и утечки данных.
Сегодня я хочу рассказать о проблемах внутренних веб-ресурсов, которые наблюдаю я и мои коллеги из самых разных компаний.
Статья основана на моем опыте работы в разработке, пентесте и AppSec. Описанные проблемы встречались систематически в разных компаниях и продуктах.
Разница между внешним вебом и внутренним
Давайте начнём с того, в чём вообще разница между безопасностью внешних сервисов и внутренних. Внутренний или внешний — это всё ещё веб, поэтому все те проблемы, которые мы видим во внешних сервисах, также возможны и во внутренних. Однако важные отличия всё же есть, и они делают часть проблем более существенными. Самые яркие особенности внутренних ресурсов:
Больше доверия пользователям.
Больше межсервисных интеграций.
Гораздо больше функциональности и критичных БП.
Недостаточное покрытие тестами.
Разберёмся, какие проблемы эти особенности усиливают.
Проблемы доступа
Небезопасная реализация механизмов аутентификации
Чтобы сделать безопасную аутентификацию, нужно приложить много усилий: умный антибрутфорс, второй фактор, восстановление пароля и функциональность «запомни меня», проверка сложности паролей и вхождение в словари. Опять же, необходима поддержка управления доступом, например, блокировка уволенных сотрудников. Внутренние же ресурсы почти никогда такое не реализуют в полном объёме. Если, например, оставить небезопасную форму аутентификации вовне, это приведёт к большому количеству инцидентов и последующей работе по их устранению. Внутри же такая форма зачастую не доставляет неприятностей, и её спокойно оставляют, как есть. Но это только до поры до времени.
Рекомендации по защите механизмов аутентификации
На первое время хорошей практикой можно считать использование корпоративных систем централизованной аутентификации и управления доступом. В них почти всегда реализована необходимая защита. Дальше корпорации обычно пишут собственные системы защиты под свои потребности.
Управление сессией
Тут встречаешься с тем, что команда продукта понимает необходимость разграничения доступа и управления сессией, но сильно заморачиваться этим не хочется. Да и надо ли? Пользователь-то внутренний. Но рано или поздно такое отношение приводит к появлению разных неприятных решений, яркий пример - токены доступа (они могут называться по-разному).
В реализации токенов доступа можно допустить множество уязвимостей. Как правило, проектированию безопасности БП, связанных с токеном, уделяют недостаточно внимания, учитывая особенности внутренних приложений. Поэтому если видите что-то похожее во внутреннем ресурсе, не жалейте усилий на проверки. Вот примерные вопросы к этой функциональности:
Кто генерирует токен?
Как он генерируется, длина, сложность?
Куда даёт доступ?
Кому выдается этот токен?
Какое у него время жизни?
Как он хранится?
Как передаётся?
Индивидуальный ли токен?
Рекомендации по защите управления сессий
Для реализации безопасного управления сессией необходимо участие ИБ в проектировании бизнес-процессов. Артефакты проектирования, схемы и документации будут крайне полезны для анализа рисков реализуемого решения.
Инъекции
Как отмечено ранее, все проблемы внешних приложений актуальны и для внутренних. Инъекции не исключение. Однако тут есть свои нюансы. Во-первых, те же SQLi встречаются чаще и могут быть злее. Злее — потому что пользователь, от лица которого произошло проникновение, может получить больше привилегий на уровне БД, что позволит дотянуться до конфиденциальных таблиц. Во-вторых, к сервису может быть подключено несколько баз, и все они с большой вероятностью окажутся полностью доступны пользователю. Одним словом, привычные уязвимости могут иметь большую зону поражения.
Небезопасный экспорт в CSV (CVS Injection)
Практически в каждой админке есть экспорт данных. Один из самых популярных форматов — это CSV. Суть этой инъекции в том, что формат CSV может содержать в себе полезную нагрузку в виде скриптов или методов Microsoft Excel. Microsoft Excel прекрасно поддерживает выполнение таких скриптов, и если пользователь нажал «Ок» в паре диалоговых окон, то у него выполнится полезная нагрузка. Понятно, что эта атака имеет предусловия эксплуатации , но, если уязвимость всё же будет проэксплуатирована, эффект от неё может быть весьма значительным. И если про XSS многие разработчики знают и принимают защитные меры на фронтенде, то данные на экспорте в CSV практически всегда будут грязными. Подробнее о векторах атаки через CSV Injection можно почитать вот здесь.
Blind XSS
Вспоминаем особенность про взаимные интеграции. Внутренние ресурсы часто передают данные друг другу. Например, одна система используется для сбора обращений в техподдержку, другая — для анализа и постановки задач. При этом первая система, скорее всего, будет защищена, поскольку имеет дело с внешними данными. А при заборе данных из внутреннего сервиса они почти всегда будут восприняты как доверенные, из-за чего, соответственно, не будут применены различные механизмы безопасности вроде фильтрации.
Поскольку доступа во внутренние ресурсы извне скорее всего не будет, то самым правильным шагом будет использование различных фреймворков постэксплуатации XSS через угон сессии. Вектором атаки может стать парсинг витрины данных и передача данных POST-запросами на контролируемый внешним злоумышленником ресурс. Эффект от такой уязвимости потенциально довольно высокий, поскольку внутренние веб-ресурсы, как правило, содержат большое количество конфиденциальных данных.
Рекомендации по защите от инъекций
При реализации продукта необходимо исходить из того, что все внешние данные являются недоверенными и могут быть использованы для атак. На границах доверия системы необходима обязательная проверка и фильтрация данных.
Управление потоками данных
Внутренние веб-приложения сложны сами по себе, к тому же содержат множество интеграций с другими сервисами. Происходит постоянный обмен данными между системами, а управление их потоком и выстраивание границ доверия требует значительного количества ресурсов и зрелого подхода к разработке. Не у всех это есть. Поэтому возникают ситуации, когда сервис А достаточно защищен, но отдаёт данные сервису Б. А что с этими данными происходит в сервисе Б, может вообще никак не контролироваться. Сервис Б может хоть из интернета запросы проксировать в сервис А.
Продовые данные в тестовом окружении
В индустрии говорить о безопасности тестового окружения считается дурным тоном. В ней регулярно проводятся различные эксперименты, используют уязвимости костыли для отладки, и вообще включен всевозможный вывод ошибок. По-другому разработка занимала бы значительно больше времени, что во многих случаях означало бы её нерентабельность и ненужность.
То, что среда разработки небезопасна, это данность. Чтобы разрабатывать и отлаживать, необходимо работать с данными, которые по структуре идентичны продовым. Поэтому самым простым решением будет сделать копию продовой базы. Получается, что конфиденциальная информация попадает в небезопасную среду, и тогда уже нет разницы – ломать dev или prod оркужение, результат, с точки зрения доступа к данным, будет одинаков. Отличие от внешней среды лишь в том, что внутри сетевого периметра находится, очевидно, больше тестовых стендов.
Нет горизонтальных ограничений на доступ к данным
Пользователям должен быть разрешён доступ только к части данных, с которыми им необходимо работать. Например, у нас есть данные о заказах и есть пользователь с ролью менеджер, который вручную обрабатывает эти данные. В большинстве случаев менеджер будет иметь доступ ко всем возможным заказам, и это уязвимость. В таком случае даже SQLi не нужна, любой менеджер может распарсить данные и фактически заполучить себе базу. Даже если процесс подразумевает доступ к определённым данным, необходимо горизонтально разделять их по какой-то классификации. Например, делить заказы по контрагенту, или индустрии, или заказчику, или ещё как-то, чего часто не делают.
Рекомендации по защите потоков данных
Для безопасного управления потоками данных необходимы практики управления архитектурой системы. Они включают в себя анализ ИТ-ландшафта, потоков данных, контрактов межсервисного взаимодействия и ещё много всего.
Небезопасные бизнес-процессы
По своей сути любое веб-приложение — это автоматизация каких-то бизнес-процессов. Прежде чем приступать к автоматизации, необходимо спроектировать БП и посмотреть на получившиеся схемы с разных позиций. Безопасность проектируемых БП сильно зависит от уровня культуры разработки и вовлечённости AppSec в продукт. Если чего-то не хватает, то однозначно можно ожидать проблем в:
Составе участников БП и их полномочиях.
Составе данных.
Взаимосвязи процессов.
Внутренний веб тут отличается тем, что внутри БП гораздо больше, и они критичнее. Далеко не все существующие в продукте БП открывают в интернет. Например, функциональность ручного начисления монетизации редко доступна вовне, но для внутренних ресурсов это не редкость, и потенциальный ущерб от компрометации этих процессов очень значительный. При этом уязвимость внутренних БП долгое время может оставаться незамеченной, потому что внутри проводится меньше тестирований.
Безопасность БП — это отдельная, достаточно сложная тема. В этой статье я не стремлюсь осветить её даже поверхностно. Есть отличная статья моего коллеги, советую прочесть.
Рекомендации по защите бизнес-процессов
Повышайте уровень культуры разработки и вовлечённости AppSec в продукт, уделяйте больше усилий на этапе проектирования бизнес-процессов, а также формируйте артефакты проектирования. Приступайте к написанию кода только после согласования артефакта со всеми участниками проектирования (включая ИБ).
Временные решения
Команда продукта иногда попадает в ситуацию, когда нужно запускаться очень быстро. Времени на проектирование или даже написание кода просто недостаточно. В таких случаях реализуют различные компромиссные временные решения. Они могут оказаться большими проблемами безопасности.
Примером временного решения может быть ручная обработка данных. Выстраивая таким образом БП, часто забывают о рисках, которые влечёт за собой человеческий фактор. Например, атакующему может быть достаточно подменить Excel-файл где-нибудь в открытой файловой шаре.
Современные условия разработки бывают таковы, что поверх временного решения наращивают функциональность, таким образом приводя к ситуации, когда временное решение существует с продуктом на протяжении всего жизненного цикла. На поздних этапах сделать какие-то изменения довольно трудно, потому что это означает значительную перестройку сервиса. Риски таких уязвимостей чаще всего «принимаются» бизнесом.
Старые API и сервисы
Пожалуй, самые яркие уязвимости находятся именно в таких ресурсах. Например, сервис начали писать в начале десятых, и он эксплуатируется по сей день. Тут возможны два ярких случая:
Сервис развивают, но делается это множеством команд и даже продуктов.
Сервис используют ограниченно.
В первом случае, если продукт рос в условиях низкой культуры разработки, у этого сервиса нет актуальной документации, описанной архитектуры, матрицы доступа, а иногда даже и владельца. Одна из ярких проблем в подобных случаях — ролевая система. Под каждую новую задачу создаётся отдельная роль, потому что так проще, чем анализировать систему целиком и искать подходящую. А ещё ведь может случиться, что подходящую роль уже кто-то использует и её нельзя гибко настроить при необходимости.
Во втором случае в сервисе вообще может не быть разработчиков. Например, разработка была у подрядчика, с которым уже давно нет трудовых отношений. Вкладываться в развитие и поддержку этого сервиса никто не готов. Также возможно отсутствие практик SRE. Это всё приводит к тому, что даже зная о наличии уязвимости в сервисе, нет возможности её исправить. Эксплуатация ресурса всё ещё необходима, возможно, даже есть какие-то планы по его переписыванию, но сейчас у него есть уязвимости.
Тут ещё можно привести пример, когда разрабатывается новая версия API, а старая всё ещё доступна. Переписали не всю функциональность в новый API, и, возможно, приоритеты разработки таковы, что старый API никогда и не будет полностью переписан. При этом отношение продукта к нему примерно такое же, как к тестовой среде.
Рекомендации по защите временных решений
ИБ должна иметь организационные рычаги воздействия на команду продукта. Конечно, возможны многие компромиссы, но ИБ должна быть арбитром, который определит границы дозволенного и проконтролирует выполнение договорённостей, с которыми был принят тот или иной компромисс.
Заключение
Вернёмся к мысли из введения. В больших ИТ-компаниях работают сотни и тысячи сотрудников. Происходит множество ротаций. Это делает модель внутреннего нарушителя актуальной. При этом в этой статье мы увидели, что без должного присмотра со стороны AppSec внутреннему нарушителю доступно множество возможностей компрометации продукта.
Что интересно, подавляющее большинство перечисленных проблем — это не проблемы кода. С помощью статических анализаторов эти проблемы не выявить. Они выявляются в продукте только AppSec-экспертами, а лечатся повышением культуры разработки и внедрением лучших практик SSDLC.
Что еще полезного для компании может сделать AppSec, можно почитать в этой статье.