На прошлой неделе разработчики клиента для веб-конференций Zoom закрыли серьезную уязвимость, которая при некоторых обстоятельствах могла приводить к выполнению произвольного кода. Уязвимость получила идентификатор CVE-2022-22787, ее особенности кратко описаны в статье издания The Register и в бюллетене компании Zoom. Обнаружил проблему эксперт из команды Google Project Zero, и вот их подробный отчет представляет большой интерес.

Исследователь Иван Фратрич (Ivan Fratric) по сути смог построить атаку на далеко не самой очевидной основе. Для пересылки сообщений в Zoom используется собственная реализация открытого протокола XMPP. Проблема заключалась в том, что код, отвечающий за разбор содержимого сообщений в формате XML, различается на сервере и на клиенте. Минимальные различия в парсинге удалось превратить в полноценную атаку, которая при этом не требует никаких действий от жертвы, если передача сообщений от атакующего в принципе разрешена.

Исследователи «Лаборатории Касперского» обнаружили свежую вредоносную атаку, использующую нетривиальный способ скрыть ключевой вредоносный код, записывая его в логи Windows. Подробный разбор атаки опубликован здесь, а еще подробнее она описана автором исследования в этом видео. Таргетированная атака была обнаружена в феврале 2022 года. Помимо попыток спрятать вредоносный код в логах, организаторы атаки использовали множество систем обфускации, которые подробно описаны в отчете.

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

Привет, Хабр!

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

Но что, если обновлений насчитывается 250+ типов? А если поддерживаемых ОС — порядка 250? И для тестирования требуется 7500+ тестовых машин? Такой вот типичный хайлоад. Который должен постоянно масштабироваться…

Я — Иван Лауре, менеджер по тестированию в «Лаборатории Касперского». Именно так, как я описал выше, выстроено «выкатывание» у нас. В этой статье я расскажу о центральной части всего процесса — как мы тестируем обновления для более чем 500 уникальных версий ПО, да и саму распределенную систему тестирования. Не сомневаюсь, что наш опыт будет вам полезен.

• в чем состоят плюсы и минусы каждого варианта;
• какие подводные камни ждут вас при смене модели;
• что делать, чтобы с минимальными потерями вырулить к новой «точке стабильности».