Защита Java-приложения от кражи данных и исходного кода

В этой статье мы рассмотрим возможные способы внедрения вредоносного кода в Java Virtual Machine (JVM) и получение доступа к конфиденциальным данным. Основная цель статьи — объяснить, как защитить ваше приложение. Планируется провести следующие атаки:

• Чтение конфиденциальных данных из дампа;
• Кража исходного кода путем внедрения вредоносного ПО во внешнюю зависимость.

Кража данных из дампа Java

Если кто-то получит доступ к процессу Java, он сможет прочитать конфиденциальную информацию – пароли или адреса баз данных. Давайте посмотрим на следующую конфигурацию DataSource:

@Bean

public DataSource dataSource(){

MysqlDataSource mysqlDataSource = new MysqlDataSource();

mysqlDataSource.setUrl("jdbc:oracle:thin:@localhost:1521:xe");

mysqlDataSource.setUser("mySqlUser");

mysqlDataSource.setPassword("secretPassword");

return mysqlDataSource;

}

Если хакер атакует наш сервер и получает доступ к процессу JVM, он может сделать дамп памяти JVM с помощью программы jcmd. Например:

jcmd 20932 GC.heap_dump d:\dump\JVM_DUMP.bin

Когда злоумышленник получит дамп JVM, он может запросить его с помощью VisualVM. Например, чтобы получить все строки, начинающиеся с «JDBC», хакер может выполнить следующий запрос:

select s from java.lang.String s where s.toString().startsWith("jdbc")

Или в качестве альтернативы он может получить объект MysqlDataSource:

select filter(heap.classes(), "/com.mysql.cj.jdbc.MysqlDataSource/.test(it.name)")

В следующем видео продемонстрировано, как можно сделать дамп и найти потенциально конфиденциальные данные из DataSource:

Как предотвратить чтение данных из дампа?

• Добавьте параметр -XX:+DisableAttachMechanism при запуске JVM;
• Отключите вызов jcmd в Linux, отключив системный вызов ptrace (если вы используете Ubuntu);
• Для пользователей без привилегий root отключите доступ к процессам, задав hipid=1;
• Настройте шифрование данных на стороне Java.

Кража исходного кода путем внедрения вредоносного ПО в зависимости от Java

Подавляющее большинство приложений Java используют зависимости. Даже программы «hello world» должны использовать зависимость от регистратора. Никто не хочет изобретать велосипед и предпочитает использовать существующие решения. Но не все знают, что зависимости могут стать источником потенциальной утечки исходного кода или даже более серьезных проблем.

Как хакер может внедрить вредоносный код, используя внешнюю зависимость?

Для проведения атаки атакующему нужны две вещи:

• Получить контроль над сторонними зависимостями в maven (или любом другом общедоступном репозитории) и выпустить новую версию с вредоносным ПО (или заменить существующую версию выпуска);
• Убедиться, что клиентское приложение использует внешний репозиторий с новой версией зависимостей.

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

• Загрузить или заменить существующий код;
• Отправка/получение данных с сервера злоумышленника;
• Замедление или полное нарушение работы приложения;
• Кража данных из файловой системы.

Вышеописанные возможности – не полный список потенциальных действий. Внутри вредоносного ПО можно запускать любой код. Но среди всех проблем, самая важная — украденный исходный код.

Как украсть исходный код?

Поскольку у JVM есть доступ к папке с классами, можно ожидать, что внешняя зависимость тоже имеет право на ее чтение. На практике кража исходного кода состоит из двух этапов:

• Скопировать файлы *.classes из каталога пользователя;
• Отправить двоичные данные *.classes на сервер хакера (в нашем примере мы просто выведем имена классов и их размер).

Воспроизведение атаки с помощью регистратора SLF4J

В этом примере мы воспроизведем атаку, внедрив вредоносное ПО в библиотеку для протоколирования SLF4J (Simple Logging Facade for Java). Предполагаем, что хакер получил доступ к репозиторию SLF4J (как вариант, хакер может провести атаку типа «человек посередине» (Man-in-the-Middle, MitM) и подменить входящие запросы jar-файла из внешнего репозитория.

Для успешной атаки требуется, чтобы у жертвы уже была зависимость регистратора от внешнего репозитория (например, maven Central).

Сценарий атаки

1. Хакер получил доступ к репозиторию SLF4J и выпустил актуальную версию;
2. Жертва обновляет версию своей зависимости до последней;
3. Проект жертвы запускается с зараженной зависимостью и, как следствие, исходный код утекает.

Пример атаки

Со стороны Java-приложения жертвы

Со стороны злоумышленника

Результаты, когда жертва обновляет версию и запускает приложение

Как защитить ваши приложения от подобных атак

На данный момент нет какого-либо окончательного способа защитить Java-приложение от таких атак – существует множество способов внедрить вредоносное ПО в ваш код. Хакеры могут внедрить вредоносное ПО во время сборки или внедрить вредоносное ПО в JDK (Java Development Kit), а также динамически заменять зависимости, получая контроль над вашей сетью. Однако ниже приведены некоторые меры предосторожности, которые следует принять для защиты вашего приложения:

1. Использование только частного репозитория: не используйте внешние репозитории, так как они могут содержать небезопасные зависимости;
2. Использование стабильных версий зависимостей: это снижает риск внедрения вредоносного кода через зависимости;
3. Избегание неофициальных и кастомных зависимостей: неофициальные источники могут быть ненадежными и содержать вредоносный код;
4. Настройка сети и закрытие лишних портов/протоколов: это помогает предотвратить несанкционированный доступ и утечку исходного кода;
5. Развертывание приложения во внутренней сети: это крайняя мера, которая может быть не подходящей для многих приложений, но она значительно уменьшает риск атак извне. В этом случае приложение работает только во внутренней сети организации, что ограничивает доступ из внешнего мира.

Заключение

Указанные меры помогают защитить приложение, но важно понимать, что полностью исключить риск атак практически невозможно – есть еще множество способов взломать Java-приложение. В этой статье мы описали самый известный и эффективный способ, которым пользуется большинство хакеров. Всегда важно оставаться в курсе последних тенденций в области кибербезопасности и регулярно обновлять меры защиты.