Атака через PDF, не требующая особых уязвимостей
Автор
Евгений Малинин
в Новости и события со всего мира
-
Похожий контент
-
Автор foroven
Добрый день. После того как мы словили вирус шифровальщик и был установлен антивирусный продукт лаборатории Касперского, в его журнале каждый час стали появляться записи о сетевой атаке. Причем адрес атакующего компьютера это Linux-система с установленным Kerio Control. Может ли Касперсий так реагировать на его работу? Или он может быть заражен? Спасибо.
-
Автор Olga Grinchuk
Взомали сервер через RDP и зашифровали файлы, оставили почту platishilidrocish@fear.pw для расшифровки и требуют оплату.
Во вложении требование и зашифрованные файлы.
требование.rar зашифрованные файлы.rar
-
Автор KL FC Bot
В мартовском вторничном патче компания Microsoft закрыла целых шесть уязвимостей, которые активно эксплуатируются злоумышленниками. Четыре из этих уязвимостей связаны с файловыми системами, причем три из них имеют одинаковый триггер, что может указывать на их использование в одной атаке. Детали их эксплуатации пока (к счастью) неизвестны, однако свежее обновление крайне рекомендуется к немедленной установке.
Уязвимости в файловых системах
Две из уязвимостей в системе NTFS позволяют злоумышленникам получить доступ к частям кучи (heap), то есть к динамически распределяемой памяти приложений. Что интересно, первая из них, CVE-2025-24984 (4,6 по шкале CVSS) подразумевает физический доступ злоумышленника к атакуемому компьютеру (он должен вставить в USB-порт подготовленный вредоносный накопитель). Для эксплуатации второй уязвимости типа Information Disclosure Vulnerability, CVE-2025-24991 (CVSS 5,5), злоумышленникам необходимо каким-то образом заставить локального пользователя подключить вредоносный виртуальный жесткий диск (VHD).
Точно также активизируются и две другие уязвимости, связанные с файловыми системами CVE-2025-24985, в драйвере файловой системы Fast FAT и CVE-2025-24993 в NTFS. Вот только их эксплуатация приводит к удаленному запуску произвольного кода на атакуемой машине (RCE). У обеих уязвимостей CVSS рейтинг составляет 7,8.
View the full article
-
Автор KL FC Bot
Атаки на open source чаще всего сводятся к публикации новых вредоносных пакетов в репозиториях. Атака, произошедшая 14 марта, из другой лиги — злоумышленники скомпрометировали популярный процесс (GitHub Action) tj-actions/changed-files, который применяется более чем в 23000 репозиториев. Инцидент получил номер CVE-2025-30066, этой уязвимости подвержены все репозитории, в которых использовался заражённый процесс changed-files. Хотя администрация заблокировала changed-files, а затем откатила его к безопасной версии, все, кто пользовался им должны провести реагирование на инцидент, а сообщество разработчиков — извлечь из него более общие уроки.
Что такое GitHub Actions
Рабочие процессы (GitHub Actions) упрощают разработку ПО при помощи автоматизации типовых задач DevOps. Они могут стартовать при наступлении каких-то событий в GitHub, например коммитов. У GitHub есть условный «магазин приложений», в котором можно взять готовый процесс и применить его в своём репозитории, например популярны процессы для автоматической инсталляции вспомогательных инструментов. Чтобы интегрировать в свой сборочный конвейер CI/CD такой готовый процесс GitHub, достаточно всего одной строчки кода.
View the full article
-
Автор KL FC Bot
Чуть больше года назад в посте Google OAuth и фантомные аккаунты мы уже обсуждали, что использование опции «Вход с аккаунтом Google» в корпоративные сервисы дает возможность сотрудникам создавать фантомные Google-аккаунты, которые не контролируются администратором корпоративного Google Workspace и продолжают работать после оффбординга. Недавно выяснилось, что это не единственная проблема, связанная с OAuth. Из-за недостатков этого механизма аутентификации любой желающий может получить доступ к данным многих прекративших деятельность организаций, перерегистрировав на себя брошенные компаниями домены. Рассказываем подробнее об этой атаке.
Как работает аутентификация при использовании «Вход с аккаунтом Google»
Некоторые могут подумать, что, доверяя опции «Вход с аккаунтом Google», компания получает надежный механизм аутентификации, использующий продвинутые технологии Google и широкие возможности интернет-гиганта по мониторингу пользователей. Однако на деле это не так: при входе с Google OAuth применяется достаточно примитивная проверка. Сводится она, как правило, к тому, что у пользователя есть доступ к почтовому адресу, который привязан к Google Workspace организации.
Причем, как мы уже говорили в предыдущем материале о Google OAuth, это вовсе не обязательно Gmail — ведь привязать Google-аккаунт можно совершенно к любой почте. Получается, что при использовании «Входа с аккаунтом Google» доступ к тому или иному корпоративному сервису защищен ровно настолько надежно, насколько защищен почтовый адрес, к которому привязан Google-аккаунт.
Если говорить несколько более подробно, то при аутентификации пользователя в корпоративном сервисе Google OAuth отправляет этому сервису следующую информацию:
В теории в ID-токене Google OAuth есть уникальный для каждого Google-аккаунта параметр sub, но на практике из-за проблем с его использованием сервисы проверяют лишь домен и адрес электронной почты. Источник
View the full article
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти