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

Докажи - покажи!

Докажи - покажи! Сгенерил трек в Suno про популярный способ саботажа Vulnerability Management процесса. Который в итоге приводит к утечкам данных и пошифрованной инфре. 🤷‍♂️ В этот раз схалтурил, так что без рифм. 🙂 Кидайте вашим IT-шникам, если заметили, что они с вами в докажи-покажи начали играть. 😉

Мы уже исправили уязвимость, это сканер наверное фолсит. Да мы уже запатчили всё. Это сканер наверное фолсит… Мы уверены в том, что ваш сканер всё время фолсит. А тыыыы…

Докажи - покажи! Докажи - покажи! Докажи нам! Давай - давай!

ОК, уязвимость действительно есть. Да, похоже, уязвимость действительно есть. Но она не эксплуатабельна! Точно, она не эксплуатабельна! Сто пудов не эксплуатабельна! А тыыыы…

Докажи - покажи! Докажи - покажи! Докажи нам! Давай - давай!

Ок, уязвимость в принципе эксплуатабельна. Вроде да, она эксплуатабельна. Но только не у нас! Нет, точно не у нас! Только не в нашей инфре! А тыыыы…

Докажи - покажи! Докажи - покажи! Докажи нам! Давай - давай!

Ок, в нашей инфре эксплуатабельна. Доказали, и в нашей инфре эксплуатабельна. Но это некритичный хост! Даже если сломают - не страшно! Мы точно считаем - не страшно! А тыыыы…

Докажи - покажи! Докажи - покажи! Докажи нам! Давай - давай!

Ладно - ладно, сломают - будет плохо. Потратил кучу времени и сил, и нам доказал, будет плохо. Ты молодец, мы уязвимость эту исправим. Конкретно эту уязвимость исправим. А в остальном ваш сканер наверное фолсит… Так что даваай!

Докажи - покажи! Докажи - покажи! Докажи нам! Давай - давай!

Вчера в канале k8s (in)security был прикольный пример как в реальности может выглядеть игра в докажи-покажи

Вчера в канале k8s (in)security был прикольный пример как в реальности может выглядеть игра в докажи-покажи

Вчера в канале k8s (in)security был прикольный пример как в реальности может выглядеть игра в докажи-покажи. Автор приводит аргументы из которых должно следовать, что на хостах, где крутится кластер Kubernetes необязательно обновлять пакеты ОС. Предлагается эти аргументы опровергнуть, а также привести сценарии атаки и модель нарушителя. Для большей заманухи ИБшников это называется "риск ориентированный подход". 🙂

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

"Никто не знает всех уязвимостей Kubernetes, возможно злоумышленнику получится провалиться из контейнера на уровень хостовой ОС и начать эксплуатировать её уязвимости".

Однако хороший специалист по Куберу (как и другой сложной IT-системе) легко накидает вам в панамку аргументов почему злоумышленнику сделать это будет крайне сложно. И вы, как неспециалист, будете иметь бледный вид. 🌝

Единственный способ не проиграть шулеру - не садиться играть по его правилам. 🃏😉

Способ затормозить Vulnerability Management процесс "докажи, что эксплуатабельно!"

Способ затормозить Vulnerability Management процесс докажи, что эксплуатабельно!

Способ затормозить Vulnerability Management процесс "докажи, что эксплуатабельно!" Этот способ ещё более универсальный, чем предыдущий. Заключается в том, что IT постоянно требуют от VM-щика что-то доказывать перед тем как приступить к непосредственному исправлению уязвимостей. Причём после каждого успешного доказательства IT могут отойти на новый "рубеж обороны".

1. Мы уже исправили уязвимость, сканер наверное фолсит. VM-щику предлагается доказать, что уязвимость действительно присутствует и сканер не фолсит.

2. Да, эта уязвимость есть, но она неэксплуатабельная. VM-щику предлагается найти эксплоит и провести демонстрацию.

3. Да, эта уязвимость в принципе эксплуатабельная, но в условиях нашей инфраструктуры она неэксплуатабельная. VM-щику предлагается доказать эксплуатабельность уязвимости, при этом не навредив инфраструктуре.

4. Уязвимость на хосте, который не является критичным, и даже если он будет скомпрометирован, то ничего страшного не произойдет. VM-щику предлагается продемонстрировать критичные последствия компрометации уязвимого хоста.

А что в итоге? Допустим, потратив кучу времени и сил VM-щик добивает своего. Статус уязвимости подтверждается. IT-шники торжественно фиксят эту уязвимость. 🥳

ОДНУ. А что с остальными сотнями и тысячами? А также. Мыло-мочало, начинай сначала!

Вместо того, чтобы поднимать реальный уровень защищённости VM-щик занимается бесконечными недопенстестами. А IT-шникам в это время хорошо, пока VM-щики заняты доказыванием чего-то, их не допекают необходимостью постоянно патчиться. 😏

Как с этим бороться? Имхо, наиболее действенный способ поставить вопрос так:

🔸 Мы специалисты по уязвимостям, а вы специалисты по эксплуатации.
🔸 Мы вам говорим, что уязвимость критична и требует исправления, основываясь на информации от вендора и своей экспертизе, которой вы, объективно, не обладаете.
🔸 В случае инцидента с эксплуатацией этой уязвимости спрос за неисправленную вовремя уязвимость будет с нас, с VM-щиков, а то, что у вас было какое-то другое мнение по поводу этой уязвимости вообще никого волновать не будет, т.к. это не ваша область ответственности и не ваша специальность.
🔸 Мы вам задачу на исправление поставили и доказывать дополнительно ничего не намерены. Не будете выполнять задачу - ваши проблемы, но в случае масштабного инцидента именно вы можете попасть под 274 УК РФ ("Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей"), т.к. по правилам необходимо устанавливать обновления безопасности. 🤷‍♂️

Жёстко? Пожалуй. Я вообще за то, чтобы как-то по-хорошему договариваться. Но если пошла игра в "докажи-покажи", то тут уже по-хорошему становится сложно и нужно это сразу пресекать.