попытка фишинга через редирект битрикс

Защита редиректов

Описание

Фишинг (англ. phishing, от password — пароль и fishing — рыбная ловля, выуживание) — вид интернет-мошенничества, целью которого является получение доступа к конфиденциальным данным пользователей (например, логинам и паролям). Это достигается путем проведения массовых рассылок электронных писем от имени популярных брендов, например, от имени социальных сетей, банков, порталов. В письме часто содержится прямая ссылка на сайт, внешне не отличимая от настоящей.

Защита редиректов от фишинга осуществляется двумя методами:

Защита может заключаться в следующих вариантах действий:

Закладка Защита редиректов

Включение или отключение защиты редиректов от фишинга выполняется на странице Защита редиректов от фишинга (Настройки > Проактивная защита > Защита редиректов) с помощью кнопки Включить защиту редиректов от фишинга (Выключить защиту редиректов от фишинга).

Закладка Параметры

Смотрите также

Пользовательские комментарии

Мы будем рады, если разработчики добавят свои комментарии по практическому использованию методов системы.

Для этого нужно всего лишь авторизоваться на сайте

Но помните, что Пользовательские комментарии, несмотря на модерацию, не являются официальной документацией. Ответственность за их использование несет сам пользователь.

Также Пользовательские комментарии не являются местом для обсуждения функционала. По подобным вопросам обращайтесь на форумы.

Источник

Попытка фишинга через редирект

Тоже началось с середины ноября, тоже Timeweb (хотя по сути, хостинг тут ни при чём, конечно же, т. к. идёт «атака» извне).

Надо посмотреть, как снизится в результате нагрузка на CPU, но думаю, что встроенная защита через редирект делает то же самое, что и этот «костыль», просто теперь это не фиксируется в аналитике, и нельзя анализировать, сколько тараканов лезет на наш rk.php. А с каждым днём, между тем, их становится всё больше и больше…

Та же беда, нагрузка растёт и растёт с середины декабря, с 10 до 60%
Попробовал добавить

Order Allow,Deny
Deny from all

php_flag allow_call_time_pass_reference 1
php_flag session.use_trans_sid off
.
.
.

ExpiresActive on
ExpiresByType image/jpeg «access plus 3 day»
ExpiresByType image/gif «access plus 3 day»

Order Allow,Deny
Deny from all

php_flag allow_call_time_pass_reference 1
php_flag session.use_trans_sid off
.
.
.

Источник

Инструкция по устранению уязвимости перенаправлений в 1C-Битрикс: Управление сайтом

Данная информация будет полезна государственным учреждениям, сайты которых проходили проверку на безопасность. Если ее итогом стало письмо, содержащее подобную формулировку: “По имеющейся информации официальный сайт ‘название учреждения’ содержит в себе уязвимость информационной безопасности, связанную с функцией перенаправления пользователей в системе управления сайтом “1С-Битрикс”. Указанная уязвимость может быть использована потенциальным нарушителем информационной безопасности. ”, мы расскажем о чем идет речь, и что с этим делать.

Под уязвимостью в данном случае понимают Open Redirect (открытые перенаправления) на вашем сайте. Если при редиректе пользователя не предупреждают о переходе, то сайт могут заподозрить в уязвимости к фишингу.

Звучит страшно, но волноваться не нужно. Эта проблема связана с тем, что изначально в Битрикс отключена защита редиректов. Мы подготовили инструкцию, как за 5 минут ограничить возможность использования нежелательных перенаправлений.

Чтобы все редиректы были защищены, вам нужно:

Авторизоваться в административной части по адресу http://НАЗВАНИЕ_САЙТА/bitrix/ (вместо НАЗВАНИЕ_САЙТА подставьте название вашего сайта), введя ваши логин и пароль.

В левом меню перейти в раздел Настройки-Проактивная защита-Защита редиректов.

Нажать кнопку «Включить защиту редиректов», если выводится сообщение «Защита редиректов от фишинга выключена». Если защита редиректов включена, пропускайте этот шаг.

Перейти во вкладку «Параметры».

В секции «Методы» выбрать все методы защиты от фишинга. Должны стоять галочки напротив следующих пунктов: «Проверять наличие HTTP-заголовка, описывающего ссылающуюся страницу», «HTTP-заголовок, описывающий ссылающуюся страницу, должен содержать текущий сайт» и «Добавлять цифровую подпись к перечисленным ниже URL».

Применить настройки, нажав кнопку «Сохранить».

Готово! Теперь все редиректы на вашем сайте защищены и соответствуют требованиям безопасности.

Источник

Уязвимость Bitrix. Как собрать персональные данные и заспамить недруга

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

Примерно год назад у одного из наших клиентов возникла проблема. Нагрузка на MySQL стала столь значительной, что хостер прислал уведомление следующего вида:

DDoS? Ок, мы принялись изучать, в чем проблема.

Беглый анализ навел на две, одинаково неприятные, мысли:

Еще было подозрение на погоду. Мало ли, надуло.

Если скачивание картинок с сайта чревато такими опасностями, значит, мы поостережемся, угомоним свои амбиции и проверку на вирусы пока отложим. Вместе с тем прикинем, не сменить ли условия хостинга.

Тем временем хостер написал еще одно обиженное письмо. А у нас подошло время полной ежемесячной проверки сайта, и в «Вебмастере» были обнаружены коварные ссылочки (очень много) следующего вида:

Сайты, которые ссылались на наш проект, были, мягко говоря, плохие. Даже не МФА, а просто не пойми что. Очень неприятный звоночек.

Таким способом несколько лет назад валили казахстанские банки. Использовали open redirect для фишингового сбора данных.

Уязвимость позволяет любому сайту закинуть на свою страницу ссылку вида:

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

Как такое возможно? А вот как.

Проблема в родной конфигурации «Битрикс». Это rk.php и redirect.php — служебные файлы, используемые системой для сбора статистики редиректов пользователей при клике по баннерам и ссылкам.

Аналогичная схема может действовать в почтовых рассылках, сообщениях в блогах и социальных сетях и т. д. и т. п. Цель злоумышленника: прикрыться трастовым доменом, чтобы заставить пользователя совершить целевое действие (оставить свои персональные или платежные данные).

Другая цель: испортить представление поисковых систем о вашем сайте. Потому что робот увидит миллион «не тех» ссылок, лучше (хуже) чтобы ссылки шли на что-то совсем неудобоваримое, типа троянов, и накажет. Опять же, скорость и доступность вашего сайта будут ограничены.

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

Мы решили бороться по-простому:

Что вы думаете, помогло? Не тут-то было.

Эмоции немножко накалились. И мы стали биться в двери «Битрикс». Что они нам изначально ответили? Ну конечно же, выслали перечень типизированных работ, которые мы уже провели!

Пишем, что все сделали, а результатов нет.

МХАТ. Пауза.

И к нашему великому удивлению решение поддержки было следующим:

Пожалуй, это и смешно, и грустно. Поддержка «Битрикса» рекомендует удалить кусок, пусть и небольшой, собственного продукта. И это помогает.

Напоминаем, проблеме уже не один год. И хотя на официальном форуме «Битрикс» старт обсуждения датируется 2004 годом, никаких упоминаний об этой лазейке в документации нет.

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

Материал подготовлен Еленой Кулишкиной. «Иващенко и Низамов»

В качестве консультанта выступил из сумрака наш разработчик: Илья Соловьев

Читателям SPARK мы предлагаем проверить свой сайт у наших специалистов совершенно бесплатно, заказав SEO-аудит с помощью промокода SPARK1809.

Источник

Топ-4 актуальных уязвимости 1С-Битрикс

Хотели написать статью об инструментах безопасности «1С-Битрикс», но постепенно «зарылись» в проблемах с этой самой безопасностью. И как оказалось, тема эта весьма актуальная. Несмотря на общепризнанный высокий уровень защищенности «Битрикс» и сегодня находятся «прорехи», которые могут причинить серьезные неприятности.

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

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

Содержание:

XSS-атака

Под данным Bitrix Hub кросс-скриптинг (межсайтовый скриптинг, XSS-атаки) возглавляет топ уязвимостей проектов на «1С-Битрикс: Управление сайтом». Проблема актуальна, когда в коде интернет-проекта присутствуют скрипты, предоставляющие злоумышленнику возможность использовать вызовы переменных и выполнять вредоносные операции. Главная причина такого положения вещей – отсутствие или недостаточно надежная фильтрация параметров, передаваемых скриптам. Проще говоря, проблема появляется, когда данные, принимаемые от пользователя, выводятся в браузер без необходимой фильтрации.

Специалист по информационной безопасности компании «1С-Битрикс» М. Низамутдинов разъясняет: XSS-атака может быть использована для изменения вида HTML-страниц уязвимого ресурса в контексте браузера целевого пользователя, похищения COOKIE данных браузера целевого пользователя, с последующим внедрением в его сессию, под его учетной записью.

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

В качестве средства защиты от подобных посягательств представитель компании-разработчика рекомендует: «Использовать htmlspecialchars. Параметры тегов с динамическими значениями ограничивать двойными кавычками. Принудительно добавлять протокол (http), где это необходимо, для значений параметров тегов, таких как href или src».

Ты опытный PHP-программист и работаешь с 1С-Битрикс?

Зачем используется кросс-скриптинг

Основная цель – кража cookies пользователей с помощью встроенного скрипта для выборки необходимых данных и использованием их для последующих атак и взломов. Атака осуществляется не напрямую на пользователя, а через уязвимости веб-ресурса, на который внедрен вредоносный JavaScript. Кстати, в браузере он виден, как органичная часть сайта.

Несмотря на то, что XSS-атака напрямую не несет угрозу серверу, если к злоумышленнику попадут cookies администратора, он сможет получить доступ к административной части сайта.

Уязвимость ищется, как правило, в формах связи на сайте. Чтобы понять, что она есть, достаточно передать в форму запрос вида:

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

Альтернативно ту же строчку скрипта можно добавить в качестве GET-параметра на страницах, генерирующие таковые. Например, в каталоге, на страницах пагинации или в фильтрах интернет-магазинов.

http(s)://<ваш_домен>/catalog?p=2 (вместо цифры 2).

Если на странице уязвимость есть, скрипт выполнится.

Важнейшим правилом для защиты сайта от таких уязвимостей является фильтрация получаемых и передаваемых данных по способу установки экранов для символов и преобразования специальных символов в HTML-сущности. Для php это осуществляется с применением функций htmlspecialchars(), htmlentities(), strip_tags(), например:

$name = htmlentities($_POST[‘name’], ENT_QUOTES, «UTF-8»);

$name = htmlspecialchars($_POST[‘name’], ENT_QUOTES).

При работе с «Битриксом» этот список можно еще дополнить методом CDatabase::ForSql. Пример:

Важно явно указывать кодировку страниц сайта:

Header(«Content-Type: text/html; charset=utf-8»);

Альтернативно можно запретить передавать в формах кавычки и скобки, занеся их в черный список. Но при этом могут появиться проблемы, так как будут блокироваться реальные запросы, содержащие «запрещенные» символы.

В общем, несмотря на многочисленные публикации в вебе, мы не можем назвать эту уязвимость присущей именно CMS «Битрикс» и указываем ее лишь по причине распространенности.

Кроме XSS-атак, к уязвимостям сайтов не специфическим для «1С-Битрикс» относят:

Подробнее можно посмотреть в документации, мы же не будем на них останавливаться, а рассмотрим более специализированные для «Битрикс» прорехи в безопасности.

Перенаправления – click.php, rk.php и redirect.php

Уязвимость открытых перенаправлений на «1С-Битрикс» известна довольно давно. На форуме разработчиков она активно обсуждается с 2014 года.

Суть проблемы заключалась в следующем:

От хостинг-провайдера приходит сообщение о том, что существенно растет нагрузка на MySQL.

Скриншот с форума разработчиков «Битрикс».

Причиной этому служило множество запросов (один пользователь отметил 30000 за 4 дня) с конструкцией вида:

При этом, после goto указывались, как правило, низкокачественные и мошеннические сайты.

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

Это конструкция open redirect.

Open Redirect (открытое перенаправление) – это редирект, позволяющий использовать произвольный URL для конечной цели перенаправления.

Собственно, проблема открытого редиректа характерна не только для «1С-Битрикс». Конкретно же на «Битриксе» уязвимость связана с тремя системными файлами:

Кому и зачем это нужно?

Первый вариант – получение трастовых ссылок. В 2014 году умельцы так поднимали индекс цитирования (ТИЦ) продвигаемых ресурсов.

В посте в открытом доступе почти 50 ссылок такой конструкции на трастовые домены, в том числе госорганов и банков. А в конце поста автор предлагает запросить у него бесплатно базу на 400+ доменов с выявленной уязвимостью. Кстати, оптимизатор не скрывает, что пользуется уязвимостью:

Даны подробные инструкции, как индексировать ссылки, рассылать их по твиттер-аккаунтам.

Но еще интереснее, что автор предлагает в разы увеличить запросы на сайты-жертвы:

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

Думаете, что 2014 год был давно? Тогда вот более свежий пример из 2017 года:

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

В 2018-2019 году темы по этой проблеме на форуме «1С-Битрикс» только набирали оборотов и свидетельствовали о ее массовости.

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

Третий вариант – спам для понижения авторитета сайта. Наличие огромного количества ссылок на низкокачественные ресурсы – негативный сигнал для поисковой системы о качестве сайта-донора.

Все дело в системных файлах «1С-Битрикс», используемых CMS для сбора статистики кликов и перенаправлений по рекламным баннерам и ссылкам. Возможность использовать сайт в качестве прокладки для сомнительных редиректов заложена «из коробки».

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

На запросы пользователей поддержка предлагает установить максимальный уровень безопасности в Проактивной защите, настроить редиректы с проверкой HTTP-заголовков.

Однако, как показывает практика, ни штатная «Защита редиректов от фишинга», ни многие другие средства не приносят необходимого результата. На повторное обращение техподдержка предложила удалить системные файлы.

Несмотря на абсурдность решения, оно, кстати, работает. Но при этом администратор ресурса теряет возможность отслеживать статистику кликов по баннерам и редиректов.

Файлы click.php и rk.php использует модуль «Битрикса» Реклама, баннеры (advertising). Если вы этот модуль не используете – без колебаний удаляйте его, соответственно и файлы эти удалятся.

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

Более специализированный вариант кода:

Однако и он не учитывает наличие файла click.php.

restore.php

Проблема была выявлена при тестировании проекта на проникновение. Ее подробно описали на Хабре. Мы же кратко изложим суть.

На публичном IP была установлена виртуальная машина «Битрикс», что стало понятно по набору открытых портов.

При переходе по адресу ip_addr:80 в браузере открывалась страница первичной настройки CMS «1С-Битрикс» со ссылкой «Восстановить копию». Клик по ней запускает переход к модулю restore.php и в окне появляется предложение загрузить резервную копию:

Ситуация объясняется скорее всего человеческим фактором: вероятно, что администратор не завершил процедуру настройки вебсайта и Виртуальной машины VMBitrix. Но несмотря на то, что проблема связана с отсутствием контроля или ошибкой специалиста, она может стать причиной взлома.

restore.php осуществляет проверку и загрузку файлов, разворачивание резервных копий проекта. А это значит, что злоумышленник может загрузить посредством модуля не бекап, а файл phpinfo.php. Проведенный анализ показал, что проверка файлов «Битрикс» не сработала и скрипт с локального компьютера загрузился в корень веб-приложения.

Чтобы повторить в лабораторных условиях, была локально развернута «1С-Битрикс: Виртуальная машина» версии 7.2.

Попытка загрузить скрипт через опцию «Скачать резервную копию с дальнего сайта» не увенчалась успехом. Сработала проверка. В restore.php есть код с соответствующим условием:

Однако, обойти первое условие оказалось возможным. Для тестов взяли скрипт cmd.php. В cli системы передали символы-идентификаторов с содержимым файла cmd.php в новый файл под именем cmd_boom.php:

В hex-таблице он стал выглядеть так:

Файл был выгружен в репозиторий, и ссылка на него «скормлена» restore.php. Появился прогресс-бар загрузки и со временем – сообщение об ошибке:

Был ли удален файл?

Нет! Он остается в корне и запускается.

В форме с ошибкой нажали кнопку «Пропустить», затем – «Попробовать снова». В результате вывелась страница с кнопкой «Удалить локальную резервную копию и служебные скрипты». После клика на нее все файлы удалились.

Домашняя директория очищается от скриптов restore.php, bitrixsetup.php и файла cmd_boom.php. Сделать с сайтом ничего нельзя: резервная копия сайта не восстановлена, к установке нового не перейти.

В теории скрипт cmd.php можно скрыть в поддиректорию или же переименовать в index.php.

Обращение в техподдержку «Битрикс» не дало результатов. Точнее, ответ был таков, что поиск уязвимостей в restore.php не имеет смысла, так как скрипт предусмотрен для загрузки php-файлов на сайт.

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

А если копнуть глубже? Надеемся, что этот факт заставит разработчиков задуматься над вопросом повышения безопасности на выявленном участке. А пока остается лишь быть предельно внимательным и не публиковать ВМ до того, как проект будет развернут на сервере, а также внимательно следить за всеми общедоступными страницами и ресурсами.

Бесконтрольная регистрация пользователей

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

«В течение последней недели наблюдаются массовые регистрации ботов на сайтах под управлением СУ Битрикс. Судя по записям в журнале событий регистрация происходит по адресу /auth/?register=yes Так вот, на этих сайтах раздел /auth/ либо отсутствует, либо там нет формы регистрации. Кто-нибудь сталкивался с подобной проблемой?»

Интересно, что с ситуацией сталкивались даже на сайтах, где регистрация вообще не предусмотрена, например, на лендингах и визитках. Появлялись пользователи и на проектах, где регистрация реализована через компонент main.register либо на самописном коде на API-Битрикс, где есть и reCaptcha, и правила валидации, и набор обязательных полей.

Главной причиной проблемы выступают старые компоненты:

На страницах они появляются со значением true константы NEED_AUTH:

Но есть нюанс. Даже если константа не установлена компоненты благополучно отрабатывают, если подается «правильный» POST-запрос. Получается, что на любую страницу сайта, на котором даже не предусмотрена регистрация, можно подать запрос и получить успешно зарегистрированного пользователя.

Разработчик и автор блога CodeBlog Панов Алексей провел исследование, составив универсальный запрос для регистрации из Postman:

Как указывалось, запрос успешно сработал и на ресурсах без регистрации (лендинги), и на интернет-магазинах, «обойдя капчу в форме регистрации».

Очевидно, что при желании не составит труда автоматизировать процесс.

Хорошая новость в том, что способ защититься от атаки есть.

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

Настроить указанные компоненты system.auth.* надлежащим образом. Подробно об этом можно посмотреть в статье на Хабре.

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

Где проверить сайт на уязвимости

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

И не забывайте: если ваш сайт по какой-то причине был выбран злоумышленниками в качестве цели, вполне возможен комплексный подход ко взлому. Делайте бекапы и следите за качеством кода и подрядчиков, с которыми вы сотрудничаете для его написания.

В качестве резюме (оптимистическое)

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

При этом по-настоящему важно:

поддерживать актуальность CMS – вовремя обновлять до последней версии;

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

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

Тема о проблемах безопасности в вебе всегда будет актуальна. И чем популярнее CMS, тем больше вариантов разнообразных атак на нее. Но не стоит постоянно думать только об этом. Достаточно соблюдать несколько простых правил, чтобы не переживать о своем сайте:

Ну, а где искать профи в Битрикс, Вы теперь точно знаете!

Кроме помеченных в статье источников, при подготовке материала использовались:

Источник