Vol de données et de code source à partir d’une application Java

Scénarios d’attaque

Dans cet article, nous passons en revue les différentes manières d’injecter du code malveillant dans la JVM/de renifler le trafic des JVM/etc. L’objectif principal de cet article est d’expliquer comment protéger votre application. Le plan est d’effectuer les prochaines attaques :

Lire les données sensibles du vidage.
Volez le code source en injectant un malware dans une dépendance externe.

Vol de données à partir d’un vidage Java

Si quelqu’un a accès au processus Java, il peut être en mesure de lire des informations sensibles telles que des mots de passe ou des adresses de base de données. Jetons un coup d’œil à la prochaine configuration de 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;
}

Maintenant, si le pirate attaque notre serveur et accède au processus JVM, il peut alors effectuer le vidage de la mémoire de JVM en utilisant un programme jcmd. Par exemple:

jcmd 20932 GC.heap_dump d:dumpJVM_DUMP.bin

Lorsqu’il obtient le dump de JVM, il peut l’interroger avec le profileur VisualVM en utilisant le langage QOL. Par exemple, pour récupérer toutes les chaînes commençant par « JDBC », il peut effectuer la requête suivante :

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

Ou comme alternative, il peut récupérer l’objet MysqlDataSource :

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

Dans la vidéo suivante, je montrerai comment nous pouvons créer un vidage et trouver des données potentiellement sensibles à partir de DataSource :

Comment empêcher la lecture de données à partir du vidage ?

Pour éviter cela, vous devez :

Ajouter un paramètre -XX:+DisableAttachMechanism au démarrage de la JVM.
Désactivez l’appel jcmd sous Linux en désactivant l’appel système ptrace (si vous utilisez ubuntu).
Pour les utilisateurs non root, désactivez l’accès aux processus en définissant hidepid=1.
Chiffrez les données du côté Java (cela nécessite un article séparé pour expliquer).

Vol de code source en injectant un logiciel malveillant dans une dépendance Java

La grande majorité des applications Java utilisent des dépendances. Même les applications hello world devraient utiliser la dépendance de l’enregistreur. Personne ne veut réinventer la roue et préfère utiliser les solutions existantes. Mais tout le monde ne sait pas que les dépendances peuvent être la source de fuites potentielles de code source ou de problèmes encore pires.

Comment un pirate peut injecter du code indésirable à l’aide d’une dépendance externe

Pour effectuer une attaque, un hacker a généralement besoin de 2 choses :

Prenez le contrôle de la dépendance à des tiers dans maven (ou tout autre référentiel public) et publiez une nouvelle version avec des logiciels malveillants (ou remplacez la version existante).
Espérons que l’application du client utilise un référentiel externe avec une nouvelle version de dépendance (ou un cas parfait avec la dernière version de $).

Si ces conditions sont remplies, une dépendance infectée peut exécuter du code malveillant. Quelle opportunité cela donne-t-il aux hackers ? Nombreux! Maintenant, il peut :

Les exemples ci-dessus ne décrivent pas tous les problèmes potentiels. À l’intérieur des logiciels malveillants, nous sommes capables d’exécuter de manière dynamique presque toutes les applications imaginables. Mais parmi tous les problèmes, je pense que le plus cher est le code source volé.

Comment voler le code source ?

Dans la mesure où JVM a accès à un dossier avec des classes, on peut s’attendre à ce que la dépendance externe ait également le droit de le lire. En pratique, voler le code source comporte 2 étapes :

Copiez les fichiers *.classes du répertoire utilisateur/classpath.
Envoyez des données binaires *.classes au serveur du pirate (dans notre exemple, nous imprimerons simplement les noms des classes et leur taille).

Reproduire l’attaque avec l’enregistreur SLF4J

Dans cet exemple, nous allons reproduire l’attaque en injectant un malware dans le logger SLF4J. Nous supposons que le pirate a eu accès au référentiel SLF4J (en option, le pirate peut effectuer une attaque Man in the Middle et remplacer les demandes entrantes de fichier jar provenant du référentiel externe).

Ce que nous attendons du côté des victimes

Il a une dépendance à l’enregistreur du référentiel externe (par exemple, maven central).
Il utilise la dernière version ou la met à jour manuellement vers la plus récente (condition non obligatoire mais dans ce cas, la fuite sera détectée ultérieurement par la communauté car la plupart des utilisateurs utilisent la version fixe).

Le scénario d’attaque

Exemple d’attaque

Détails de l’application Java de la victime

Côté pirate

Résultats lorsque la victime met à jour la version et démarre l’application

Comment protéger vos applications contre de telles attaques

Existe-t-il un moyen ultime de protéger votre application Java contre de telles attaques ? Malheureusement non, il existe de nombreuses façons d’injecter des logiciels malveillants dans votre code. Les pirates peuvent injecter des logiciels malveillants pendant la construction ou en injectant des logiciels malveillants dans le JDK, ainsi que remplacer les dépendances de manière dynamique en contrôlant votre réseau. Cependant, voici quelques mesures de précaution que vous devez mettre en œuvre afin de protéger votre application :

N’utilisez jamais un référentiel externe mais votre référentiel privé (par exemple https://oss.sonatype.org/).
Utilisez une version de dépendance stable et n’utilisez jamais $LATEST.
N’utilisez jamais de dépendances personnalisées et non officielles (pas de sources officielles).
Configurez le réseau et fermez la plupart des ports/protocoles pour éviter le transfert de code source.
Dans le cas critique, déployez votre application dans un réseau privé interne (bien que ce ne soit pas une option pour la plupart des applications, en particulier avec les clients du monde entier).

Conclusion

Il existe de nombreuses autres façons de pirater des applications Java. Dans cet article, j’ai décrit le moyen le plus connu et le plus efficace utilisé par la plupart des pirates. N’ignorez pas la recommandation mentionnée et protégez votre application.

C’était mon premier article avec GIF. Faites-moi savoir si vous l’aimez afin que je puisse garder cette pratique pour de futurs articles. Merci d’avoir lu!