Введение
Согласно статистике реагирования на инциденты за последние годы, количество инцидентов информационной безопасности непрерывно растет. Злоумышленники постоянно совершенствуют свои техники и тактики, используемые при реализации атак. Мы все чаще сталкиваемся с техниками и тактиками, которые ранее редко встречались или не встречались вообще.
C октября 2024 года мы начали фиксировать атаки, в которых задействовались серверы с программным обеспечением 1С. При этом такие серверы могут как служить вектором проникновения злоумышленника во внутреннюю инфраструктуру, так и использоваться для повышения привилегий — в таком случае атакующие целенаправленно ищут серверы 1С во внутренней сети жертвы. В обоих случаях компрометация серверов оказывается возможна в результате серии мисконфигураций, допущенных при настройке 1С.
В этой статье мы опишем конкретные мисконфигурации, которые привели к компрометации 1С в реальных инцидентах, а также расскажем, как можно было предотвратить развитие подобных атак.
Поиск следов злоумышленника
Как уже упоминалось ранее, в рамках реагирования на инциденты мы сталкиваемся с двумя типами атак на 1С. В тех инцидентах, где серверы 1С являлись вектором проникновения в инфраструктуру, информационные базы оказывались доступными напрямую из интернета в результате человеческой ошибки или же были опубликованы намеренно, без подозрений о наличии мисконфигураций.
В случае использования злоумышленниками 1C-серверов для повышения привилегий возможность атаки обусловлена сложившимся подходом к построению безопасности, который не отвечает современным требованиям к защите инфраструктуры, а именно упором на защиту исключительно внешнего периметра. В большинстве атак, с которыми нам приходилось сталкиваться, безопасности внутренней инфраструктуры уделялся меньший приоритет. Так, мы отмечаем отсутствие разграничения доступа к ресурсам, в частности к серверам 1С внутри сети, в результате чего такие серверы оказываются доступными и с пользовательских машин, и с серверов, и с сетевого оборудования. При таком подходе злоумышленник, попав во внутреннюю сеть, может беспрепятственно найти нужные ему серверы с известными уязвимостями и мисконфигурациями.
В общем случае, если во время расследования инцидента мы понимаем, что злоумышленники использовали именно программное обеспечение 1С, нам необходимо проанализировать соответствующий сервер. Первое, на что мы обращаем внимание, — журналы регистрации 1С. В них хранится информация о событиях, происходивших в информационной базе в определенный момент времени. Для анализа инцидента особенно полезна информация о том, когда злоумышленник подключился к базе и отключился от нее, а также какую учетную запись использовал. Кроме того, по отдельным событиям в журналах регистрации можно предположить, какие действия выполнял атакующий.
На скриншоте выше представлено множество полезных данных для изучения действий злоумышленника: имя учетной записи, с помощью которой был получен доступ к информационной базе, а также имя компьютера, откуда было инициировано подключение. Отметим, что в журналах регистрации 1С записывается именно имя компьютера, а не его IP-адрес, что часто осложняет расследование инцидента.
Кроме того, в журнале регистрации мы видим, что при работе внешней обработки произошла ошибка с подстрокой 1C_SHELL, что прямо указывает на активность злоумышленников. Для дальнейшего анализа нам нужно ответить на следующие вопросы: как злоумышленник выяснил имя целевой информационной базы, имя пользователя для подключения и его пароль. Далее в статье мы разберем эти вопросы, выясним, что такое внешняя обработка и какие меры следует предпринять, чтобы не допустить реализацию любого из этапов описанной атаки.
В случае использования 1С для повышения привилегий злоумышленники часто уже закреплены в скомпрометированной инфраструктуре в точке проникновения. Тенденция такова, что в качестве закрепления злоумышленники выбирают различные утилиты для сетевого туннелирования. Сканирование внутренней сети и поиск серверов 1С осуществляются при наличии у злоумышленника подключения через туннель. Тогда в журналы регистрации 1С, как в целом и в любые другие журналы ОС Windows, в большинстве случаев попадет не имя легитимной системы из инфраструктуры жертвы, с которой фактически было инициировано подключение, а имя системы злоумышленника, с которой он подключался к внутренней сети. Скомпрометированную машину в таком случае можно попытаться найти различными способами в зависимости от конкретной ситуации: IP-адрес системы при определенных условиях может попасть в журналы ОС Windows или сохраниться в журналах сетевых соединений, если такие имеются. В ходе расследований мы регулярно встречаем в журналах имена систем, отсутствующих в инфраструктуре организации. Например, на скриншоте выше мы видим, что подключение производилось с системы DESKTOP-9QVS1BH — это стандартное имя компьютера, которое в большинстве случаев не соответствует принципам унифицированного именования устройств в организации.
Виды мисконфигураций
Получение списка информационных баз
Как злоумышленник может узнать имена информационных баз? Во всех расследованных нами инцидентах, в которых злоумышленникам удалось найти доступный сервер 1С внутри инфраструктуры, они могли подключиться к консоли администрирования кластера серверов без аутентификации. Получив доступ к консоли, злоумышленники могли просматривать список информационных баз 1С, а также управлять кластером: создавать новые базы, удалять имеющиеся и т. д.
- Рекомендация: консоль администрирования кластера серверов 1С должна быть доступна только аутентифицированным пользователям. Важно сразу после установки создать администратора кластера с надежным паролем.
Получение списка пользователей
Следующий этап атаки после получения злоумышленником имен информационных баз в кластере 1С — попытка подключения к ним. В результате еще одной мисконфигурации на панели входа в 1С злоумышленник может увидеть раскрывающийся список пользователей базы, что упрощает дальнейшее развитие атаки.
- Рекомендация: при добавлении нового пользователя в базу 1С по умолчанию выставляется флаг «Показывать в списке выбора». Этот флаг необходимо снимать — тогда пользователь не будет отображаться в раскрывающемся списке на панели входа. Проверить эту настройку можно через режим «Конфигуратор» в разделе «Администрирование» -> «Пользователи».
Парольная аутентификация
Чтобы подключиться к информационной базе, необходимо указать имя пользователя и пароль. В большинстве инцидентов, которые мы расследовали, злоумышленники с легкостью находили возможность подключения к базам, не зная пароля от учетной записи. Нам известны две мисконфигурации, позволяющие подключаться к базе без пароля, которыми активно пользуются злоумышленники.
Вариант 1. Для пользователя настроена аутентификация средствами 1С, однако при создании учетной записи поле Password было оставлено пустым. В результате вход в систему для этого пользователя будет осуществляться с пустым паролем, то есть без ввода пароля вообще. В свойствах пользователя это выглядит следующим образом:
Вариант 2. Для пользователя настроена доменная аутентификация. Однако по умолчанию при создании пользователя устанавливается флаг, включающий аутентификацию средствами 1С с пустым полем Password. Соответственно, для такой учетной записи будет доступно два варианта аутентификации: с доменной учетной записью и средствами 1С с пустым паролем. Далее представлены свойства пользователя с описанной мисконфигурацией:
- Рекомендация: важно разработать эффективную парольную политику и обеспечить ее соблюдение. Базовые требования к паролям можно задать при помощи штатных средств 1С.
Установите флаг «Проверка сложности паролей пользователей» в разделе «Администрирование» -> «Параметры информационной базы». Этот параметр устанавливает ряд требований к паролям. Длина должна быть не менее семи символов; пароль должен содержать не менее трех типов символов из следующего списка: заглавные буквы, строчные буквы, цифры, специальные символы; пароль не должен совпадать с именем для входа. Такой флаг как минимум позволит избежать установки пустых паролей для новых пользователей. Мы рекомендуем включать эту настройку сразу после установки программного обеспечения 1С, чтобы избежать появления в информационной базе учетных записей с пустым паролем (например, тестовых). Если установить флаг «Проверка сложности паролей пользователей» позднее, стоит произвести ревизию имеющихся учетных записей и установить надежный пароль для тех пользователей, у кого он отсутствует.
Необходимо также подчеркнуть, что само по себе наличие пароля не является надежным средством защиты от несанкционированного доступа. Так, использование простых паролей представляет собой потенциальную угрозу брутфорс-атаки, то есть перебора паролей злоумышленником в поисках пользователя с легко угадываемым паролем. Иногда в исследованных нами инцидентах активность злоумышленника попадала в поле зрения DLP-системы: судя по ее данным, злоумышленник явно пытался вручную перебирать простые и короткие пароли.
- Рекомендация: задайте значения для полей «Максимальное количество неуспешных попыток аутентификации» и «Длительность блокировки при превышении количества неуспешных попыток аутентификации» в разделе «Администрирование» -> «Параметры информационной базы». Например, можно задать их следующим образом: не более пяти неуспешных попыток аутентификации и 1 минута блокировки при превышении этого количества. Выбор таких значений значительно снизит риски брутфорс-атаки.
Избыточные привилегии
Одной из самых надежных практик в области информационной безопасности является принцип наименьших привилегий, и настройка серверов 1С не является исключением.
К примеру, зачастую рядовому бухгалтеру не требуются права администратора базы. Стоит отметить, что в ходе расследований нам встречались скомпрометированные информационные базы, где до 96% пользователей имели права администратора. Администратор базы имеет право на управление пользователями и их ролями, а значит, в случае компрометации такой учетной записи злоумышленник сможет выдать себе недостающие права и внести изменения, необходимые для развития атаки.
- Рекомендация: выдавайте права пользователям, руководствуясь принципом наименьших привилегий. Права администратора базы необходимо выдавать только администратору.
Вредоносные внешние обработки
Внешние обработки — это бинарные файлы с расширением .epf, содержащие код на языке 1С. В общем случае они легитимны и предназначены для расширения функциональности конфигурации 1С без изменения ее структуры. Однако злоумышленники пользуются вредоносными внешними обработками, так называемыми 1С-шеллами, которые позволяют выполнять сторонний код на сервере с программным обеспечением 1С.
Атакующие запускают 1С-шеллы после получения доступа к информационной базе. Некоторые внешние обработки, которые мы находили в ходе расследования инцидентов, доступны для скачивания на GitHub уже более двух лет.
Например, злоумышленники часто используют внешнюю обработку, позволяющую выполнять команды на сервере, вызывать функции VBScript, читать файлы, делать SQL-запросы и т. д.
Встречаются и более простые варианты, которые позволяют выполнять команды на сервере:
Если запустить команду на сервере 1С через внешнюю обработку, она будет выполняться от имени учетной записи, от которой запущены службы 1С на сервере. Если для работы служб 1С используется доменная учетная запись, добавленная в группу доменных администраторов, компрометация такой учетной записи может обернуться серьезными последствиями для инфраструктуры, хотя отметим, что подобные случаи возникают крайне редко. Наиболее часто в инцидентах, которые мы расследуем, для работы служб 1С используются учетные записи с правами локальных администраторов или доменные учетные записи с привилегиями, которые позволяют быстро получить права локального администратора, что способствует быстрому развитию атаки.
Примером реализации атаки с использованием вредоносной внешней обработки является создание запланированной задачи на запуск вредоносной нагрузки.
Эта команда создает в планировщике Windows задачу MalwareTask, которая каждые три минуты запускает malware.exe с максимальными правами и автоматически восстанавливается, если ранее была удалена.
В Kaspersky Endpoint Detection and Response Expert эта активность детектируется следующими правилами:
- interpreter_process_spawned_by_1c_app отслеживает сеанс интерпретатора, созданный приложением 1С;
- scheduled_task_creation_via_schtasks отслеживает создание запланированной задачи;
- using_schtasks_to_create_minute_task отслеживает создание задачи планировщика, выполняющейся с периодичностью в минутах.
- Рекомендация: следуйте принципу наименьших привилегий. То есть при создании учетных записей право «Интерактивное открытие внешних отчетов и обработок», позволяющее работать с обработками, важно выдавать только тем пользователям, кому это действительно необходимо. Альтернативное решение — вовсе отказаться от использования обработок.
- Рекомендация: настройте профиль безопасности, в соответствии с которым процессы кластера серверов будут работать в контексте пользователей операционной системы с минимально необходимыми привилегиями.
Как настроить журналы регистрации
В ходе проведения расследований нам часто приходится сталкиваться с ситуациями, где единственным местом поиска следов активности злоумышленника оказываются именно журналы регистрации 1С. Однако в некоторых случаях запись событий в такие журналы была отключена задолго до инцидента либо фиксировался минимальный объем событий.
Важно правильно настроить журналы регистрации. Средства 1С позволяют настроить уровень детализации событий, отображаемых в журналах: можно регистрировать не только ошибки и предупреждения, но также и общую информацию в различных комбинациях. С точки зрения расследования наиболее полезным оказывается максимально подробное логирование. Его можно включить в режиме «Конфигуратор».
Также хорошей практикой является разделение журналов регистрации по периодам. В зависимости от размера базы события можно группировать с различной частотой: каждый час, день, неделю и т. д., что в случае возникновения инцидента значительно облегчит анализ действий в информационной базе и оптимизирует работу с журналами регистрации.
Наконец, последним параметром оптимального логирования является период хранения журналов регистрации. Мы рекомендуем сохранять журналы за последние 6–12 месяцев: в большинстве случаев этого периода хватит на случай расследования инцидента. Более старые записи в журнале можно удалять. Тем не менее удаляемые события стоит записывать в отдельный файл, из которого в случае необходимости их можно восстановить. Это позволяют сделать штатные средства 1С.
Заключение
По нашим данным, продукты 1С применяют более 1 600 000 организаций. На российском рынке ERP-решений доля 1С превышает 85%. Ожидается, что эти цифры будут только расти. Таким образом, отсутствие пристального внимания к настройке программного обеспечения 1С может иметь непоправимые последствия.
Как мы отмечали ранее, мисконфигурации серверов 1С способны привести к проникновению атакующих во внутреннюю инфраструктуру или повышению привилегий. Имена информационных баз и учетных записей могут с легкостью оказаться известными, а инциденты с пустыми паролями говорят о необходимости повсеместного внедрения строгой парольной политики.
Используя вышеописанные мисконфигурации в программном обеспечении 1С, злоумышленники переходят к дальнейшему развитию атаки. В большинстве расследуемых нами инцидентов такие атаки наносили серьезный ущерб целевой инфраструктуре: они завершались шифрованием данных, удалением виртуальных машин и пр.
Для защиты серверов 1С мы настоятельно рекомендуем уделять пристальное внимание настройке параметров безопасности, разграничению доступа и повышению уровня киберграмотности сотрудников. Кроме того, стоит обеспечивать максимально возможное логирование на случай непредвиденных обстоятельств.
На серверах с программным обеспечением 1С важно обращать внимание на любые срабатывания защитных решений. Продукты «Лаборатории Касперского» обнаруживают и блокируют попытки вредоносной эксплуатации 1С при помощи компонента Behavior Detection с вердиктом PDM:Exploit.Win32.Generic. Кроме того, наши решения детектируют различные вредоносные внешние обработки, доступные на GitHub, со следующими вердиктами:
- Backdoor.Script.1CShell.*;
- HackTool.Script.1CShell.*;
- Trojan.Multi.Agent.y.
















По следам реальных атак: как можно было избежать компрометации 1C