Взломать за 60 секунд!

Привет! Меня зовут Дорошкевич Антон. Я руководитель ИТ в компании «ИнфоСофт» из Новосибирска, из далекой Сибири. Сегодня хочу с вами поговорить о безопасности в 1С.

Проблема безопасности в ИТ

За 25 лет, которые существует 1С, все привыкли, что программа 1С – это удобно, красиво, комфортно. А в опытных руках – это даже быстро и надежно. 

Но такой момент, как безопасность, почему-то никто не любит настраивать. Более того, о нем никто не любит даже думать. Такая ситуация не только в мире 1С. Такая ситуация в принципе в ИТ. 

Из-за бурного роста ИТ-сектора все свободные руки программистов и команд вокруг них заняты разработкой новой и развитием текущей функциональности. Всем не до безопасности. Этот момент всегда откладывают, из-за этого технический долг растет лавинообразно. Конечно, технический долг у нас накапливается не только в безопасности. И в последнее время в командах разработчиков 1С хотя бы слышится такое слово – рефакторинг кода. Давайте уберем все костыли, сделаем правильно, код хотя бы быстро заработает. То есть, на оптимальность у нас технический долг хотя бы начинает уменьшаться. Но на безопасность он растет катастрофическими объемами. 

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

Такая ситуация почти везде. Ситуация немного плачевная. И я сейчас хочу вам рассказать, как реально за 60 секунд одним из вариантов взломать базу 1С и получить неограниченный доступ ко всем данным.

3 шага к данным

Когда мы в первый раз провели тестирование на взлом у себя внутри компании, мы удивились, насколько быстро мы смогли сломать, казалось бы, нормально защищенную систему. У нас ушло 15 минут. 

Второе удивление было – каким огромным количеством способов мы смогли это сделать. Вариантов огромное количество. Все не расскажу. Не потому, что жадный, а потому, что времени не хватит. 

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

И кстати – ни разу за все тесты, проведенные нами, ни один антивирус не обнаружил подозрительных действий. Поэтому ставить на сервера приложений и баз данных антивирусы не только вредно для быстродействия системы, но и совершенно бесполезно.

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

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

Что делаем? Всего в три шага, за одну минуту мы ломаем всю 1С-ку. 

• Первым делом мы запускаем внешнюю обработку, написать которую занимает буквально пару минут. Эта обработка умеет делать всего две процедуры: читать файлы на сервере 1С и копировать к себе тот файл, который тебе нужен. Этой обработкой мы копируем к себе файл реестра кластера 1CV8Clst.lst. В этом файле содержится список всех баз 1С на кластере, список всех серверов БД, к которым подключены базы на этом кластере, логины к серверам БД  – все в открытом виде. И зашифрованные пароли к серверам баз данных. Вот по паролям не известны ни алгоритмы, ни соль, с помощью которой все это шифруется. И я надеюсь, что алгоритм шифрования паролей к базам данных – это один из главных секретов разработки платформы в фирме «1С».

• Получили файл, прочитали. Практически всегда в крупном корпоративном секторе оказывается, что все базы подключаются к СУБД «прозрачной авторизацией» из-под пользователя, под которым запущен сам сервер 1С – в 99% случаев мы видим, что для конкретной базы у нас логин сервера СУБД в этом файле пустой. Как ни парадоксально, такое происходит именно по требованиям службы безопасности. Это означает, что учетка, из-под которой запущен сервер 1С, является на серверах баз данных системным администратором (либо суперпользователем, если это Postgres). 

• Нам ничего не мешает создать еще одну обработку, которая просто подключится к MS SQL, PostgreSQL, не указывая ни логина, ни пароля к базе данных (заметьте, он нам не нужен мы ничего не подбирали, потому что эта обработка подключается с правами сервера 1С, а он там – системный администратор). И создать еще одного системного администратора в СУБД – с логином и паролем, никакой доменной авторизации. 

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

Более того, мы можем это делать настолько скрытно, что вы годами можете не знать, что у вас давно все взломано и все данные улетают не туда, куда вам надо.

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

Полной безопасности, конечно, не добиться. У нас всегда есть баланс между удобством и безопасностью. И соблюсти этот баланс – сложная и интересная задача, решать которую надо как можно раньше:

• единственный способ прийти к безопасности – это выключить сервер из розетки. Все безопасно, но работать нельзя. 

• придем к удобству – это как сейчас в 1С, мы сломаем за минуту любую базу.

Первая ошибка – право на запуск внешних обработок

Итак, первый грех, самая важная и распространенная ошибка – это возможность пользователя запускать внешние обработки. Это вообще вселенское зло. Первое, что вы должны сделать – отобрать у всех пользователей права на запуск внешних обработок. 

Хотите кастомизировать свою систему – делайте это красиво и надежно. Хватит «фигачить гаражный тюнинг», навешивать на систему обвесы в виде внешних обработок, иначе у десятков ваших пользователей на рабочих столах будут храниться сотни версий одной и той же обработки со времен Деда Мазая:

• во-первых, используя старую версию обработки на реструктурированных данных, вы получите непредсказуемый вал ошибок. А бухгалтеру удобно – обработка лежит на рабочем столе, он ее и запускает;

• во-вторых, вы получите возможность взлома. Поверьте, у каждого пятого, наверное, вашего бухгалтера есть сын, племянник или сосед, который посмотрел курс «Как программировать на 1С». Первым делом он захочет получить данные из вашей базы и напишет для этого обработку – там делов-то на две минуты. 

Если все-таки по условиям бизнеса вам нельзя отказаться от внешних обработок, то хотя бы размещайте их в справочнике дополнительных отчетов и обработок (а лучше все-таки включать свои доработки в конфигурацию). Относитесь к этому очень аккуратно. Это – удобство, которое граничит с полной небезопасностью. Удобный механизм, но очень опасный. 

И еще один момент – когда вы перенесете все внешние обработки в справочник, наведете там полный порядок, удалите оттуда, пожалуйста, все обработки универсального доступа. Как минимум, удалите консоль запросов – в 90% случаев она в вашем справочнике будет. Это такая штука, с помощью которой любой 1С-ник, который проработал хотя бы две недели, обойдет все ограничения прав (кроме RLS), обойдет все ограничения отборов, и получит все, что угодно – любые данные по зарплате, налогам и пр.

Поэтому внешние обработки, к сожалению, должны умереть. Как бы это ни было удобно.

Вторая ошибка – «прозрачная авторизация» платформы на серверах СУБД

Еще одно «удобство», которое можно записать «в плюс» платформе – это та самая «прозрачная авторизация» платформы на серверах СУБД. В стандартном варианте использования, когда на сервере 1С крутится много баз – это грубейшая ошибка с точки зрения безопасности. Чем это грозит, я уже рассказал. А как этого избежать?

Самое простое – это под каждую базу завести отдельного пользователя СУБД, под которым к ней подключается сервер 1С. Причем, на сервере СУБД этот логин должен быть лишен прав сисадмина и быть просто Owner’ом для этой базы (на Postgres быть просто админом этой базы).

Классно, быстро, за три минуты это все сделаете – создадите 40 пользователей СУБД для 40 баз данных.

Но что же делать, когда с одной стороны безопасники требуют не передавать по сети пароли от сервера 1С в СУБД (это в файле они лежат шифрованные, а в базу данных полетят в открытом виде), а с другой стороны Дорошкевич на Инфостарте говорит: «Не будете передавать логин и пароль – я вас взломаю». 

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

Тогда вы не только резко повысите безопасность ваших данных, вы еще и получите хороший бонус к гибкости управления платформами в вашей инфраструктуре. Вы сможете совершенно безболезненно менять версии платформы только для любой из баз, рестартовать службы и т.д. Вы же все любите рестартовать сервер, когда у вас начинает тормозить, вместо того чтобы разобраться, почему тормозит – это же сложно, дорого. А еще регулярные выражения начать писать для разбора техжурнала – это вообще мрак. Зачем это надо? Сейчас рестартану – всегда помогает. Вот, пожалуйста – рестартуйте. Делайте, что хотите – зато безопасность будет еще сильнее. Правда есть побочный эффект нескольких служб в части управления ragent-ом оперативной памятью, но это отдельная история.

Третья ошибка – отсутствие ограничений FireWall

И третий момент смертного греха, про который все постоянно забывают, – это настройка сетевого экрана на серверах во внутренней сети.

К сожалению, почти у всех сервер СУБД сетевым экраном вообще не закрыт, хотя обязательно должен быть закрыт полностью – все порты и все IP-шники, кроме порта, по которому к нему обращается сервер 1С и кроме IP-шника сервера 1С. Плюс еще пара компов админов БД должны иметь доступ на этот сервер. И больше никто. Это сервер базы данных, а не детская площадка для гуляний с колясками.

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

Чем грозит отсутствие запрета?

Это грозит тем, что любой пользователь (даже без прав админа) может поставить себе на локальный компьютер дистрибутив 1С-ки с галочкой «Администрирование» – и у него появится консоль сервера 1С. Казалось бы, что такого? Мы все свои базы данных защитили, и у нас все круто – у нас под каждую базу данных свои пользователи в СУБД есть.
А вот и не все. После того, как он поставит себе консоль сервера 1С, он поднимет у себя на компьютере Postgres. А поскольку локальный компьютер вы на вход сетевым экраном тоже не защищаете, он, имея доступ из консоли до сервера 1С, правой кнопочкой на вашем кластере создаст новую базу и подключит ее к своей локальной базе данных Postgres. А затем запустит 1С, пропишет в ней свою вновь созданную базу данных и запустит любую обработку. 

А дальше – читайте первый слайд. За 60 секунд мы, как минимум, получим список всех ваших кластеров, всех ваших баз данных. И дальше уже будем смотреть, что с этим делать – не поленились ли вы создать для каждой базы своего пользователя? А вы поленитесь – и если у вас в какой-то базе пользователь СУБД прописан не будет, мы сможем запустить в ней любую обработку от имени пользователя сервера 1С.

Второй момент, как можно сделать то же самое, но чуть сложнее – Remote Access Server (RAS). Если у вас на серверах работает эта служба, то с помощью Remote Access Client (RAC) вы получите ту же самую консоль, только в командной строке. Можно делать все то же самое. 

Поэтому порт консоли сервера 1С должен быть закрыт. 

Казалось бы, закроем порт – наступит счастье? Не наступит.

Есть самый страшный метод создать базу в вашем кластере. Это стартер 1С. 

Там, если вы нажмете кнопку «Добавить новую базу», вам предложат все прописать. Помните, база данных установлена у меня локально. Мне ваши пароли не нужны. И я создам базу на вашем кластере даже при закрытых портах. Потому что стартер обращается к кластеру по порту менеджера rmgr – 1541. А если вы закроете этот порт – у вас 1С-ка не запустится. 

Казалось бы, теперь пора валить из страны. Нет. Дальше будет еще страшнее…

Создайте новую роль – администратор сервера 1С

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

И у нас появляется новая роль – администратор сервера 1С.

Создайте эту роль у себя в компании. В платформе 1С есть огромная функциональность для решения этой задачи – возможность назначать роли администратора кластера и сервера 1С. Только это защитит вашу систему от несанкционированного создания баз на кластерах и кластеров на серверах 1С.

Самое главное, что тут надо понимать – простого технического решения недостаточно. Если у вас 1С-ник, он же DBA-шник, как почти везде, он же еще чуть-чуть админ, потому что «Ваша 1С повисла, вот и разбирайтесь» – и он же станет администратором сервера 1С, все то, что вы сделали – это профанация. У вас один человек – просто бог, он стащит любые данные. Системный администратор, администратор баз данных, администратор 1С и разработчик 1С должны быть не только разными ролями, но и обязательно разными людьми. Все эти четыре роли должны занимать четыре разных человека, желательно друг друга ненавидящие. Этого добиться сложно и легко одновременно. Просто «засветите» им зарплаты друг друга – и все будет хорошо. Вы добьетесь максимального уровня безопасности.

Итак, когда вы наделите этого админа (настоящего, отдельного человека) ролью администратора сервера 1С, не забудьте сделать очень легкий и очень важный шаг: создайте для этого человека в консоли сервера две административные учетки:

• администратора внутри кластера 1С;

• и, самое главное, администратора внутри сервера 1С. 

Про администратора кластера обычно не забывают – кто вообще слышал про администраторов кластеров 1С, его создают. Классно – создать базу в кластере, не зная логина и пароля, нельзя. Но только можно создать еще один кластер, потому что администратора сервера не создано. 

Создайте обе эти учетки. Это очень важно. 

На этом моменте мы с вами обеспечили такой уровень безопасности, что ломать вас имеет смысл только под заказ за очень большие деньги. 

Используйте профили безопасности

Но остались суперпользователи – это админы, 1С-ники с полными правами, пользователи с полными правами и т.д. 

Чтобы как-то бороться еще и с этим «злом полных прав», в платформе есть мегамощный механизм профилей безопасности. Механизм очень обширный. Рассказывать про все – это отдельный доклад. Почитайте на ИТС, там все написано.

Единственное, есть нюанс: профили безопасности – это функциональность уровня КОРП. Но и безопасность изначально должна заботить КОРП-сектор, а ему уже давно пора быть на КОРП-лицензиях. 1С давно перестала шутить и 10 сентября 2019 года доказала это во всей красе. 

Кто столкнулся с табличкой: «Вы используете КОРП-функциональность, Ай-яй-яй! Я запускаться не буду!» и большими красными крестиками, которые пугали бабушек-бухгалтеров полдня? 

Кто паниковал на форумах Инфостарта? Я специально встал пораньше, чтобы всем вам отписываться: «Не пугайтесь, вот здесь нужно снять вот эти галочки» – скриншоты вам присылал. 

Причем Инфостарт за три месяца до этого вас предупреждал – писал пугающую статью, что через три месяца включат ограничение, и не будет дороги назад. 

Да, профили безопасности – это КОРП-функциональность, но очень крутая КОРП-функциональность. Что в ней такого с точки зрения обеспечения безопасности от взлома? 

Только с помощью профилей безопасности мы можем поставить под контроль даже людей с полными правами, которые могут зайти в конфигуратор и что-то сделать. Как минимум мы можем поставить под контроль внешние обработки: какие можно использовать, а какие – нет. Мы можем поставить под контроль расширения: какие можно использовать, а какие – нет. 

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

А саму конфигурацию (да, безопасность связана еще и со сложностью – во времени и в бюрократии) вам придется выгружать в cf-ник, считать его контрольную сумму. И если она поменялась – его нельзя накатывать на базу, пока вы не проведете сторонний анализ безопасности на предмет «закладок». 

Безопасность – сложная штука, к ней надо идти долго. Но те, кому данные важны (а 1С все больше и больше содержит в себе пикантных подробностей финансового учета вашей компании), должны об этом задуматься. Это только кажется, что 1С только для бухгалтеров. На самом деле, 1С давно уже для бизнеса. 

Поэтому, когда мы создали админов, купили КОРП-лицензии, все это настроили, жить стало хорошо. 

Но в качестве первого тренировочного задания для этих админов я бы дал следующее.

Изолируйте серверные процессы ragent, rmngr и rphost

Заставьте админов настроить платформу 1С так, чтобы изолировать серверные процессы друг от друга. Это не КОРП-функциональность, вы можете сделать это хоть сегодня с помощью настроечного файла swpuser.ini (на ИТС описаны его параметры). 

Смысл в чем? Сервер 1С состоит из трех видов процессов, грубо говоря, из трех EXE-шников (в том числе и Linux-вариант – из трех бинарников). Это:

• агент сервера 1С:Предприятия (ragent);

• менеджер кластера (rmngr);

• и рабочие процессы rphost. 

Весь ваш код 1С на сервере выполняется только процессом rphost. 

По умолчанию все три вида процессов запускаются от одного пользователя, и именно поэтому мы смогли прочитать обработкой файл реестра кластера, хотя этот файл не нужен рабочему процессу rphost, а нужен только процессу менеджера кластера rmngr.

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

Рабочему процессу rphost для счастья нужен каталог текущей платформы 1С (папка bin) на чтение и каталог временных файлов на изменение. 

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

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

Например, пользователю, от которого запущен rmgr – ему вообще нужно очень мало, ему нужен доступ только на то, чтобы этот кластер прочитать. И к файлам журнала регистрации – он их пишет. Также он пишет файлы полнотекстового поиска. 

Поэтому делите, настраивайте. Сразу говорю, нормально заработает, только если прочитать статью на ИТС внимательно (а не как мы все с вами обычно читаем – сверху прочитали и дальше не дочитываем). Иначе не стартанет, будут ошибки. Читайте до конца. Статья маленькая, так что не поленитесь: дайте все права так, как вам об этом сказали.

После этих настроек и организационных мер несанкционированный доступ к вашим данным в 1С будет крайне затруднен.

Настройте двухфакторную аутентификацию и прозрачную авторизацию в 1С

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

Этим пользователям в обязательном порядке нужно включить двухфакторную авторизацию. Начиная с версии платформы 8.3.15, это позволяет делать сама платформа. Да, к сожалению, пока нет формы настройки – все это делается просто на встроенном языке. Но делается быстро, за 2-3 минуты. Включайте, отправляйте им SMS (можете им в Telegram коды отправлять) – как угодно, что придумаете, какой HTTP-сервис напишете, такой и будет работать.

Эти пользователи должны быть подконтрольными. Помимо двухфакторной авторизации они в обязательном порядке должны иметь только прозрачную авторизацию в 1С. Никакой авторизации с помощью платформы – уберите галку «Аутентификация 1С:Предприятия». При авторизации с помощью 1С логины и пароли передаются в открытом виде.

А логины и пароли прозрачной авторизации не передаются – передается Kerberos билет, для которого реальных способов взлома нет при настроенной политике блокировки паролей. Может быть, математические есть, но реальных нет. Поэтому – только прозрачная авторизация. 

Плюс – настройте в домене правила блокировки по подбору пароля. Почему именно в домене, а не в 1С? Ведь в 8.3.16 появилась возможность включить защиту от брутфорса – указать количество попыток. Эта защита распространяется на всю базу 1С, а не на конкретных пользователей, что не всегда удобно. Плюс она реализована немного опасным способом – теперь, чтобы не попасть в капкан своей же защитной системы, когда у вас заблокируются все пользователи и вы ничего сделать не сможете, там еще и указывается префикс входа мимо брутфорса. Грубо говоря, суперпароль, который доступен администратору сервера 1С. А это – нехорошо. Лучше эти роли разделить, чтобы этот суперпароль доменного админа был доступен только доменному администратору, и чтобы только он мог разблокировать учетку, которая у вас прозрачно авторизуется. Но с другой стороны, раньше в 1С вообще никакой защиты от подбора не было, а теперь есть, и это отлично.

Для критических важных процессов компании нужен сторонний наблюдатель

Ну раз уж мы заговорили о критически важных процессах компании, вам, по-хорошему, нужен третий наблюдатель для объективного контроля этих процессов. Это – технология типа блокчейн.

Приведу пример – заявка на расходование денежных средств. Завели заявку – 500 т.р. Ее все радостно согласовали, и на моменте перед передачей этой заявки в бухгалтерию админ зашел и нолик добавил. Причем, неважно какой админ: 1С-ник или админ базы данных (только админ сервера 1С не сможет эту гадость сделать). И у вас улетело 5 миллионов. Но ладно нолик. Он скорее всего, контрагента поменяет, кому эти деньги улетят. Поэтому думайте о том, как сторонними технологическими средствами обеспечить еще один уровень безопасности от шаловливых ручек. Чтобы каждый участник процесса твердо знал, что с момента появления заявки на расходование в системе никакие ее основные параметры не были изменены.

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

И не путайте это с майнингом и криптовалютами. Никакого отношения одно к другому практически не имеет. Криптовалюты – это паразиты на теле блокчейна. Не надо их туда наворачивать. Блокчейн для другого был создан.

Проводите аудит и тестирование на получение несанкционированного доступа к 1С

И на десерт – чтобы все, что я тут говорил, и все, что вы придумаете сами, не осталось на бумажках в регламентах, которые вы будете показывать своей службе безопасности, вам жизненно необходимо периодически проводить тесты на проникновение. Как внутренними силами ИТ, так и приглашая внешних подрядчиков. 

У внешних подрядчиков по сравнению с вашим ИТ-отделом (или 1С-отделом – я их не объединяю в одно) есть одно неоспоримое преимущество – они видели в сто раз больше инсталляций, чем вы. 

Белый хакер только кажется дорогим. Черный хакер может привести просто к катастрофическим финансовым последствиям вашей системы. Поэтому об этом надо думать заранее – платить белым хакерам, чтобы черные хакеры ничего не получили. 

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

Дорошкевич Антон, с заботой о вас и ваших данных!

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.