← На главную

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

В этой статье мы подробно разберем, почему возникает такое поведение, заглянем во внутреннее устройство механизмов авторизации платформы, выясним причины избирательного проявления этой проблемы на разных операционных системах (таких как Windows 7 и Windows 10) и предоставим пошаговый алгоритм полного устранения данной уязвимости.

Выясняем первопричину: техническая сторона обхода проверки паролей

Для того чтобы понять, как такое возможно, рассмотрим внутреннюю архитектуру защиты 1С:Предприятие 7.7. В оригинальной платформе за шифрование, хранение, сопоставление хэшей паролей и управление списком пользователей отвечает специализированная библиотека seven.dll (а не BkEnd.dll, как ошибочно полагают некоторые специалисты, хотя последняя также играет важнейшую роль в работе с базой данных и SQL-запросами). Список пользователей и их зашифрованные пароли хранятся в специальном файле users.usr, который находится в подкаталоге usrdef в папке с базой данных.

Существуют сторонние утилиты и патчи (например, небезызвестный патчер seven77n или специализированные скрипты-взломщики), которые модифицируют исполняемый код библиотеки seven.dll в HEX-редакторе. Давайте разберем технический принцип работы такого патча:

1. Поиск сигнатуры проверки: Патч сканирует бинарный файл библиотеки seven.dll на наличие определенной последовательности байт, которая отвечает за функцию сравнения введенного пользователем пароля с хэшем, хранящимся в файле users.usr. В стандартных релизах (25, 26, 27) эта сигнатура представляет собой характерную ассемблерную последовательность, начинающуюся со сравнения регистров.
2. Подмена ассемблерной инструкции: После успешного нахождения сигнатуры патч заменяет инструкцию условного перехода 75 (в архитектуре x86 это инструкция JNZ — переход, если не равно, то есть если пароли не совпали) на безусловный переход или на так называемые «холостые» инструкции NOP (код операции 90, означающий отсутствие действия, или EB 00).
3. Результат модификации: При выполнении этого измененного кода функция проверки пароля всегда возвращает истину (успешное совпадение). Платформа считает, что пользователь ввел абсолютно верный пароль, независимо от того, что именно было введено в поле авторизации. Соответственно, происходит успешный вход в систему с правами выбранного пользователя.

Подобные модифицированные файлы часто распространяются в составе различных «сборок» платформы 1С 7.7, предназначенных для обхода ограничений HASP-ключа или для обеспечения запуска старой платформы на современных операционных системах.

Почему проблема проявляется только на некоторых компьютерах?

Один из главных вопросов, который ставит в тупик администраторов: почему на десяти компьютерах в сети пароли запрашиваются корректно, а на одном или двух — база пускает всех подряд? Кажется, что исполняемые файлы везде одинаковые, но это не так. Проанализируем ключевые системные механизмы современных Windows, которые вызывают этот эффект.

1. Виртуализация файлов UAC (папка VirtualStore)

Начиная с Windows Vista и во всех последующих версиях (Windows 7, 8, 10, 11) включена технология контроля учетных записей (UAC). Если платформа 1С установлена в защищенный системный каталог, например C:\Program Files (x86)\1Cv77\BIN\, операционная система жестко контролирует любые попытки изменения файлов в этой папке. Если администратор или автоматический скрипт-патчер пытается заменить файлы seven.dll или BkEnd.dll без явного повышения прав (запуска от имени Администратора), Windows выполняет незаметную подмену. Она перенаправляет операцию записи в изолированное виртуальное хранилище конкретного пользователя:

%localappdata%\VirtualStore\Program Files (x86)\1Cv77\BIN\

В результате на одном и том же компьютере под учетной записью администратора может запускаться оригинальная, нетронутая версия программы из Program Files (которая честно требует пароль), а под учетной записью обычного пользователя — запущенный экземпляр подхватывает патченную библиотеку из VirtualStore, где проверка паролей отключена.

2. Использование локальных каталогов BIN

В системном администрировании 1С 7.7 частой практикой было копирование папки BIN целиком на локальные диски рабочих станций для повышения быстродействия. Если на компьютерах с Windows 7 Professional была установлена чистая официальная платформа, а на компьютерах с Windows 10 или Windows 7 Ultimate администраторы развернули «быструю» сборку из сетевой папки, содержащую пропатченные файлы, то мы получим именно такое хаотичное поведение. Разница кроется не в версии операционной системы, а в происхождении файлов в локальной папке BIN.

3. Технология DEP (Data Execution Prevention)

Функция предотвращения выполнения данных (DEP) на некоторых редакциях Windows (особенно Ultimate и Enterprise с включенными строгими политиками безопасности) может блокировать динамически модифицируемый в памяти код старых патчей. Это либо приводит к аварийному завершению работы программы, либо заставляет систему использовать оригинальные библиотеки из кэша системных файлов, предотвращая выполнение взломанного кода.

Пошаговое руководство по устранению проблемы и восстановлению безопасности

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

Шаг 1: Замена модифицированных библиотек на оригинальные файлы платформы

Прежде всего, нам необходимо избавиться от взломанных версий исполняемых файлов. Рекомендуется использовать официальный дистрибутив последнего стабильного релиза платформы 1С:Предприятие 7.7 (для большинства конфигураций это релиз 7.70.027).

1. Полностью закройте все запущенные сеансы 1С на проблемном компьютере.
2. Перейдите в каталог установки платформы (по умолчанию это C:\Program Files (x86)\1Cv77\BIN\).
3. Удалите или переименуйте файлы seven.dll, BkEnd.dll и основной исполняемый файл 1cv7.exe.
4. Скопируйте на их место оригинальные файлы из чистого дистрибутива соответствующего релиза. Если у вас нет дистрибутива под рукой, переустановите платформу заново из официального источника.

Шаг 2: Очистка виртуализированных файлов пользователя

Чтобы исключить влияние механизма UAC VirtualStore, обязательно проверьте пользовательские папки на наличие «скрытых» копий библиотек 1С:

1. Откройте проводник и перейдите по пути: %localappdata%\VirtualStore\ (или введите этот путь в строку поиска Windows).
2. Если внутри вы обнаружите ветку папок Program Files (x86)\1Cv77\BIN\, без колебаний удалите всю папку 1Cv77 из виртуального хранилища. Это гарантирует, что операционная система будет использовать только оригинальные файлы из основного системного каталога.

Шаг 3: Настройка прав доступа к каталогу BIN

Чтобы предотвратить повторение подобной ситуации в будущем (когда продвинутый пользователь или вредоносное ПО могут попытаться заменить файлы платформы на патченные версии), необходимо ограничить права доступа к исполняемым файлам 1С на уровне файловой системы NTFS:

1. Нажмите правой кнопкой мыши на папку C:\Program Files (x86)\1Cv77\ и выберите «Свойства».
2. Перейдите на вкладку «Безопасность» и нажмите кнопку «Изменить».
3. Для группы пользователей «Пользователи» (Users) или «Все» (Everyone) установите права только на «Чтение и выполнение» (Read & Execute), «Список содержимого папки» (List folder contents) и «Чтение» (Read).
4. Категорически запретите права на «Запись» (Write) и «Изменение» (Modify). Права на запись должны остаться только у группы «Администраторы» (Administrators) и системы (SYSTEM).

Дополнительная уязвимость: защита файла users.usr

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

Если временно переименовать файл users.usr (например, в users.bak) в каталоге \usrdef\ внутри папки базы данных, то при запуске Конфигуратора система посчитает базу абсолютно новой и откроет её без запроса пароля. После этого файл можно вернуть на место и через открытый Конфигуратор сбросить пароль любого администратора.

Чтобы минимизировать этот риск, администратору необходимо:

• Настроить права NTFS на папку базы данных таким образом, чтобы обычные пользователи имели доступ на запись только к файлам данных (файлы с расширениями .dbf, .cdx, .1s).
• Ограничить доступ к каталогу usrdef, оставив права на изменение файла users.usr только системному администратору или учетной записи, под которой выполняются регламентные задания резервного копирования.

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