iot時代に求められるリスク対応と jpcert/ccの取り組み ·...

IoT時代に求められるリスク対応とJPCERT/CCの取り組み

2019年12⽉18⽇第11回TCG⽇本⽀部公開ワークショップJPCERT/CC 福本郁哉

Copyright ©2019 JPCERT/CC All rights reserved.

はじめに

1


「JPCERT/CCをご存知ですか︖」

JPCERT/CCとは⼀般社団法⼈ JPCERT コーディネーションセンター

Japan Computer Emergency Response Team Coordination Centerジェーピーサートコーディネーションセンター

コンピュータセキュリティインシデントへの対応、国内外にセンサをおいたインターネット定点観測、ソフトウエアや情報システム・制御システム機器等の脆弱性への対応などを通じ、セキュリティ向上を推進インシデント対応をはじめとする、国際連携が必要なオペレーションや情報連携に関する、我が国の窓⼝となるCSIRT（窓⼝CSIRT）

CSIRT: Computer Security Incident Response Team※各国に同様の窓⼝となるCSIRTが存在する(⽶国のUS-CERT、CERT/CC、中国のCNCERT/CC, 韓国のKrCERT/CC 等)

経済産業省からの委託事業として、サイバー攻撃等国際連携対応調整事業を実施

2


JPCERT/CCの活動〜 JPCERT/CCをご存知ですか︖〜

重要インフラ、重要情報インフラ事業者等の特定組織向け情報発信早期警戒情報

海外のNational-CSIRTや企業内のセキュリティ対応組織の構築・運⽤⽀援CSIRT構築⽀援

脆弱性情報ハンドリングØ 未公開の脆弱性関連情報を製品開発者

へ提供し、対応依頼Ø 関係機関と連携し、国際的に情報公開

⽇を調整Ø セキュアなコーディング⼿法の普及Ø 制御システムに関する脆弱性関連情報

の適切な流通

マルウエア（不正プログラム）等の攻撃⼿法の分析、解析アーティファクト分析

各種業務を円滑に⾏うための海外関係機関との連携国際連携

インシデントの予測と捕捉インシデント予防

制御システムに関するインシデントハンドリング/情報収集、分析発信制御システムセキュリティ

⽇本シーサート協議会、フィッシング対策協議会の事務局運営等国内外関係者との連携

Ø マルウエアの接続先等の攻撃関連サイト等の閉鎖等による被害最⼩化

Ø 攻撃⼿法の分析⽀援による被害可能性の確認、拡散抑⽌

Ø 再発防⽌に向けた関係各関の情報交換及び情報共有

インシデントハンドリング（インシデント対応調整⽀援）

情報収集・分析・発信定点観測（TSUBAME）

Ø ネットワークトラフィック情報の収集分析Ø セキュリティ上の脅威情報の収集、分析、必要とする組織への提供

3

ソフトウエア製品等の脆弱性情報に関わる開発者等との調整・公表脆弱性情報ハンドリング

発⽣したインシデントへの対応


コーディネーションセンターとしての役割様々なパートナーとの調整

NISC

ISAC CEPTOAR

国内外CSIRT

セキュリティ関連組織、ベンダ、研究者等

警察, IPA, NICT, J-LIS,個⼈情報保護委員会等

METI

Partnership

情報共有

活動

⽀援情報共有

情報共有Coordination

政府組織

被害組織攻撃者

情報

共有

Coordination

脅威

情報

モニ

タリ

ング

攻撃情報

調整

ISP, クラウド事業者, ネットワーク管理者

インシデントに関する調整 (coordination) 機関として問題解決に向けて、必要な⼈に必要な情報を届ける業務を⾏っています

4


連携活動の例: 脆弱性情報の流通

5

経済産業省告⽰等に基づく脆弱性情報ハンドリングの制度における「調整機関」を担う発⾒された脆弱性についてメーカーと調整を⾏い、「対策の準備」と「対策周知のための公表」を関係者間で準備する。年間で国内外数百件の調整を実施

発⾒者

海外CSIRT等

国内の「届出窓⼝」は（独）情報処理推進機構（IPA）が実施発⾒者

国内外のソフトウェア・機器メーカー

利⽤者

対策⽅法（修正パッチ）の準備

修正依頼公開⽇調整

注意喚起

IPA

発⾒者


JVN（Japan Vulnerability Notes）

6

情報セキュリティ早期警戒パートナーシップ

脆弱性発⾒者

IPA(受付機関)

JPCERT/CC(調整機関) ユーザ

関係者合意の元 JVN 発⾏

• 開発ベンダに修正パッチなどの作成を依頼

• CVEの採番• 脆弱性公表⽇などの調整

国内外の脆弱性について記載• JPCERT/CCで調整、公表• CERT/CC VU翻訳• etc.

届出通知

通知国外CSIRT 等


JPCERT/CCの活⽤コーディネーションセンターの役割と活⽤インシデントレスポンス脆弱性・脅威情報に関する情報流通

脆弱性情報【JVN】脅威情報、注意喚起、早期警戒情報他

アーティファクト分析【検体解析など】国内外のCSIRT 連携促進、コミュニティ推進

例えば、こんなときにお役⽴てくださいインシデントが発⽣し、初動対応での技術的な⽀援や情報が必要となるケース

⽇々の対策を進める上で、脆弱性や脅威に関する情報が必要となるケース

その他、お気軽にご相談ください

“インシデント”に向き合った活動を展開しています

7


製品セキュリティをめぐる2019年の動向と課題

8



観測データから⾒る2019年の製品セキュリティ動向

サプライチェーンと 3rd party library の問題

9



観測データから⾒る2019年の製品セキュリティ動向

10


インターネット定点観測システム "TSUBAME"

2007年活動開始APCERT* のWGとして活動中

11

(*): Asia Pacific Computer Emergency Response Team


インターネット定点観測システム "TSUBAME"

12

2019年12⽉現在


TSUBAMEによる観測23/TCP (Telnet) 宛の不審なパケットは定常的に観測送信元の多くはMirai系マルウエアに感染した監視カメラ、モニタリング装置等の IoT

機器固定IPアドレスでインターネットからアクセス可能

Shodan, Censys 等のサービスで検索可能デフォルト/推測しやすいパスワードでの運⽤、接続するネットワーク環境に改めて注意を

13

5555/TCP

Internet

対策されていない機器

Internet

感染前感染後

23/TCP2323/TCP

悪

wget / curl 等で取得

対策されていない機器

悪


TSUBAMEによる観測修正されていない過去の脆弱性を⽤いてマルウェア・ランサムウェアの感染拡⼤を狙うパケットも依然として多い 52869/TCP, 8081/TCP ... Realtek SDK の脆弱性(CVE-2014-8361) 37215/TCP, 32764/TCP ... Cisco, Huawei ほか複数社製ルータの脆弱性 (CVE-

2014-0659 , CVE-2017-17215 10000/TCP ... Webmin のコマンドインジェクションの脆弱性 (CVE-2019-15107)

15


TSUBAMEによる観測複数のSSL-VPN製品で発⾒された脆弱性を狙ったパケットが増加（8⽉下旬以降） Palo Alto Networks (CVE-2019-1579) Fortinet (CVE-2018-13379) Pulse Secure (CVE-2019-11510)

JPCERT/CC のハニーポットでもパケットを確認⾃社環境内の機器のアップデートは確実に

16

https://badpackets.net/over-14500-pulse-secure-vpn-endpoints-vulnerable-to-cve-2019-11510/https://www.jpcert.or.jp/at/2019/at190033.html


2019年に発⾏した注意喚起JPCERT/CC からの注意喚起の発⾏ 53件 (12⽉18⽇現在) 主な注意喚起

2019-02-14: runc の権限昇格の脆弱性 (CVE-2019-5736) に関する注意喚起2019-04-28: Oracle WebLogic Server の脆弱性 (CVE-2019-2725) に関する注意喚起2019-05-15: Intel 製品の複数の脆弱性 (INTEL-SA-00213) に関する注意喚起2019-09-02,06,10: 複数の SSL VPN 製品の脆弱性に関する注意喚起2019-10-28: ウイルスバスターコーポレートエディションの脆弱性 (CVE-2019-18187) に関する注意喚起2019-11-27, 12-02,06: マルウエア Emotet の感染に関する注意喚起

発⾏時点で実証コード or 悪⽤が確認されていたもの ... 13件脆弱性情報が公開された後に実証 (PoC) コードが公開されるケースもある脆弱性を早期に修正すること修正を利⽤者に早期に適⽤してもらうこと

17

これらが不可⽋


組織におけるインシデントへの対応発⽣したインシデントへの対応 (主に CSIRT) インシデント初動対応への技術的な⽀援、助⾔例）インシデントレスポンス、アーティファクト分析など

CSIRT : Computer Security Incident Response/Readiness Team

製品の脆弱性への対応 (主に PSIRT) 届けられた製品の脆弱性についての調整、脆弱性情報の公開 PSIRT : Product Security Incident Response/Readiness Team

この⼆つの組織内機能を活⽤して対策を進めることが肝要です

18

JPCERT/CC は CSIRT や PSIRT の構築・運⽤の関するノウハウや技術の⽀援を⾏っています


組織における PSIRT の活動CSIRT と PSIRT の違い CSIRT

組織内のシステムに対するセキュリティに注⽬した活動 PSIRT

⾃社製品のセキュリティ (脆弱性等) に注⽬した活動

PSIRT には製品・サービスの脆弱性への対応が期待される脆弱性情報の受領、調査、報告・通知の管理等守る対象となる製品・サービス、組織などの特性に応じてPSIRT の組織構造やサービスは様々な形態が考えられる

19


PSIRT Services FrameworkFIRST が作成した PSRIT の構築・運⽤のためのガイドライン https://www.first.org/education/FIRST_PSIRT_Service_Framework_v1.0 ⽇本語版を作りましたhttps://www.first.org/education/PSIRT_Services_Framework_v1.0_ja.pdf

PSIRTのサービスを6つに分類して、必要な機能や資産を解説1. ステークホルダエコシステムマネジメント2. 脆弱性の発⾒3. 脆弱性のトリアージと分析4. 対策5. 脆弱性の開⽰6. トレーニングと教育⾃組織に必要なPSIRT構築・運⽤の指針としてご活⽤ください

20


5555/TCP を悪⽤したMirai系マルウエアの活動は継続中5555/TCP を悪⽤したMirai亜種の感染拡⼤活動は昨年から継続中 5555/TCP の観測状況 (2018.01 ~ 2019.11)

21

Android Debug Bridge (ADB) 本来 Android の開発・デバッグ⽤途に⽤いられる機能 5555/TCP で接続し shell を開いて任意のコマンドを実⾏することが可能


5555/TCP を利⽤したMirai系マルウエアの活動は継続中攻撃対象となった Android の利⽤シーン Android Emulator

NICT, “継続する 5555/TCP ポート宛攻撃通信と ADB が有効化された脆弱なAndroid エミュレータについて”https://blog.nicter.jp/2018/10/android-5555/

セットトップボックスSophos, “Botnet targets set-top boxes using Android OS”https://nakedsecurity.sophos.com/2019/08/30/botnet-targets-set-top-boxes-using-android-os/

22

https://blog.nicter.jp/2018/10/android-5555/

https://nakedsecurity.sophos.com/2019/08/30/botnet-targets-set-top-boxes-using-android-os/


5555/TCP を利⽤したMirai系マルウエアの活動は継続中ADBの本来の⽤途とは異なる利⽤⽅法 Android Emulator: 便利なAPIとしてセットトップボックス: 製品にアプリをインストールする⼿段として

ベンダは、販社がアプリインストール後にADBを無効化して運⽤することを想定製品（特にIoT機器）はしばしば開発者の想定とは異なる⽅法・環境下で利⽤される LAN 内で使われるだろうという思い込み理解している⼈が注意をもって使うだろうという思い込み

23


想定外の状況の発⽣にどのように対処していくか︖製品において、脆弱性、攻撃者による悪⽤、改ざんなど、利⽤シーンとして想定されていないセキュリティ上の問題が発⽣した場合に、どのように対応することが望ましいか︖

特に、共通コンポーネント、ライブラリ、OSなど、共通するフレームワークに脆弱性があった場合、複数の製品など広い範囲に影響が出る可能性がある

そのときに・・・誰がコストを負担するのか関係者に誰が説明するのか運⽤中のシステムに適⽤できるのか

サプライチェーン全体で考えていく必要性

24



サプライチェーンと 3rd Party Library の問題

25


Stagefright 問題を思い返してみるStagefright 2.0 脆弱性 (2015年)CVE-2015-1538, CVE-2015-1539CVE-2015-3824, CVE-2015-3826CVE-2015-3827, CVE-2015-3828CVE-2015-3829, CVE-2015-3864 Android で指摘された、細⼯したコンテンツを開くことでコード実⾏が

可能な脆弱性多くの端末において、アップデートが滞った

サプライヤチェーンにおける責任分担が問題となったアップデートに対する端末製造者にかかる責任/負担端末製造者と OS 供給者、キャリア間の問題

責任分担と負担軽減

26


サプライヤ間での問題サプライヤ側も開発は⽌まっていない OSSから取り込んだソースコードが⽣んだ脆弱性

Apache Struts2 の脆弱性 (S2-052 / CVE-2017-9805) 取り込んだソース (Xstream) に起因する問題汎⽤製品で発⽣した場合を考えてみる

OEM (A社)

Tier1 (モジュール供給)

Tier2 (チップ供給) (脆弱なコンポーネント)

OEM (B社)製品 A社

Apache Struts2

Xstream(⼊⼒値未検証 : その後修正)

製品 (B社)

27


Apache Struts2 の脆弱性 (S2-052 / CVE-2017-9805)XStreamHandler⼊⼒値が検証されず渡されていたことに起因

外部コンポーネント由来の問題 XstreamHandler.java … 2008年6⽉ Xstream (本家) 1.3 released … 2008年2⽉ 1.4.7 released … 2014年2⽉“Added methods addPermission, denyPermission, allowTypesXXXand denyTypesXXX to c.t.x.XStream to setup security at unmarshalling time.”

デシリアライズ時点＊何もせず (⾚ライン)＊復元するクラスを制限(緑ライン)

取り込めていなかった

28


ソフトウエアライブラリのアップデート問題Yasumatsu, T. et al. “Understanding the Responsiveness of Mobile App Developers to Software Library Updates” - ACM Conference on Data and Application Security and Privacy(CODASPY) 2019

アプリ開発者はライブラリアップデートをしないことが多い古いライブラリ利⽤の50%は10ヶ⽉以上放置されている

29

Yasumatsu, T. et al. 2019Figure 3 に加筆


SBoM (Software Bill of Materials) とコンポーネント管理そもそも、⾃社製品に含まれているコンポーネントを把握できていますか︖ソフトウエア・開発上での Supply Chain Component 問題依存性, 世代管理, 形式, ライセンスなどなどリスクは分かっていても、具体的にどう管理したらよいか︖が課題

⼀つの⽅法論として提案されているのがSoftware Bill of Materials (SBoM)

いわゆるコンポーネント・成分表Type, Name, Version(Type:library, Name:tomcat-Catalina, Version:9.0.4)

⽶国NTIAの主導で導⼊に向けた議論が始まっている

30

OWASP, Dependency-Check の出⼒例→Apache Struts2 は複数のコンポーネントから構成される

← CycloneDX Specification (example BoM)


脆弱性に対する製品の管理における課題ファームウエアや、サードパーティのライブラリなどでの脆弱性をどう考えるか︖ 最終的な製品がどの脆弱性の影響を受けるのか、影響範囲がどこまでなのかと

いった脆弱性の管理が必要開発が⼤規模になればなるほど、既知の脆弱性対策の反映が困難

脆弱性情報の収集と取りまとめ外部委託先での管理

IoT機器の場合、影響が広い範囲に及ぶケースも考えられる製品に脆弱性が発⾒された場合、ユーザに不安を与えず、冷静に対処してもらうことも重要

業界全体で対応を検討していくことも必要

ライブラリ供給（脆弱なコンポーネント）

モジュール供給A社

モジュール供給B社

C社製品 D社製品 E社製品

以前は供給

影響を受ける︖



31


業界や関係者で情報共有を⾏うことの重要性対策を進める上では情報共有 (PSIRT間、同業他社、コミュニティ) がカギ情報セキュリティの分野では、ISAC (Information Sharing and Analysis Center) に

よる脅威情報の共有が進められている PSIRT Services Framework: SA1「Stakeholder Ecosystem Management」

を参考に具体的な連携のカタチを検討特に、脅威や脆弱性、影響などに関して共通の話題がある場合には情報共有は進みやす

い

国内のソフトウェアベンダーにおける取組の例 Software ISAC

(CSAJ, http://www.csaj.jp/committee/security/softwareisac.html)

32

環境を改善していく上でコミュニティ活動が⼤きな役割を担うのではないかと考えられる


業界や関係者で情報共有を⾏うことの重要性⼀⽅で情報共有には様々な問題も存在

組織内の問題① 組織の問題② 共有ルールが不明確メリットがない

なんで出すの︖


幹部や法務部等他部⾨

どこまで出ちゃうの︖


報告しよう

まずは相談だ

他社がどうしているか知りたい

他社にも知らせよう

33

社内社内


IoT・製品を取り巻くエコシステムにおける課題解決のための協⼒

1

11

1ISP事業者

被害組織

ベンダ(国内・海外) 設置事業者・販売店

ユーザ・管理者ファームウエアの

アップデート開発課題︓・使⽤可能な機能を制限することは

対処しづらい・OEM製品の場合、⾃社による

対応が困難

アップデートや機器の復旧⽅法のアナウンス

課題︓販売先、設置先管理まで⾯倒は⾒られない

ファームウエアのアップデート実施課題︓・そもそも感染に気付けない・⾃らは被害者ではないので、対策を

とるインセンティブがない

脆弱性などのある機器の特定課題︓ネットワーク上の機器の状態を認知することが困難

インシデント対応⽀援課題︓被害組織や原因が必ず

特定できるわけではない

被害への対応課題︓影響範囲の特定や対策の実施には時間がかかるお互いの⽴場や範囲を理解し、

協⼒していくことが重要︕

34


おわりに

35


まとめIoT 機器をターゲットにする攻撃はますます増加

製品に含まれるライブラリ（コンポーネント）の把握、管理を改めて確認

製品のインシデントに対応するための体制（PSIRT）の構築・運⽤が⼤事

インシデントの影響範囲が広範囲に及ぶケースが増えている

他組織との連携を前提とした体制づくりがカギ

36

セキュリティに関して何かございましたら、JPCERT/CCまでご⼀報ください︕（些細なことでも構いません）


お問合せ、インシデント対応のご依頼は

JPCERTコーディネーションセンター—Email︓[email protected]—https://www.jpcert.or.jp/

インシデント報告—Email︓[email protected]—https://www.jpcert.or.jp/form/

制御システムインシデントの報告—Email︓[email protected]—https://www.jpcert.or.jp/ics/ics-form.html

※資料に記載の社名、製品名は各社の商標または登録商標です。

http://jpcert.or.jp

http://jpcert.or.jp

http://jpcert.or.jp


おわり

iot時代に求められるリスク対応と jpcert/ccの取り組み ·...

Documents