Атаки на SharePoint связали с уязвимостью пятилетней давности

Атаки на SharePoint связали с уязвимостью пятилетней давности

Атаки на SharePoint связали с уязвимостью пятилетней давности

Эксперты «Лаборатории Касперского» разобрали новую волну атак на серверы Microsoft SharePoint и пришли к выводу, что в её основе лежит старая уязвимость пятилетней давности. Исследователи изучили эксплойт ToolShell, который использовался в атаках, и обнаружили сходство с CVE-2020-1147.

Напомним, CVE-2020-1147 — уязвимость, обнаруженная в SharePoint ещё в 2020 году. Похоже, тогда брешь закрыли не до конца, и только обновление 2025 года (CVE-2025-53770) устранило проблему полностью.

Дополнительный анализ показал, что уязвимости CVE-2025-49704 и CVE-2025-49706, которые были закрыты 8 июля, тоже имели общий корень с CVE-2020-1147.

Причём обойти защиту можно было, просто добавив один символ — «/» — в код эксплойта. Microsoft позже выпустила заплатки, устранившие этот обход, и присвоила им отдельные номера.

Атаки на SharePoint фиксировались по всему миру — в том числе в России, Египте, Иордании, Вьетнаме и Замбии. Под удар попали организации из разных сфер: финансы, госсектор, промышленность, а также сельское и лесное хозяйство.

Например, с помощью соответствующего эксплойта киберпреступники атаковали Министерство внутренней безопасности США. То же касается попытки атаки на Национальное управление ядерной безопасности США.

Специалисты напоминают, что старые уязвимости вроде ProxyLogon, PrintNightmare и EternalBlue до сих пор активно используются злоумышленниками.

Если обновления не установлены вовремя, система остаётся уязвимой. С ToolShell, по всей видимости, может случиться то же самое: эксплойт уже опубликован, прост в использовании и, скорее всего, скоро появится в инструментах, которыми пользуются хакеры.

Подпишитесь на новости

Android 17 запретит приложениям внезапно орать в фоне

Google решила покончить с одной из самых мерзких мобильных неожиданностей: когда давно свёрнутое приложение или забытая вкладка браузера внезапно начинает воспроизводить звук. В Android 17 для этого появился системный механизм Background Audio Hardening.

Теперь приложение сможет включать аудио, запрашивать аудиофокус и менять громкость только при видимом на экране интерфейсе либо при корректно запущенной foreground-службе.

Ограничение действует на все приложения в Android 17, даже если они пока не адаптированы под API 37.

Если программа попытается шуметь из неподходящего фонового состояния, система просто проигнорирует её запрос. Воспроизведение и изменение громкости будут заблокированы без ошибки или падения приложения, а запрос аудиофокуса завершится отказом.

Как объясняет Google, нововведение должно остановить случайный запуск звука. Например, приложение могло зависнуть из-за проблем с сетью, быть заморожено системой, а затем очнуться через несколько часов и внезапно продолжить воспроизведение. Другой сценарий — потерянная медиасессия, которая продолжает жить уже без видимого интерфейса и понятной кнопки остановки.

Изменение работает на уровне всей операционной системы, поэтому это не специальное лекарство для Chrome, YouTube или сайтов с наглым автовоспроизведением. Под новые правила попадут браузеры, игры, медиаплееры и остальные приложения.

Побочный эффект тоже имеется. Программы, которым действительно нужно играть музыку или подкасты при выключенном экране, должны правильно использовать foreground-службу для медиавоспроизведения. Разработчикам с кривой реализацией придётся переписать код, иначе Android молча прикрутит им громкость.

Google также предусмотрела тестирование через ADB: защиту можно включить, отключить или перевести в жёсткий режим, при котором некорректные обращения к аудиоинтерфейсам вызывают явные ошибки.

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