🤔 А что, если использовать метод определения security-патчей для выявления закладок в бинарном коде?

Гипотеза: метод и система определения security-исправлений в бинарном коде может быть применима для выявления вредоносных модификаций (закладок/имплантов) в приложениях.

Этапы исследования для проверки гипотезы:
1. подбор примеров (семплов) модификаций кода, являющихся закладками;
2. формирование CFG для подобранных семплов;
3. обучение сиамской сети для определения сходства заданного CFG с целевым CFG, полученным от семплов.

А теперь вопрос: студент направления ИБ, готов ли ты взять эту работу в качестве темы своей курсовой в весеннем семестре? Если да, то пиши в ЛС (контакты в описании канала).

Вы готовы, самураи?

Сетевая ИБ, оверлейные технологии, DevSecOps, криптография, стеганография, обнаружение и противодействие атакам, поиск уязвимостей, безопасность ОС, технологии блокчейн..
Это наиболее популярные тематики научно-исследовательских работ на кафедре

> Только начало: уже загружено 650 страниц ваших отчетов о НИР (средний объем отчета 59 страниц)
> Идейно работы можно разделить на 3 типа: разработка программных решений, исследовательские, а также связанные с учебным процессом кафедры и в перспективе интегрируемые в него

Шепотом можно произнести: пора думать о НИР следующего семестра

Информация для тех, кто готов. Наш преподаватель Денис Николаевич Макрушин предлагает в рамках НИР проверить такую гипотезу — метод и система определения security-исправлений в бинарном коде могут быть применимы для выявления вредоносных модификаций в приложениях

🌀Подробнее о методе

Разработчик, будь внимательнее: уязвимость в GitLab позволяет захватить учетную запись

CVE-2023-7028 позволяет атакующему изменить значение электронной почты в механизме восстановления пароля при отправке специально сформированного запроса, в котором нулевой элемент массива содержит действительный email, а следующий элемент - email злоумышленника.

Уязвимые версии:

все версии с 16.1 до 16.1.6,
16.2 до 16.2.9,
16.3 до 16.3.7,
16.4 до 16.4.5,
16.5 до 16.5.6,
16.6 до 16.6.4,
16.7 до 16.7.2.

PoC: 1, 2.

Прогнозы 2024: развитие угроз

Напоминаю: мы с вами строим технологии и процессы защиты в асимметричной среде.

Асимметрия заключается в нашей прозрачности для атакующего. Как в дикой природе: хищника не видно, пока он изучает жертву и готовится напасть. Жертва изучает хищника только в момент нападения.

Сделаем прогноз о развитии кибер-угроз в 2024 году:

* Генеративные сети значительно ускорят «time-to-market» разработчикам вредоносного кода. С одной стороны, это приведет к росту случайных атак и повысит вероятность обнаружения антивирусным ПО, а с другой - усложнит атрибуцию авторов вредоносного кода.

* Вырастет количество фейковых «утечек», в которых для генерации синтетических данных использовались LLM. И в итоге, в даркнете вырастет количество предложений о продаже фейковых данных.

* Увидим больше имплантов, написанных на Go и Rust. И как следствие, будет больше атак с использованием кросс-платформенных вредоносов.

* Увеличится количество cloud-native ransomware: разработчики вредоносного кода будут внедрять функции инвентаризации storage-аккаунтов и поддержку API для манипуляции с облачным хранилищем данных.

* Увидим больше фишинговых email, сгенерированных LLM. Больше аналогичного фрода в мессенджерах. Например, мошенники уже синтезируют голосовые сообщения в Телеграм.

Технологические тренды 2024: оптимизация и гиперавтоматизация в средствах защиты

Прогнозы по угрозам сделали. Теперь подумаем о трендах в технологиях защиты.

Опишу их двумя терминами: гиперавтоматизация и оптимизация. Во всех аспектах. От выявления аномалий до последующего реагирования на инциденты. И не обязательно с использованием алгоритмов машинного обучения.

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

А вот с гиперавтоматизацией нужно разобраться. Некоторые технологические гиганты определяют гиперавтоматизацию, как «концепцию автоматизации всего, что возможно автоматизировать в организации». Другими словами: исключить человеческий фактор из всех бизнес-процессов.

Еще в 2021 году Gartner утверждал, что внедрение подхода гиперавтоматизации превращается «из опционального требования в необходимое условие для выживания бизнеса». Только Gartner не уточнял формальные критерии для реализации этого подхода. И отличия между «автоматизацией» и «гиперавтоматизацией» все еще четко не определены.

В 2024 году у нас по-прежнему есть возможность определить эти критерии самостоятельно:

1. описание абсолютно всех процессов жизненного цикла ИБ для заданной системы;
2. технологическая возможность автоматизации всех описанных процессов;
3. при допустимой вариативности процесса система способна без участия человека определить эффективное решение (вариацию);
4. эффективность решения - метрика, которую система способна определять самостоятельно на основе бизнес-показателей.

В этом году мы увидим больше вендоров, которые используют подход гиперавтоматизации для задач ИБ. Например, в январе очередной раунд инвестиций поднял стартап Torq. Теперь последим за секцией Innovation Sandbox на RSA Conference 2024 и посчитаем количество компаний, которые что-то “гиперавтоматизируют с использованием AI”.

Вторая сессия на факультете «Стратегического управления» и ключевые инсайты:

* Курс «Разработка и принятие управленческих решений» дал новый инструмент - теорию решения изобретательских задач (ТРИЗ). Теперь при описании Definition of Done какой-либо задачи нужно помнить о необходимости сначала сформулировать «идеальный конечный результат», а затем браться за поиск решения. Цитаты на полях:

«инновация - это решение противоречия»

«компромисс - слабое решение»

* «Стратегический менеджмент» напомнил про теорию ограничений (theory of constraints, ТОС), которую ранее упоминал в контексте построения Security Operation Center. ТОС рассматривает любую систему, как цепь взаимозависимых элементов. Поэтому вся цепь не может быть сильнее, чем ее самое слабое звено. Ограничение в производстве и бизнесе является основной причиной снижения его эффективности. Хочешь повысить эффективность - ищи ограничения.

А еще на полях записал цитату:

Стратегия - это также ответ на вопросы «что мы не делаем?» и «от каких возможностей отказываемся?»

На GitHub больше 1000 уязвимых репозиториев: в чём суть угрозы и что с этим делать

Опубликовали результаты своего исследования, в котором проверили 6349287 репозиториев Github на возможность захвата. Получили следующие данные:

* захват учетной записи возможен для 986 уникальных аккаунтов, то есть все репозитории этих пользователей уязвимы для атаки RepoJacking;
* обнаружили 1363 репозиториев, уязвимых к RepoJacking.

Методику исследования опубликовали в статье. Делись этим материалом с другом-разработчиком, чтобы он мог проверить свой код на отсутствие уязвимых зависимостей.

Инструменты поиска репозиториев, доступных для захвата

Для анализа репозиториев на устойчивость к RepoJacking-атакам мы опубликовали набор скриптов, которые поготовили в процессе исследования.

Скрипты потребуются для реализации ключевых шагов методики:

1. извлечение всех GitHub-ссылок из целевого репозитория;
2. сканирование и получение битых ссылок;
3. проверка GitHub-аккаунтов, доступных для атаки «account takeover»;
4. (опционально) регистрация доступного username.

Если в результате шага 3 в файле result_github.txt нашлись какие-либо ссылки, то это повод убрать данные зависимости из своего кода.

Методику и скрипты можно адаптировать не только для GitHub и не только для repository hijacking, но также для поиска уязвимых зависимостей в других доступных открытых репозиториях, пакетных менеджерах и внешних источниках артефактов.

Что, если генеративный ИИ может упростить атаки typosquatting на зависимости в разработке?

Typosquatting в разработке - это загрузка в репозиторий вредоносного пакета с именем, похожим на название популярного и уже существующего пакета.

На что рассчитывает атакующий в этом сценарии? На опечатку, в результате которой подключится вредоносный компонент. Например, Python-разработчик допустил ошибку в файле requirements.txt и вместо популярного пакета “requests” подключил “requesst” - а там вредоносный код.

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

LLM может упростить процесс генерации названий. Пример запроса: generate 100500 words with typo for word “requests”.

Но исследователь может использовать эту же технику генерации словарей с наименованиями для сканирования пакетного репозитория на появление вредоносных пакетов. Кто хочет провести исследование?

Кстати, не пора ли запускать раздел #Инсайт, в котором будем описывать гипотезы для исследований?

💯- запускаем
🗿- отпускаем

Инвентарь для оффлайн-исследования готов: вещи собраны, плейлист заряжен.

Чего не хватает: ⛷️ , 🏂 или 🥄?

Есть ли что-то общее между космическим и киберпространством?

Для исследователя точно есть. Например, можно переиспользовать методы открытия космических объектов для выявления аномалий в сетях.

В 2022 году российский астроном Владимир Георгиевич Сурдин открыл секцию «Прорывные технологии в ИБ» интересным докладом про новые технологии для поиска экзопланет. А я открыл для себя инсайт, что возможно применять математические модели астрономии для задач кибербезопасности. И добавил в эту секцию тему машинного обучения в системах симуляции атак.

#Инсайт

Лови открытку! У нас их много.

Атака на атакующего: уязвимость RCE в популярном у Red Team фреймворке Empire

Те, кто использовал опен-сорсный инструмент Empire для пентеста и ред тиминга, знают его возможности на этапе постэксплуатации.

Фреймворк состоит из четырех компонент, один из которых - Agent. Его задача заключается в установке канала управления и эксфильтрации данных с атакуемого хоста.

Уязвимость, позволяющая осуществить обход каталога (directory traversal), обнаружена в коммуникации между Agent и сервером управления. Можно подменить запросы агента и загрузить на сервер любой файл в произвольной директории.

Для этой уязвимости уже доступен PoC, поэтому пентестры и ред тимеры, проверяйте свою инфраструктуру на наличие имплантов.

Топ-10 техник атак на веб-приложения в 2023 году

Компания Portswigger при поддержке сообщества исследователей и багхантеров составляет рейтинг исследований безопасности веб-приложений. Кстати, в рейтинге 2021 года отметилось исследование нашей команды Advanced Security Research, которое было посвящено технике JS Prototype Pollution.

В 2023 году первое место в рейтинге заняло исследование “Smashing the state machine: the true potential of web race conditions”, в котором автор подсветил новые аспекты атак Race Condition в современных приложениях.

Скомпрометированные учетки становятся основным вектором проникновения

В недавнем отчете подразделения Palo Alto Unit42 отмечен тренд: использование скомпрометированных учетных записей становится ключевой тактикой атакующих для обеспечения первичного доступа в организацию. Если в 2022 году для этой задачи в основном использовался фишинг, то уже в 2023 году эта техника отошла на второй план. Доля взломанных учёток: 20.5% от всех зафиксированных инцидентов.

Способов получить доступ к учетной записи - множество. О некоторых наиболее распространенных мы уже рассказывали. Чтобы исключить этот вектор атак, мы разработали и добавили в портфолио облачный сервис многофакторной аутентификации. И дополнили эту технологию новыми ценностями для бизнеса:

* подключение инфраструктуры за несколько дней;
* быстрое масштабирование на все филиалы;
* исключение капитальных затрат на инфраструктуру и внедрение.

И пусть MFA станет обязательной частью парольной политики в любой организации, где используются пароли.

Старое фото команды GReAT, на котором каждый сотрудник в образе какого-то героя. Где-то можно узнать персонажей из “Assassin’s Creed” или “Kill Bill”.

А мой персонаж просто не выспался. Потому что раскручивал какую-то уязвимость 🤪 Возможно, в домашнем роутере.

Да пребудет с нами бодрая неделя!

Опубликован NIST Cybersecurity Framework v.2

О ключевом нововведении фреймворка рассказывал летом, когда NIST опубликовал драфт документа. Основные обновления финальной версии:

* расширен скоп применения: теперь в фокусе не только критически важная инфраструктура, но и организации любого размера;
* Govern: добавлена новая функция, которая выделяет приоритет политикам управления ИБ;
* добавлен новый раздел “Supply Chain Risk Management”, который уделяет внимание устойчивому тренду защиты цепочки поставок;
* Implementation Examples: обновляемые примеры внедрения рекомендаций.

FinDevSecOps или безопасная разработка в финтехе: перспективы, вызовы и совместные планы

Вместе с коллегами из Ассоциации ФинТех в формате круглого стола обсудим актуальные вопросы безопасной разработки и коллаборации между различными крупными игроками финансовой отрасли.

Безопасная разработка все больше и больше становится важной составляющей технологического ландшафта компаний.
Сообщество FinDevSecOps создано в 2023 году на площадке Ассоциации ФинТех при поддержке Московской биржи для объединения усилий участников финансового рынка и смежных отраслей в развитии безопасной разработки программного обеспечения и opensource-решений. В сообщество вошли эксперты - представители участников Ассоциации.

На круглом столе с лидерами FinDevSecOps обсудим:

1. ТТМ против appsec: увеличивает ли внедрение процессов и инструментов DevSecOps время разработки? Как найти баланс между бизнесом и безопасной разработкой?

2. ИБ против ИТ или вместе с ИТ? Какая должна быть стратегия безопасности в финансовых компаниях?

3. Отличие процессов разработки в финансовых компаниях от нефинансовых? Перспективы развития регуляторных требований.

Увидимся на DevOpsConf 2024.

Рост активности мошенников в Telegram

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

Пик данной активности мы наблюдали в период с октября по декабрь и вместе с коллегами по индустрии подготовили комментарий для РБК о том, как устроена эта мошенническая схема.

Сегодня злоумышленники масштабируют свою схему. Теперь они взламывают аккаунты пользователей, собирают голосовые сообщения, прогоняют их через генеративные нейросети (например, murf.ai) и рассылают контактам жертвы фейковые голосовые сообщения с просьбой о помощи.

Рекомендация и напоминание: не доверять никаким голосовым и видео-сообщениям, в которых есть побуждение к какому-либо действию, критичному для финансов или личных/корпоративных данных. Для защиты от подобных атак выработать привычку подтверждать это действие дополнительным звонком по альтернативному каналу (не в мессенджере).

Безопасная разработка в финтех: итоги круглого стола DevOpsConf

Ключевые тезисы, которые вместе с коллегами из финансовой отрасли озвучили в ходе обсуждения вопросов безопасной разработки:

* Процессы, роли и инструменты SSDL влияют на time-to-market продукта, но возможно снизить это влияние до минимальных значений. Например, за счет автоматизации процессов безопасной разработки и, в некоторых сценариях, за счет принятия рисков. В последнем сценарии важен баланс между риск-аппетитом владельцев бизнеса (то есть финансовыми и репутационными потерями, с которыми готов мириться бизнес) и требованиям регулятора.

* «Платформизация» разработки - тренд, который нужно учитывать организации любого уровня, разрабатывающей финансовые продукты. Объединение ключевых компетенций в команде-платформе и ее последующее масштабирование в продуктовые команды позволяет сохранять экспертный ресурс при росте масштабов разработки. Именно таким образом правильно внедрять практику Security Champions.

* Интегрировать и поддерживать open-source или купить коммерческое решение для безопасной разработки - ответ на этот вопрос находится в экономической плоскости. Развивать собственную команду разработки, которая будет адаптировать решение с открытым исходным кодом под имеющиеся процессы - инвестиция с высоким уровнем риска. Лучше инвестировать в процессы, которые не будут зависеть от инструмента и которые можно поддержать любым продуктом.