НКЦКИ не советует обновлять opensource-софт из-за угрозы новых санкций

НКЦКИ не советует обновлять opensource-софт из-за угрозы новых санкций

НКЦКИ не советует обновлять opensource-софт из-за угрозы новых санкций

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

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

Минимизировать риски в отношении текущих угроз, по мнению НКЦКИ, помогут следующие меры (PDF): 

  1. Перенос хостинга общедоступных ресурсов на территорию РФ.
  2. Готовность компенсировать риски в случае отказа хостера разместить публичный ресурс из-за ассоциаций с компанией, находящейся под санкциями.
  3. Отказ от использования иностранных DNS-серверов для публичных ресурсов, в том числе в качестве промежуточного звена.
  4. Передача управления доменными именами публичных ресурсов отечественным регистраторам.
  5. Перенос публичных ресурсов в TLD-зону .ru (по возможности).
  6. Регулярная проверка связности подопечных AS-систем.
  7. Разработка плана по переходу на самоподписанные SSL-сертификаты или сертификаты УЦ, находящихся на территории России.
  8. Замена облачных решений (мессенджеров, CRM, IDE, средств коллективной работы, офисных пакетов) отечественными аналогами либо решениями, которые разворачиваются локально и не предусматривают внешнего контроля со стороны производителя.
  9. Замена продуктов, требующих проверку лицензии за рубежом.
  10. Создание локальных хранилищ дистрибутивов программных продуктов и opensource-софта, отказ от обновления таких продуктов (в случае особой нужды апдейт всегда можно проверить в тестовой среде).
  11. Предельное ограничение использования стороннего софта с открытым исходным кодом.
  12. Создание условий для безопасного обновления opensource-софта в составе программных комплексов отечественного производства.
  13. Отказ от сотрудничества с контрагентами, которые не могут принимать платежи с территории РФ.

Напомним, ранее НКЦКИ опубликовал рекомендации по повышению уровня защищенности веб-приложений в рунете и снижению рисков для пользователей.

Новая атака на кеш Nginx позволяет красть данные и ломать сайты

Исследователь YesWeHack Алекс Брумен описал вектор кибератаки Cache Key Injection. В случае её эксплуатации последствия для потенциальной жертвы опасные: обход контроля доступа, раскрытие закрытых страниц, отказ в обслуживании и при определённых условиях.

Как объясняет исследователь YesWeHack, проблема возникает не в Nginx по умолчанию, а в конфигурациях, где администраторы просто склеивают несколько значений переменной длины без разделителей. Например:

$scheme$host$request_uri$http_accept

Разных запроса два, а итоговая строка может получиться одна. Так, запрос к /h с заголовком Accept: ome*/* создаёт тот же ключ, что и обычное обращение к /home с Accept: */*.

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

 

Ещё веселее становится с закрытыми разделами. В лабораторном примере страница /admin была доступна только с localhost, но злоумышленник мог обратиться к /ad и перенести оставшуюся часть имени в соседний компонент ключа. Nginx видел разрешённый путь, однако доставал из кеша содержимое админ-панели.

При совпадении нескольких условий техника позволяет столкнуть HTTP- и HTTPS-запросы и записать в кеш страницу со ссылкой на атакующий JavaScript, превратив ошибку конфигурации в stored XSS. Даже Cloudflare не всегда спасёт: заголовок Authorization может провести запрос мимо его кеша прямо к уязвимому кешу Nginx.

 

Защита выглядит до смешного просто: не склеивать значения вслепую. Между элементами ключа нужны разделители или структурное кодирование, например:

$scheme|$host|$request_uri|$http_accept

Также следует проверять Host, перенаправлять HTTP на HTTPS и не кешировать аутентифицированные запросы.

RSS: Новости на портале Anti-Malware.ru