Macaron. Une porte dérobée pour JavaEE. Philippe PRADOS. Solutions Linux

Transcription

1 Macaron Une porte dérobée pour JavaEE Philippe PRADOS Solutions Linux

2 Curriculum Vitae» Philippe PRADOS» Architecte, Consultant» Expert sécurité applicative» Nombreuses publications 2

3 Le risque» Combien faut-il payer pour convaincre un développeur d'insérer un code malveillant? $ US?» «La plupart des agressions dont sont victimes les entreprises viennent de l intérieur. Les différentes études estiment ce chiffre aux alentours de 80%.» Pascal Courtin, chef de la Brigade d Enquête sur les Fraudes aux Technologies de l Information» Cas réels de «traitrise»,» Un site US de e-commerce développé en inde. Un développeur a ajouté du code pour lister toutes les informations bancaires.» Utilisation frauduleuse de milliers de cartes bancaires.»»»»» 3 e-bay, Modem Alcatel ADSL Ministère des finances TS Ameritrade (2007)...

4 Les travaux de recherche Atos Origin» Plusieurs mois de recherche pour identifier différentes techniques d'attaques» Résistant aux audits classiques» Résistant à tous les outils de protection (firewall réseau ou applicatif)» Identification de nouvelles failles» La porte dérobée «macaron»» Permet des attaques internes au projet (présence d'un traite)» Ou des attaques externes!» lors de l'intégration de composants logiciels.» Travaux viennent d'être publiés» Symposium sur la Sécurité des Technologies de l'information et des Communications (Juin 2009)» Publication dans MISC (magazine de référence) et GNU Linux Mag 4

5 Le projet «macaron» Une porte dérobée pour les serveurs JavaEE 5

6 Backdoor JavaEE» L'affaire Kerviel à démontré que les attaques peuvent venir de l'intérieur.» Les développeurs peuvent volontairement laisser des portes dérobés permettant une exploitation inhabituelle de l'application if (contribuable.equals("philippe") impot=(byte)impot;» Comment s'en protéger?» Quelles techniques sont utilisées? 6

7 À la place du pirate» Pour étudier les possibilités d'injecter des portes dérobées dans les applications JavaEE nous allons nous positionner - pour la bonne cause - dans l'optique d'un pirate.» Quels sont les objectifs?» Quels sont les moyens de détection à contourner?» Quels sont les solutions de protection? 7

8 Sommaire» Objectif du pirate» Implémentation» Démonstration» Propagation» Solutions 8

9 Une porte dérobée» Doit résister à un audit du code de l'application» La découverte est sinon possible par chaque développeur qui participe au projet» Doit résister aux évolutions futures du code» Il ne doit pas y avoir de dépendance avec le code existant. Une évolution de l'application ne doit pas faire échec à la porte dérobée.» Doit contourner le firewall réseau et le firewall applicatif» La communication avec la porte doit être invisible.» Contourner les outils d'analyse de vulnérabilité dans le byte-code, par propagation de teinture sur les variables. 9

10 Objectifs» Résister aux audits applicatifs» Le code de la porte dérobée ne doit pas être présent dans les sources ;» L'application ne doit pas l'invoquer ;» Solution: - Présent dans une archive déclarée saine (JAR). - Utilisation de pièges pour exécution implicite de code» Résister aux évolutions future du code» Le code doit être actif, quelque soit l'application pervertie.» Solution: - Utiliser des attaques génériques, exploitant les spécifications JavaEE» Doit contourner le firewall réseau et le firewall applicatif» Solution: - Simuler une navigation légitime de l'application» Contourner les outils d'analyse de vulnérabilité dans le byte-code» Utiliser du code d'échappement des analyses de code. 10

11 Sommaire» Objectif du pirate» Démonstration» Implémentation» Les pièges» Augmentation des privilèges» Exécution» Détection de l'ouverture» Discrétion» Les agents» Propagation 11» Solutions

12 Les pièges : Initialisation de la porte dérobé» La porte dérobé doit pouvoir démarrer alors que le code applicatif ignore sa présence.» Il faut utiliser une technique permettant une exécution de code par la simple présence de l'archive JAR» Plusieurs pièges :» Surcharge d'une classe» Ajout d'un fichier de paramétrage» Exploitation d'un «Ressource Bundle»» Exploitation des «services»» Exploitation de l'aop» Utilisation des annotations 12

13 Piège : Surcharge de classes» Dupliquer une classe de l'application ou d'une autre librairie pour enrichir son comportement» Les classes sont recherchées dans toutes les librairies, les unes après les autres.» Si la librairie de la porte dérobée à la chance d'être avant la librairie originale, le code de la porte dérobée s'exécute a'.class 13 a.class

14 Piège : Surcharge de classes» Inconvénient :» Le code de la porte dérobée est fortement dépendant du code original ;» Il est difficile de propager les traitements sur l'original en mode «hook» ;» La modification de l'original peut entraîner le plantage de l'application ;» L'exécution n'est pas garantie. Cela dépend de l'ordre de sélection des archives par la JVM» Approche rejetée 14

15 Piège : Paramétrage» Utilisation de fichiers de paramétrages» Certains frameworks recherchent des fichiers de paramètres à différents endroits dans les archives.» Ces fichiers possèdent des noms de classes.» En plaçant un fichier de paramètre dans un lieu prioritaire, il est possible d'injecter du code» Et de déléguer le comportement à la classe originale. 15

16 Piège : Paramétrage» Exemple : Axis (Invocation de Web-services)» recherche le fichier client-config.wsdd» Dans : - <warpath>/web-inf/ - /WEB-INF/ - /» Ce dernier indique les classes en charge des transports lors de l'invocation d'un service Web» La présence du fichier dans la racine d'une archive quelconque suffit à injecter du code lors de l'invocation du premier service Web 16

17 Piège : ResourceBundle 1/4» Pour gérer les messages en plusieurs langues, Java utilise des ResourcesBundles.» L'algorithme recherche un fichier.properties suivant différents critères de langues. 17

18 Piège : ResourceBundle 2/4» ResourceBundle.getBundle("Messages")» Lecture de fichier.properties (clef/valeur) Messages_fr_FR.properties Messages_fr.properties Messages.properties 18

19 Piège : ResourceBundle 3/4» ResourceBundle.getBundle("Messages")» Mais avant cela, recherche de classes Messages_fr_FR.class Messages_fr_FR.properties Messages_fr.class Messages_fr.properties Messages.class Messages.properties 19

20 Piège : ResourceBundle 4/4» Simuler un comportement classique, tous en ajoutant du code public static class messages extends PropertyResourceBundle { public messages() throws IOException { super(messages.class.getresourceasstream( '/'+messages.class.getname().replace('.','/')+".properties")); System.err.println( "*** Backdoor-JavaEE start via"+ " the RessourceBundle "+getclass().getname()); } } 20

21 Pièges : Exploitation des services» Fichier META-INF/services/xxx» Permet aux archives de proposer des implémentations de services» Utilisé par les parseurs XML, Log4j, et tous les composants JavaEE» Un service peut détourner un parseur XML pour modifier le flux avant son analyse.» Permet l'injection de paramètres complémentaires pour les frameworks (Log4j, Spring, etc.). 21

22 Piège : AOP» Les «aspect» sont décrit dans un fichier aop.xml» C'est une technologie naturelle d'injection de code» Il est alors facile d'injecter du traitement n'importe où,» Entre autre, dans toutes les servlets. 22

23 Piège : Annotation» De plus en plus de framework utilisent l'annotation pour identifier des classes et des instances à initialiser.» C'est un objectif de l'annotation : réduire la paramétrage.» Par exemple, Spring instancie les classes étant annotées Contrainte : Il faut déclarer une classe dans un répertoire consulté par l'application lors de son initialisation.» Contrainte levée avec les spécifications Servlet 3.0.» Toutes les classes sont consultées pour les nouvelles annotations (@Filter) 23

25 Les droits lors de l'exécution du piège» Le code du piège n'a pas toujours les droits nécessaires à la mise en place judicieuse de la porte dérobée.» Si la porte dérobée ne bénéficie pas d'un environnement idéal pour installer tous le nécessaire, elle doit augmenter ses privilèges.» Les privilèges peuvent être des droits à des API (Sécurité Java2)» ou pouvoir accéder à des classes du serveur d'application.» Les classes sont isolées dans des ClassLoaders différents» Les applications n'ont pas accès à toutes les classes du serveur d'application Communs Serveur d'application 25 Applications Applications

26 Augmentation de privilèges» La porte dérobée doit s'insérer dans l'application et y rester après un redémarrage, avec plus de privilège.» Une copie d'une archive dans un répertoire plus privilégié permettra d'augmenter les droits du code (répertoire des archives de Tomcat)» La technique de ResourceBundle sur une ressource de Tomcat permet l'injection de code lors du redémarrage du serveur d'application.» Technique parfois nécessaire en Tomcat 5, mais plus en Tomcat 6! 26

28 Où insérer la porte dérobée?» L'idéal est de pouvoir l'injecter dans chaque requête pour y détecter une clef spécifique ouvrant la porte.» Plusieurs stratégies :» Ajout d'un filtre JavaEE» Ajouter dynamiquement une Valve Tomcat» Injection par XML» Injection par Autoproxy» Injection par Aspect» Injection lors de la compilation 28

29 Injection : Ajout d'un filtre JavaEE 1/2» Le serveur Tomcat dé-zip les archives des composants dans un répertoire de travail.» Le piège de la porte dérobé» retrouve le fichier web.xml du cache de Tomcat» Injecte un filtre JavaEE dans ce fichier» Le filtre sera présent après un redémarrage de Tomcat» Avec les Servlet 3.0 :» nouvelle API : ServletContext.addFilter(...)» Ou web-fragment.xml 29

30 Injection : Ajout d'un filtre JavaEE 1/2» Le filtre JavaEE capture toute les requêtes... <filter> <filter-name>backdoor</filter-name> <filter-class>backdoorfilter</filter-class> </filter> <filter-mapping> <filter-name>backdoor</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>... 30

31 Injection : Valve Tomcat» Tomcat propose des Valves (filtres spécifiques) pouvant être ajoutée dynamiquement via une requête JMX» Avec Tomcat 5,» Nécessite une augmentation de privilège (pour avoir accès à la classe Valve)» Ou présence de l'attribut privileged="true" dans <Context/>» Avec Tomcat 6,» Toujours possible, si le serveur n'utilise pas la sécurité Java2 31

32 Injection : Parseur XML» En déclarant un service,» Détournement d'un parseur XML pour modifier le flux avant analyse par les frameworks» Permet l'injection de <bean/> dans Spring, la manipulation des logs, etc.» Pas de solution de protection autre que l'application du patch JDK que nous avons publié. 32

33 Injection : Auto-Proxy» Les proxies du JDK où généré par CGLIB, permettent d'injecter du code dans les singletons.» Le privilège suppressaccesschecks permet alors de modifier les singletons.» Et même de modifier des instances immuables «String» 33

34 Injection : Aspect» La programmation par Aspect permet naturellement l'injection de code dans l'application.» Si la fonctionnalité est présente globalement (via l'agent AspectJ),» Tous le flux de traitement vers les requêtes ou les fichiers JSP peuvent être public static class BackDoorAspect doget(..))" + " execution(void dopost(..))" + " execution(void service(..))" + " execution(void _jspservice(..))") public void backdoor(proceedingjoinpoint pjp) {... } } 34 throws Throwable

35 Injection : Servlet 3.0» Les nouvelles annotations permettent naturellement les injections» De servlet» De filtre,» De session listener» Etc.» Plus les technologies évolues, plus les attaques sont faciles. 35

36 Injection : lors de la compilation» JSR268 est un service, permettant d'ajouter des plugins lors de la compilation» Permet» l'ajout de classe,» de librairie» De fichiers de paramètres» voir la modification du byte code d'une classe compilée!» L'audit du code source ne révèle rien.» La vérification des composants et leurs signatures ne révèle rien!» Il faut décompiler le code pour trouver l'attaque! 36

38 Détection de l'ouverture» Sur la présence d'une clef dans un champ quelconque de n'importe quel formulaire :» détournement du traitement vers la porte dérobée» La clef est le mot MACARON en écriture Elit :«M4c4r0n» 38

39 Sommaire» Objectif du pirate» Démonstration» Implémentation» Initialisation» Augmentation des privilèges» Exécution» Détection de l'ouverture» Discrétion» Les agents» Propagation 39» Solutions

40 Évasion des firewall applicatif» Les firewalls applicatifs détectent :» Les URLs utilisées via une liste blanche» La liste des champs pour les URLs et les contraintes de format (chiffre/lettre, taille, etc.)» La vitesse des requêtes (n requêtes par secondes maximum pour un humain). Attention, les robots violent cette contrainte.» Une liste noire de mot clef dans les réponses. 40

41 Pour contourner...» Le filtre utilise une URL standard de l'application, celle utilisée pour insérer la clef.» La communication s'effectue en remplissant un formulaire avec une valeur spéciale (conforme aux contraintes des champs)» Les agents de la porte dérobées n'utilisent alors que cette URL, en soumettant toujours le même formulaire, avec les mêmes valeurs.» Sauf pour un seul champ qui sert de transport» Le code injecté capture les requêtes avant l'application.» Et offre différents services d'attaques en exploitant AJAX. 41

42 Le scénario d'attaque est le suivant» Étape 1 : Si nécessaire, augmentation des privilèges» Utilisation d'un piège» Déplacement de l'archive de la porte dérobée» Attente d'un redémarrage du serveur d'application» Étape 2 : Installation effective de la porte dérobé» Utilisation d'un piège avec plus de privilèges» Injection d'un filtre sur toutes les requêtes» Détection de la clef pour détourner le flux de traitement des requêtes» Étape 3 : Utilisation des agents disponibles, suivant les privilèges accordés à l'application. 42

44 Les agents» Différents agents d'analyses sont disponibles» History (les dernières requêtes)» JNDI (Annuaire d'objets : DB, files, etc.)» JMX (Outils de gestions dynamique du serveur)» JDBC (Base de donnée)» Java (Compilation et exécution dynamique de code)» Shell (Pour exploiter le serveur) 44

46 Demonstration La démo 46

47 Diffusion» Le code est un bon exemple de ce que peut faire un développeur inconvenant» Pour vérifier que les protections sont en place, il faut les chalenger» Le code proposé sert à cela (POC)» Il vous permet de qualifier votre environnement» Il est diffusé en archive non hostile, pas en source. 47

48 Diffusion = risque?» «Vous diffusez un code de pirate!»» Pour éviter des usages malvenus, le code est techniquement fortement protégé contre la décompilation.» Un pirate étant capable de le décompiler est capable de l'écrire, et cela plus rapidement ;-)» Il est volontairement très verbeux. Les logs présents reçoivent un message signalant clairement sa présence et ce qu'il fait. 48

49 Diffusion = risque?» La clef est codé en «dur» et ne peut pas être modifiée» Une simple règle du firewall permet alors d'interdire son usage depuis le réseau.» Il suffit de détecter le mot «M4c4r0n» pour couper la communication. 49

50 Le code à vocation «preuve de concept»» Il peut être utilisé pour qualifier l'environnement d'exécution» Les sources n'étant pas publique, rien ne garantie qu'il n'y a pas de deuxième porte dérobée dans le code (bon reflex!).» J'affirme que ce n'est pas le cas, mais vous ne pouvez le vérifier sans une étude approfondie.» Conclusion : ne pas l'utiliser en production» Vous avez alors saisie le message important de cette présentation 50

52 Injection de la porte dans un projet» Attaque interne (présence d'un traite) :» Injecter le code dans une archive d'un Open Source ou non, utilisé par le projet» Déclarer une dépendance MAVEN dans un des composants du projet»...» Attaque externe :» Déclarer une dépendance MAVEN dans le repository standard de MAVEN.» Attaquer le compte d'un contributeur et injecter la porte dans un composant Open Source» Possible même si le composant en question n'est pas présent en production! (via le JSR269)» Ainsi, tous les projets injectent la porte dérobée! 52

54 Pourquoi ce risque» Risque inhérents aux développements Java actuels» Confiance absolue accordée» aux développeurs,» prestataires,» composants tiers.» Des solutions existent, mais» Ignorées des développeurs» Complexes à appliquer 54

55 Solutions» Atos Origin propose avec «Macaron» trois outils d'aide à l'identification et au renforcement des développements» Expertise pratiquement unique d'atos Origin sur le sujet.» Seulement deux publications (approches complémentaires)» «Macaron» en Juin 2009 au SSTIC par Philippe Prados, Atos Origin» «Entreprise Java Rootkits» en Aout 2009 par Jeff Williams au BlackHat 55

56 Les solutions Java» Java possède un mode «sécurisé» limitant fortement les possibilités de la porte dérobée» Correctement utilisé, la porte dérobée ne peut s'installer en tant que filtre et capturer tous le trafic.» Permet de confiner le code serveur dans un «bac à sable»» Lorsque la sécurité Java est activé, les APIs disponibles sont limitées» Les classes du serveurs d'applications ont tous les privilèges, mais pas les applications hébergées 56

57 L'utilisation de la sécurité Java» Dans ce mode,» les projets doivent déclarer des privilèges pour leurs projets (accès à certains répertoires, certaines machines du réseau, etc.)» Attention, l'ouverture de privilèges peut également permettre les portes dérobées.» Il faut ouvrir les privilèges pour chaque archive et non globalement pour l'application.» Ainsi, un droit offert à un framework n'est pas disponible pour la porte dérobée.» Mais, cette information est rarement disponible.» Seul un test permet d'ouvrir, au fur et à mesure, l'ensemble des droits nécessaires à l'application» Macaron-policy facilite la gestion des privilèges 57

58 Archives scellée» Java permet également de sceller les packages dans les archives.» Ainsi, si la sécurité Java est active, toutes les classes d'un package doivent venir de la même archive.» Protège des attaques par remplacement de classes.» Macaron-seal facilite le scellement de tous les composants 58

59 Dans la vraie vie» Les serveurs d'applications utilisent rarement la sécurité Java2» Pourquoi?» Les développeurs ne connaissent pas» N'ayant jamais testé ce mode, ils ne savent pas les droits minimums nécessaires.» Dans le doute, pour ne pas faire planter l'application, tous les privilèges sont ouverts» Cela complexifie l'installation des composants car il faut modifier un fichier global du serveur d'application (*.policy).» Impact sur les performances sur-estimé 59

60 Tomcat» Tomcat propose un paramètre pour utiliser la sécurité Java2.»./catalina.sh run -security» Il aurait été préférable d'avoir la sécurité par défaut, et un paramètre pour la supprimer.» Les droits peuvent être spécialisés pour chaque composant applicatif. 60

61 JBoss» JBoss ne propose pas la sécurité Java 2!» Le wiki indique comment modifier le script de lancement pour ajouter les droits» Mais, par défaut, il n'est pas possible d'indiquer des droits différents pour chaque composant ou chaque archive.» Un paramètre permet de modifier cela.» Par défaut, sous JBoss, la porte dérobée est pratiquement toujours possible! 61

62 Détection» Différent symptôme peuvent éveiller les soupçons :» La présence de classes ou de package de même nom dans des archives différentes» La présence de fichiers de même nom à des emplacement différents» La présence de fichiers de même nom avec des extensions différentes dans les mêmes répertoires.» La présence de certaines annotations» Macaron-audit permet d'identifier les risques 62

63 Deux patchs à OpenJDK 6 sont proposés» Pour contrer les attaques» RessourceBundle» ServiceLocator» Deux patchs sont proposés.» SUN et Tomcat travaillent sur ces vulnérabilités, sur la base de nos patchs 63

64 Conclusion» Vous n'êtes pas obligé de faire confiance aux développeurs» Imposez l'utilisation de la sécurité Java2 dès les phases de développement» Ne faite pas confiance aux repositories» Limité au maximum les droits ouverts aux projets et aux composants» Testez l'utilisation de la porte dérobée «macaron» dans votre projet.» Il suffit d'ajouter une archive. Il n'est pas nécessaire de modifier le code.» En production, vous pourrez alors choisir d'activer ou non la sécurité, suivant le niveau d'alerte du moment. 64

65 Offre» Macaron-audit» «Vos développements Java vous exposent-ils à ce risque»?» Audit par sondage ou complet des dév. Java» Utilisation des outils + analyse d'un expert» Rapport détaillé» Failles détectées, criticité» Comment y remédier» Macaron-best practices» Mise en place des processus préventifs et de l'outillage» Rédaction de charte de développement» Coaching des équipes de développement» Macaron-fix in» Recherche de preuves» Option «durcissement des dév.» dans nos offres de TMA 65

66 Questions? 66

67 Pour plus d informations, contacter : Philippe PRADOS +33 (0) macaron@prados.fr Atos Origin 18 avenue d'alsace 92926, Paris la Défense Cedex