Не успел мир отойти от Apache Log4j2 (CVE-2021-44228), как в сети появились сообщения о новых 0-day уязвимостях. В Spring Framework для Java обнаружено сразу несколько уязвимостей "нулевого дня", позволяющих, в том числе, выполнять произвольный код (RCE).

На данный момент выявлено 3 недостатка:

  • RCE в библиотеке Spring Cloud Function (CVE-2022-22963) - уязвимость актуальна для версии библиотеки до 3.2.3;

  • Уязвимость среднего уровня, которая может вызвать состояние DoS (CVE-2022-22950) - затрагивает версии Spring Framework с 5.3.0 по 5.3.16;

  • Spring4Shell в Spring Core — уязвимость внедрения классов для эксплуатации RCE (еще не присвоен идентификатор CVE).

Информация представлена в ознакомительных целях, не нарушайте законодательство.

Spring4Shell в Spring Core

Клиенты, использующие JDK версии 9 и новее, уязвимы для атаки удаленного выполнения кода из-за обхода CVE-2010-1622. Уязвимости подвержены все версии Spring Core (исправление еще не выпущено). Уязвимость затрагивает функции, использующие RequestMapping и параметры POJO (Plain Old Java Object).

Работа эксплоита сводится к отправке запроса с параметрами class.module.classLoader.resources.context.parent.pipeline.first.*, обработка которых при использовании WebappClassLoaderBase приводит к обращению к классу AccessLogValve. Указанный класс позволяет настроить логгер для создания произвольного jsp-файла в корневом окружении Apache Tomcat и записи в этот файл указанного атакующим кода. Созданный файл становится доступным для прямых запросов.

Результатом эксплуатации будет созданный shell.jsp, при обращении к которому можно выполнять произвольные команды на сервере, например:

# curl http://example.com/shell.jsp?cmd=whoami

Эксплойт уже доступен в паблике, но по этическим соображениям мы пока не будем публиковать PoC.

Разработчики еще не выпустили патч, но вы можете использовать Nemesida WAF, блокирующий попытки эксплуатации этой и других уязвимостей, включая техники обхода. Оставайтесь защищенными.

P.S:

Комментарии (11)


  1. Regis
    31.03.2022 17:57

    Актуальная информация из Spring Blog:

    https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement


    1. sshikov
      31.03.2022 18:45

      Почему это называется уязвимостью в Spring Framework или Core? WebappClassLoaderBase — насколько я помню, это вообще часть томката, то есть связана строго с вебом. Core != не веб. У меня есть Spring Core, у меня есть Spring Jdbc, но у меня и близко нет никакого томката. Более того, у меня кое-где даже IOC нет. И Jetty судя по всему это не касается тоже.

      По вашей ссылке, кстати, гораздо более четко сформулировано, что это касается именно томката, war, webmvc и webflux. И где тут Core?


      1. Regis
        31.03.2022 18:48

        Во-первых, на момент начальной публикации подробностей было намного меньше. Я бы даже сказал, почти не было.

        Во-вторых, сама концептуальная проблема находится в Spring Core. А вот конкретный практически осуществимый вариант её использования для RCE — требует деплой через WAR на Tomcat.


        1. sshikov
          31.03.2022 19:01

          >Во-первых, на момент начальной публикации подробностей было намного меньше.
          Ну это понятно. А концептуальная проблема в чем? Я вижу одну в SpEL — это наверное не веб, да. А еще? Ну или даже так — если у меня нет веба, нет томката — то нет и никакой проблемы вообще, потому что никакое выражение на SpEL никто снаружи засунуть в код не сможет?


          1. Regis
            31.03.2022 19:22

            если у меня нет веба, нет томката — то нет и никакой проблемы вообще, потому что никакое выражение на SpEL никто снаружи засунуть в код не сможет?

            Если вы совсем-совсем никаких данных никаким образом "снаружи" не получаете, то ваше приложение, действительно, не уязвимо к этой атаке (и к 99% любых атак в принципе).

            На практике вы так или иначе получаете в приложение данные внешних источников. Если в процесс парсинга данных и биндинга их на POJO/DTO будет вовлечён Spring - вы всё ещё можете быть под угрозой. Сказать наверняка - трудно, так как подробностей всё ещё опубликовано мало.

            Вот тут есть некоторая информация помимо той, что опубликована в Spring Blog:

            https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/


            1. sshikov
              31.03.2022 19:31

              Понятненько, почитаем, спасибо. Пока на log4shell не очень тянет, на первый взгляд.


            1. sshikov
              31.03.2022 19:33

              Еще раз спасибо, это очень хороший источник как раз.


      1. pentestit-team
        31.03.2022 19:17

        Потому, что уязвимость в Spring Framework, но для эксплуатации требуется, чтобы приложение работало на Tomcat. При этом они не исключают, что можно выполнить эксплуатацию и без запуска под Tomcat:

        The vulnerability impacts Spring MVC and Spring WebFlux applications running on JDK 9+. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.


        1. sshikov
          31.03.2022 19:29

          >The vulnerability impacts Spring MVC and Spring WebFlux
          Ну Томкат ладно, это специфический эксплойт на нем основан, но тут же ясно написано — Spring MVC and Spring WebFlux. Это широко распространенные вещи, но это сильно меньше, чем все множество спринг-приложений.

          Ну то есть, как-то пока непонятно, в каком месте есть дырка, через которую уязвим кто-то ниже веба. Только SpEL таким слегка выглядит, но уязвимость в SpEL недаром описана как среднего уровня — потому что внедрить просто так SpEL в произвольное приложение не выйдет, для этого нужно нечто большее, дополнительные какие-то условия. У меня вот и spring-expression.jar в приложении вообще нет.


          1. Throwable
            01.04.2022 11:24
            +1

            Глобально в Java имеется один небезопасный слой -- это reflection, который позволяет динамически инстанциировать и обращаться к объектам произвольных классов. Все интерпретируемые субъязыки наподобие SpEL, EL или Log4j2 EL, а также большинство data-binding фреймворков, использующих сериализацию, в той или иной форме используют reflection, а поэтому потенциально уязвимы. Основные причины две:

            • Семантическое core субъязыка позволяет выполнять "injections" через параметры.

            • Язык имеет полный неконтролируемый доступ ко всей платформе через reflection.


            1. sshikov
              01.04.2022 14:27

              Пардон, но возможности reflection просто так снаружи обычно недоступны. Через языки выражений разного рода — да, конечно, они именно для этого в значительной степени и существуют. Но — их реализация, насколько я помню, в отдельном jar, и если его нет — то ее нет тоже (и нет уязвимости). Разве не так?

              Опять же — по ссылке написано кое-что про сериализацию и binding, но это все описано применительно к webmvc — но не к Core. По поводу Core я лично еще в сомнении. Не вижу пока явного указания на что-то в Spring Core, что было бы уязвимо всегда, пусть и потенциально.