Mettez-vous hors ligne avec l'application Player FM !
LCC 272 - Interview sur Log4Shell avec this
Manage episode 320231512 series 25488
Emmanuel et Arnaud reviennent sur la fameuse faille #log4shell qui a fait travailler beaucoup d’équipes Java en décembre et janvier.
Enregistré le 11 février 2022
Téléchargement de l’épisode LesCastCodeurs-Episode–272.mp3
Interview Quelle est cette vulnérabilité et pourquoi est-elle si dangereuse ?Reportée chez Apache le 24 Novembre, Enregistrée en CVE le 26 Nov Probablement connue depuis au moins Mars 2021: https://github.com/nice0e3/log4j_POC
- fix 2.15.0 le 10 décembre
- Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints.
- Severity CVSS de 10 sur 10
- jamais vu
- Back to basics: C’est quoi JNDI?
- the JNDI features used in configurations, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints
- l’attaquant trouve une donnée utilisateur qui est loggée
- Pas que HTTP
- et injecte {JNDI:ldap pointant vers un ldap malicieux qui retour du code java sérialisé
- log4j deserialise et execute ce que l’on veut
- que log4j2-core pas api
- détail de Lunasec log4j zero day
- mitigations initiales
- 2.16.0 (change des fonctionalités) le 13 décembre
- Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote code execution in certain non-default configurations
- When the logging configuration uses a non-default Pattern Layout with a Context Lookup
- $${ctx:loginId})
- attackers with control over Thread Context Map (MDC / Mapped Diagnostic Context) input data can craft malicious input data using a JNDI Lookup pattern
- donc on peut injected une chaine JNDI encore
- mais on doit savoir comment de la date utilisateur on peut pousser dans une Thread Context Map référencée par la config
- on alors l’attaquant a accès à la config et c’est game over
- Initialement on parlait de denial of services
- via une reference infinie probablement
- c’est une chemin qui n’était pas protégé des interpolations de messages et donc de l’accès JNDI
- fix dans 2.17.0 le 18 décembre
- recursion non controlée dans un lookup auto référentiel
- When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}
- Besoin de l’attaquant control de Thread Context Map (peut etre une donnée injectée par un framework d’une entrée utilisateur
- changer la config log4j locale?
- 2.17.1 le 27 décembre
- Apache Log4j2 vulnerable to RCE via JDBC Appender when attacker controls configuration
- malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code.
- attaquant accede et modifie la config
- pas simple
- sauf si la plateforme permet la reconfiguration par un utilisateur???
- log
- montre 8% de packages sur central affectés par log4j 2
- niveau de dépendance transitive monte jusqu’à 9
- du coup il y a neuf vendeurs qui doivent corriger leurs dépendances
Toujours plus de 40% de téléchargement sur Maven central des versions impactées
Log4j1 n’est pas en reste:
- JMSAppender
- JMS dit JNDI et paf on recommence
- JDBCAppender
- SQL injection FTW
- log4j1 n’est plus maintenue ah merde!
- Apache Kafka
- 1.2.17 compatible
- voir les fixes
Peu au final Car chaque usage de log4j est unique Entrée quoi est loggé etc Donc trop dur pour les script kiddies
Mais dans les megasploits et autres toolkits d’attaque
VMware vSphere et Hoirizon Ubiquity Solarwind etc
Quel process suivreverifier la véracité de la CVE et comprendre ses vecteurs d’attaque
identifier ses dépendances et donc ses soft impacté
identifier les éléments fournis par l’utilisateur qui sont loggés
définir le risque par software et par service
appliquer le patch de sécurité et reconstruire le package
déployer ou livrer chez les clients
répéter pour les semaines à venir
shading? :)
La chine a tapé sur les doigts Alibaba qui n’a pas donné cette faille d’abord au gouvernement chinois
The Gift of It’s Your Problem Now
- Discussion sur le paiement et l’open source
- Pour un individuel l’open source est un cadeau, et donner de l’argent n’améliore pas le cadeau
- Injecter de la compensation financière dans un cadeau casse le cadeau et ne change pas la motivation (ou la casse)
- Pour une société, l’open source est un moyen de récupérer du feedback et du marketing, donc c’est une transaction et pas un cadeau
- Un autre article similaire burden open source maintainer
- mainteneur rajoute une boucle infinie dans un package modems très utilisé
- en protestation de non contribution (financière)
- 20 millions de téléchargements par semaine
- GitHub a bloqué son compte et nom a remis une ancienne version
- un peu de temps avant il s’est fait copié son idée de faker.js as a service
Reflection on log4shell par diabolical developer
- marathon pas un sprint, on fatigue après 5 ou 6 jours a fond, donc faites des rotations
- comm sur le réseau, que regarder : Adding encryption, Auth/Auth, I sanitize data that goes over the wire, I sanitize input that could execute, DOS protection – backoff strategies and more.
- supply chain sécurisation and component governance
- OSS funding (hum?)
Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/
320 episodes
Manage episode 320231512 series 25488
Emmanuel et Arnaud reviennent sur la fameuse faille #log4shell qui a fait travailler beaucoup d’équipes Java en décembre et janvier.
Enregistré le 11 février 2022
Téléchargement de l’épisode LesCastCodeurs-Episode–272.mp3
Interview Quelle est cette vulnérabilité et pourquoi est-elle si dangereuse ?Reportée chez Apache le 24 Novembre, Enregistrée en CVE le 26 Nov Probablement connue depuis au moins Mars 2021: https://github.com/nice0e3/log4j_POC
- fix 2.15.0 le 10 décembre
- Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints.
- Severity CVSS de 10 sur 10
- jamais vu
- Back to basics: C’est quoi JNDI?
- the JNDI features used in configurations, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints
- l’attaquant trouve une donnée utilisateur qui est loggée
- Pas que HTTP
- et injecte {JNDI:ldap pointant vers un ldap malicieux qui retour du code java sérialisé
- log4j deserialise et execute ce que l’on veut
- que log4j2-core pas api
- détail de Lunasec log4j zero day
- mitigations initiales
- 2.16.0 (change des fonctionalités) le 13 décembre
- Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote code execution in certain non-default configurations
- When the logging configuration uses a non-default Pattern Layout with a Context Lookup
- $${ctx:loginId})
- attackers with control over Thread Context Map (MDC / Mapped Diagnostic Context) input data can craft malicious input data using a JNDI Lookup pattern
- donc on peut injected une chaine JNDI encore
- mais on doit savoir comment de la date utilisateur on peut pousser dans une Thread Context Map référencée par la config
- on alors l’attaquant a accès à la config et c’est game over
- Initialement on parlait de denial of services
- via une reference infinie probablement
- c’est une chemin qui n’était pas protégé des interpolations de messages et donc de l’accès JNDI
- fix dans 2.17.0 le 18 décembre
- recursion non controlée dans un lookup auto référentiel
- When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}
- Besoin de l’attaquant control de Thread Context Map (peut etre une donnée injectée par un framework d’une entrée utilisateur
- changer la config log4j locale?
- 2.17.1 le 27 décembre
- Apache Log4j2 vulnerable to RCE via JDBC Appender when attacker controls configuration
- malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code.
- attaquant accede et modifie la config
- pas simple
- sauf si la plateforme permet la reconfiguration par un utilisateur???
- log
- montre 8% de packages sur central affectés par log4j 2
- niveau de dépendance transitive monte jusqu’à 9
- du coup il y a neuf vendeurs qui doivent corriger leurs dépendances
Toujours plus de 40% de téléchargement sur Maven central des versions impactées
Log4j1 n’est pas en reste:
- JMSAppender
- JMS dit JNDI et paf on recommence
- JDBCAppender
- SQL injection FTW
- log4j1 n’est plus maintenue ah merde!
- Apache Kafka
- 1.2.17 compatible
- voir les fixes
Peu au final Car chaque usage de log4j est unique Entrée quoi est loggé etc Donc trop dur pour les script kiddies
Mais dans les megasploits et autres toolkits d’attaque
VMware vSphere et Hoirizon Ubiquity Solarwind etc
Quel process suivreverifier la véracité de la CVE et comprendre ses vecteurs d’attaque
identifier ses dépendances et donc ses soft impacté
identifier les éléments fournis par l’utilisateur qui sont loggés
définir le risque par software et par service
appliquer le patch de sécurité et reconstruire le package
déployer ou livrer chez les clients
répéter pour les semaines à venir
shading? :)
La chine a tapé sur les doigts Alibaba qui n’a pas donné cette faille d’abord au gouvernement chinois
The Gift of It’s Your Problem Now
- Discussion sur le paiement et l’open source
- Pour un individuel l’open source est un cadeau, et donner de l’argent n’améliore pas le cadeau
- Injecter de la compensation financière dans un cadeau casse le cadeau et ne change pas la motivation (ou la casse)
- Pour une société, l’open source est un moyen de récupérer du feedback et du marketing, donc c’est une transaction et pas un cadeau
- Un autre article similaire burden open source maintainer
- mainteneur rajoute une boucle infinie dans un package modems très utilisé
- en protestation de non contribution (financière)
- 20 millions de téléchargements par semaine
- GitHub a bloqué son compte et nom a remis une ancienne version
- un peu de temps avant il s’est fait copié son idée de faker.js as a service
Reflection on log4shell par diabolical developer
- marathon pas un sprint, on fatigue après 5 ou 6 jours a fond, donc faites des rotations
- comm sur le réseau, que regarder : Adding encryption, Auth/Auth, I sanitize data that goes over the wire, I sanitize input that could execute, DOS protection – backoff strategies and more.
- supply chain sécurisation and component governance
- OSS funding (hum?)
Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/
320 episodes
Tous les épisodes
×Bienvenue sur Lecteur FM!
Lecteur FM recherche sur Internet des podcasts de haute qualité que vous pourrez apprécier dès maintenant. C'est la meilleure application de podcast et fonctionne sur Android, iPhone et le Web. Inscrivez-vous pour synchroniser les abonnements sur tous les appareils.