Критична вразливість Spring4Shell

Що трапилося?

У популярному Java-фреймворку для розробки веб-застосунків Spring Framework була виявлена ​​вразливість нульового дня (0-day), що дозволяє віддалене виконання коду без автентифікації. Уразливості було надано номер CVE-2022-22965. Також її називають Spring4Shell і SpringShell (за аналогією з гучною вразливістю в грудні 2021 Log4Shell).

Вже спостерігаються спроби масової експлуатації вразливості зловмисниками з метою компрометації застосунків та систем.

29-го березня дослідники codeplutos, meizjm3i з AntGroup FG Security Lab повідомили про вразливість VMware, компанії-власника фреймворку. Наступного дня, поки готувалося виправлення, стався публічний витік усіх деталей уразливості.

31 березня Spring було офіційно підтверджено наявність вразливості та випущено версії Spring Framework 5.3.18 та 5.2.20 із виправленнями. Також були випущені версії Spring Boot 2.6.6 та 2.5.12, які залежать від Spring Framework 5.3.18.

Зазначимо, що водночас з’явилася інформація про дві інші, не пов’язані з CVE-2022-22965, уразливості, що створило плутанину. Перша з них, CVE-2022-22963, що дозволяє віддалене виконання коду, була виявлена ​​в Spring Cloud Function (не входить у Spring Framework), і виправлена ​​у версіях 3.1.7 та 3.2.3. Друга, CVE-2022-22950, ​​дозволяє зупинити роботу застосунку, була виявлена ​​в Spring Framework, та виправлена ​​у версії 5.3.17.

Що зачеплено?

Як мінімум, уразливість торкається застосунків на базі SpringMVC та Spring WebFlux, що працюють на JDK 9+.

Умови експлуатації вразливості в окремому випадку, що був описаний у первинному звіті:

• JDK 9 або вище,
• Apache Tomcat в якості контейнеру сервлетів,
• упаковка в WAR (на відміну від виконуваного jar-файлу Spring Boot),
• залежність від spring-webmvc або spring-webflux,
• версія Spring Framework із 5.3.0 до 5.3.17, із 5.2.0 до 5.2.19, або застаріла версія, що не підтримується.

Через природу вразливості очікується поява нових більш універсальних експлойтів.

За оцінкою Rapid7, будь-які компоненти, що використовують Spring Framework версії до 5.2.20 або 5.3.18 разом із JDK версії 9 або вище, вважаються потенційно вразливими. Компоненти, які, крім цих умов, використовують анотацію @RequestMapping і параметри типу Plain Old Java Object (POJO), вважаються вразливими та піддаються ризику експлуатації. Компоненти, які додатково до всіх попередніх умов використовують Apache Tomcat, найбільш схильні до ризику через наявність готового експлойту.

Rapid7 наводять приклад уразливого коду у своєму звіті. Крім цього, Microsoft випустили звіт із аналізом уразливості.

Адміністратори та розробники можуть перевірити свої програми за допомогою curl шляхом наступного запиту:

$ curl host:port/path?class.module.classLoader.URLs%5B0%5D=0

Застосунки, які повертають відповідь із HTTP-кодом 400, вважаються вразливими. Інші відповіді не свідчать про наявність чи відсутність уразливості.

Що робити?

Найбільш оптимальним рішенням є оновлення застосунків до версій Spring Framework 5.3.18 та 5.2.20, у яких виправлена ​​ця вразливість.

Якщо це неможливо зробити зараз, то, як просто тимчасове рішення, розробникам рекомендується скористатися методом setDisallowedFields у WebDataBinder через @ControllerAdvice, щоб заборонити пов’язані з вразливістю шаблони полів запиту. Приклади цього рішення наведені у блогах Spring та Praetorian.

Як відзначають Spring, попереднє рішення може залишити прогалини. Зокрема, якщо контролер сам встановлює заборонені параметри через власний метод @InitBinder, що перевизначає глобальне налаштування.

Більш просунутим рішенням буде розширення RequestMappingHandlerAdapter для оновлення WebDataBinder після решти ініціалізації. Для цього програма може визначити бін (bean) WebMvcRegistrations (SpringMVC) або WebFluxRegistrations (Spring WebFlux). Приклад цього рішення доступний у згаданому блозі Spring.

За наявності WAF у якості тимчасового рішення можна блокувати HTTP-запити, що містять такі рядки, як “class.”, “Class.”, “.class.” і “.Class.”. Проте, цей спосіб захисту легко оминути, тому не варто розраховувати на нього в довгостроковій перспективі.

Нарешті, організаціям рекомендується вести моніторинг журналів застосунків, а також появу на серверах нових процесів із метою своєчасного виявлення аномалій, які можуть свідчити про успішний злом.

Потрібна допомога?

Наші фахівці готові допомогти вам із перевіркою на наявність Spring4Shell та інших уразливостей за допомогою тестування на проникнення та розслідування інцидентів.

У разі виявлення вразливостей, загроз та атак ми допоможемо захистити та очистити вашу систему.

Зверніться до нас за додатковою інформацією. Ми з радістю відповімо на ваші запитання.

Підпишіться на наш канал Телеграм, щоб не пропустити наші новини.