1С Inside. Теория: Дырки в 1C

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

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

Таковой информацией, например, являются данные работы бухгалтерии. Но удовлетворяют ли современные программы автоматизации бухгалтерского учета предЪявляемым требованиям конфиденциальности? Исследования показывают, что, по крайней мере, не все.

Скажем популярная система 1С: Предприятие 1С версии 7.7 для SQL не только с легкостью предоставляет доступ к работе всем желающим, но и с ее помощью даже можно получить права администратора БД на SQL сервере, на котором располагается база 1С. Как? Об этом позже. А для начала давайте рассмотрим предпосылки, которые приведут нас к таким выводам.

  1. Вся информация о пользователях 1С хранится в локальных файлах на компьютерах пользователей (а не на сервере, как должно быть в нормальных клиент - серверных системах). Конкретнее, эта информация хранится в файле :userdefusers.user
  2. Информация о связи SQL-Сервером (ConnectionString) также хранится локально - в файле 1cv7.dba. Причем, там хранится ConnectionString не абы-какого пользователя, а администратора и owner-а (владельца) БД!
  3. ConnectionString шифруется на основании информации из файла users.usr, а именно с помощью зашифрованного пароля первого заведенного в 1С пользователя. От имени этого пользователя зашифрованная информация из ConnectionString никак не зависит, т.к. зашифрованные пароли пользователей 1С не зависят от имени этих самых пользователей. Алгоритм шифрования паролей стандартный - MD5.

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

  1. Запускаем 1С из-под отладчика (я, например, пользовался MS VC++6.0 :). Вводим произвольное имя пользователя, любой пароль, получаем сообщение об отказе в доступе. Прерываем выполнение. "Разматываем" стек до адресов основного модуля и выше по тексту ищем место в программе, с которого, после сравнения введенного пароля, закодированного с помощью MD5, с имеющимся паролем в файле users.usr, идет переход на вывод сообщения. Такое место есть :)! Теперь меняем команду условного перехода jxx : на jmp - готово! Теперь мы можем зайти под любым зарегистрированным именем пользователя (выбираем первое попавшееся на глаза имя пользователя из файла users.usr - благо они не шифруются :) и под любым паролем!
  2. Совсем просто - отлавливаем вызов соответствующей API-ой функции установления связи с SQL-сервером и смотрим передаваемые ей параметры :).

Автор: Vik

Комментарии

8
  • Хранитель_врат
    Автор претендую на описания дырок защиты 1С на самом деле мало чего знает. На несанкционированный вход в 1С нет необходимости использовать отладчик. Все делается гораздо проще, просто знать надо 1С.
  • Хранитель_врат
    Согласен с мнениями предыдущих анонимусов - в нете уже давно валяется программы с исходниками для расщелкивания 1cv7.dba, причем на разных языках (мне попадались на С, 1С).