Вы проверили ваши плагины 1С-Битрикс сегодня?

До 50 000 сайтов в рунете могут быть сегодня открыты

Ваши хэши паролей уже могли утечь на чужой сервер

🔐 Честно говоря, за последние несколько лет в моей практике я видел десятки случаев компрометации корпоративных порталов. Но та история, которая всплыла недавно с плагинами Esolutions, — это отдельный разговор. Она не про сложные zero-day атаки, а про тихий, почти бытовой беспорядок в безопасности, который оставили тысячи разработчиков и администраторов. И знаете, что самое неприятное? До 50 000 сайтов в рунете могут быть сегодня открыты, как квартира со сломанным замком.

Причем взломщику даже не нужно быть хакером-гением — достаточно иметь аккаунт контент-менеджера.

Звучит пугающе? Так и есть.

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

Кто виноват и что произошло на самом деле?

Давайте без воды. Специалисты, в частности, компания «СайберОК» Роберта Торосяна, нашли в популярных плагинах для обмена данными с Excel дыры, которые в паре создают идеальный шторм. Речь о двух классических, но от этого не менее опасных вещах: Sensitive Data Exposure (раскрытие чувствительных данных) и Path Traversal (обход пути к файлам).

И если по отдельности они могут и не сработать, то вместе — это почти гарантированный доступ ко всему, что есть на сервере. Представьте: злоумышленник, а это может быть недовольный сотрудник или взломанный аккаунт редактора, через форму импорта товаров получает не товары, а… хэши паролей всех пользователей сайта. Да, прямо в интерфейсе. Это Sensitive Data Exposure.

А дальше — Path Traversal. С помощью простой манипуляции с путями к файлам (типа ../../../bitrix/php_interface/dbconn.php) он может вытащить конфигурационные файлы базы данных, исходный код, логи — что угодно. Это как дать сантехнику ключ не только от котельной, но и от кабинета генерального директора. По моему опыту, после такого полный захват сервера — вопрос времени, причем небольшого.

Затронуты три популярнейших модуля:

• «Экспорт/Импорт товаров в Excel» (esol.importexportexcel) — всё, что старше версии 3.2.6.
• «Импорт из Excel» (kda.importexcel) — аналогично, до 3.2.6.
• «Многофункциональный экспорт/импорт в Excel» (esol.allimportexport) — версии до 0.6.4.

Проверьте прямо сейчас в своем маркетплейсе Bitrix. Если у вас стоят эти версии — вы в зоне риска. И это не абстрактный риск, а прямое нарушение требовай ФСТЭК и 152-ФЗ о защите персональных данных. На бумаге у вас может быть всё прекрасно, а на практике — слив.

Почему это случилось и при чем тут «человеческий фактор»?

Тут начинается самое интересное. Как эксперт, который проводил десятки аудитов, скажу прямо: корень проблемы не в злом гении-хакере, а в нашей общей беде — вторичность безопасности при разработке. Плагины пишутся для функциональности: «чтобы быстро выгрузить в Excel». Проверка входных данных, санитайзинг путей, контроль прав доступа — всё это отходит на второй план.

К слову, я сам видел в коде подобных решений прямое чтение файлов по пути из GET-параметра, без какой-либо фильтрации. Разработчик думал об удобстве, а не о том, что кто-то подставит ../../... И знаете, что удивляет? В 2025 году такие элементарные ошибки всё ещё массово кочуют из проекта в проект. Это как покупать машину без подушек безопасности, потому что «я же аккуратно езжу».

А дальше подключается второй фактор — запущенность обновлений на проектах. Администратор сайта устанавливает плагин, он работает. Замечательно. Проходит год, два. Разработчик выпускает патчи, но кто их ставит? В лучшем случае обновят ядро Bitrix, а про «какие-то там модули» забудут. В итоге получаем идеальную мишень: уязвимый код + беспечное администрирование. Рецепт катастрофы готов.

Что будет, если проигнорировать проблему? Реальные последствия

Если ваши плагины уязвимы, сценарий развивается не по дням, а по часам.

Давайте без страшилок, только факты из практики CTI-аналитика.

1. Кража учетных данных. Хэши паролей слиты. Современные мощности перебора (особенно с уязвимыми алгоритмами хэширования, которые ещё встречаются) позволяют «восстановить» часть простых паролей за часы. Теперь у атакующего есть логины и пароли реальных пользователей. И не просто пользователей, а часто — администраторов, потому что их хэши тоже в общей куче.
2. Горизонтальное перемещение. Вошел под учеткой редактора? Отлично. Через Path Traversal достаем конфиг базы данных. Теперь у нас есть доступ ко всем данным сайта: клиенты, заказы, внутренние документы. Это уже прямая кража конфиденциальной информации, о которой говорит 152-ФЗ.
3. Полный захват. С данными БД или через другие уязвимости получаем доступ на сервер. Дальше — тишина. Современные злоумышленники не будут ломать сайт. Они установят бэкдор, будут тихо сидеть в системе месяцами, сливая коммерческую тайну или готовя атаку на финансовую операцию. Обнаружить такое без продвинутого мониторинга EDR/XDR очень сложно.
4. Регуляторные штрафы. ФСТЭК при проверке не примет в оправдание «это был взлом». Не обновили известную уязвимость? Это ваша вина. Штрафы, предписания, а в случае с КИИ (критической информационной инфраструктурой) — уголовная ответственность по 187-ФЗ. И это не пустые слова.

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

══════

Нужна помощь?
Оставьте заявку на Бесплатную консультацию на сайте: https://securedefence.ru/
Пришлём чек-лист + дорожную карту + КП
Первые 5 заказов каждый месяц — расширенный аудит на 12 страниц в подарок!

══════

10 правил 2026 года от практика SOC

Забудьте про общие списки «установите антивирус».

Вот правила, которые работают в реалиях российского рынка и которые я применяю сам.

1. Автоматизируйте учёт сторонних компонентов. Ведите реестр ВСЕХ плагинов, библиотек, модулей с версиями. Используйте софт типа SCA (Software Composition Analysis). Без этого вы слепы.
2. Обновления — это не совет, а правило мониторинга. Назначьте ответственного, который раз в неделю проверяет обновления для всех компонентов из вашего реестра. Не только Bitrix. Особенно — самописные и малоизвестные модули.
3. Принцип минимальных привилегий — ваша мантра. Контент-менеджеру НЕ НУЖЕН доступ к инструментам импорта, которые могут читать файлы. Разделите роли. Это остановит 80% внутренних инцидентов.
4. Пароли — это слабое звено. Внедряйте двухфакторную аутентификацию (2FA) ВСЕГДА для администраторов. Даже если хэш утечёт, этого будет недостаточно для входа. И да, переходите на стойкие алгоритмы хэширования.
5. WAF — не панацея, но обязательный щит. Настройте WAF (Web Application Firewall) на блокировку попыток Path Traversal (../) и SQL-инъекций. Это остановит автоматические скрипты и «чайников».
6. Мониторинг необычной активности — ваши глаза. Внедрите хотя бы простую систему логирования и алертов. Кто и когда запускал импорт? Что за файлы запрашивались? Аномалии нужно искать.
7. Регулярный пентест, особенно «белый ящик». Раз в квартал давайте специалистам доступ к исходникам ваших доработок и плагинов. Пусть ищут уязвимости, подобные этой. Это дешевле, чем ликвидация последствий взлома.
8. Обучение — не для галочки. Расскажите администраторам и разработчикам об этой конкретной истории с Esolutions. Покажите, как выглядит Path Traversal. Живые примеры запоминаются лучше сотни инструкций.
9. Имейте план реагирования (IRP). Что делать, если обнаружили подозрительную активность? Кого звонить? Как изолировать систему? Без плана вы будете метаться в панике.
10. Доверяйте, но верифицируйте. Даже после обновления плагина проверьте, что уязвимость действительно закрыта. Иногда одного патча недостаточно.

Что делать прямо сейчас? Пошаговый план на сегодня

Не откладывайте. Выделите два часа и пройдите по этому чек-листу.

1. Сверка. Зайдите в админку Bitrix → Маркетплейс → Установленные решения. Найдите esol.importexportexcel, kda.importexcel, esol.allimportexport. Какие версии?
2. Действие. Если версии ниже указанных — обновляйте немедленно. Нет кнопки «Обновить»? Удаляйте плагин и ставьте свежую версию из маркетплейса. Предварительно, конечно, сделайте бэкап.
3. Аудит. Проверьте логи веб-сервера (access.log, error.log) за последние 30-90 дней. Ищите странные запросы с множественными ../, ....// или попытки доступа к файлам вроде dbconn.php. Это индикатор возможной уже состоявшейся атаки.
4. Проверка прав. Пройдитесь по группам пользователей. Кто имеет доступ к уязвимым (или похожим) модулям? Сократите этот круг до абсолютного минимума.
5. Инвентаризация. Начните вести тот самый реестр компонентов. Прямо сегодня в Excel. Запишите все нестандартные модули.

Если на шаге 3 вы нашли подозрительные записи — это красный флаг. Возможно, компрометация уже произошла. Значит, пора не просто обновляться, а начинать полноценное расследование инцидента: менять пароли, искать бэкдоры, анализировать базу данных на предмет внедрения скрытого кода.

FAQ: ответы на главные вопросы от владельцев бизнеса и CISO

1. Мы обновили плагины. Этого достаточно?
   Честно? Нет. Это закрыло конкретную дыру. Но нужно проверить, не остались ли другие подобные уязвимости в ваших других плагинах и самописных модулях. Без аудита кода или пентеста вы этого не узнаете.
2. У нас стоит WAF. Мы защищены?
   WAF — отличный инструмент, но его часто обходят через техники обфускации или целенаправленные атаки на приложение в обход правил. Не полагайтесь только на него. Это один из слоев защиты, а не волшебный щит.
3. Как понять, что на нас уже нападали через эту уязвимость?
   Смотрите логи (шаг 3 из плана выше). Ищите файлы с подозрительными датами изменения в корне сайта и в папке /bitrix/. Проверьте учетные записи администраторов на предмет несанкционированных действий. Если сомневаетесь — нужен специалист по расследованию инцидентов.
4. Мы используем облачный Битрикс. Это нас спасает?
   Частично. Провайдер отвечает за инфраструктуру. Но безопасность самого приложения (ваши плагины, ваш код, ваши настройки прав) — это полностью ваша зона ответственности. Обновлять плагины всё равно придется вам.
5. Какая главная ошибка при реагировании на такие уведомления?
   Самая большая ошибка — обновить плагин и забыть. Не проверить логи, не проанализировать, не было ли проникновения. Атака могла произойти неделю назад, и злоумышленник уже внутри. Обновление его не выгонит.
6. Эти плагины популярны. Почему о такой серьезной уязвимости не объявили громче?
   Индустрия движется к ответственному разглашению. Исследователи дают время разработчикам на выпуск патча, чтобы не обрушить все сайты сразу. Но теперь патч есть — и игнорировать публичную информацию уже преступно.
7. Мы маленькая компания. Нам это грозит?
   Автоматические сканеры ищут уязвимости без разбора. Ваш сайт могут взломать не ради вас, а чтобы использовать ваш сервер как прокси для атак на других, для рассылки спама или майнинга. Ущерб репутации и простои будут вашими.
8. Что страшнее: внешний хакер или свой сотрудник?
   В случае с такими уязвимостями — часто свой. У сотрудника уже есть аккаунт. Ему не нужно искать пароли. Недооценка внутренней угрозы — бич российского рынка.
9. Можно ли написать свой безопасный плагин вместо этих?
   Можно. Но будет ли он безопаснее? Только если вы с самого начала закладываете security-требования, проводите код-ревью и аудит. Иначе просто поменяете одну потенциальную дыру на другую, менее изученную.
10. С чего начать построение нормальной безопасности, если всё в запущенном состоянии?
    С инвентаризации и приоритизации. Составьте реестр (правило №1), обновите всё критическое (как эти плагины), настройте бэкапы и 2FA для админов. Потом уже беритесь за WAF, мониторинг и регулярный аудит. Главное — начать и делать это системно.

Безопасность — это не точка, а постоянный процесс. Нельзя «установить и забыть». Сегодня это плагины Esolutions, завтра — новая дыра в другом компоненте. Ваша задача — создать систему, которая позволит оперативно находить и закрывать такие угрозы. Иначе вы всегда будете бежать позади проблемы, туша уже разгоревшийся пожар.

Если после прочтения вы осознали, что в вашей компании нет ни одного из этих пунктов, — это первый и самый важный шаг к изменениям. Дальше — действие.

══════

Больше материалов: Центр знаний SecureDefence.

Оставьте заявку на бесплатную консультацию: [Перейти на сайт]