Уязвимость во фреймворке Spring Java позволяет удаленно выполнять код
Раздел: Уязвимости систем и приложений
Обнародована информация о новой уязвимости нулевого дня в инфраструктуре Java Spring Core под названием Spring4Shell, позволяющей удаленно выполнять код в приложениях без проверки подлинности.
Spring — это очень популярная платформа приложений, которая позволяет разработчикам программного обеспечения быстро и легко разрабатывать приложения Java с функциями корпоративного уровня. Затем эти приложения можно развернуть на серверах, таких как Apache Tomcat, в виде автономных пакетов со всеми необходимыми зависимостями.
Вчера была раскрыта новая уязвимость Spring Cloud Function, отслеживаемая как CVE-2022-22963, за которой вскоре последуют эксплойты Proof-of-Concept.
Однако позже информация о более критической уязвимости Spring Core для удаленного выполнения кода распространилась в чат-сервисе QQ и на китайском сайте кибербезопасности.
Сегодня эксплойт для этой уязвимости нулевого дня ненадолго просочился, а затем был удален, но не раньше, чем исследователи кибербезопасности смогли загрузить код.
С тех пор многочисленные исследователи кибербезопасности и охранные фирмы подтвердили, что уязвимость действительна и вызывает серьезную озабоченность.
Эта новая уязвимость Spring RCE, получившая название Spring4Shell, вызвана небезопасной десериализацией переданных аргументов.
Хотя изначально предполагалось, что это повлияет на все приложения Spring, работающие на Java 9 или более поздней версии, позже было установлено, что существуют определенные требования, которые должны быть выполнены, чтобы приложение Spring было уязвимым.
Уилл Дорманн, аналитик уязвимостей в CERT/CC, сказал, что приложение также должно использовать «Spring Beans», использовать «привязку параметров Spring», а «связывание параметров Spring должно быть настроено для использования небазового типа параметра, такого как POJOs."
Фирма по кибербезопасности Praetorian также подтвердила, что ошибка зависит от определенных конфигураций для правильного использования.
«Для эксплуатации требуется конечная точка с включенным DataBinder (например, запрос POST, который автоматически декодирует данные из тела запроса) и сильно зависит от контейнера сервлета для приложения», — объяснил Преториан в своем блоге.
«Например, когда Spring развернут на Apache Tomcat, доступен WebAppClassLoader, что позволяет злоумышленнику вызывать геттеры и сеттеры, чтобы в конечном итоге записать вредоносный JSP-файл на диск».
«Однако, если Spring развернут с использованием встроенного контейнера сервлетов Tomcat, загрузчик классов — это LaunchedURLClassLoader, доступ к которому ограничен».
«В некоторых конфигурациях использование этой проблемы является простым, поскольку для этого требуется, чтобы злоумышленник отправил созданный запрос POST в уязвимую систему. Однако использование других конфигураций потребует от злоумышленника дополнительных исследований, чтобы найти полезные данные, которые будут эффективными. ."
Хотя требования могут ограничивать размер цели, несколько источников сообщили, что уязвимость Spring4Shell активно используется в атаках.
Сообщение в блоге Praetorian описывает способ частичного смягчения атак Spring4Shell, запрещая передачу определенных «шаблонов» в функциональность Spring Core DataBinder.
Поскольку для этой уязвимости в настоящее время нет исправления, настоятельно рекомендуется, чтобы администраторы, использующие приложения Spring, как можно скорее развернули эти средства устранения.
Это новый Log4Shell?
Spring — очень популярная платформа приложений для Java-приложений, что вызывает серьезные опасения, что это может привести к широко распространенным атакам, поскольку злоумышленники сканируют уязвимые приложения.
Поскольку для эксплуатации требуется простой HTTP POST для уязвимого приложения, злоумышленники смогут создавать сценарии, которые сканируют Интернет и автоматически используют уязвимые серверы.
Злоумышленники могут использовать эти эксплойты для выполнения команд на сервере, что позволит получить полный удаленный доступ к устройству.
Этот сценарий атаки напоминает то, что мы видели в декабре с массовой эксплуатацией серверов Log4j с использованием эксплойтов Log4Shell для установки вредоносных программ и проведения атак программ-вымогателей.
Из-за требований, предъявляемых к использованию этой ошибки, еще слишком рано говорить о том, сколько приложений уязвимы.
Чтобы в конечном итоге предотвратить этот сценарий, настоятельно рекомендуется, чтобы администраторы как можно скорее применяли меры по смягчению последствий, предоставляемые Praetorian, если они считают, что их приложения уязвимы.
https://www.bleepingcomputer.com/news/security/new-spring-java-framework-zero-day-allows-remote-code-execution/
Spring — это очень популярная платформа приложений, которая позволяет разработчикам программного обеспечения быстро и легко разрабатывать приложения Java с функциями корпоративного уровня. Затем эти приложения можно развернуть на серверах, таких как Apache Tomcat, в виде автономных пакетов со всеми необходимыми зависимостями.
Вчера была раскрыта новая уязвимость Spring Cloud Function, отслеживаемая как CVE-2022-22963, за которой вскоре последуют эксплойты Proof-of-Concept.
Однако позже информация о более критической уязвимости Spring Core для удаленного выполнения кода распространилась в чат-сервисе QQ и на китайском сайте кибербезопасности.
Сегодня эксплойт для этой уязвимости нулевого дня ненадолго просочился, а затем был удален, но не раньше, чем исследователи кибербезопасности смогли загрузить код.
С тех пор многочисленные исследователи кибербезопасности и охранные фирмы подтвердили, что уязвимость действительна и вызывает серьезную озабоченность.
Эта новая уязвимость Spring RCE, получившая название Spring4Shell, вызвана небезопасной десериализацией переданных аргументов.
Хотя изначально предполагалось, что это повлияет на все приложения Spring, работающие на Java 9 или более поздней версии, позже было установлено, что существуют определенные требования, которые должны быть выполнены, чтобы приложение Spring было уязвимым.
Уилл Дорманн, аналитик уязвимостей в CERT/CC, сказал, что приложение также должно использовать «Spring Beans», использовать «привязку параметров Spring», а «связывание параметров Spring должно быть настроено для использования небазового типа параметра, такого как POJOs."
Фирма по кибербезопасности Praetorian также подтвердила, что ошибка зависит от определенных конфигураций для правильного использования.
«Для эксплуатации требуется конечная точка с включенным DataBinder (например, запрос POST, который автоматически декодирует данные из тела запроса) и сильно зависит от контейнера сервлета для приложения», — объяснил Преториан в своем блоге.
«Например, когда Spring развернут на Apache Tomcat, доступен WebAppClassLoader, что позволяет злоумышленнику вызывать геттеры и сеттеры, чтобы в конечном итоге записать вредоносный JSP-файл на диск».
«Однако, если Spring развернут с использованием встроенного контейнера сервлетов Tomcat, загрузчик классов — это LaunchedURLClassLoader, доступ к которому ограничен».
«В некоторых конфигурациях использование этой проблемы является простым, поскольку для этого требуется, чтобы злоумышленник отправил созданный запрос POST в уязвимую систему. Однако использование других конфигураций потребует от злоумышленника дополнительных исследований, чтобы найти полезные данные, которые будут эффективными. ."
Хотя требования могут ограничивать размер цели, несколько источников сообщили, что уязвимость Spring4Shell активно используется в атаках.
Сообщение в блоге Praetorian описывает способ частичного смягчения атак Spring4Shell, запрещая передачу определенных «шаблонов» в функциональность Spring Core DataBinder.
Поскольку для этой уязвимости в настоящее время нет исправления, настоятельно рекомендуется, чтобы администраторы, использующие приложения Spring, как можно скорее развернули эти средства устранения.
Это новый Log4Shell?
Spring — очень популярная платформа приложений для Java-приложений, что вызывает серьезные опасения, что это может привести к широко распространенным атакам, поскольку злоумышленники сканируют уязвимые приложения.
Поскольку для эксплуатации требуется простой HTTP POST для уязвимого приложения, злоумышленники смогут создавать сценарии, которые сканируют Интернет и автоматически используют уязвимые серверы.
Злоумышленники могут использовать эти эксплойты для выполнения команд на сервере, что позволит получить полный удаленный доступ к устройству.
Этот сценарий атаки напоминает то, что мы видели в декабре с массовой эксплуатацией серверов Log4j с использованием эксплойтов Log4Shell для установки вредоносных программ и проведения атак программ-вымогателей.
Из-за требований, предъявляемых к использованию этой ошибки, еще слишком рано говорить о том, сколько приложений уязвимы.
Чтобы в конечном итоге предотвратить этот сценарий, настоятельно рекомендуется, чтобы администраторы как можно скорее применяли меры по смягчению последствий, предоставляемые Praetorian, если они считают, что их приложения уязвимы.
https://www.bleepingcomputer.com/news/security/new-spring-java-framework-zero-day-allows-remote-code-execution/
Мы ищем точки опоры не с целью перевернуть мир, но чтобы не позволить миру опрокинуть нас.
Тэги темы:
Войдите или Зарегистрируйтесь чтобы комментировать.
Комментарии
Spring выпустила экстренные обновления, чтобы исправить уязвимость нулевого дня удаленного выполнения кода Spring4Shell, которая преждевременно просочилась в сеть до того, как был выпущен патч.
Вчера эксплойт для уязвимости нулевого дня удаленного выполнения кода в Spring Framework, получивший название Spring4Shell, был кратко опубликован на GitHub, а затем удален.
Однако, поскольку в Интернете ничто не остается скрытым, код быстро распространился по другим репозиториям и был протестирован исследователями безопасности, которые подтвердили, что это был законный эксплойт для новой уязвимости.
Сегодня Spring выпустил совет по безопасности, в котором объясняется, что уязвимость теперь отслеживается как CVE-2022-22965 и влияет на приложения Spring MVC и Spring WebFlux на JDK 9.
Для эксплуатации уязвимости также требуется Apache Tomcat, приложение, упакованное как WAR, и зависимости spring-webmvc или spring-webflux.
«Эта уязвимость затрагивает приложения Spring MVC и Spring WebFlux, работающие на JDK 9+. Конкретный эксплойт требует, чтобы приложение запускалось на Tomcat как развертывание WAR», — говорится в бюллетене Spring.
«Если приложение развернуто как исполняемый jar-файл Spring Boot, то есть по умолчанию, оно не уязвимо для эксплойта. Однако природа уязвимости носит более общий характер, и могут быть другие способы ее использования».
Spring говорит, что odeplutos, meizjm3i из AntGroup FG, сообщил им об уязвимости во вторник, и они разрабатывали и тестировали исправление, которое, как ожидается, будет выпущено сегодня.
Однако после того, как в среду исследователь безопасности опубликовал в Интернете полную информацию, они отодвинули выпуск исправления до запланированного выпуска.
Версии Spring, исправляющие новую уязвимость, перечислены ниже, и все, кроме Spring Boot, доступны на Maven Central:
Spring Framework 5.3.18 и Spring Framework 5.2.20
Весенняя загрузка 2.5.12
Spring Boot 2.6.6 (пока не доступен)
Spring Boot 2.6.6 должен быть выпущен в течение следующих нескольких часов.
Хотя уязвимость предъявляет определенные требования для эксплуатации, Уилл Дорманн, аналитик уязвимостей из CERT/CC, обнаружил, что уязвим даже пример кода из spring.io.
Поскольку разработчики обычно используют пример кода в качестве шаблона для своих собственных приложений, многие уязвимые приложения могут быть доступны в Интернете.
Администраторы Spring должны уделить первоочередное внимание развертыванию этих обновлений безопасности как можно скорее, поскольку сканеры Spring4Shell уже созданы, и есть сообщения об активном использовании уязвимости.
https://www.bleepingcomputer.com/news/security/spring-patches-leaked-spring4shell-zero-day-rce-vulnerability/
VMware опубликовала обновления безопасности для критической уязвимости удаленного выполнения кода, известной как Spring4Shell, которая затрагивает несколько ее продуктов для облачных вычислений и виртуализации.
Список продуктов VMware, затронутых Spring4Shell, доступен в информационном бюллетене компании. Там, где исправление недоступно, VMware выпустила обходной путь в качестве временного решения.
В настоящее время крайне важно следовать советам, данным в бюллетене по безопасности, поскольку Spring4Shell является активно используемой уязвимостью.
Ошибка в популярном фреймворке
Spring4Shell, официально отслеживаемая как CVE-2022-22965, представляет собой уязвимость удаленного выполнения кода в среде Java Spring Core, которая может быть использована без аутентификации и имеет оценку серьезности 9,8 из 10.
Это означает, что любой злоумышленник, имеющий доступ к уязвимым приложениям, может выполнять произвольные команды и полностью контролировать целевую систему.
Из-за широкого распространения Spring Framework для разработки приложений Java аналитики безопасности опасаются крупномасштабных атак с использованием уязвимости Spring4Shell.
Что еще хуже, на GitHub просочилась работающая проверка концепции (PoC) еще до того, как стало доступно обновление безопасности, что повысило вероятность злонамеренной эксплуатации и «неожиданных» атак.
Воздействие и исправление
Критическая уязвимость затрагивает приложения Spring MVC и Spring WebFlux, работающие на JDK 9+. Эксплойт требует, чтобы приложение запускалось на Tomcat как развертывание WAR, хотя точные ограничения все еще изучаются.
Фиксированные версии приложений:
Spring Framework 5.3.18 и Spring Framework 5.2.20
Spring Boot 2.5.12
Spring Boot 2.6.6 (скоро выйдет)
VMWare пересмотрела свой портфель продуктов, и хотя расследование еще продолжается, указанные ниже продукты уже были определены как затронутые:
Служба приложений VMware Tanzu для виртуальных машин — версии с 2.10 по 2.13
VMware Tanzu Operations Manager — версии с 2.8 по 2.9
VMware Tanzu Kubernetes Grid Integrated Edition (TKGI) — версии с 1.11 по 1.13
Поставщик уже выпустил обновления безопасности для первых двух продуктов, охватывающие несколько веток версий с точечными выпусками, но постоянное исправление для VMware Tanzu Kubernetes Grid Integrated Edition все еще находится в разработке.
Для этих развертываний VMWare опубликовала обходные пути, призванные помочь администраторам временно защитить свои системы до выпуска исправлений.
Следует отметить, что VMWare обнаружила, что эксплуатация Spring4Shell в TKGI сложна, поэтому рекомендации по смягчению последствий и предстоящее обновление безопасности предоставляются для максимальной уверенности клиентов и во избежание ложных срабатываний.
https://www.bleepingcomputer.com/news/security/vmware-patches-spring4shell-rce-flaw-in-multiple-products/
Вредоносная программа Mirai теперь использует эксплойт Spring4Shell для заражения уязвимых веб-серверов и использования их для DDoS-атак (распределенный отказ в обслуживании).
Spring4Shell — это критическая уязвимость удаленного выполнения кода (RCE), отслеживаемая как CVE-2022-22965 и затрагивающая Spring Framework, широко используемую платформу разработки Java-приложений корпоративного уровня.
Spring выпустила экстренные обновления для исправления уязвимости нулевого дня через несколько дней после ее обнаружения, но злоумышленники уже начали использовать уязвимые развертывания.
Хотя Microsoft и CheckPoint обнаружили множество атак с использованием Spring4Shell в дикой природе, их успех был сомнительным, поскольку не было сообщений о крупномасштабных инцидентах, связанных с этой уязвимостью.
Таким образом, обнаружение Trend Micro варианта ботнета Mirai, успешно использующего CVE-2022-22965 для продвижения своих вредоносных операций, вызывает обеспокоенность.
Наблюдаемая активная эксплуатация, которая началась несколько дней назад, сосредоточена на уязвимых веб-серверах в Сингапуре, что может быть предварительным этапом тестирования, прежде чем субъект угрозы начнет масштабировать операцию по всему миру.
Spring4Shell используется для записи веб-оболочки JSP в корневую папку веб-сервера с помощью специально созданного запроса, который злоумышленники могут использовать для удаленного выполнения команд на сервере.
В этом случае злоумышленники используют свой удаленный доступ, чтобы загрузить Mirai в папку «/tmp» и запустить его.
Злоумышленники получают несколько образцов Mirai для различных архитектур ЦП и выполняют их с помощью сценария «wget.sh».
Те, которые не запускаются успешно из-за их несовместимости с целевой архитектурой, удаляются с диска после начальной стадии выполнения.
От Log4Shell к Spring4Shell
Различные ботнеты Mirai были одними из немногих настойчивых пользователей уязвимости Log4Shell (CVE-2021-44228) до прошлого месяца, используя уязвимость в широко используемом программном обеспечении Log4j для привлечения уязвимых устройств в свою DDoS-ботнет.
Вполне возможно, что операторы ботнетов теперь экспериментируют с другими уязвимостями, которые потенциально могут иметь значительное влияние, такими как Spring4Shell, чтобы получить доступ к новым пулам устройств.
Учитывая, что эти типы атак могут привести к развертыванию программ-вымогателей и утечке данных, случай захвата ресурсов Mirai для отказа в обслуживании или крипто-майнинга выглядит относительно безобидным.
По мере продолжения установки исправлений для систем и снижения числа уязвимых развертываний неисправленные серверы будут появляться в большем количестве вредоносных сетевых сканирований, что приведет к попыткам эксплуатации.
Администраторам необходимо как можно скорее обновиться до Spring Framework 5.3.18 и 5.2.20, а также до Spring Boot 2.5.12 или более поздней версии, чтобы закрыть дверь для этих атак до того, как наиболее опасные группы угроз присоединятся к эксплойту.
https://www.bleepingcomputer.com/news/security/mirai-malware-now-delivered-using-spring4shell-exploits/