строгий аудит для 1с

NICE

Спецвыпуск: Хакер, номер #066, стр. 066-048-1

ПОЛУЧАЕМ ДОСТУП К БД С МАКСИМАЛЬНЫМИ ПРИВИЛЕГИЯМИ

ЭТА ИСТОРИЯ НАЧАЛАСЬ ОЧЕНЬ ПРОСТО. В ОДИН ПРЕКРАСНЫЙ ДЕНЬ ШЕФ ВЫЗВАЛ МЕНЯ К СЕБЕ И ПОСТАВИЛ ЗАДАЧУ: ПРОВЕСТИ АУДИТ БЕЗОПАСНОСТИ 1С И ПОПЫТАТЬСЯ ПОЛУЧИТЬ ДОСТУП К БАЗЕ ДАННЫХ, ЖЕЛАТЕЛЬНО С МАКСИМАЛЬНЫМИ ПРИВИЛЕГИЯМИ

Мой опыт 1С-ника показывает, что злоумышленники в основном пытаются ломать файл users.usr. Он находится по адресу: каталог_с_базой\usrdef \users.usr и хранит информацию о пользователях и их паролях. Пароли хранятся в виде хэшей: MD5(pass), поэтому просмотреть пароль просто так не выйдет. Существуют брутфорсеры MD5 (именно для 1С), а также есть возможность скинуть пароли всех пользователей. Однако сброс всех паролей мгновенно вызовет подозрение админов или бухгалтеров. Я протестировал такой брутфорсер и пришел к выводу, что числовые пароли взламываются очень быстро, но достаточно подключить символы и ограничить длину 8-10 символами — и уже становится невесело, так как дело попахивает долгими часами перебора. Ты скажешь: «Да бухгалтеры для пароля всегда свой год рождения пишут!» В чем-то правильно, но… Последние тенденции в корпорациях и даже мелком бизнесе показывают стремление защитить информацию (данные о клиентах, поставщиках, оборотах предприятия) от кражи и от глаз весьма заинтересованных конкурентов. В борьбе за сохранность данных создаются службы безопасности, вводятся административные меры наказания, минимальные требования к длине пароля и т.п. К примеру, в фирме, где работал я, мы сами задавали пароли и ставили вот такие условия:

Длина = восемь символов

Цифры + буквы + одна заглавная в английской раскладке.

[для промежуточного вывода] могу сказать, что атака на users.usr имеет несколько недостатков:

1 ПОДБОР ПАРОЛЯ ПЕРЕБОРОМ НЕ ВСЕГДА ОСУЩЕСТВИМ В КОРОТКИЕ СРОКИ, ОСОБЕННО ЕСЛИ ОСТАЛОСЬ РАБОТАТЬ ДВЕ НЕДЕЛИ :).

2 ВРЯД ЛИ ПОЛУЧИТСЯ УДАЛИТЬ ФАЙЛ. ЛЮБОЙ НОРМАЛЬНЫЙ АДМИН ПОСТАВИТ НА ЭТОТ ФАЙЛ АТРИБУТ READONLY (ТОЛЬКО ДЛЯ ЧТЕНИЯ). И ЕСТЕСТВЕННО, ПОДМЕНИТЬ ХЭШ-СУММУ ТОЖЕ НЕ ПОЛУЧИТСЯ.

Ну что ж, придется поступить хитрым образом. Учитывая свой опыт реверсера, я решил поковыряться в 1CV7s.exe (25-й релиз). Как выяснилось, не зря. Буква S в конце имени файла указывает на SQL-версию, локальную и сетевую. Мой выбор пал именно на нее, одну из самых распространенных, неслучайно: она превосходно работает на Терминале, поддерживает как DBF, так и SQL-базы, освобождает от головной боли насчет электронных ключей (кто видел голубые экраны при установке эмуляторов хаспов, тот поймет).

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

Запускаем отладчик (я использовал OllyDbg), в списке выбираем нужную базу и пытаемся авторизоваться как «Админ» (рис. 1). Получаем сообщение об ошибке (рис. 2.).