9 из 10 утечек данных из облаков происходит из-за человеческого фактора

9 из 10 утечек данных из облаков происходит из-за человеческого фактора

9 из 10 утечек данных из облаков происходит из-за человеческого фактора

Согласно результатам нового исследования антивирусной компании «Лаборатория Касперского», около 90% утечек корпоративных данных из облаков происходят из-за человеческих ошибок. Таким образом, социальная инженерия, провоцирующая ошибки сотрудников, становится одной из главных угроз для данных организаций.

Исследователи «Лаборатории Касперского» также выяснили, что 26% компаний в России (и 33% в мире) беспокоят возможные киберинциденты в ИТ-инфраструктуре, за управление которой отвечает сторонний поставщик.

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

Однако, как выяснили аналитики антивирусного гиганта, бизнес напрасно боится утечек по вине провайдера, ведь они чаще происходят из-за внутренних действий. Для примера — лишь каждая десятая (11%) утечка данных из облака стала возможной из-за тех или иных действий провайдера.

Куда выше процент (31% в России и 33% в мире) киберинцидентов, произошедших по вине сотрудников, которые попались на уловки социальной инженерии.

«Важным шагом в принятии решения о переносе данных в публичное облако является понимание того, кто будет отвечать за безопасность хранящихся в нём корпоративных данных», — говорит Матвей Войтов, руководитель направления развития бизнеса защиты виртуальных и облачных сред «Лаборатории Касперского».

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

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

В Exim нашли критическую RCE-уязвимость: почтовики лучше обновить срочно

В популярном почтовом сервере Exim обнаружили критическую уязвимость CVE-2026-45185. При определённых условиях она позволяет удалённому атакующему без аутентификации выполнить произвольный код на сервере. Вполне себе неприятный сценарий, поэтому лучше не затягивать с установкой патча.

Проблема затрагивает версии Exim с 4.97 по 4.99.2, если они собраны с библиотекой GnuTLS и рекламируют STARTTLS вместе с CHUNKING. Сборки на OpenSSL, по имеющимся данным, не страдают — редкий случай, когда можно выдохнуть, но только после проверки конфигурации.

Суть бага — use-after-free во время завершения TLS-сессии при обработке SMTP-трафика BDAT. Exim освобождает TLS-буфер передачи, но затем продолжает использовать устаревшие callback-ссылки, которые могут писать данные уже в освобождённую область памяти. А дальше начинается классика жанра: повреждение памяти, удалённое выполнение кода и очень плохой день у администратора.

Exim широко используется на Linux- и Unix-серверах, в корпоративных почтовых системах, а также в Debian- и Ubuntu-based дистрибутивах, где он исторически часто выступал почтовым сервером по умолчанию.

По данным XBOW, баг был передан мейнтейнерам Exim 1 мая, подтверждение пришло 5 мая, а ещё через три дня уведомили затронутые Linux-дистрибутивы. Исправление уже выпущено в Exim 4.99.3.

Отдельная перчинка — попытка собрать PoC с помощью ИИ. XBOW устроила семидневное соревнование между своей автономной системой XBOW Native и человеком-исследователем, которому помогала большая языковая модель. ИИ смог собрать рабочий эксплойт для упрощённой цели без ASLR и с бинарником non-PIE. Во втором подходе LLM добралась до эксплуатации на системе с ASLR, но всё ещё без PIE.

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

RSS: Новости на портале Anti-Malware.ru