Pull to refresh
33
1.2
Jet CSIRT @CSIRT

Центр мониторинга и реагирования на инциденты ИБ

В принципе pkexec возможно использовать и в headless режиме, все зависит от используемого дистрибутива и ПО. Если Вы планируете остановиться на воркэраунде, то Вам предварительно стоит уточнить нюансы использования polkit и его компонентов у мейнтейнеров используемых Вами дистрибутивов и ПО, и следовать их рекомендациям. Иначе применение воркэраунда остается на Ваш страх и риск. Лучше всего, конечно, установить актуальные патчи.

Уязвим именно pkexec, воркэраунд ломает тот функционал, где задействован pkexec (т.е. через него уже не получится получить повышенные привилегии). Например, управлении системными настройками в Вашем desktop environment через GUI может сломаться. Таким образом, лучше применить патч (хотя, как и в случае с log4shell высока вероятность, что фикс будет обойден). Наличие pkexec следует искать не в системных логах, а на файловой системе, например через

ls -lash /usr/bin/pkexec

4ekin, спасибо за фидбэк! Конкретно табличка из статьи скорее показательная, чем реальная. Её задача — продемонстрировать подход к вычислению decay_rate под определенный тип инфраструктуры с определенным уровнем зрелости ИБ. Так, для инфраструктур с низким уровнем зрелости скорость выхода срока годности индикаторов будет ниже, чем у более зрелых. Понятно, что для полностью захардеренной инфраструктуры с отлаженными процессами реагирования на инциденты, патчинга, управления уязвимостями и т.п списать эксплуатируемый индикатор можно раньше, чем для инфраструктуры с базовыми методами защиты, т.к. для неё повторное срабатывание будет менее критичным (индикатор с большей долей вероятности будет обнаружен повторно и заблокирован). В реальности же для получения такой статистики нужен некий буферный период, в рамках которого мы начинаем списывать индикаторы после определенного срока и наблюдаем за тем, какие были списаны раньше времени, а какие корректно, причем для каждого контролируемого типа. На основании этих данных определяем decay_rate обратным преобразованием формулы CIRCL. Так у нас получается неправильный decay_rate для рано списанных и правильный для списанных корректно. Затем среднее значение корректного decay_rate нужно умножить на коэффициент уровня зрелости ИБ этой инфраструктуры.
Вредонос был нацелен на Windows узлы, данных по распределению ОС в инфраструктуре, увы, нет. Очевидно только то, что в офисных сегментах большая часть машин была именно под Windows.
Именно об этом и речь. Пока что не ясно, действительно ли данный вредонос создан для вымогательства или это все ширма, а настоящяя цель — уничтожение данных (ввиду полного вывода из строя зараженных узлов в ряде случаев) как у wannacry и notpetya.
Исторически лучшей практикой действительно являлась изоляция промышленного сегмента от корпоративного путем того же «воздушного зазора». Однако в условиях современного техпроцесса это не всегда приемлимо ввиду высокой степени интеграции производства и бизнес-систем.
Касательно hydro — точно известно, что офисный сегмент «лег», атака вероятнее всего распространялась политиками на доменные машины, однако нет информации о том, в какой мере были изолированы их промышленные сегменты и насколько правильно соблюден баланс безопасности и нужд производства. На пресс-конференции заявлялось, что изоляция заводов была произведена в качестве мер предосторожности, что, естественно не дает много информации о «прямоте» архитектуры :) Можно лишь предполагать, что где-то сегментирование/компенсационные ИБ меры были недостаточными, раз не на всем производстве выпуск продукции восстановлен в полном объеме.
Вариантов довольно много: от фишинговых писем, содержащих вредоносные вложения, до эксплуатации уязвимостей, например PrivExchange.

В ближайшее время мы опубликуем цикл статей по атакам и защите AD.

Information

Rating
1,078-th
Location
Россия
Works in
Registered
Activity