Spring4Shell зловживали в кампанії підштовхування Mirai

Реалізації на основі Java, здається, є подарунком, який продовжує дарувати. З періодичними повідомленнями про постійні спроби використання Log4j , уразливості, яка була у всіх на увазі взимку, тепер надходять новини щодо активної експлуатації останньої значної уразливості, виявленої в бібліотеці Spring Core Java.

Збройне зловмисне програмне забезпечення Mirai, використане в кампанії

Кампанія атаки з використанням Spring4Shell контролюється двома окремими дослідницькими фірмами безпеки. Тепер дослідницькі групи помічають, як старий знайомий використовував уразливість Spring4Shell.

Обидві компанії безпеки помітили, що для активного використання недоліку Spring4Shell використовується збройна версія зловмисного програмного забезпечення Mirai , зазвичай пов’язана з використанням бот-мереж.

Досліджуючи системи, уразливі до нової кампанії, яка підштовхнула Mirai до зловживання Spring4Shell, дослідники помітили ряд ознак, виявлених у системах, схильних до експлуатації. Серед них наявність фреймворку Spring, запущені виправлення до 5.2.20 і JDK, оновлений до версій 9 або новіших. Відомо, що недолік Spring4Shell не впливає на платформи, на яких працюють старіший Java Development Kit, наприклад JDK 8.

Apache Tomcat і конкретні конфігурації прив’язки параметрів Spring, налаштовані на використання неосновного типу параметра, також є одними з функцій, характерних для вразливих систем.

Перші спроби зловживати недоліком і перенести дату Мірай на кінець березня

В останній день березня 2022 року маніпулятори, якими керують дослідники, виявили перші спроби вторгнення.

Атаки із застосуванням зловмисного програмного забезпечення Mirai на системах, уразливих до Spring4Shell, були зосереджені переважно на цілях, розташованих у Сінгапурі та регіоні.

Дослідники очікують, що атаки, які намагаються використати вразливість Spring4Shell, лише збільшаться впродовж наступних місяців, оскільки недолік добре задокументований, а деталі доступні для загроз. Виправлення залишається таким же важливим, як і раніше, але, як і у випадку з Log4j , тут проблема не в виправленні, а в величезній кількості систем, на яких запущено вразливий код. У цьому сенсі навіть 1% невиправлених систем із мільйонів є значною кількістю потенційних цілей для експлойту.