https://ruler-project.github.io/ruler-project/

Проект направленный на документирование какие именно логи полезно собирать для расследования.

Так как нашей команде Luntry часто приходится участвовать в различных проектах по безопасности Kubernetes систем: аудиты, пентесты, архитектурные проекты. То приходится порой думать о некоторых моментах, к которым просто так не придешь, никогда об этом не задумываясь. Одним из таких последних моментов был момент, когда требовалось понять стоит ли определенные высокопривелигерованные микросервисы (там хороший SA) располагать в одном Namespace или расселить на разные. При решении этой задачи как раз и пригодился наш атакующий опыт.

Смысл заключается в том, что если у злоумышленника на Node есть возможность создать Pod в таком Namespace (где и эти высокопривелигерованные сервисы), даже с учетом того что стоит множества правильных политик PolicyEnginе (против Bad Pods и тд), то у него все равно остаётся возможность смонтировать внутрь такого Pod интересующий его SA из того же самого Namespace! Далее когда он смонтируется туда, то можно смело забирать его с Node ...

Как митигейшены можно сделать следующее:
1) Чтобы уменьшить риск компрометации, критичные сервисы разделать по Namespaces
2) Namespaces c критичными/инфраструктурными сервисами привязывать только к определенным инфраструктурным Nodes
3) Писать политики PolicyEngine, которые проверяют использование критичных SA, только в определенных сервисах

P.S. Еще была крутая идея для атаки - все это провернуть через StaticPod, но там нельзя ссылать на другие ресурсы (на тот же SA)…

P.S.S. Ближайшие дни мы на HighLoad++ 2023 Msk и будем рады пообщаться лично =)

Моя первая презентация с вчерашнего #soctech про мониторинг угроз от|на подрядчиков. Я специально сделал disclaimer во время выступления, что, во-первых, вариантов угроз на цепочку поставок достаточно много (от аппаратных имплантов до несанкционированных действий сотрудников подрядчиков), а во-вторых, по каждой из них можно отдельно говорить не менее 20 минут, а у меня на все было 20 минут. Так что в презентации некоторые мысли о том, на что стоит обратить внимание...

VMware исправила критическую уязвимость обхода аутентификации в платформе управления ЦОД Cloud Director, которая более двух недель с момента ее обнаружения 14 ноября оставалась без патча.

CVE-2023-34060 влияет только на устройства под управлением VCD Appliance 10.5, которые ранее были обновлены с более старой версии.

Удаленные злоумышленники могут использовать ошибку CVE-2023-34060 в атаках низкой сложности, не требующих взаимодействия с пользователем.

В обновленной версии VMware Cloud Director Appliance 10.5 злоумышленник, имеющий сетевой доступ к устройству, может обойти ограничения входа в систему при аутентификации на порту 22 (ssh) или порту 5480 (консоль управления устройством).

Такой обход отсутствует на порту 443 (поставщик VCD и вход клиента). При новой установке VMware Cloud Director Appliance 10.5 обход также отсутствует.

Помимо патча поставщик представил рекомендации по VMSA-2023-0026 и временное решение для администраторов, которым потребуется время для установки исправлений.

Обходной путь работает только для затронутых версий VCD Appliance 10.5.0 и требует запуска специального сценария.

https://thehackernews.com/2023/11/us-uk-and-global-partners-release.html

"The U.K. and U.S., along with international partners from 16 other countries, have released new guidelines for the development of secure artificial intelligence (AI) systems."

Проект CNCF Cloud Native Interactive Landscape обновился и получил версию 2.0!

По прежнему гигантский и ребята перестали гнаться уместить его на один экран и более удобно разместили на странице, добавив различную статистику, более удобные фильтры и инструкцию по работе с этим landscape.

Разработана новая атака по побочному каналу под названием SLAM, которая использует аппаратные функции повышения безопасности для будущих процессоров Intel, AMD и Arm, позволяя получить хэш корневого пароля из памяти ядра.

SLAM - это атака временного выполнения, которая использует преимущества функции памяти, обеспечивающие использование ПО нетранслированных битов адреса в 64-битных линейных адресах для хранения метаданных.

Производители процессоров воплощают механизм и называют его по-разному: у Intel - это линейная маскировка адреса (LAM), AMD называет его игнорированием верхнего адреса (UAI), а Arm - функцей игнорирования верхнего байта (TBI).

Атака SLAM (означает Spectre, основанный на линейной маскировке адресов) была обнаружена командой исследователей VUSec Group в Vrije Universiteit Amsterdam.

Эксперты продемострировали свои выводы, разработав комплексный эксплойт Spectre, нацеленный на LAM на будущих процессорах Intel.

Эксплойт фокусируется на более позднем варианте атаки Spectre BHI, который обходит некоторые аппаратные средства защиты, реализованные в ответ на оригинальный Spectre, и злоупотребляет различными гаджетами в последней версии ядра Linux для утечки хэша пароля root из памяти ядра в течение нескольких минут.

Код и данные для воспроизведения SLAM-атаки доступны в репозитории VUSec на GitHub. Исследователи также опубликовали технический документ с пояснениями того, как работает атака.

По данным VUSec, SLAM будет влиять главным образом на чипы в будущем, соответствующие определенным критериям. Причинами этого является отсутствие строгих проверок каноничности в будущих конструкциях микросхем.

Таким образом, хотя и расширенные аппаратные функции улучшают безопасность и управление памятью, но также фактически увеличивают поверхность для атак Spectre, о чем были проинформированы производители Intel, AMD и Arm.

Intel, одна из спонсоров исследования, заявила, что планирует предоставить рекомендации по программному обеспечению до выпуска процессоров с поддержкой LAM.

Компания Arm опубликовала рекомендацию, в которой объясняется, что ее системы уже принимают меры против Spectre v2 и Spectre-BHB и не планируют никаких дальнейших действий в ответ на SLAM.

AMD также указала на текущие меры по смягчению последствий Spectre v2 для борьбы с атакой SLAM и не предоставила никаких указаний или обновлений, которые могли бы снизить риск.

А вот, инженеры Linux создали исправления для отключения функции безопасности по умолчанию до тех пор, пока не станут доступны рекомендации.