Хочу рассказать об уязвимостях в проектах 1С. Сразу обозначу границы доклада – я буду рассказывать только о потенциальных уязвимостях в исходном коде конфигураций 1С. Мы не будем рассматривать внешние утилиты, которые диагностируют систему и т.п.
Виды уязвимостей
Уязвимостью называют возможное воздействие на информационную систему с последующим нанесением какого-либо ущерба.
Если все обобщить, то можно классифицировать уязвимости как:
-
Организационные – это отсутствие каких-то процессов либо требований к обеспечению информационной безопасности.
-
Технологические – отсутствие механизмов и технологий обеспечения безопасности.
-
Эксплуатационные – уязвимости, связанные с недостатками и дефектами существующих компонентов инфраструктуры.
Цена «бреши»
Бреши или дефекты в информационной системе могут привести к печальным последствиям. Я расскажу два случая – все события и персонажи вымышлены, любое совпадение имен и событий с реальными является случайностью.
Кейс №1: Подмена электронного адреса
Случай первый – подмена электронного адреса.
Дано: организация занимается продажей запчастей к тепловому оборудованию – это котлы, горелки, тепловые пушки и т.п. К ним через сайт интернет-магазин обращается потенциальный покупатель, запрашивает коммерческое предложение с запчастями в нужном объеме. Менеджер через условную «1С:Управление торговлей 11» отправляет письмо с коммерческим предложением из 1С и, соответственно, ждет ответа от клиента – согласится он или не согласится на условия, чтобы в случае согласия завершить сделку и получить деньги.
Что происходит за кулисами?
В модуль отправки электронных сообщений конфигурации «1С:Управление торговлей» в скрытую копию добавлен какой-то непонятный email с чужим доменным именем.
Возможно, недовольный сотрудник добавил в скрытую копию email конкурента компании, чтобы копии коммерческих предложений отправлялись конкуренту с контактами потенциальных клиентов. Конкурент эти предложения перехватывает и выставляет потенциальным клиентам более выгодные условия сотрудничества.
Получается, что если коммерческое предложение было на 400 тыс. рублей, то компании нанесен ущерб как минимум 400 тысяч, а перехват клиентов по такой схеме может происходить длительное время.
Кейс №2: Хардкод паролей
Второй кейс – организация занимается торговлей, как и в предыдущем случае. Торгуют мелкой бытовой техникой. Существенная часть продаж происходит через Яндекс.Маркет. Для этого в конфигурации реализована интеграция с Яндекс.Маркет – каждый день на FTP выгружаются товары, цены, остатки, изображения.
И вдруг неожиданно в апреле продажи падают, и новые покупатели с площадки Яндекс.Маркет перестают приходить.
Оказывается, что в марте из компании был уволен программист 1С, у которого сохранились исходные коды конфигурации 1С.
Но, так как он с компанией расстался не в лучших отношениях, ему не составило труда написать скрипт, который подключается к FTP, и все данные для Яндекс.Маркета там подчищает.
На экране, конечно, показан не тот случай, про который я рассказываю, но здесь тоже мы видим реализацию обмена с Яндексом из реального проекта – хардкод для отправки картинок прямо в продакшен-конфигурации. Получаем доступ к FTP и делаем, что хотим.
Самое интересное, что даже если доступ к Яндекс.Маркету хранится в безопасном хранилище подсистемы БСП, пароль к нему все равно нужно регулярно менять – поэтому не забывайте об этом.
Подведу итог. Средний оборот компании в месяц – 10 миллионов рублей. Примерный объем продажи с Яндекс.Маркет – 50-60%. Итого, как минимум 5-6 миллионов убытков в месяц, пока мы эту ситуацию не заметили и не исправили.
Конечно, эту проблему заметили раньше, чем через месяц, но пару недель она влияла на продажи, а 2-3 миллиона – это весомая сумма по отношению к общему обороту компании.
Что мы имеем в итоге? Даже безобидные дефекты – хардкод какого-то пароля или вставка в копию чужого email может привести печальным последствиям, к нанесению ущерба для компании.
К счастью, с этим можно бороться различными способами.
Способы поиска уязвимостей
Для поиска возможных уязвимостей есть:
-
ручные способы поиска;
-
и автоматизированные средства – на основе Open Source и коммерческие.
С ручными способами поиска уязвимостей все более-менее понятно:
-
либо ручками проводится код-ревью, регулярно просматривается код;
-
либо в компании есть отдел безопасности или сотрудник «безопасник», который пытается за этим следить, контролировать – не только на уровне конфигурации, но и на уровне самой инфраструктуры.
Но при определенных объемах ручной труд становится очень дорогим удовольствием. Тем более, он не может покрыть большую часть проблем, которые он должен отловить.
Автоматизированные средства поиска – SonarQube
Автоматизированные средства поиска, про которые я буду рассказывать, основаны на SonarQube.
Если кто не знает, SonarQube – это платформа для статического анализа кода, которая поддерживает множество языков программирования. С определенными плагинами поддерживает и язык 1С.
Также в эту платформу можно в определенном формате загрузить какие-то свои замечания, которые были сгенерированы где-то в другом месте – в конфигурации АПК, при ручном или автоматизированном код-ревью.
BSL Language Server
В Open Source есть несколько продуктов, которые могут отлавливать потенциальные уязвимости в конфигурациях 1С.
Первый продукт, про который, я думаю, многие слышали – это проект с открытым кодом BSL Language Server, который реализует Language Server Protocol для языка 1С.
Проект BSL LS используется:
В состав проекта BSL LS входит 6 проверок для поиска потенциальных уязвимостей.
Но есть определенные проблемы – если вам нужно расширить этот список под ваши нужды, вам либо нужно уметь разрабатывать на Java, либо найти того, кто умеет кодить на Java. И, соответственно, оплатить ему за написание такой проверки.
Проект os-scanner
Специально для митапа я подготовил демо-проект https://github.com/otymko/os-scanner, на котором показываю, что те же самые проверки в каком-то виде можно писать и на языке 1С.
Со страницы релизов можно скачать ospx-файл пакета, его можно установить по команде:
opm install -f "path/to/ospx"
После установки у нас появится доступ к консольной утилите os-scanner.
Смысл этого проекта в том, что мы берем папку с исходными кодами конфигурации, запускаем консольную утилиту os-scanner, и указываем, куда сохранить результат этого анализа.
os-scanner analyze "project/src/cf" "./generic-issue.json"
JSON-файл в формате generic-issue с результатами диагностики также можно посмотреть визуально – для этого есть самодельный отчет, в котором можно посмотреть содержимое этого JSON-файла, и посмотреть, что у нас там срабатывает.
А потом этот json-файл можно загрузить в платформу SonarQube либо с помощью комьюнити плагина, либо с помощью плагина от Серебряной пули. И смотреть результаты проверки в интерфейсе SonarQube.
Внутри реализовано две проверки:
-
Хардкод сетевых адресов – мы выискиваем из исходного кода хардкод сетевых адресов.
-
И запуск внешних приложений – если мы встречаем в коде модуля метод, который находится в нашем списке триггеров, мы фиксируем ошибку.
Все написано на языке 1С, там есть AST-дерево, с которым можно работать. Если кому-нибудь будет интересно, люди могут заморочиться и, не переключая контекст с разработки 1С, что-то для себя написать, чтобы какие-то свои вещи отлавливать.
Коммерческие решения для поиска уязвимостей
Дальше – коммерческие решения. Коммерческих решений несколько:
-
Есть решение Ростелеком-Солар от компании Ростелеком, который многие языки проверяет на какие-то общеизвестные уязвимости, в том числе, у них есть направление для 1С.
-
И есть возможности проверки в АПК. Мы считаем, что конфигурация АПК относится к коммерческим решениям, потому что чтобы им пользоваться, нужно иметь определенные доступы.
-
Есть 1С BSL Plugin для SonarQube от Серебряной пули. Он на данный момент имеет на борту 16 проверок на потенциальные уязвимости. Помимо этих проверок, есть около 200 собственных проверок кода 1С – на соблюдение стандартов, отлов каких-то ошибок и т.п.
1С BSL Plugin для SonarQube
Покажу, как 1С BSL Plugin для SonarQube выводит срабатывания уязвимостей в доработанной конфигурации ЗУП – часть из этих уязвимостей появилась в результате доработок.
Мы для этой конфигурации установили в нашем плагине специальный профиль качества «Аудит безопасности» и получили следующий перечень результат диагностик.
У нас в основные типы уязвимостей выбилось:
-
В коде не должно содержаться URL-ссылок – чаще всего, при использовании URL-ссылок в коде можно нарваться на подмену.
-
Опасность использования операторов сбора системной информации – это сбор информации о компьютере, сбор информации о пользователе информационной системы. Это тоже все нужно контролировать.
-
Ограничения на использование "Выполнить" и "Вычислить" на сервере.
-
Запуск внешних приложений.
-
Использование внешних объектов без безопасного режима.
-
Еще, из интересного здесь – IP-адреса не должны храниться в коде, отлавливаются IP-адреса, которые каким-то образом попали в код.
В общем, много пищи для проверки безопасникам.
Пять самых популярных проблем и методы их устранения
Расскажу о самых популярных уязвимостях в конфигурациях. Эту информацию мы собрали в результате проверки большого количества исходного кода. Входные данные:
-
Было проверено 15 случайных разномастных проектов, куда вошли конфигурации ERP, ЗУП, Управление торговлей, Розница, пару самописок.
-
В целом это примерно 35 миллионов строк кода.
-
Из них удалось получить 4682 срабатывания на потенциальные уязвимости.
-
Согласно статистике, 2903 срабатываний из них относятся к ТОП-5 основных типов уязвимостей.
На пятом месте оказалось интерактивное удаление. Нередко в проектах 1С можно встретить возможность интерактивного удаления объектов. Не всегда понятно, зачем это разрешение было выдано. Возможно, по ошибке, возможно, намеренно, до быстрого решения какой-то проблемы.
Риски – если у кого-то есть право интерактивного удаления, он может умышленно или по неосторожности остановить какие-то критические процессы в организации.
Например, в розничной торговле есть процесс приемки товара – один из наиболее критических процессов после продажи. Если у Старшего кассира есть право удаления номенклатуры, он может случайно удалить номенклатуру, по которой идет приемка. Соответственно, приемку не завершили в полном объеме, товар завис – его не смогли выложить, и, соответственно, не смогли продать, упустили какую-то прибыль.
Что с этим делать? Во-первых, убирать все разрешения на интерактивное удаление, кроме полных прав, и контролировать эти полные права в дальнейшем.
Если нужно именно удалять объекты, можно использовать специальные 1С-ные утилиты, например, «Поиск и удаление объектов», которая производит контроль ссылочной целостности.
На четвертом месте – «хардкод» электронной почты.
Вообще, разработчикам часто проще оставить какой-либо хардкод в коде, чем организовывать хранение в каком-то безопасном виде.
Я уже в кейсе №1 рассказывал, что хардкод какого-то непонятного email чаще всего чреват какими-то последствиями.
Также на контуре разработки, либо на тестовом контуре можно заспамить клиента при разработке. Это может испортить карму – в плохих случаях вы можете расторгнуть отношения с этим клиентом, что тоже приведет к потерям в деньгах.
Что с этим делать? Контролировать чужие email, чтобы их не было, и желательно, хранить email в каких-то специализированных местах, например, в контактной информации, к которой для конкретных людей можно ограничить доступ в разрезе RLS записей по контрагентам.
Если нужно отдельно выделить какой-то email, его можно хранить в константе, либо реализовать свой регистр сведений или справочник.
Третье место – это хардкод IP-адресов.
Опять же, хардкод IP адресов может послужить порчей данных в продуктиве с теста или с контура разработки.
Соответственно, это приведет к денежному ущербу организации.
Что с этим делать? Желательно вообще от IP адресов отказываться, конечно, использовать какие-то доменные имена, чтобы перемещать сервера в своей инфраструктуре было удобнее, использовать внутренние сайты, которые могут постоянно переезжать и т.п.
Опять же, храните сетевые адреса в константах, в регистрах сведений. Чтобы, если что-то поменялось, вам не нужно было дорабатывать конфигурацию, а достаточно было просто зайти в базу данных и поменять то, что вам нужно.
Дальше, если не говорить конкретно о сетевых адресах, нужно поотрубать все интеграции в тестовом режиме, чтобы они не навредили продуктиву.
И последний радикальный способ – вести разработку и тестирование в полном закрытом контуре, без связи с продуктивом, с какими-то внешними сервисами. Тогда большой беды не будет.
И второе место – это хардкод паролей, кейс № 2, про который я рассказывал ранее.
Риски по нему понятны. Что с ним делать? Хранить пароли через безопасное хранилище в подсистеме БСП, если у вас БСП, либо использовать свое безопасное хранилище, которое вы сделаете в своей конфигурации 1С, либо использовать внешние сервисы для хранения секретов. Например, Vault от компании HashiCorp, у них есть удобное API, авторизация и можно организовать удобный доступ и получение этих секретов, и их безопасность.
На первом месте находится выполнение внешнего кода. Если вы используете «Выполнить()» и «Вычислить()» и передаете туда какие-то параметры извне, куда можно вставить какой-то вызов функции или что-то еще. И если администратор не запаролен, инстансы не разнесены, или если выполнение кода делается где-то в привилегированном режиме, то через него можно получить доступ к серверу и что-то там похимичить.
Риски – злоумышленник может сломать продуктив или получить доступ к данным компании. Это чревато тратой денег.
Что с этим делать?
-
Во-первых, контролировать каждое такое выполнение. Мы знаем, что в БСП помечают код комментариями АПК, потому что они сами проверили, что этот код безопасен. Проводите свое код-ревью, потому что через такие уязвимости можно сделать все что угодно.
-
Я думаю, что у многих есть правила «Конвертации 2.0», где используются обработчики событий, а в них можно добавить все что угодно. И если вы все эти обмены запускаете под полными правами, то придет беда.
Вроде по ТОП-5 – уже все, но я выбрал еще одно правило вне конкурса – это внешние объекты и безопасный режим.
Внешние объекты – это внешние отчеты, обработки, расширения, которые мы все любим подключать в свои базы данных. Их подключение в небезопасном режиме чревато тем, что вы можете испортить данные базы, а при выполнении в привилегированном режиме злоумышленники могут добраться непосредственно до сервера.
Что с этим делать? Лучше всего загружать эти объекты в базу данных через подсистему «Дополнительные отчеты и обработки БСП» и открывать их только в безопасном режиме.
Подсистема «Дополнительные отчеты и обработки БСП» позволяет все запускать в безопасном режиме и не дает другим людям этот флажок снимать.
По общей сводке получилось, что эти ТОП-5 + 1 срабатываний – самые популярные, они составляют примерно 62% всех срабатываний по 15 различным конфигурациям.
Исследование проводилось с помощью плагина «Серебряной пули».
Остальные 38% – менее популярные, но могут иногда сделать больно. Даже заметили случай, что кто-то в каталог программы 1С пишет. Был пример, когда мы обнаружили, что платежки почему-то сохраняются туда, хотя это место должно быть в принципе защищено и туда не должно ничего класться.
Если провести немного занимательной статистики, то получается, что примерно на 9 тыс. строк кода приходится 1,2 уязвимости. Это – немало.
Что дальше?
Теперь, когда вы знаете, какие бывают виды потенциальных уязвимостей, знаете, как их искать – нужно найти и исправить эти проблемы с помощью настройки прав, разнесения инстансов и т.п.
Компания «Серебряная пуля» продолжает развивать плагин, в этом году мы планируем реализовать еще 15-20 проверок на уязвимости (всего их будет где-то 30-40), чтобы какие-то основные вещи можно было отлавливать из кода до помещения в продуктив.
Как обычно, в конце я приведу полезные ссылки.
-
SonarQube - https://www.sonarqube.org/
-
1C BSL Plugin для SonarQube - https://silverbulleters.org/sonarqube
-
Проект на OneScript - https://github.com/otymko/os-scanner
-
BLS Language Server - https://github.com/1c-syntax/bsl-language-server
Вопросы
Где и как рекомендуется хранить пароли для внешних сервисов, с которыми интегрируется 1С?
Первый способ – реализовать свое безопасное хранилище, к которому разграничить доступ правами. Но если база утечет, это не поможет,
Следующий способ – это безопасное хранилище из подсистемы БСП. То же самое, только уже сделанное, рабочее и во многих местах используется.
Есть внешние системы, допустим, Vault от компании HashiCorp. Это внешнее хранилище секретов, куда есть доступ по токену, по сроку действия и т.п. И там можно из API по защищенному протоколу эти секреты вытаскивать в момент их использования. Если они были скомпрометированы, перехвачены и т.п., база ушла – быстро обновляем доступы и доступ к этим секретам пропадает. На мой взгляд, это самый лучший способ, но это чревато со стороны разработки, потому что такую систему нужно интегрировать. Я пока не видел в открытом доступе таких интеграций.
Ведется ли вообще учет паролей, к которым имеют доступ разработчики? И вообще, как часто меняются пароли?
До «Серебряной пули» я работал в большом сибирском ритейле, где в сопровождении и в разработке участвовало очень много человек. Там было принято менять пароли раз в месяц. Для системных учеток Active Directory у нас настроено менять пароль раз в две недели, потому что все подключаются по удаленному доступу, и важно контролировать утечки паролей, если у кого-то вирусы на компьютере.
По поводу разработки и использования паролей в самих базах есть несколько вариантов. Либо вы делаете доступ по доменной учетке – тогда много вопросов сразу отметается.
А если говорить про внешние объекты, то там лучший вариант – Vault и контролировать срок действия токена доступа – 2 недели, а потом просить разработчика, чтобы он ввел новый пароль, чтобы все это дело никуда не утекло.
И, соответственно, все это желательно хранить внутри организации, не используя интернет, потому что у многих хранилище с HTTP-доступом открыто наружу и есть учетки, в которых пустой пароль. А если у них еще и есть право захвата объекта, то можно вытянуть конфигурацию целиком. А там, опять же, хардкод паролей и мы развлекаемся, как хотим – получаем доступы к площадкам-агрегаторам типа Яндекс.Маркета и начинаем чудить.
Школьники таким очень часто балуются. Конечно, это больше всего касается не 1С, а серверов телефонии вроде Asterisk. Лет пять назад было популярно найти такой сервер, подобрать к нему пароль, получить доступы на SIP и начинать звонить куда-нибудь, продавать трафик.
Моя рекомендация – не доводить до абсурда, а устанавливать срок годности паролей максимум месяц. Особенно, если вы пользуетесь базой внутри закрытой организации. Потому что сотрудники меняются – есть определенная текучка в организациях. Лучше перестраховаться.
Через тот же самый Vault можно настроить срок годности этих паролей, и по истечении срока годности их менять.
Как вы находите такие уязвимости? Вы разворачиваете тестирование у клиента или тестируете у себя внутри? Какие правила закладываете? Определенные или параметрические?
Если говорить про поиск уязвимости внутри кода 1С, мы это делаем автоматизировано с помощью нашего плагина и написанных проверок. Смотрим, что у нас получилось. А потом уже начинаем ручками смотреть.
Если говорить еще отдельно про инфраструктуру, то у нас есть определенные скрипты, с помощью которых мы проверяем, отлавливаем банальные вещи. А есть интересные вещи, про которые немногие знают, как их отлавливать. Мы все это автоматизированным образом получаем – формируем файлик, а потом начинаем вместе с заказчиком разбираться в том, что в этот файлик попало. Для инфраструктуры мы чаще всего используем уже заготовленные кейсы, но часто в процессе работы находим что-то новенькое, и, соответственно, добавляем в нашу базу.
Еще у нас в компании развивается тема с Vault, используется Service Discovery – сервис с хранением секретов. В принципе, тема для многих подъемная, чтобы разобраться. Если будете смотреть – не пугайтесь, что вам предлагают развернуть docker, чтобы это хранить. Есть готовые примеры, как все это безопасно получать оттуда. Многие используют программки для хранения паролей от серверов в браузере. Вы можете то же самое разместить в Vault и оценить все его прелести. Vault имеет бесплатную версию.
А не пробовал сервис OnePassword?
Пробовал, хорошая программа, у нее есть разграничение прав. Но она платная и у нее нет API, это работает только локально, десктопно. Из-за этого к 1С это трудно применимо. Конечно, можно сохранить там пароль от 1С, но какая разница – либо ты в браузере открываешь закладку и начинаешь там смотреть, либо в программе на компьютере.
Какие самые печальные последствия могут быть при уязвимостях?
Самый известный случай, который был у меня – компания просто закрылась. У нее утекли доступы к серверу, эти IP-шники были захардкожены в конфигурации – по ним добрались до базы физически и прошли по ней шифровальщиком. В итоге учредитель психанул и закрыл компанию.
А этого можно было избежать, если использовать хотя бы VPN. Это немного усложняет быстрый вход на чужой сервер.
По теории боли, пока что-то не случится, заказчик об этом и знать-то не будет. Как часто у вас, по статистике, клиенты превентивно обращаются посмотреть, проанализировать конфигурацию? И как часто они обращаются, когда уже все сломалось.
Тех, кто просто хочет провести аудит безопасности – таких очень мало. В основном, если такие и есть, они из госсектора. Из тех, кто обратился, когда случилась какая-то боль – я думаю, таких 15%. Все остальные пытаются решить это какими-то своими способами. Точной статистики у меня нет, но могу предположить, что примерно 20% обращается, когда их либо клюнуло, либо они хотят все это дело проконтролировать. А все остальные – параллельно с контролем качества обращают внимание на такие вещи и начинают задумываться. А потом, если у них еще и есть безопасники, там уже они активизируются. Они же хотят разработчиков помучить – смотрите, что у вас тут, я же вам говорил. Так и начинается. 20% обращаются либо когда у них случилась боль, либо когда они хотят проверить безопасность своих решений.
Как лучше защитить пароли пользователей для типовых конфигураций – ЗУП, Бухгалтерии для некрупных фирм?
Начнем с того, что в платформе появилась двухфакторная авторизация. Если у вас развернуто Active Directory, вы можете использовать доменную авторизацию для этого.
Плюс, не забывайте, что можно контролировать права тех, кто может подменить пользователя, под которым авторизуется какой-то конкретный человек.
Лучшие способы – это OpenID, двухфакторная авторизация и т.п. В мире 1С, к сожалению, ничего лучше нет.
В данном случае, часто бывает достаточно просто поработать со стороны сетевой службы.
Покажи, как устроен проект с диагностиками, написанными на OneScript
Есть библиотека от Цуканова Александра os-parser, она строит AST-дерево по коду 1С. В данном случае, у нас точка запуска – файл os-scanner.os, его параметры мы передаем в класс Сенсор.
os-scanner analyze "project/src/cf" "./generic-issue.json"
Потом из этого Сенсора мы перебираем каждый файл – запоминаем контекст, какие-то описания методов. Мы просто парсим модуль, передаем туда классы, которые реализуют проверки, и потом забираем оттуда ошибки, если они есть. А потом все это сохраняем в отчет.
Самая простая проверка – это «ЗапускВнешнихПриложений». У нас есть подписка «ПосетитьВыражениеИдентификатор», и, если мы встречаем в коде модуля метод, который находится в нашем списке триггеров, мы фиксируем ошибку.
На мой взгляд, это выглядит проще, чем АПК. Я тоже пробовал писать свои проверки для АПК, в АПК порог входа намного больше. Тем более, не стоит забывать, что АПК уже перестает развиваться, только сопровождается, теперь уже команда со стороны EDT что-то для статического анализа делает. Но оно пока не опубликовано (прим. ред. – на момент доклада в сентябре 2020 года еще не было опубликовано).
*************
Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе "Безопасность в 1С".
