Архив метки: silentpatching

Безусловные регулярные обновления - путь реалиста

Добавить комментарий

Безусловные регулярные обновления - путь реалиста

Безусловные регулярные обновления - путь реалиста. Ставшие публичными кейсы Silent Patching-а демонстрируют беспомощность Vulnerability Management-а перед реальностью, в которой мы знаем об уязвимостях продуктов только то, что нам по доброй воле сообщает вендор. Дал информацию вендор - мы разбираем CVE-шки и умничаем о приоритетах их устранения в конкретной инфре. Не дал - мы пребываем в сладких иллюзиях, что всё безопасно вплоть до начала массовых инцидентов. 🤷‍♂️

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

Единственный вариант снизить риски - принять реальность такой, как она есть. Наши знания об уязвимостях ограничены. Видишь в инфре не обновленный до последней версии софт - обнови его! Семь бед - один apt-get update && apt-get upgrade! 😅 Может обновление не исправляет критичную уязвимость, а может исправляет. 😉 Достоверно нам об этом знать не дано. 🤷‍♂️

Про Silent Patching на примере кейса Аспро

Добавить комментарий

Про Silent Patching на примере кейса Аспро

Про Silent Patching на примере кейса Аспро. Эта компания предлагает услуги по запуску и миграции сайтов с использованием своего решения на базе 1С-Битрикс.

14 октября 2024 года центр кибербезопасности белорусского хостинг-провайдера HosterBy сообщил об обнаружении цепочки взломов веб-сайтов на основе решения Аспро (по большей части интернет-магазинов). RCE уязвимость связана с использованием небезопасной PHP-функции unserialize. Уязвимы версии Аспро:Next до 1.9.9.

6 февраля 2025 в блоге Аспро вышел пост, в котором они презентовали бесплатный скрипт-патчер, исправляющий уязвимость. 👍 Но там же они пишут, что сами нашли и исправили эту уязвимость ещё в 2023 году, но "намеренно не афишировали детали".

✅ Те, кто платили Аспро за поддержку и обновлялись до последней версии, были в безопасности.

❌ А те, кто обновлялись только при детекте уязвимости - нет. Информации по уязвимости не было. Ни CVE, ни BDU. 😏

И вендор ответственности за сокрытие не несёт. 🤷‍♂️

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

Добавить комментарий

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

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

И тут я сформулирую предложение, без которого первое не работает. Если вендор знает об уязвимости в версии своего продукта, используемой у клиентов, и этот факт замалчивает, то это должно классифицироваться как КРАЙНЕ серьёзное нарушение. Если такая ситуация вскрывается, то

🔹 сертификат продукта должен отзываться, лицензия вендора анулироваться, назначаться крупный штраф

🔹 ответственный (гендир) должен лично нести за это уголовную ответственность

По какой статье? Имхо, стоит расширить 274.1, т.к. такое замалчивание создаёт риски для КИИ.

Следует сделать так, чтобы между публикацией информации об уязвимости (и последующим объяснением с регулятором) и замалчиванием вендору ВСЕГДА рационально было бы сделать выбор в пользу первого.