# От уязвимости к недопустимому: повторяющиеся паттерны в 150+ нуликов

## Метаданные

Доклад: «От уязвимости к недопустимому: повторяющиеся паттерны в 150+ нуликов»

Спикеры: Кирилл Полегаев, Роман Малов и СОК товарищи

## Вступление

Всем привет. Извините за задержку.

Меня зовут Кирилл Полегаев, со мной Роман Малов. Сегодня мы расскажем о результатах нашей команды. По соглашению с организаторами мы не называем, к какой компании относимся. Это команда, которая занимается непрерывным тестированием внешнего периметра.

Мы проведем анализ результатов, которые собрали: немного посмотрим на статистику, интересные кейсы и на то, какие выводы из этого можно сделать.

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

## О чем доклад и как собирался dataset

У нас накопился довольно большой, на наш взгляд, опыт проведения тестирования на предотвращение пробива внешнего периметра: более 50 проектов. Также у нашей команды накопилось довольно большое количество опубликованных 0-day уязвимостей: более 150 на текущий момент.

Нам показалось, что такого объема данных может быть достаточно, чтобы провести анализ и вывести какие-то интересные закономерности.

Мы сфокусировались не на известных CVE, BDU и так далее. Нас интересовали именно новые уязвимости, которые не встречались ранее: те, что мы находим на проектах, либо те, что находим в рамках 0-day research.

Также нам хотелось рассмотреть не просто отдельные уязвимости, а составить модель. В сумме у нас получилось 250+ записей: 0-day, проектные находки и так далее.

В каждой записи мы категорировали уязвимость. Есть категория по OWASP 2025. Есть vulnerability type: по сути, CWE-like тип, только человекочитаемый. Не просто номер, а, например, SQL injection.

Нам хотелось рассмотреть potential impact: например, XSS и потенциальный impact как account takeover. Также мы смотрели confirmed impact: для чего у нас действительно получилось раскрутить данную уязвимость. Смотрели тип ПО, где была найдена уязвимость, и по potential либо confirmed impact определяли рекомендуемые controls: как можно предотвратить данную уязвимость.

Важный момент про методологию. Dataset - это наш набор уязвимостей, которые не встречались раньше: проектные находки плюс 0-day. Здесь нет известных CVE, BDU и misconfiguration, которые находятся сканерами. То есть фокус не на vulnerability management, а именно на новых уязвимостях, которые встречаются в бизнес-логике и похожих местах.

Типы уязвимостей, как я сказал, мы классифицировали по OWASP 2025 и CWE-like. Типы ПО - это тоже наша классификация. Impact и controls - это человекочитаемые словари, чтобы по тегам можно было понять, какой здесь impact и какие controls закрывают эти уязвимости.

## Ограничения

Важно сказать про ограничения. Это не универсальная статистика всех уязвимостей. Это только наш опыт. Соответственно, мы не можем сказать, что его можно взять и аппроксимировать, допустим, на весь внешний периметр Рунета или еще где-то. Это только наш командный опыт.

И это только внешний периметр.

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

## Статистика

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

По нашим результатам Broken Access Control - это почти половина всех найденных уязвимостей. Если посмотреть на две остальные категории, Authentication Failures и Injection, то в сумме эти три типа уязвимостей составляют более 90% всего, что мы находим.

Если смотреть более подробно по типам уязвимостей и по типам ПО, распределение уже более равномерное: всем известные XSS, IDOR, disclosure, user enumeration и так далее. Такая классификация, во-первых, человекочитаемая, а во-вторых, дает более равномерную картину, потому что все не складывается в одну большую кучу Broken Access Control.

По типам ПО более 50% - это либо бизнесовые вебчики, либо CMS. Это довольно логично, учитывая, что мы фокусируемся не на CVE и не на известных уязвимостях, а на новых уязвимостях. Они часто живут в бизнес-логике.

Не будем долго тянуть со статистикой: потом мы к ней еще вернемся. Перейдем к наиболее интересным кейсам, которые приводили к недопустимым событиям.

Небольшой disclaimer: мы были больше сосредоточены на impact, а не на технической части самих уязвимостей. То есть стараемся рассматривать не то, что существует какая-то SQL injection и у нее интересный bypass, а то, что эта SQL injection существует и что с ней в принципе можно сделать.

## User enumeration и слабая парольная политика

Первая история - про user enumeration плюс слабую парольную политику.

User enumeration как таковой некоторые компании и даже вендоры не считают за уязвимость. Казалось бы, можно получить имя пользователя, который существует в системе, но ни RCE, ни SQL-инъекции, ничего такого не утекает. Но в совокупности со слабой парольной политикой эта история может стать критичной.

Мы постоянно с этим сталкиваемся: в облаках, в почтовых шлюзах, во всевозможных прикладных интеграциях, в самописном ПО и так далее. User enumeration может оказаться вообще везде.

Последствия наглядные. В приложении, где не используется интеграция с доменом, в 99% случаев мы собираем map по пользователям и начинаем брутить top-100, top-1000, top-10000 - насколько хватает ресурсов.

Интересно, что этот баг часто не живет один. Рядом идут облегчающие проблемы: отсутствие rate limit, отсутствие lockout учетных записей и отсутствие блокировки атакующего, например по IP.

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

В следующем кейсе история была еще интереснее. Был выполнен enumeration в Exchange, собраны учетные записи, по ним был выполнен password spray, и одна из учеток сработала. После этого был получен доступ в [неразборчиво], и там уже нашли интересные истории: доступ к машинам обновлений, доступ к работам. Очень дешевая атака: просто подождали, посмотрели на консоль - и получили пробив внешнего периметра.

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

Что из этого получили? Мы смогли собрать список существующих доменных учетных записей, и примерно к 100 удалось подобрать пароль. Атака получилась супертривиальной и дешевой, но последствия достаточно критичные.

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

Следующий impact - сбор актуальных доменных учетных записей и материал для phishing campaigns. Enumeration - это старые добрые фиши, с которыми можно очень активно работать, в том числе на больших объемах данных.

## IDOR, GUID и безопасность на знании идентификатора

Следующий тип уязвимостей и история, про которую расскажем, - это IDOR, всем довольно знакомые.

Самая стандартная история: идентификатор какого-то объекта перебираемый, это просто числовой номер. Его можно менять и смотреть чужие объекты. Все давно знакомо.

Но интерес этой истории не в классическом IDOR. Когда мы обычно про такие IDOR рассказываем и даем рекомендации, мы говорим, что нужно сделать две вещи. Первая - уйти от перебираемых идентификаторов, использовать GUID, чтобы их нельзя было просто инкрементировать или декрементировать. Вторая - реализовать нормальный контроль доступа: если субъект не имеет права доступа к объекту, он не должен получать его даже по прямой ссылке.

Мы часто сталкиваемся с мнением: «Давайте просто реализуем GUID». Видимо, потому что сделать неперебираемые GUID проще, а полноценную ролевую модель с проверкой на уровне объекта - сложнее. Нам часто говорят: «Давайте мы просто GUID реализуем. Перебрать вы никак не сможете, на этом и будет строиться безопасность».

Следующий кейс как раз про то, что на одном только знании GUID и на их секретности безопасность строить нельзя.

Приложение мы здесь скринить не стали, чтобы не раскрывать, что это за приложение. В самом приложении обрабатывалась крайне критичная и чувствительная информация. Аутентификация была через ЕСИА, то есть фактически OAuth, делегированная аутентификация. В целом в самом приложении все выглядело неплохо.

Немного покопавшись и посмотрев приложение, мы обнаружили интересный JavaScript endpoint. Там увидели ряд интересных ключей, которые говорили о какой-то регистрации, видимо, внутренней. Также увидели некие роли, которые тоже выглядели как GUID.

Мы ткнулись в ручку, которая, кажется, позволяла регистрировать пользователя. Причем это явно была не та ручка, которая стандартно работает через ЕСИА. Видно, что GET не поддерживается, поддерживается POST.

В процессе изучения API было замечено, что это, видимо, API какой-то встраиваемой системы или стороннего компонента. Чтобы аутентифицироваться и получить валидный токен сессии, нужно было передать определенные идентификаторы: ECR ID и WIC Profiles. Это тоже не перебираемые значения, которые особо не раскрывались.

Но была найдена уязвимость: ручка возвращала валидный токен даже без передачи этих идентификаторов. Единственная разница была в том, что токен не был привязан к конкретной сущности. Видимо, привязка к субъекту как раз строилась по идентификаторам. Тем не менее токен был валидным, и с ним можно было ходить.

Дальше мы покопались еще и раскрыли схему ролей: какой GUID за какую роль отвечает. Уже здесь есть крайне критичная уязвимость: нет нормальной проверки, нужно только предоставить какую-то роль, и нам выдается валидный токен. Дальше мы с этой ролью можем ходить, а все роли системы мы уже раскрыли.

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

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

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

Быстрый вывод: на одних только GUID строить безопасность нельзя.

## 1С во внешнем периметре

Теперь про 1С.

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

Первый кейс - уже, наверное, народный метод. Аутентификация реализована через SSO на базе ID. Вроде бы все хорошо, но архитектурно SSO является либо отдельной базой данных, либо общей базой данных, в которую ты входишь.

Нам удалось с помощью небольшого bypass спуститься до классической аутентификации 1С. Это была архитектурная проблема, которая позволила получить список пользователей базы и попробовать подбираться внутрь.

Мы сфокусировались на RCE. Нам не повезло: не было ни слабых паролей, ни пустых паролей. Но мы не сдавались, начали крутить, начали искать пути на том же домене. Оказалось, что была найдена дополнительная база. Она имела такую же доменную авторизацию. Там тоже был список пользователей, и вот тут нам уже повезло: мы получили список пользователей, нашли пользователя с пустым паролем и административной ролью.

Далее мы выполнили [неразборчиво] и RCE, получили RCE на хосте по классическим пунктам.

Второй кейс больше не про типовую историю «опубликовали базу и забыли прикрыться», а про архитектурные сложности в 1С.

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

Это нас привлекло. Мы заметили в логах утечку системного пользователя и провернули ту же историю с downgrade до прямого пути к базе данных. Мы пытались перебрать пароль к этому пользователю, но безуспешно. После 10 попыток столкнулись с тем, что учетная запись была заблокирована.

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

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

Проблема была в том, что для попадания внутрь портала и доступа к функционалу нужно было получить approve от администратора. Такой approve просто так не выдавался, приходилось связываться и проходить бюрократию. Но мы заметили, что какую-то часть функциональности уже можем использовать через штатный механизм 1С.

В Web 1C по прямому пути, через штатное окно операции, нам удалось сбросить пароль через функциональность «забыли пароль». Мы восстановились, попали в портал и начали изучать функциональность: нажимать кнопки и смотреть интересные места.

Было замечено, что в штатном методе происходит открытие формы. Web 1C работает достаточно специфично. Когда мы запрашиваем какую-то форму и хотим что-то открыть, сначала запрашивается список доступных сущностей, грубо говоря ссылки: куда нужно сходить, что должно открыться, что должен вернуть backend и что должно отрисоваться на frontend.

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

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

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

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

Итоговые последствия: массовое раскрытие персональных данных и чувствительной информации, выполнение произвольных глобальных [неразборчиво] из первого кейса, а также демонстрация финансовых и репутационных рисков. Если у вас 1С выставлена в интернет, есть шанс, что что-то пойдет не так. И риск остается дешевым для атакующего.

Мы показали это на большом объеме данных, но это касается и малого, и среднего бизнеса - всех, кто выставляет 1С в интернет.

## Платформы мониторинга: dashboard, data source и SSRF

Следующая история - пара кейсов, связанных с платформами мониторинга.

Эти платформы по своей природе склонны к одному типу уязвимостей: SSRF. Платформа мониторинга обычно подключает какие-то data source и как-то графически их отображает.

Первый кейс не про SSRF. Мы столкнулись с платформой мониторинга, в которой был неавторизованный доступ ко всем dashboard и data source. Неавторизованный доступ к мониторинговой платформе означает, что в эти data source можно ходить.

Что обычно такое data source? База данных или что-то похожее, откуда тянутся данные для графического отображения. Один из data source оказался базой MySQL.

Помимо просмотра уже настроенных данных, так как у нас был неавторизованный доступ, мы могли по-своему настраивать отображаемые данные. А настройка отображаемых данных, когда data source - это MySQL, по сути означает SQL-запрос в эту базу данных.

То есть неавторизованно можно было делать прямые запросы в базу данных: например, вывести пользователей, посмотреть пароли, имена и так далее. На слайде видно, что это была не просто случайная база данных, а база Asterisk - система IP-телефонии. Соответственно, можно было делать запросы к базе, где хранится информация, связанная с IP-телефонией.

Риск был реализован довольно быстро. Так как это MySQL, мы смогли подгружать файлы и читать файлы. Но основное недопустимое событие было в другом: в этой базе данных хранились записи разговоров IP-телефонии. По виду файлов было видно, что есть внешние и внутренние разговоры. Мы смогли прочитать такие файлы и получили доступ к крайне критичной внутренней информации - записям разговоров.

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

Это была тоже мониторинговая платформа, в которой была функциональность создания отчетов. Там можно было передавать link, который предполагался как путь к локальным файлам. Это обходилось значком `@`, то есть можно было сделать SSRF.

Мы сильно удивились, когда сделали такой запрос на наш interactsh-сервер, и запрос со стороны уязвимого сервера прилетел вместе с заголовком Authorization, в котором в Basic были учетные данные.

Мы подумали, что это очень странно. Тем не менее на внешнем периметре было много различных порталов, куда можно было попробовать эти учетные данные. Они подошли. Причем подошли к SSL VPN-порталу, и это оказались доменные учетные данные.

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

Еще стоит сказать, что SSRF этим не ограничивалась. Она также давала account takeover. Если эту ссылку нажимал пользователь, зарегистрированный в системе, запрос прилетал вместе с username и password в GET-параметрах. То есть еще и account takeover, причем логин и пароль прилетали в открытом виде.

Мы нарвались на что-то очень древнее, но оно предоставило нам доступ во внутренний периметр.

Реализованные недопустимые события: получение доступа во внутреннюю сеть и получение несанкционированного доступа к записям телефонных разговоров в системе IP-телефонии.

## SQL injection и impact

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

Первый кейс. В коде был обнаружен параметр, в нем была SQL injection. При изучении базы было видно: у нас есть логин, у нас есть пароль, но пароль хеширован современным алгоритмом и не подвержен расшифровке. Назад его не получить, немного грустно.

Но нет. В соседней таблице, в соседней колонке, лежал идентификатор пользователя, который полностью обходил проверку и безопасное хранение пароля. Заходим, получаем доступ, меняем пароли и в общем делаем что хотели.

Второй кейс. У нас был выбор, он был закрыт достаточно специфично, реализован PIN-кодом. Мы этот PIN перебрали, попали в админку приложения и начали изучать.

Также в параметре была обнаружена SQL injection, но тут немного интереснее: был пройден путь до эскалации. Внутри был нестрогий WAF, и это позволило через URL-encoding пройти дальше.

Установили, что СУБД - Microsoft SQL Server. Имя пользователя на слайде зацензурено. Пользователь обладал правами sysadmin, и был включен доступ к модулю `xp_cmdshell`. Несколько запросов - и получили RCE.

Атака опять получилась дешевой. Это был 2026 год: все еще доступно, все еще существует.

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

## CMS и модули

Следующий кейс довольно быстрый. Это история про CMS и модули в них.

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

Первый пример хрестоматийный: file upload. Есть форма, в которую можно прикрепить файл. Файл просто прикреплялся; можно было прикрепить PHP, потом найти его в папке вроде `tmp-upload` и выполнить. RCE получалось одним очень простым действием.

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

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

Следующий кейс - с неузнаваемой CMS, ее можно не замазывать, все равно никто не узнает. Да, это «Гитрикс».

В ней был модуль, который позволял делать импорт-экспорт файлов. Уязвимость была видна прямо из интерфейса: там прямо было подписано, что можно вставить path file. В этот путь можно было написать `/etc/passwd`, и выпадала ссылка, которая любезно предоставляла этот файл.

То есть здесь был local file read: можно было читать произвольные файлы.

Вывод по CMS: на них находится много всего из-за их природы. Они очень модульные, модули пишутся разными людьми, и безопасность там часто оказывается слабым местом. Недопустимые события в этих кейсах - удаленное выполнение кода и массовое раскрытие персональных данных.

## Документация, source maps и недооцененные источники разведки

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

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

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

На слайде можно обратить внимание, что в документации можно обнаружить: в админке нас ждет выполнение [неразборчиво] и поля, позволяющие написать собственную PHP-форму. Тут можно, конечно, применить к текстовому шаблону какие-то запросы, но нас интересует другое: что из этого можно сделать RCE. Наша задача - пробиться внутрь, а дальше уже «дернуть за спуск».

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

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

При поиске документации бывают случаи, когда блок найти не получается: ПО уже не новое, сайты закрыты, ничего нет. Тогда на помощь приходит Web Archive. Архивы очень классно все хранят. В них можно найти достаточно интересную информацию, которая оказывается правдой.

Еще один частый источник - source maps. Они очень много раскрывают. В последнее время, в 2026 году, было много громких кейсов: все сливают, все пишут, все паникуют. Но это все еще есть и в 2026 году.

Source maps используются для отладки, но атакующие тоже приходят, смотрят и что-то ломают. В данном случае в map-файле от stand-сервера были credentials. Обратите внимание: stand-сервер. Удалось запроксироваться, проверить гипотезу: да, до IP мы ходим через proxy, и все ок.

Опять же, просто посмотрев map-файл, получили доступ к критичным активам, персональным данным, документам.

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

## Какие ошибки чаще всего приводят к недопустимым событиям

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

На примере кейсов мы, конечно, никого не удивим: обычно реализация недопустимого события - это комплексная проблема. Она зачастую строится не на одной конкретной уязвимости, а на комплексе проблем.

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

Обычно реализация недопустимых событий - это какой-то комплекс из этих проблем.

Стоит выделить, что Broken Access Control, который у нас статистически оказался наиболее частым, даже как одна уязвимость может вести к реализации недопустимых событий.

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

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

Второй тип - мониторинговые платформы. У них явно выделяется SSRF, что связано с природой самого программного обеспечения.

И еще один слайд с большой цифрой. Мы заметили, что на нашем опыте 1С Enterprise, которая выставлена во внешний периметр, приводит к недопустимому событию в 87% случаев. Но стоит признать: она крайне редко встречается на внешнем периметре.

## Controls: как ломать цепочки недопустимых событий

Теперь про controls: как можно ломать цепочки недопустимых событий и предотвращать эти уязвимости.

Controls в нашем случае - это не жестко захардкоженная метрика. Это человекочитаемая условность, которую мы хотим принести.

В кейсах, о которых мы рассказывали, прослеживается общая схожесть: первичный доступ часто получен достаточно тривиальным способом. Где-то утек пароль, где-то что-то не сошлось, где-то доступ получен иначе.

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

Первый контроль - object level authorization. Он про то, чтобы тестировать систему: низкопривилегированный пользователь не должен получать данные высокопривилегированного пользователя или соседнего пользователя. Это горизонтальные перемещения, IDOR, BOLA и вся классика. Неаутентифицированный атакующий тоже не должен получать данные там, где не должен.

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

Второй контроль - централизованная авторизация. Это как раз про то, что критичное лучше хранить либо за SSO, либо точно за вторым фактором, и не пропускать потенциального злоумышленника к нему напрямую. Например, если бы у 1С висел второй фактор, маловероятно, что получился бы пробив и что-то интересное удалось бы искать.

Третий контроль - least privilege. Он про понятное: не давать пользователю привилегий больше, чем ему нужно. Низкопривилегированный пользователь не должен иметь доступ к системным функциям, не должен иметь возможность выполнять административный функционал, дергать какие-то ручки и так далее.

Как в кейсе с SQL injection: особого смысла давать пользователю права sysadmin не было, но они были. Если возможно избежать такого - не стоит так делать.

Четвертый контроль - rate limit. Это история про brute force, OTP, пароли, DoS и все похожее. Никто не запрещает применять все вместе и комбинировать. Мы говорили про дешевую атаку; rate limit может стать дешевой защитой, которая рвет цепочку. Например, при enumeration вы собрали пользователей, но дальше не можете spray-ить пароль и брутить их: атака останавливается.

Главный вывод: эти controls нужно применять и тестировать. Особенно для простых багов. Не стоит отталкиваться только от метрики CVSS, потому что на все уязвимости, которые мы рассматривали, можно смело повесить PR:High - и на этом расслабиться. Но это не так. Фактическая критичность может взлетать до Critical, а на руках у атакующего могут быть тривиальные способы bypass.

## Итоговые выводы

Мы немного вышли за время, поэтому быстро про выводы всего исследования.

Недопустимые события происходят из-за комплекса проблем. Соответственно, решать их нужно комплексно и разным командам: AppSec - следить за реализацией ролевой модели, инфраструктурным командам - следить за внешним периметром и так далее.

Приоритизировать можно как атакующие, так и защитные действия. На предыдущем слайде мы показывали, какие controls покрывают больше уязвимостей. Если реализовать небольшой набор из четырех controls, можно закрыть довольно большой пласт уязвимостей.

Атакующие тоже могут приоритизировать проверки на основе tech detect или других сигналов с внешнего периметра.

Проблемы с учетными данными и контролем доступа - наиболее массовые паттерны, которые мы до сих пор встречаем.

Доклад командный. На слайде представлена команда. Всем большое спасибо, кто на этом слайде: тем, кто находил баги, делал research и так далее.

У нас на этом все. Если есть время на вопросы, готовы выслушать. Спасибо.

## Вопросы и ответы

Вопрос из зала: используете ли вы свои AI-инструменты?

Ответ: в принципе, да, постоянно используем. Если это какие-то анонимизированные данные, которые никак не касаются заказчиков, то используем облачные. Если это что-то критичное, то у нас, естественно, развернуты self-hosted решения, которые мы тоже активно используем на каждом этапе: от pentest до анализа информации и так далее.

На самом деле все довольно просто обходится. Возможно, сейчас уже есть облачные решения, которые с этим строже. Но в целом, если сказать: «У меня есть моя система, и я хочу понять, как меня могут взломать, расскажи пять наиболее вероятных векторов», - по крайней мере у нас это работает.

Мы пока не сталкивались с такими, чтобы модель совсем не отвечала и запрещала из-за политик. Self-hosted - точно. Иногда ее нужно чуть-чуть успокоить и объяснить, что это не атака, а справка.

Вопрос из зала: [неразборчиво]

Ответ: нет, не за деньги. [неразборчиво]

Вопрос из зала: репортов много. Это Bug Bounty?

Ответ: нет, это не Bug Bounty. Это 0-day, которые мы репортим регулятору, а регулятор потом вместе с вендорами это устраняет.

Вопрос из зала: могли бы на Bug Bounty заработать?

Ответ: наверное, могли бы.

Вопрос из зала: почему регулятору, а не вендорам?

Ответ: потому что сложно со всеми вендорами. Мы не хотим усложнять процесс репорта уязвимости. Наша задача - чтобы уязвимость закрыли. Искать разных вендоров, смотреть, есть ли у них security policy, есть ли отдельный почтовый ящик для репортов или нет, - это отдельная работа. Есть отлаженная схема, по которой все проходит.

Комментарий из зала: насчет взаимодействия. На самом деле disclosure в России очень странный. Команду, которую здесь не называют, три раза обещали засудить за последний год, причем через регулятора, через стек. После этого мы уже просто [неразборчиво].

Ответ: если говорить, что все еще beta, [неразборчиво]. Потому что векторы странные, уровень зрелости небольшой, особенно у тех, у кого это первая BDU, которая прилетает.

И то, что коллеги говорят про Bounty: мы какой-то hold выдерживаем. Если мы нашли на проекте 0-day, отправляем, BDU отреагировал, вендор отреагировал, раз, два, три, четыре, пять - и только потом можно Bounty. Потому что иначе это нечестно.

Спасибо еще раз.

## Неоднозначные места

- В начале ASR ошибочно распознал фамилии как «Калегаев» и «Новых»; по контексту слайдов исправлено на Кирилл Полегаев и Роман Малов.
- В кейсе с Exchange после успешного password spray неразборчиво название системы, куда был получен доступ: в сыром тексте похоже на «Google Playpack».
- В блоке про 1С несколько технических фрагментов сильно повреждены ASR: точное название действия после получения администратора в первой базе, фрагменты про «полкреф/полпе», а также «глоб» во фразе про выполнение произвольных действий. Эти места помечены как [неразборчиво].
- В блоке про документацию неразборчив фрагмент про выполнение «3 4 под заметь»; смысл сохранен только на уровне impact/RCE.
- В Q&A часть реплик из зала плохо слышна и распознана фрагментарно; такие места помечены как [неразборчиво], без попытки восстановить факты.