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

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

Докажи — покажи! Сгенерил трек в Suno про популярный способ саботажа Vul­ner­a­bil­i­ty Man­age­ment процесса. Который в итоге приводит к утечкам данных и пошифрованной инфре. 🤷‍♂️ В этот раз схалтурил, так что без рифм. 🙂 Кидайте вашим IT-шникам, если заметили, что они с вами в докажи-покажи начали играть. 😉

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Способ затормозить Vul­ner­a­bil­i­ty Man­age­ment процесс "докажи, что эксплуатабельно!" Этот способ ещё более универсальный, чем предыдущий. Заключается в том, что IT постоянно требуют от VM-щика что-то доказывать перед тем как приступить к непосредственному исправлению уязвимостей. Причём после каждого успешного доказательства IT могут отойти на новый "рубеж обороны".

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

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

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

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

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

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

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

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

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

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