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

Если вам больше по душе видео формат, то вот видеоверсия этой статьи:

Ну а любителям текста добро пожаловать под кат. 

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

• Как правило у нас есть какой-то большой сервер, на котором крутятся продуктивные базы 1С.

• Есть главная база, предположим 1С:ERP, в которой ведется основной учет.

• Есть какие-то Бухгалтерии, для ведения учета в организациях холдинга, не занимающихся основной деятельностью.

• Есть конечно же "Зарплата и управление персоналом" (далее ЗУП), куда ж без него, еще какие-то базы.

• Пусть также имеется отдельный сервер для разработки и тестирования. Здесь расположены тестовые и разработочные базы.

• Есть еще другие сервера под различные задачи.

• Кроме того, есть отдельные терминальные сервера, на которых работают пользователи.

Для простоты будем считать, что сервера СУБД совмещены с кластером серверов 1С. Ну и все это, конечно же, расположено в одном домене.

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

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

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

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

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

Перезаходим в базу и… Видим, что набор прав не поменялся. Дело в том, что на последних версиях платформы в тонком клиенте по умолчанию внешние обработки запускаются в режиме защиты от опасных действий, а установка прав считается как раз таким опасным действием.

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

Заходим в базу в режиме обычных форм. Также открываем консоль кода, повторяем фокус и на этот раз он удается.

Перезаходим в базу и обнаруживаем, что у нас появились полные права.

Через конфигуратор или через ту же консоль кода снимаем у пользователя флаг «Защита от опасных действий» и далее мы можем делать в базе уже что хотим.

Итак, полные права в копии базы ЗУП мы получили.

Выводы:

Первое, конечно же, это

Необходимо категорически запретить использование внешних обработок.

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

Можно использовать БСП-ушную подсистему внешних отчетов и обработок, но лично я рекомендую, если включен режим редактирования конфигурации (а он как правило включен), встраивать все отчеты и обработки прямо в конфигурацию. На сложность обновления это не влияет, но сразу же проблемы версионирования и параллельной разработки решаются посредством хранилища. Можно настраивать права доступа. Их удобно переносить между базами и т. д.

Второй вывод, заключается в том, что

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

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

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

Но мы нашли только имя пользователя. Где же взять пароль? Чтобы ответить на этот вопрос, давайте вспомним, как 1С хранит пароли пользователей:

1. При установке пароля происходит вычисление хеш-значения введенного пароля – вы ввели пароль, 1С посчитала хэш.

2. Вычисление хеш-функции производится по алгоритму SHA-1 – алгоритм хороший, надежный, известный.

3. Зная хеш-функцию, невозможно назад восстановить прежний пароль. По крайней мере, это очень сложно сделать.

4. Дальше все это еще дополнительно оборачивается в base64. И то, что получилось (обернутый хеш) хранится в самой базе данных в поле «СохраняемоеЗначениеПароля».

Нормальная и безопасная схема. Когда пользователь авторизуется, все это повторяется, хеш-функция по SHA-1 оборачивается в base64 и сравнивается – соответствует то, что получилось, тому что хранится в базе или нет. Если равно, то пользователь авторизируется.

Да, мы можем получить сохраняемое значение пароля, и преобразовав его из BASE64 получить и саму хеш-сумму.

Но по хеш-сумме нельзя получить изначальное значение. И это действительно так. Но дело в том, что в интернете есть базы уже рассчитанных хеш-сумм для наиболее вероятных значений, используемых в качестве паролей. Например, первый же сайт из поисковой выдачи яндекса предлагает доступ к базе с почти 5 триллионами (!) различных значений хеш-сумм, всего за 20 центов за расшифровку одного хеша, в самом дорогом тарифе.

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

Поэтому пароль Марии Ивановны без проблем поддается расшифровке. Очень похоже, что это день рождения ее ребенка. Подходит по дате. И правильно, какой еще может быть пароль и среднестатистического бухгалтера? Особенно, если вы при создании нового пользователя устанавливаете флаг «Потребовать установку пароля при входе». То что-то подобное, скорее всего, пользователь и задаст.

Ну и кроме того, не надо забывать и о том, для 1С существуют и программы по перебору паролей. Перебор паролей можно делать и по протоколу ТСР и по http. Ссылки специально приводить не буду, но знайте, что такие программы есть, более того они есть даже в открытом доступе. И есть словари для перебора, скажем так, адаптированные под русских пользователей.

Выводы:

Кажется, что правильным здесь будет правило «Использовать сложные пароли в 1С».Но вспоминаем про имеющиеся базы хеш-сумм и фиксируем правило:

Использовать доменную авторизацию.

Считается, что учетные записи Windows невозможно взломать, поэтому все вопросы безопасности мы отдаем на сторону контроллера домена.

Итак, пароль главного бухгалтера у нас есть. Далее берем какой-нибудь портабельный сканер портов и начинаем сканировать сеть, смотрим, что и где открыто. В частности, нас интересуют порты 1540, 2540 и т. д. То есть мы ищем агента сервера. Находим всех агентов 1С. Как правило, они не закрыты. Далее оглядываемся вокруг, находим на терминальном сервере консоль администрирования серверов 1С, подключаемся к найденным серверам и получаем список всех имеющихся в организации информационных баз 1С.

Ну а далее пробуем зайти во все найденные базы используя полученные в ЗУПе учетные данные. Таким образом, мы заходим в боевую базу ЗУП, в Бухгалтерии. Ну а в базу ERP, предположим, мы доступа не получили. Пусть это был не главный бухгалтер, а бухгалтер по зарплате.

Выводы:

Ну, стоит сказать, что наличие консоли администрирования серверов 1С на терминальном сервере не является такой уж большой уязвимостью. Открытые порты тоже. К кластеру серверов можно подключится и через COM, и через утилиту rac, если используется сервер администрирования кластера серверов. Вывод здесь другой:

Нужно всегда определять администраторов кластеров 1С.

Как только вы добавили администратора кластера, несанкционированное подключение к агенту сервера как и добавление новых баз будет невозможно.

Ну и раз уж мы затронули тему СОМ, то если уж вы задействуете COMConnector, то обязательно настраиваете права на его использование. Ниже показан скриншот неправильной настройки. Все пользователи могут использовать компоненту.

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

Поэтому добавим еще одно правило:

Ограничивайте доступ к COMConnector.

Настраивайте COM только тем в домене, кто его реально использует, в ком вы уверены. И выдавайте права только по распоряжению руководства. А лучше вообще от COM отказаться, а перейти на веб или HTTP-сервисы. Но я понимаю, что иногда бывает производственная необходимость использовать именно COM.

Ну а далее мы собираем все логины / пароли, которые удается расшифровать также и в новых базах. Исследуем их, ищем сохраненные пароли в базе данных, в регистрах, справочниках и даже в коде. Например, получаем данные к настроенным учетным записям почты.

Кроме этого, часто бывает, что достаточно зайти в конфигуратор, поискать пароли в коде конфигурации. Это, конечно, смешно, но до сих пор очень много где встречается. Кто-то говорит: «Так исторически сложилось», а кто-то: «А что такого?». В БСП есть такая штука как «Безопасное хранилище паролей», где пароль нельзя извлечь, потому что часть хэша пароля хранится на клиенте. Но будем честны – разработчики не хотят разбираться, как это работает, просто закрывают пароль звездочками и считают, что он защищен. Но вы же знаете, что звездочки – это просто включенный режим пароля для поля ввода, а в базе данных лежит сам пароль.

Выполняя таким образом поиски находим, что база Бухгалтерия обменивается с базой ERP. И обмен происходит через веб-сервис и под конкретным пользователем. Поскольку обмен происходит через веб-сервис, то в данном случае не подходит доменная авторизация. Это, кстати, очень большой недостаток той же интеграции с 1С:Документооборот, т. к. нельзя авторизоваться в базе через веб-сервис пользователю с доменной авторизацией, потому как подключение происходит на сервере, а значит происходит оно под пользователем Windows, под которым запущен агент сервера 1С. Так что использовать авторизацию по паролю все же иногда приходится. Но а в данном конкретном случае мало того, что пароль оказался не очень сложным – его получилось определить, так еще и пользователь был с полными правами.

Таким образом мы получили полный доступ и в базу 1С:ERP.

Выводы:

Так как использовать авторизацию по паролю иногда все же приходится, то вместо правила «Использовать сложные пароли в 1С» добавляем

Использовать действительно сложные пароли в 1С, если невозможна доменная авторизация.

Для защиты себя, можете выставить примерно такие настройки в параметрах информационной базы.

Также, если пользователь вне домена, настройте для него двухфакторную авторизацию с подтверждением по СМС, 1С это умеет.

Так, но давайте предположим, что база 1С:ERP нам не поддалась и в этот раз. Где еще можно поискать данные для авторизации? Следующим объектом изучения будет тестовый сервер. Доступ у нас есть только на терминальный сервер. Но попробуем исследовать его через сам сервер 1С.

Для этого в консоли кода выполняя код на сервере, получаем списки файлов на диске. Например при помощи метода «НайтиФайлы». При настройках по умолчанию, сам сервер 1С дает нам это сделать. При необходимости можно написать полноценный менеджер файлов для сервера 1С. Более того, таким образом можно и передавать файлы на сервер и даже запускать нужные файлы на выполнение!

Но в данном случае этого не понадобилось. Разработчики в этой организации руками базы не обновляют, а используют специальные скрипты для деплоя. Внимание привлекла папка С:\Deploy, в которой обнаружились различные скрипты, в частности был скрипт для обновления продуктивной базы - deploy_work. В коде этого скрипта в явном виде обнаружился логин и пароль к базе данных – ему же нужно как-то обновлять боевую базу. Пусть не в скрипте, а рядом, в JSON-файлике с настройками.

Таким же образом можно проанализировать и продуктивный сервер. Рано и или поздно необходимые учетные данные все же будут найдены и мы получим полный доступ и в базу 1С:ERP.

Выводы:

Необходимо настроить профиль безопасности кластера серверов 1С.

Правда профили безопасности доступны только в КОРП функционале. Но и с обычной платформой можно ограничить каталог «видимости» сервера 1С. Читайте ИТС, также в этом мастер-классе от Антона Дорошкевича подробно разбирается данный вопрос безопасности.

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

Выводы:

Не стоит хранить пароли в открытом виде.

Очевидный, казалось бы, но часто игнорируемый совет. Если вы все же используете различные скрипты, содержащие пароли, то не поленитесь строго настроить права на каталоги, где могут быть доступны учетные данные. Дайте права на чтение и выполнение только тем сотрудникам, которые будут их выполнять. Как вариант, можно конвертировать скрипты в ехе.

А если вы пускаете к себе внешних сотрудников, то желательно

Сделать отдельный терминальный доступ, изолированный от основной сети и домена.

Ну и это еще не все. Пусть на сервере 1С обнаружилась еще одна очень важная и очень секретная база. И никакими полученными раннее данными не удалось в ней авторизоваться. Пусть это будет какая-нибудь база по стратегическим планам развития компании, или там, по откатам партнерам, или еще с чем-нибудь, и туда имеет доступ только высшее руководство. Здесь можно отметить, что высшее руководство часто это первая группа нарушителей безопасности. Как правило, у них почему-то простые пароли, и им иногда бывает сложно навязать политику безопасности паролей. Но будем считать, что здесь с этим все нормально, пароль директора мы не знаем – стучимся в эту базу, не можем попасть. Что можно сделать?

Заходим в свойства любой другой информационной базы в консоли администрирования серверов и видим следующее:

Во первых видно, что в качестве СУБД используется MS SQL Server. Запомним это. Далее, видно, что авторизация на сервере происходит под отдельным специальным пользователе, имя которого мы теперь знаем. Вопрос в том, где достать пароль от этого пользователя.

Ну, к тому времени, мы должны были накопить уже достаточную базу логинов/паролей в этой организации. Пробуем все известные пароли. И с большой вероятностью, один из них подойдет. В частности, при анализе базы ERP, был найден пользователь с именем admin, пароль которого удалось расшифровать. Этот же пароль совершенно невообразимым образом подошел и для пользователя SQL.

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

Но представим, что подобрать пароль к пользователю SQL не удалось. Отмечу, что в файле списка кластера тоже лежит хеш этого пароля. К самому файлу 1CV8Clst.lst, к сожалению, у нас по умолчанию есть доступ через сам сервер 1С.

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

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

Ну а дальше через ODBC-драйвер мы подключаемся к SQL-серверу. Может и Management Studio где найдется. И одним простым скриптом:

1. Создаем новую базу на сервере.

2. Разворачиваем в нее копию той самой секретной базы.

3. Очищаем таблицу v8users.

4. И удаляем определенную строку в таблице Params.

Все учетные данные 1С хранит в этих двух таблицах.

Теперь беспрепятственно входим в базу.

Если у пользователя нет прав создавать новые базы данных на сервере SQL, то все это можно проделать ночью прямо в боевой базе, не забыв вернуть все потом назад.

Вот таким образом, мы получили доступ ко всем 1С-ным базам в организации, помимо этого хакнули еще и сервер SQL, набрали приличную базу паролей и кто знает, до каких еще данных мы смогли бы дотянуться?

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

Выводы:

Не используйте одинаковые пароли.

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

Ну а как защититься от дешифровки пароля из файла с настройками кластера? Первое, что приходит на ум, это использовать доменную авторизацию с сервера 1С на MS SQL Server. В этом случае в файле будет храниться пустое значение. Но тут же появляется другая дыра в безопасности. Если есть доступ к внешним обработкам, а у полных прав, как мы увидели, он есть всегда, то появляется возможность с сервера подключиться к MS SQL через ODODB и, в общем-то, выполнить любой SQL-запрос.

Поэтому рекомендация у нас обратная:

НЕ использовать доменную авторизацию между сервером 1С и MS SQL Server.

И добавляем правило:

Ограничить доступ к файлу 1CV8Clst.lst.

Инструкция, как это сделать есть на ИТС и в книге «Руководство администратора клиент-серверный вариант». Коротко скажу, что делается это с помощью специально подготовленного файла swpuser.ini.

Ну и последнее. Не думайте, что ваши данные никому не нужны, что вас никто не хакнет и вообще это не про вас.

Думайте о безопасности, даже когда просто разворачивайте новую базу 1С.

У меня все! Спасибо, кто дочитал до конца. Еще раз список всех рекомендаций ниже:

1. Запретить использование внешних обработок (и не использовать их в работе).

2. Запретить все виды соединений кроме Тонкого клиента и/или Web-клиента.

3. Использовать доменную авторизацию.

4. Использовать действительно сложные пароли в 1С, если невозможна доменная авторизация.

5. Определить администраторов кластера серверов 1С.

6. Ограничить доступ к V83.COMConnector.

7. Настроить профиль безопасности кластера серверов 1С.

8. Не хранить пароли в открытом виде.

9. Настраивать права на критичные каталоги.

10. Изолировать внешних пользователей от основной сети.

11. Не использовать одинаковые пароли.

12. НЕ использовать доменную авторизацию сервера 1С на MS SQL Server.

13. Ограничить доступ к файлу 1CV8Clst.lst (swpuser.ini).

14. Думать о безопасности.