Пароль СУБД из 1CV8Clst.lst достать нельзя? Можно. Проверьте свой кластер 1С
Начну с истории, потому что из неё вырос и вывод, и инструмент.
Прихожу в компанию. За месяц до меня собственник в один день распустил весь ИТ-отдел — целиком, без замены и без передачи дел. Инфраструктура работает, пользователи что-то делают, а документации ноль. Разбираюсь по ходу. И упираюсь в стену: нужно зайти на SQL Server, а пароля нет. Те, что нашлись в старых файлах и заметках, не подходят — их, видимо, меняли. Спросить не у кого.
Ситуация абсурдная: это моя инфраструктура, я за неё теперь отвечаю, а доступа к собственной СУБД у меня нет. И тут возникает мысль, с которой всё и началось: постойте, а как система вообще работает прямо сейчас, если пароль от SQL не знает никто? Значит, кластер 1С его где-то хранит — и хранит так, что умеет им пользоваться. А раз умеет пользоваться, значит, хранит обратимо.
Где лежит пароль
Пароль пользователя СУБД для каждой базы кластер держит в файле 1CV8Clst.lst — обычно это …\srvinfo\reg_XXXX\1CV8Clst.lst на сервере 1С. Открываем в блокноте и видим примерно такое (данные вымышленные):
{7732df89-…,"Base01","Base01","MSSQLServer","Server1C","DB01","1cuser",
"<пароль пользователя СУБД, base64, AES-128>",
"DB=DB01;DBMS=MSSQLServer;DBSrvr=Server1C;DBUID=1cuser;…"}
Разбираем строку по полям: сервер СУБД (Server1C), имя базы на сервере (DB01), пользователь СУБД открытым текстом (1cuser), затем длинная строка в base64 — это и есть зашифрованный пароль, — и следом строка подключения, где всё то же продублировано параметрами.
Логин виден сразу. Осталось разобраться с паролем.
Заодно в этом же файле лежит список всех баз кластера, адреса серверов СУБД и — отдельным блоком — зашифрованный пароль администратора кластера (тот самый, про который на форумах обычно и пишут «не расшифровать»). Нас сейчас интересует не он, а пароль пользователя СУБД: именно он даёт прямой вход в SQL Server в обход всех прав и ролей 1С.
«Расшифровать нельзя» — но можно
Первое, что находишь по теме на форумах: «пароль СУБД в 1CV8Clst.lst зашифрован AES-128, соль и ключ неизвестны, расшифровать нельзя». И это отчасти правда — про пароль администратора кластера написано много и подробно, а вот про пароль пользователя СУБД обычно ставят точку: не достать.
На деле достать можно. Пароль пользователя СУБД зашифрован AES-128-CBC с фиксированным ключом и вектором инициализации, зашитыми в саму платформу 1С. Это не «секрет, который я взломал»: ключ один и тот же для всех установок платформы, он давно известен. Разница в том, что публичные разборы почти всегда останавливаются на пароле администратора кластера, а до пароля пользователя СУБД — того, что даёт прямой вход в SQL Server, — доходят редко, потому и живёт миф «не достать». Само шифрование здесь — не защита от того, кто добрался до файла, а способ платформы не держать пароль совсем уж голым текстом рядом с логином.
Расшифрованный блок внутри выглядит как <случайный префикс>,"<пароль>" — пароль лежит в первых кавычках. В моём случае из того самого файла вышло ровно то, что было нужно, и доступ к своей инфраструктуре я вернул за пять минут.
Почему пароль хранится обратимо — и почему это не «поправят в релизе»
Резонный вопрос: зачем платформа вообще держит пароль в извлекаемом виде, а не хеширует его, как поступают с паролями пользователей 1С? Ответ — в архитектуре. Рабочий процесс сервера (rphost) поднимается сам, без человека за клавиатурой, и должен подключиться к SQL Server самостоятельно — под тем логином и паролем, что заданы для базы. Хеш здесь не годится: хешем нельзя пройти аутентификацию на стороне СУБД, серверу нужен именно пароль в открытом виде. Значит, платформе необходимо хранить его так, чтобы уметь восстановить, — отсюда обратимое шифрование, а не хеш.
Это не ошибка и не недосмотр, а прямое следствие того, что 1С сама, без участия человека, ходит в чужую систему (SQL Server) по паролю. Поэтому надежда «в следующем релизе исправят» здесь не работает: любой механизм, позволяющий службе подключиться к СУБД без ручного ввода, по определению обратим. Единственная точка, которую вы реально контролируете, — кто имеет доступ к файлу.
А теперь неприятная часть
Обрадовавшись, что задача решена, я тут же поймал вторую мысль, уже неприятную: если это смог я, имея всего лишь доступ к файлу на диске, — это может кто угодно с таким же доступом.
Прикиньте, у кого фактически есть чтение папки srvinfo на типовом сервере 1С:
- администратор домена — почти всегда;
- бэкап-оператор и сама система резервного копирования — папка часто попадает в бэкап целиком;
- любой процесс, работающий под учётной записью службы сервера 1С;
- подрядчик, которого пускали «посмотреть»;
- файловая синхронизация, если сервер случайно попал в общую шару.
Каждый из них при желании достаёт пароли СУБД всех баз кластера — и получает прямой доступ к данным в SQL Server, минуя все права и роли внутри 1С.
А теперь худшая, но очень частая деталь. Обработка достаёт тот логин, под которым 1С ходит в СУБД. И если этот логин — sa (а так настроено сплошь и рядом, «чтобы просто работало»), то прочитавший файл получает не пароль к одной базе 1С, а пароль sa — полный контроль над всем SQL Server: все базы на инстансе, не только 1С, и вдобавок выполнение команд операционной системы через SQL (тот самый xp_cmdshell — по умолчанию он выключен, но sa включает его одной командой). Один файл на диске — и весь сервер баз данных в чужих руках.
Если же 1С подключается под отдельной ограниченной учётной записью — злоумышленник получит доступ только к данным конкретной базы. Тоже плохо, но локально. Вся разница между «утекла одна база» и «утёк весь сервер» — в том, под каким логином настроено подключение.
Как понять, под каким логином ходит именно ваш кластер? Тот же файл это и показывает — поле DBUID в строке подключения (в примере выше это 1cuser). Если там sa или доменная учётка с широкими правами — это первый кандидат на замену. Знакомая история «поставили временно, заработало — не трогаем» превращается в постоянный риск ровно потому, что об этом потом никто не вспоминает.
Что с этим делать
Само шифрование поменять нельзя — это механизм платформы, ключ публичен, и никакие настройки 1С этого не отменяют. Единственная реальная защита — права доступа к файлу и гигиена учётных записей СУБД. Конкретно:
- Ограничьте NTFS-права на
srvinfo. Доступ на чтение — только у учётной записи службы «Агент сервера 1С» и у администраторов сервера. Больше ни у кого. Это закрывает основную массу сценариев утечки. - Проверьте, куда утекает папка. Не попадает ли
srvinfoв открытые бэкапы, файловые синхронизации, сетевые шары. Зашифрованный пароль в бэкапе — тот же незашифрованный. - Отдельная учётка СУБД с минимумом прав. Для каждой базы — своя учётная запись SQL Server с доступом только к этой базе, а не
saи не доменный администратор. Тогда даже извлечённый пароль стоит немного. - Ротация при смене людей. Уволили админа, отпустили подрядчика — смените пароли СУБД и пароль кластера. Тот, кто хоть раз имел доступ к файлу, унёс их с собой навсегда.
Практический минимум по правам — снять с папки srvinfo лишние учётки. Посмотреть, у кого сейчас есть доступ, можно одной командой:
icacls "C:\Program Files\1cv8\srvinfo"
В выдаче не должно быть ни Everyone, ни BUILTIN\Users, ни широких доменных групп — только учётная запись, под которой запущена служба «Агент сервера 1С» (часто это USR1CV8), и администраторы сервера. Всё лишнее — убрать, наследование прав от родительской папки на srvinfo — отключить. Это ровно та мера, которая закрывает основную массу сценариев из списка выше: нет доступа к файлу — нет и пароля.
Как проверить у себя за минуту
Чтобы не делать это руками, я собрал отдельную обработку — аудитор доступности паролей СУБД. Она читает 1CV8Clst.lst и по каждой базе показывает, извлекается пароль или защищён, помечает заведомо слабые (короткие и чисто числовые) и выдаёт тот самый план защиты. Путь к srvinfo подбирает сама — автопоиском по типовым расположениям, вручную вбивать не обязательно. К СУБД она не подключается вообще, ничего не пишет и никуда не отправляет — только читает файл. По умолчанию сами пароли не показывает: виден лишь факт «извлекается / защищено», а открытым текстом пароль появляется только по явному подтверждению — для того самого сценария восстановления своей инфраструктуры. Если хочется просто посмотреть, как выглядит отчёт, не трогая боевой кластер, — внутри есть встроенный демо-пример. Реализована без внешних компонент, AES написан на встроенном языке, так что работает и на Windows, и на Linux-сервере.
Один технический момент, чтобы не было вопросов: файл кластера обработка читает на стороне сервера 1С, поэтому запускать её удобнее всего на самом сервере (или из клиента, подключённого к нему), а путь указывать так, как его видит сервер. Папка srvinfo на сервере и так доступна службе «Агент сервера 1С» — отдельный доступ к машине с рабочего места не нужен.
Частые вопросы
Это вообще законно? Проверять свою инфраструктуру и восстанавливать доступ к своим системам — да. Применять к чужим системам без разрешения владельца — нет. И статья, и обработка — про аудит и восстановление собственного доступа, а не про доступ к чужому.
Поможет ли сменить пароль кластера? Нет. Пароль администратора кластера и пароль пользователя СУБД — разные вещи, и лежат они в файле независимо друг от друга. Речь о втором, и смена первого его не закрывает. Помогают только права на файл и отдельная ограниченная учётная запись СУБД.
А если у меня PostgreSQL, а не MS SQL Server? Механизм тот же: платформа хранит пароль пользователя СУБД так же обратимо, в файле просто указан другой тип СУБД. Сценарий с sa — это специфика MS SQL, но сам факт извлекаемости пароля от типа СУБД не зависит.
Антивирус или EDR это поймает? Ловить нечего: чтение файла с диска, к которому у процесса есть легитимный доступ, — не атака и не эксплойт, сигнатуре тут не за что зацепиться. Именно поэтому защита не в мониторинге, а в правах доступа к файлу.
Обработка — «Аудит доступности паролей СУБД»: за один прогон она показывает по всем базам кластера, где пароль вынимается, и сразу даёт план защиты. Если у вас похожая история или свой способ закрывать этот риск — расскажите в комментариях: тема неудобная, но лучше узнать о ней от своих, чем от чужих.
Другие наши инструменты администратора СУБД:
- Чек-ап СУБД под 1С - правильно ли база стоит на сервере.
- Карта объёмов базы 1С - из чего состоит база.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
