Архив рубрики: Темы

В официальном канале PT вышел рекламный ролик курса по Управлению Уязвимостями

В официальном канале PT вышел рекламный ролик курса по Управлению Уязвимостями
В официальном канале PT вышел рекламный ролик курса по Управлению УязвимостямиВ официальном канале PT вышел рекламный ролик курса по Управлению Уязвимостями

В официальном канале PT вышел рекламный ролик курса по Управлению Уязвимостями. По сюжету злобный хацкер старается сломать инфраструктуру, но у него ничего не получается, т.к. для организации с выстроенным VM-процесом страшные зловреды превращаются в банан. 🍌🙂 В инфраструктуре, которая регулярно патчится особенно не развернёшься. 🤷‍♂️

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

Так что рекомендую записаться и пройти курс. Как минимум его бесплатную вводную часть. Ну а в идеале выбить у руководства бюджет на полноценный месячный курс. Не зря же я там участвовал. 😉

Старт 29 октября.

Вопрос по поводу практического применения методики оценки уровня критичности уязвимостей ФСТЭК

Вопрос по поводу практического применения методики оценки уровня критичности уязвимостей ФСТЭК

Вопрос по поводу практического применения методики оценки уровня критичности уязвимостей ФСТЭК. Наверное у каждого, кто пробовал применять методику возникал вопрос. Ну хорошо, Iinfr зависит от типа уязвимого актива. А что делать, если у меня разные типы активов (хостов) подвержены данной CVE/БДУ уязвимости? Например, у меня уязвимость Windows, которая детектируется и на десктопах, и на серверах. Какое тогда значение показателя K выбирать? Или, например, у меня уязвимости подвержены и хосты на периметре, и глубоко во в внутрянке. Тоже непонятно какое значение показателя P выбирать.

Кажется, что здесь могут быть два основных подхода:

1. Единый Iinfr для всей инфраструктуры, через максимизацию значения показателей. То есть если уязвимость есть на десктопах и серверах, то берём значение K для серверов. Если есть хоть один уязвимый хост на периметре, то берем P для средств доступных из Интернет.

✅ Плюс: в итоге получаем один уровень критичности V для уязвимости, этакий "улучшенный CVSS" и используем его так, как использовали бы CVSS.

⛔ Минус: получается, что этот максимизированный V будет аффектить все активы и задавать требования по оперативности исправления. Если у нас уязвимость на 100 десктопах и одном сервере, то будьте любезны пофиксить её на десктопах с той же срочностью, что и на сервере. Ну или сначала пофиксить на сервере, и потом пересчитать Iinfr и, соответственно, V. Получим меньшую критичность и более комфортные сроки устранения уязвимости.

2. Считаем Iinfr независимо для каждого уязвимого актива. То есть сколько у нас активов (или групп однотипных активов), столько у нас будет Iinf и, соответственно, V.

✅ Плюс: получаем атомарность, практически избавляемся от неоднозначности.

⛔ Минус: это уже будет не "улучшенный CVSS", нельзя будет сказать, а какова критичность этой CVE/БДУ, т.к. для каждого уязвимого актива она может отличаться. В прочем, с CVSS может быть та же история, если активно подкручивать Temporal часть вектора для каждого актива (на практике я правда такое не встречал).

А как правильно? 🧐 Видится, что можно жить и с первым, и со вторым вариантом. Но было бы здорово получить разъяснения ФСТЭК о том, как оно изначально задумывалось, и на это уже ориентироваться.

Upd. Получил неофициальное разъяснение от ФСТЭК. Задумывался первый вариант, но можно оба.

Выпустил отчёт по октябрьскому Linux Patch Wednesday!

Выпустил отчёт по октябрьскому Linux Patch Wednesday!

Выпустил отчёт по октябрьскому Linux Patch Wednesday! Первый! 🥳 Результатом доволен. Топ выглядит адекватно и соответствует тому, что я подсвечивал в канале.

1. Memory Corruption - Chromium (CVE-2023-5217). Это уязвимость в библиотеке libvpx, которая была самой критичной и в октябрьском Microsoft Patch Tuesday. Есть PoC на гитхабе и признаки эксплуатации вживую.
2. Remote Code Execution - GNU C Library (CVE-2023-4911). Это Qualys Looney Tunables. Давно есть PoC, но признаков эксплуатации вживую пока нет.
3. Denial of Service - Golang Go (CVE-2023-29409). Есть PoC. Vulristics определил софт как TLS, т.к. в описании уязвимости CVE никакого намека на Go. 🤷‍♂️
4. Denial of Service - HTTP/2 protocol (CVE-2023-44487). Также был в MSPT.

14. Memory Corruption - Curl (CVE-2023-38545). Для этой уязвимости появились PoC-и на Github.

Остальное без эксплоитов и признаков эксплуатации вживую.

🗒 Vulristics report

По Privilege Escalation в Cisco IOS XE (CVE-2023-20198), о которой вчера писал, прям паника в ИБшных СМИ пошла

По Privilege Escalation в Cisco IOS XE (CVE-2023-20198), о которой вчера писал, прям паника в ИБшных СМИ пошла

По Privilege Escalation в Cisco IOS XE (CVE-2023-20198), о которой вчера писал, прям паника в ИБшных СМИ пошла. Товарищи из Vulnerability Intelligence компании VulnCheck выпустили скрипт для проверки Cisco IOS XE на компрометацию и начали сканировать выдачу Shodan/Censys с устройствами Cisco. В этой выдаче где-то 140000 хостов. И вот они заявили журналисту из Bleeping Computer, что где-то половину хостов просканили и где-то 10000 устройств с имплантом обнаружили. То есть не просто уязвимых, а уже взломанных. А сколько их всего будет сложно даже предположить. 🍿

Хорошая демонстрация почему нужно отслеживать информацию об уязвимостях и быстро-быстро реагировать. Ну и стараться уменьшать свой периметр на сколько возможно, убирая от туда ненужное (типа веб-гуёв сетевых устройств).

Очередная Privilege Escalation c CVSS 10, на этот раз в Cisco IOS XE (CVE-2023-20198)

Очередная Privilege Escalation c CVSS 10, на этот раз в Cisco IOS XE (CVE-2023-20198)

Очередная Privilege Escalation c CVSS 10, на этот раз в Cisco IOS XE (CVE-2023-20198). Как и в случае с Confluence, это значит полную компрометацию актива неаутентифицированным злоумышленником.

"Cisco известно об активной эксплуатации ранее неизвестной уязвимости в функции веб-интерфейса Cisco IOS XE, когда его выставляли в Интернет или в ненадежные сети. Эта уязвимость позволяет удаленному злоумышленнику, не прошедшему аутентификацию, создать учетную запись в уязвимой системе с уровнем привилегий 15. Затем злоумышленник может использовать эту учетную запись для получения контроля над уязвимой системой." 🤷‍♂️

Есть IOCи, патчей нет. Рекомендуют клиентам отключать функцию HTTP-сервера во всех системах доступных из Интернет.

Cisco IOS XE - усовершенствованная версия Cisco IOS, построенная на базе Linux, которую Cisco представила в 2008 коду в продуктах ASR и Catalyst.

Обнаружил фичу в Телеграмме, о которой не могу молчать

Обнаружил фичу в Телеграмме, о которой не могу молчать. Хоть она напрямую с уязвимостями и безопасностью не связана. Ну, почти. Оказывается мало того, что контакту можно принудительно выставить имя и фамилию (это я давно знал и практиковал), ему оказывается можно выставить ещё и аватарку! 🤩 И эти данные будут видны только вам.

Edit contact -> Set Photo for …

Вот так просто. То есть понимаете, больше не надо держать, в голове, что пользователь с ником c00lhazker377 и аватаркой Нео из Матрицы это твой коллега Вася Иванов. Можно выставить ему имя Василий Иванов и настоящую фотку анфас. И никто об этом не узнает, Вася так и продолжит думать, что он самый анонимный аноним и оригинал.

Восхитительно, просто восхитительно. 😇 Причесал основной контакт-лист - прям залюбуешься теперь.

PS: с безопасностью-то это конечно связано - через эту фичу администрация Телеграмма вполне вероятно получит от ваших контактов вашу реальную внешность и имя-фамилию. 🤫🤷‍♂️

В CISA KEV, каталоге эксплуатируемых уязвимостей, появилась новая колонка, отвечающая за использование уязвимости в атаках шифровальщиков

В CISA KEV, каталоге эксплуатируемых уязвимостей, появилась новая колонка, отвечающая за использование уязвимости в атаках шифровальщиков

В CISA KEV, каталоге эксплуатируемых уязвимостей, появилась новая колонка, отвечающая за использование уязвимости в атаках шифровальщиков. Колонка называется "Known to be Used in Ransomware Campaigns". Возможные значения: Known и Unknown. Сейчас там 184 уязвимости, которые Known. В JSON-выгрузке также есть это поле. Неплохо, но хотелось бы, конечно, не только флажок, но и подробности какие именно шифровальщики эксплуатируют уязвимости.

Также CISA завели новую страничку с мисконфигурациями, которые используются в атаках шифровальщиков. Пока там только таблица с сервисами, использование которых может быть небезопасно (RDP, FTP, TELNET, SMB, VNC). Но, возможно, эта тема разовьётся во что-то более интересное.