Архивы автора: Alexander Leonov

Об авторе Alexander Leonov

Привет! Меня зовут Александр. Я специалист по Управлению Уязвимостями. Подробнее обо мне можно прочитать здесь. Приглашаю подписаться на мой канал в Telegram @avleonovrus. Я обновляю его чаще, чем этот сайт. Вы можете обсудить мои посты или задать вопросы в @avleonovchat или в группе ВКонтакте. And I invite all English-speaking people to another telegram channel @avleonovcom.

А вот помните, когда был кейс со зловредным кодом в node-ipc, удаляющим содержимое файлов на хостах с российскими и белорусскими IP-адресами, многие говорили (да и я тоже), что нужно как-то заранее отслеживать буйных политизированных деятелей опенсурса, которые могут что-то подобное в свои проекты засунуть?

Добавить комментарий

А вот помните, когда был кейс со зловредным кодом в node-ipc, удаляющим содержимое файлов на хостах с российскими и белорусскими IP-адресами, многие говорили (да и я тоже), что нужно как-то заранее отслеживать буйных политизированных деятелей опенсурса, которые могут что-то подобное в свои проекты засунуть?

А вот помните, когда был кейс со зловредным кодом в node-ipc, удаляющим содержимое файлов на хостах с российскими и белорусскими IP-адресами, многие говорили (да и я тоже), что нужно как-то заранее отслеживать буйных политизированных деятелей опенсурса, которые могут что-то подобное в свои проекты засунуть? И, соответственно, их проекты стараться обходить стороной.

Как вчера выяснилось, главный по разработке ядра, используемого чуть менее чем во всех отечественных ОС, позиционирует себя расовым гекльберрифинном, борцом с "агрессией" и, видимо, большим знатоком зимней войны. И вот чего теперь? На такого буйного опенсурсера реакция вендоров отечественных ОС-ей и ИБ регуляторов будет? 🤔

Ознакомился с драмой про удаление 11 российских разработчиков из списка мейнтейнеров стабильной ветки ядра Linux

Добавить комментарий

Ознакомился с драмой про удаление 11 российских разработчиков из списка мейнтейнеров стабильной ветки ядра Linux

Ознакомился с драмой про удаление 11 российских разработчиков из списка мейнтейнеров стабильной ветки ядра Linux. Поглядел оригинальный тред, темы с обсуждением на Хабре и на OpenNet.

Так-то ничего нового, уже после скандала с Baikal Electronics было понятно, что нормально контрибьютить в ядро Linux российским организациям (да и просто специалистам с российским бэкграундом) не дадут.

Могу только повторить:

"Предсказуемо. Опенсурс-опенсурсом, а Linux Foundation это конкретная американская организация. Как и банящий разработчиков GitHub это Microsoft. Понятно каким регуляциям они подчиняются.

Поэтому ядро Linux должно быть своё. Например, от ИСП РАН. И репозитории должны быть свои. И дистрибутивы Linux. Это породит дополнительную фрагментацию и несовместимость, но это выглядит как неизбежные издержки."

И от термина "Linux" тоже неплохо бы уйти в перспективе. 🤷‍♂️

На прогибы Торвальдса сотоварищи смотреть, конечно, тошновато, но другого я от just4fun-щика и не ожидал.

В понедельник 21 октября снова вышли обновления для критичной уязвимости Remote Code Execution - VMware vCenter (CVE-2024-38812)

Добавить комментарий

В понедельник 21 октября снова вышли обновления для критичной уязвимости Remote Code Execution - VMware vCenter (CVE-2024-38812)

В понедельник 21 октября снова вышли обновления для критичной уязвимости Remote Code Execution - VMware vCenter (CVE-2024-38812). Стоп, а разве обновления для неё не вышли ещё 17 сентября? Вышли, но их оказалось недостаточно.

"VMware by Broadcom определили, что исправления vCenter, выпущенные 17 сентября 2024 г., устраняют CVE-2024-38812 не полностью. Всем клиентам настоятельно рекомендуется применить исправления, которые в настоящее время перечислены в матрице реагирования. Кроме того, также доступны исправления для линейки 8.0 U2."

Если у вас используется VMware vCenter, обратите внимание и обновитесь ещё раз. Текущие исправленные версии VMware vCenter Server 7.0 U3t, 8.0 U2e и 8.0 U3d.

Также обновления доступны для решения VMware Cloud Foundation.

Повысилась критичность уязвимости Elevation of Privilege - Windows Kernel-Mode Driver (CVE-2024-35250)

Добавить комментарий

Повысилась критичность уязвимости Elevation of Privilege - Windows Kernel-Mode Driver (CVE-2024-35250)

Повысилась критичность уязвимости Elevation of Privilege - Windows Kernel-Mode Driver (CVE-2024-35250). Эта уязвимость была исправлена в июньском Microsoft Patch Tuesday. Как и в случае с уязвимостью CVE-2024-30090, её обнаружил исследователь с ником Angelboy из компании DEVCORE. И она также касается фреймворка Kernel Streaming, а конкретно его ядерного компонента - драйвера ks.sys. Подробности по этой уязвимости Angelboy написал в посте 23 августа.

13 октября на GitHub появился PoC эксплоита от пользователя varwara. Также в репозитории есть видео, демонстрирующее запуск эксплоита и получение прав System.

Обновления доступны для Windows 10 и 11, а также Windows Server от 2008 до 2022.

Повысилась критичность уязвимости Elevation of Privilege - Microsoft Streaming Service (CVE-2024-30090)

Добавить комментарий

Повысилась критичность уязвимости Elevation of Privilege - Microsoft Streaming Service (CVE-2024-30090)

Повысилась критичность уязвимости Elevation of Privilege - Microsoft Streaming Service (CVE-2024-30090). Уязвимость была исправлена в рамках июньского Microsoft Patch Tuesday. На тот момент никто эту уязвимость не выделял. Уязвимость обнаружил исследователь с ником Angelboy из компании DEVCORE. Подробности по уязвимости содержатся в серии его постов, опубликованных 23 августа и 5 октября.

Уязвимость касается фреймворка Kernel Streaming, который отвечает за обработку потоковых данных. Он используется, например, когда системе необходимо прочитать данные с ваших микрофонов или веб-камер в оперативную память. Этот фреймворк работает, в основном, в режиме ядра.

5 октября Angelboy выложил видео эксплуатации уязвимости, демонстрирующее получение интерактивной консоли с правами System.

17 октября исследователь с ником Dor00tkit выложил PoC эксплоита на GitHub.

Обновления доступны для Windows 10 и 11, а также Windows Server от 2008 до 2022.

16 октября Китайская Ассоциация Безопасности Киберпространства (КАБК, 中国网络空间安全协会) выпустила интересный пост, направленный против компании Intel

Добавить комментарий

16 октября Китайская Ассоциация Безопасности Киберпространства (КАБК, 中国网络空间安全协会) выпустила интересный пост, направленный против компании Intel

16 октября Китайская Ассоциация Безопасности Киберпространства (КАБК, 中国网络空间安全协会) выпустила интересный пост, направленный против компании Intel. Каких-то новых откровений в посте нет. Это скорее подборка разнообразных проблем с безопасностью процессоров Intel за много лет. Отдельно выделили ресёрч по безопасности Intel ME Марка Ермолова и Максима Горячего. 👍

То, что вызывает интерес, это очень жёсткая тональность поста. Авторы не стесняются называть Intel ME бэкдором NSA, а использование продукции Intel серьёзной угрозой национальной безопасности Китая. Более того, они рекомендуют начать проверку сетевой безопасности продуктов Intel, продаваемых в Китае. 😈

Учитывая, что КАКБ это не группка ноунеймов, а организация одобренная Государственной канцелярией интернет-информации КНР (国家互联网信息办公室), вполне вероятно, что призывы возымеют действие.

Intel ответили на пост отпиской: "безопасность и качество продуктов является их постоянным приоритетом". 😏👌

Сравнение сканеров уязвимостей по качеству детектирования - важная тема

Добавить комментарий

Сравнение сканеров уязвимостей по качеству детектирования - важная тема

Сравнение сканеров уязвимостей по качеству детектирования - важная тема. Несмотря на довольно очевидные проблемы методологий конкретных сравнений, они хоть в какой-то мере побуждают клиентов снять розовые очки.

"Получается можно купить дорогое VM-решение и НЕ получить надёжный поток продетектированных уязвимостей? Даже критичных и эксплуатабельных?" 😯

Вот представьте себе! 🤷‍♂️ VM-вендор может

🔹 вообще не поддерживать какие-то софты
🔹 не детектировать какие-то CVE для каких-то софтов
🔹 только декларировать, что детектирует какие-то CVE, а на самом деле детекты будут отрабатывать некорректно; или будут отрабатывать корректно только в определённых режимах (например, с аутентификацией)

Я не понимаю, когда говорят, что сканер детектирует слишком много уязвимостей в инфраструктуре и исправлять нужно 2%. Как по мне, беда в обратном - уязвимостей детектируется слишком мало, они детектируются не все. И среди недотектируемых могут быть самые опасные.

Upd. переформулировал