Архив за месяц: Июль 2025

Вы точно знаете своих удалёнщиков?

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

Вы точно знаете своих удалёнщиков?

Вы точно знаете своих удалёнщиков? Как хитрые товарищи из одной изолированной страны зарабатывают сотни млн. $ и усиливают кибероперации, используя западную расслабленность и любовь к удалённой работе? 💸😏

🔹 Они натаскивают своих ІТ-шников.

🔹 Перевозят их в нейтральные страны с быстрым интернетом.

🔹 Трудоустраивают в западные компании, преимущественно в американские.

🔹 ІТ-шники (тысячи их!) усердно работают работу, перечисляя большую часть своих западных зарплат в пользу Родины. Параллельно сливают данные и дают доступ к инфраструктуре работодателей. Двойной профит! 🤑

А требования в вакансиях к наличию гражданства и работе только из США? 🥸 Легко обходятся! 😏 На днях американку приговорили к 8,5 годам за поддержание фермы из 90 ноутбуков для имитации работы из США.

Бороться с этим возможно только отменой удалёнки и значительным усилением background checks. Но компании вряд ли на это пойдут. И не стоит забывать про проблему многочисленных подрядчиков. 😉

Иногда общение стоит минимизировать

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

Иногда общение стоит минимизировать

Иногда общение стоит минимизировать. Главная проблема в работе с уязвимостями - это НЕ сами уязвимости. Это необходимость постоянно общаться с людьми, которые этого общения не хотят и которым ты не нравишься. 🫩 Это актуально и при пушинге устранения уязвимостей в инфраструктуре, и при сдаче-приёмке уязвимостей, найденных в ходе багбаунти.

Поэтому я сторонник того, чтобы неприятное общение максимально сокращать и формализовывать. Игры в "докажи-покажи" отнимают массу сил и времени, а когда общение неизбежно заходит в тупик, обе стороны всё равно начинают действовать формально. 🤷‍♂️ Так почему бы не поступать так с самого начала? 😏

➡️ В качестве примера рекомендую ознакомиться с эпичной историей, как Игорь Агиевич сдавал уязвимость в блокчейне Hyperledger Fabric (CVE-2024-45244). Имхо, вместо общения в такой ситуации было бы достаточно скинуть вендору ресёрч и PoC, выждать 3 месяца, зарегать CVE и, без особых рефлексией, сделать full disclosure. 🤷‍♂️😈

Не может быть, оказывается MAX не pivacy-driven messenger! 😱

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

Не может быть, оказывается MAX не pivacy-driven messenger! 😱

Не может быть, оказывается MAX не pivacy-driven messenger! 😱😆 Раньше про MAX набрасывали, что он небезопасный. После объявления багбаунти перестали. 🙂🤷‍♂️ Теперь разгоняют, что MAX "неприватный". Для пруфов ковыряют Android-клиент и скринят текст EULA. 😏

Моё мнение такое:

🔹 Собирает ли MAX информацию о пользователях? Безусловно. Как и любое приложение "фонарик" на вашем устройстве. Зачем? В основном, чтобы показывать вам релевантную рекламу в сервисах VK. По сравнению с тем, что собирают операционные системы и веб-браузеры это крохи и ни о чём.

🔹 Сообщит ли MAX о ваших тёмных делишках в правоохранительные органы? 🌚 Если от этих органов придёт запрос, то сообщит. Как и любой другой мессенджер и веб-сервис. 🤷‍♂️

🔹 Мог бы MAX быть privacy-driven? Как условный Signal? Или An0m? 😉 В принципе да. Но задача создать инструмент, которым могли бы безбоязненно пользоваться всякого рода злодеи и не ставилась. 😏 Наоборот, злодеям в нём должно быть МАКСимально некомфортно. 😈

Нетрадиционное использование комплаенс-сканирования

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

Нетрадиционное использование комплаенс-сканирования

Нетрадиционное использование комплаенс-сканирования. Как правило, комплаенс-сканирование в организации преследует две цели:

🔹 Удостовериться, что настройки сетевых хостов удовлетворяют регуляторным требованиям.

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

Иногда эти цели совпадают, иногда не особо. 😉 Но есть и третья цель:

🔻 Удостовериться, что настройки хостов позволяют средствам защиты информации работать адекватно.

В качестве примера можно привести статью моего коллеги по PT ESC, Романа Чернова, о настройке аудита на Linux-хостах таким образом, чтобы данных было достаточно для надёжного детектирования инцидентов SIEM-ом.

Как можно видеть на схеме, отслеживать корректность настроек логирования в Linux не так-то просто. 😱 Но эту задачу можно решать автоматизированно с помощью комплаенс-сканов MaxPatrol HCC. 😉

Кибероружие следует сдавать государству

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

Кибероружие следует сдавать государству

Кибероружие следует сдавать государству. Продолжу накидывать аргументы за централизацию репортинга уязвимостей через государственного регулятора. Давайте проведём аналогию между уязвимостями и оружием. Идея не нова, термин "cyberweapon" употребляется десятки лет.

Если человек идёт по дороге и видит, допустим, пистолет, что он вправе с ним легально сделать? Может ли он его использовать по своему усмотрению? Может ли он его продать? Может ли он его вывезти за пределы страны?

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

Тогда почему сейчас считается нормальным передавать уязвимости ("кибероружие") разработчикам ПО из недружественных стран? Вместо использования этой важной информации во благо нашей страны? Как по мне, это следует изменить.

Интригующие статьи про CVSS от Kaspersky

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

Интригующие статьи про CVSS от Kaspersky

Интригующие статьи про CVSS от Kaspersky. Ссылки на вполне годные статьи на днях опубликовали в канале Kaspersky B2B:

🔹 В первой рассматривают историю развития стандарта и общие принципы оценки уязвимостей с помощью CVSS.

🔹 Во второй описывают основные проблемы при работе с CVSS. Проблемы сводятся к тому, что CVSS - это субъективная оценка критичности самой уязвимости, а не оценка риска эксплуатации этой уязвимости в инфраструктуре. Нельзя по одному CVSS сделать вывод, какую уязвимость следует устранять в первую очередь. Уязвимость со средним CVSS, но на критичных хостах, вполне может привести к компрометации всей инфраструктуры организации.

А где интрига? В том, что решение проблем CVSS они видят в продуктах типа RBVM ("Risk-Based" VM). Ещё одна аббревиатура. 😉 Такого продукта в портфеле Kaspersky сейчас нет, но ходили слухи, что они над ним активно работают. Похоже на маркетинговый "прогрев" перед скорым релизом. 🤔

Лично я уже прогрелся и с нетерпением жду. 🙂🔥

Эксплуатация ToolShell (CVE-2025-53770) на серверах NNSA

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

Эксплуатация ToolShell (CVE-2025-53770) на серверах NNSA

Эксплуатация ToolShell (CVE-2025-53770) на серверах NNSA. Пока самая интересная жертва атак с эксплуатацией трендовой уязвимости SharePoint - Национальное управление по ядерной безопасности США (National Nuclear Security Administration, NNSA). Пресс-секретарь Министерства энергетики США (Department of Energy, DOE), в которое входит NNSA, заявил следующее:

"В пятницу, 18 июля, эксплуатация уязвимости нулевого дня Microsoft SharePoint начала затрагивать Министерство энергетики, включая NNSA. […] Пострадало очень небольшое количество систем. Все затронутые системы DOE восстанавливаются. NNSA принимает необходимые меры для снижения риска и перехода на другие решения по мере необходимости."

NNSA управляет запасами ядерного оружия США, включая его тестирование и безопасную транспортировку, занимается ядерными силовыми установками, термоядерным синтезом и т.д.

Немерено секретной информации! И при этом SharePoint. 🤷‍♂️ И, видимо, где-то на периметре. 🤡🤦‍♂️