Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | |
О грамотности такого подхода думаю не стоит дисскусию... 20.06.05 14:24 Число просмотров: 1807
Автор: TARASA <Taras L. Stadnik> Статус: Member
|
> Во-первых 1С никогда особо о безопасности не беспокоилась,
> все что есть - защита от дурака.
О грамотности такого подхода думаю не стоит дисскусию разводить.
> Формат внешних обработок (ert) очень легко вычисляем, он
> никак не шифруется и не сжимается, т.е.
> фактически текстовый. Любой субъект [возможно и процесс],
> который имеет доступ к этому файлу на запись может его
> поправить как угодно, в частности внести туда строки с
> вирусом. Сам вирус написать очень легко свой, а не
> копировать существующий, поэтому по сигнатурам такие вирусы
> найти нельзя!
>
> С другой стороны ert активно используются бухгалтерами для
> отчетности, эти ert поставляются 1С-кой каждый квартал в
> виде поддержки (грубо говоря). И в частности эти самые ert
> пишут в файлы и запускают внешние приложения, поэтому по
> этим действиям отследить вирус нельзя.
Допустим тогда развитие систуации по следующему сценарию:
Не чистый на руку человек (сообщество) пишут некий ert который сливает конфиденциальную информацию средствами копирования, электронной почты ... etc.
Данный отчет распространяется 1С по системе поддержки, распространяется спаммерами, передается из рук в руки ... да малоли каким еще способом "зловредный" документ будет внедрен на компьютер бухгалтера? И это приведет к тому что все пользователи 1С ложатся "к верху пузиком"?
Помоему ситуация тревожная и нужно что-то решать.
Возможные варианты:
Осуществлять контроль целостности получаемых из вне ert или контролировать возможность модификации уже установленного отчета каким либо процессом. Если формат отчета фактически текстовый - то разрешить исполнять только доверенные (подписанные) объекты. Ну или отказатся от использования 1С вообще. Хотя последнее - крайняя мера, но если нет другого разумного выхода, отказ - тоже выход.
|
|
<sysadmin>
|
Демовирус для 1С (ссылка) 17.06.05 10:45
Автор: Deviator <n/a> Статус: Member
|
...Вирус представляет из себя макро-модуль, встроенный в файл-отчет 1C. Способ расположения этого вирусов в файлах-отчетах 1C и его функционирование во многом напоминает макро-вирусы, заражающие документы и таблицы MS Office...
Описание - Virus.1C.Tanga.a
|
|
До поры до времени не содржит деструктивных функций... 17.06.05 16:21
Автор: TARASA <Taras L. Stadnik> Статус: Member
|
> ...Вирус представляет из себя макро-модуль, встроенный в
> файл-отчет 1C. Способ расположения этого вирусов в
> файлах-отчетах 1C и его функционирование во многом
> напоминает макро-вирусы, заражающие документы и таблицы MS
> Office...
До поры до времени не содржит деструктивных функций. Дописать их туда уже дело техники.
Ну а последствия не сложно себе представить, от хищения конфиденциальной информации, до вывода из строя всего, чего можно. Вопрос стоит как быстро среагируют антивирусные компании и насколько часто такие отчеты пересылаются. Или как быстро 1С выпустит патч.
|
| |
А от чего 1С патч будет выпускать? 18.06.05 02:29
Автор: whiletrue <Роман> Статус: Elderman
Отредактировано 18.06.05 02:35 Количество правок: 1
|
Это формат ert-шника надо менять... Патч один: 1С:8.0, да и там есть внешие обработки, у которых тоже формат почти что текстовый...
Кстати, еще добавлю, что в 1С-ке можно не только писать в любые файлы, но запускать любой exe-шник от имени 1С-ки, то есть вирь может перелезть потом куда угодно в каком угодно виде...
Защита: Не запускать левых ert-шников. Или перед запуском тщательно проверить код.
|
| | |
Дисскусия перетекает чисто в теоретическое русло, потому как... 20.06.05 11:49
Автор: TARASA <Taras L. Stadnik> Статус: Member
|
> Защита: Не запускать левых ert-шников. Или перед запуском
> тщательно проверить код.
Дисскусия перетекает чисто в теоретическое русло, потому как специалистом по 1С не являюсь (чему и рад вполне), поэтому могу предположить лишь следующие моменты:
1) не запускать левых ert или проверить код - думаю, что можно все эти проверки реализовать неким механизмом в 1С.
2) если что то и запускается, то запускается в аналоге unix chroot - дабы если "нечто" кудато полезло, то хоть не в систему.
3) отслеживать какое приложение что и куда пытается передать - чтобы не утекла конфиденциальная информация.
Думаю, что все эти моменты программисты из 1С могут решить.
|
| | | |
Re 20.06.05 13:07
Автор: whiletrue <Роман> Статус: Elderman
Отредактировано 20.06.05 13:49 Количество правок: 1
|
> > Защита: Не запускать левых ert-шников. Или перед
> запуском
> > тщательно проверить код.
> Дисскусия перетекает чисто в теоретическое русло, потому
> как специалистом по 1С не являюсь (чему и рад вполне),
Тогда тебе достаточно сложно представить проблему...
Во-первых 1С никогда особо о безопасности не беспокоилась, все что есть - защита от дурака.
Формат внешних обработок (ert) очень легко вычисляем, он никак не шифруется и не сжимается, т.е.
фактически текстовый. Любой субъект [возможно и процесс], который имеет доступ к этому файлу на запись может его поправить как угодно, в частности внести туда строки с вирусом. Сам вирус написать очень легко свой, а не копировать существующий, поэтому по сигнатурам такие вирусы найти нельзя!
С другой стороны ert активно используются бухгалтерами для отчетности, эти ert поставляются 1С-кой каждый квартал в виде поддержки (грубо говоря). И в частности эти самые ert пишут в файлы и запускают внешние приложения, поэтому по этим действиям отследить вирус нельзя.
> поэтому могу предположить лишь следующие моменты:
> 1) не запускать левых ert или проверить код - думаю, что
> можно все эти проверки реализовать неким механизмом в 1С.
В 1С есть своя аутентификация и разрешения на пользование объектами (документами, справочниками), в частности можно, конечно, запретить пользоваться внешними обработками (ert), но, как я говорил - бухам они очень даже нужны.
Даже если 1С сподобится нечто такое эвристическое реализовать - то ЧТО такая проверка будет искать?
> 2) если что то и запускается, то запускается в аналоге unix
> chroot - дабы если "нечто" кудато полезло, то хоть не в
> систему.
Ничего она не проверяет! Запускает грубо говоря cmd и туда пихает все команды. Но это в лучшем случае, а в худшем - просто запускает от своего имени.
Вот теория:
1. Процесс верхнего уровня (1С) полагается на безопасность ОС (Винда), и просто дает ей на выполнение некие команды пользователя
2. ОС втихаря все это и выполняет от имени 1С
Вопрос: а где проверка на корректность команд должна стоять? В 1С - так она, типа, верхний уровень и о функционировании ОС ничего не знает. Во внешнем антивире - так откуда он узнает что надо 1С-ке. А если я захочу некий хитрый функционал реализовать (да хоть просто выгрузку данных на сайт) - такая проверка мне наверняка будет мешать!
Здесь проблема в том, что стоит виртуальная машина (1С) на виртуальной машине (Винда), и политики безопасности у них не согласованы и никто их никогда согласовывать не будет!
> 3) отслеживать какое приложение что и куда пытается
> передать - чтобы не утекла конфиденциальная информация.
> Думаю, что все эти моменты программисты из 1С могут решить.
Пример: Пусть спарвочник "Контрагенты" - конфиденциален, я манагер - мне надо его использовать, программа, которую я использую должна уметь делать выборки по нему, т.е. уметь его читать. С другой стороны любая программа умеет записывать любую выбранную инфу во внешний файл и передавать его по инету... Вот ЧТО здесь искать? Прога может, конечно, слить конфиденциальную инфу, НО, мне, как манагеру, хотелось бы отправить контрагенту по почте прайс-лист (не конфиденциальный)... Действия м.б. в одном случае корректными, а вдругом нет, и нету НИКАКОЙ демаркации между ними. Все равно, что подобную проверку в perl или в компилятор С встраивать...
|
| | | | |
Я тоже не специалист 1С и мне тоже сложно понять 20.06.05 14:46
Автор: Heller <Heller> Статус: Elderman
|
> Формат внешних обработок (ert) очень легко вычисляем, он
> никак не шифруется и не сжимается, т.е.
> фактически текстовый. Любой субъект [возможно и процесс],
> который имеет доступ к этому файлу на запись может его
> поправить как угодно, в частности внести туда строки с
> вирусом. Сам вирус написать очень легко свой, а не
> копировать существующий, поэтому по сигнатурам такие вирусы
> найти нельзя!
>
> С другой стороны ert активно используются бухгалтерами для
> отчетности, эти ert поставляются 1С-кой каждый квартал в
> виде поддержки (грубо говоря). И в частности эти самые ert
> пишут в файлы и запускают внешние приложения, поэтому по
> этим действиям отследить вирус нельзя.
ЗАЧЕМ и ЧТО они пишут в файлы? Зачем они запускают ВНЕШНИЕ приложения? Насколько я понимаю, документ 1С это что-то наподобие документа Excel, максимум из необходимых расширений которого - доступ к некоей внутренней (встроенной в 1С) базе данных. Я просто не вижу смысла разрешать макроязыку 1С запускать что-то стороннее, писать в файлы и тем более отсылать по сети. Если надо что-то кому-то отправить, пускай бухгалтера осваивают электронную почту. Если надо сохранить изменения в файле, пускай бухгалтер осваивает кнопку "сохранить", к которой макроязык не имеет доступа.
Насчёт поставляемых ert в качестве "поддержки". Как я понимаю, это что-то типа обычных апдейтов как самой 1С, так и базы, содержащихся в ней всяких там каталогов ОКОНХ (или как его) и прочее? Так если это обновление самой проги, пускай они это делают экзешником и реализуют это по аналогии с апдейтами от майкрософт. Всегда можно подсунуть пользователю гадость, но это уже проблемы пользователя. Нефиг запускать апдейты, скачанные с не официального сайта, или предоставленные не самой 1С. С тем же успехом пользователь может запустить любой левый exe'шник, не имеющий вообще никакого отношения к 1С, так что защищённость в этом случае не понижается.
Если же нужно просто обновить базу программы, то пускай они это делают по аналогии с reg-файлами в винде. ЗАЧЕМ разрешать им для этих целей писать что угодно куда угодно?
> --skiped--
> В 1С есть своя аутентификация и разрешения на пользование
> объектами (документами, справочниками), в частности можно,
> конечно, запретить пользоваться внешними обработками (ert),
> но, как я говорил - бухам они очень даже нужны.
Опять же, зачем они им нужны? Приведи пример.
> Пример: Пусть спарвочник "Контрагенты" - конфиденциален, я
> манагер - мне надо его использовать, программа, которую я
> использую должна уметь делать выборки по нему, т.е. уметь
> его читать. С другой стороны любая программа умеет
> записывать любую выбранную инфу во внешний файл и
> передавать его по инету... Вот ЧТО здесь искать? Прога
> может, конечно, слить конфиденциальную инфу, НО, мне, как
> манагеру, хотелось бы отправить контрагенту по почте
> прайс-лист (не конфиденциальный)... Действия м.б. в одном
> случае корректными, а вдругом нет, и нету НИКАКОЙ
> демаркации между ними. Все равно, что подобную проверку в
> perl или в компилятор С встраивать...
А управлять уровнем доступа до файла никак? Они могут держать какую-то внутреннюю базу с указанием уровня конфиденциальности конкретных файлов (можно хранить, например, подписи файлов) или использовать для этих целей систему прав доступа ОС и если файл конфеденциален, запрещать руками из самой 1С что-то с ними делать (изменять, копировать и пр.). Конечно, защита не ахти какая, но макровирус конфиденциальных данных уже не утянет.
|
| | | | | |
Ты ошибаешься по всем пунктам :) 1С - далеко не Ексель. Она... 20.06.05 15:58
Автор: whiletrue <Роман> Статус: Elderman
|
> ЗАЧЕМ и ЧТО они пишут в файлы? Зачем они запускают ВНЕШНИЕ
> приложения? Насколько я понимаю, документ 1С это что-то
> наподобие документа Excel, максимум из необходимых
> расширений которого - доступ к некоей внутренней
> (встроенной в 1С) базе данных. Я просто не вижу смысла
> разрешать макроязыку 1С запускать что-то стороннее, писать
> в файлы и тем более отсылать по сети. Если надо что-то
> кому-то отправить, пускай бухгалтера осваивают электронную
> почту. Если надо сохранить изменения в файле, пускай
> бухгалтер осваивает кнопку "сохранить", к которой макроязык
> не имеет доступа.
>
> Насчёт поставляемых ert в качестве "поддержки". Как я
> понимаю, это что-то типа обычных апдейтов как самой 1С, так
> и базы, содержащихся в ней всяких там каталогов ОКОНХ (или
> как его) и прочее? Так если это обновление самой проги,
> пускай они это делают экзешником и реализуют это по
> аналогии с апдейтами от майкрософт. Всегда можно подсунуть
> пользователю гадость, но это уже проблемы пользователя.
> Нефиг запускать апдейты, скачанные с не официального сайта,
> или предоставленные не самой 1С. С тем же успехом
> пользователь может запустить любой левый exe'шник, не
> имеющий вообще никакого отношения к 1С, так что
> защищённость в этом случае не понижается.
Ты ошибаешься по всем пунктам :) 1С - далеко не Ексель. Она скорее Visual Basic. То есть можно сделать все, что угодно, от тетриса до чата... ну и конечно, все задачи учета нужно делать на 1С-ке, а не изобретать велосипед на Вижуал Сях :) Там так же рисуются формы, на них ставятся кнопки, вешаются события... ну и т.д. Т.е. полноценный интерпретатор под винду.
Бухам ежеквартально надо делать отчет в налоговую, эти формы отчетности меняются постоянно, поэтому 1С готовит и поставляет их ежеквартально и именно в виде ert-шников.
Запуск внешней проги: при установке этих форм запускается arj для их распаковки
Запись во внешние файлы: этим формам надо как-то хранить данные...
> Если же нужно просто обновить базу программы, то пускай они
> это делают по аналогии с reg-файлами в винде. ЗАЧЕМ
> разрешать им для этих целей писать что угодно куда угодно?
> А управлять уровнем доступа до файла никак? Они могут
> держать какую-то внутреннюю базу с указанием уровня
> конфиденциальности конкретных файлов (можно хранить,
> например, подписи файлов) или использовать для этих целей
> систему прав доступа ОС и если файл конфеденциален,
> запрещать руками из самой 1С что-то с
> ними делать (изменять, копировать и пр.). Конечно, защита
> не ахти какая, но макровирус конфиденциальных данных уже не
> утянет.
Опять про разные политики безопасности: с точки зрения 1С справочник может быть закрыт, но с точки зрения Винды - доступ к соответсвующему dbf - и на чтение и на запись от данного пользователя, ибо иначе 1С-ка работать не будет!..
Все упирается именно в согласование политик - что гнило, имхо!
|
| | | | |
О грамотности такого подхода думаю не стоит дисскусию... 20.06.05 14:24
Автор: TARASA <Taras L. Stadnik> Статус: Member
|
> Во-первых 1С никогда особо о безопасности не беспокоилась,
> все что есть - защита от дурака.
О грамотности такого подхода думаю не стоит дисскусию разводить.
> Формат внешних обработок (ert) очень легко вычисляем, он
> никак не шифруется и не сжимается, т.е.
> фактически текстовый. Любой субъект [возможно и процесс],
> который имеет доступ к этому файлу на запись может его
> поправить как угодно, в частности внести туда строки с
> вирусом. Сам вирус написать очень легко свой, а не
> копировать существующий, поэтому по сигнатурам такие вирусы
> найти нельзя!
>
> С другой стороны ert активно используются бухгалтерами для
> отчетности, эти ert поставляются 1С-кой каждый квартал в
> виде поддержки (грубо говоря). И в частности эти самые ert
> пишут в файлы и запускают внешние приложения, поэтому по
> этим действиям отследить вирус нельзя.
Допустим тогда развитие систуации по следующему сценарию:
Не чистый на руку человек (сообщество) пишут некий ert который сливает конфиденциальную информацию средствами копирования, электронной почты ... etc.
Данный отчет распространяется 1С по системе поддержки, распространяется спаммерами, передается из рук в руки ... да малоли каким еще способом "зловредный" документ будет внедрен на компьютер бухгалтера? И это приведет к тому что все пользователи 1С ложатся "к верху пузиком"?
Помоему ситуация тревожная и нужно что-то решать.
Возможные варианты:
Осуществлять контроль целостности получаемых из вне ert или контролировать возможность модификации уже установленного отчета каким либо процессом. Если формат отчета фактически текстовый - то разрешить исполнять только доверенные (подписанные) объекты. Ну или отказатся от использования 1С вообще. Хотя последнее - крайняя мера, но если нет другого разумного выхода, отказ - тоже выход.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
