こんにちは、ひろかずです。
CODEBLUE2019に行ってきましたので、一筆書きます。

例によって、リアルタイム執筆ですので、誤字脱字記載漏れ表記ゆれはご容赦ください。

基調講演：核兵器とハッキング

アンドリュー・ファター

Hacking The Bombという著書について語っていきたい
11の点を伝えていく

講演資料はこちらのようです

Cyber核チャレンジ

• ハッカーが侵入して、核兵器を使えるのか
• 権限者が騙されて、危機的な意思決定をしてしまうのか
• WarGames
  -- 1983年に描かれたハッカー像が、いま現実になりつつある

Cyberという言葉の定義

• 関わる人によって違う
• 多様な定義
• トランプ
  -- Cyberセキュリティは難しい。1番になることは難しい
• どのような文脈で何ができるか
• フレームワークから入るより、事象から入っていくほうがいいと思う

2. Cyberと核は別物である

• どれだけCyberと核が与える被害の額であるか
• Cyber攻撃は一時的なもの
• Cyber攻撃は、最大の妨害である
• Cyber攻撃は、致死的ではないもの
• 核は、被害の範囲と数量がわかっているが、Cyber攻撃は未知数である
• 2つは比べることができない

3. Cyber攻撃の行為者

• Cyber攻撃は一連の流れである
• Cyberで戦争という言葉を使うのは間違っているかもしれない
  -- 誤解が生じる
  -- 抑止力を使うときに誤った使い方をしてしまう
• 意図と能力が重要なキーワードである
• 国家アクターは、何かを起動しようとする、武器・防衛システムを止めようとする
  -- 直接武器を攻撃するだろう。資源と時間があるから
• 非国家アクターは、情報を操作する方向に行くだろう

4. ネットワークを分離することは防衛？

• ネットワーク隔離は必ずしも防御になるのは誤解
• Stuxnetではエアギャップはあった
• ネットワークが分離されていても、コードはどこかで誰かが書いている
  -- パッチ適用の際に、ネットワークがつながることがある
  -- 少量でも通信が発生するタイミングを狙われる
• 軍ネットワークは、他の艦にも影響が出る
• 継続的な対応が必要
• 民生品の利用が増えてきている
  -- 経済的な理由でもある
  -- 核兵器でも民生品を使っている国は、少なくとも2カ国ある

5. Cyberチャレンジは誤って使われる

• Cyber化された領域は、いつでも誤って利用される可能性がある
• 間違って発射されてしまう可能性がある
• いつでも利用できるようにすることのジレンマ
• ハッカーに因らなくても起きる可能性がある
• 早期警告システムが、誤った判断を引き起こす可能性がある
  -- Command and Control(書籍)より

6. Cyberチャレンジは人間がキー

• 人間のミスに起因する
• 人間は与えられた情報に基づいて判断する
• 人間は明らかなターゲット。人間を突破口にするほうが効率的
• FBで核兵器に関心がある人達のやり取りでは、たくさんの情報が共有されている
• どのような形でインテリジェンスを入れていくか
• 自動化は進んでいるが、これ自体もリスクになってきている
• スパイ活動は、Cyberの時代で変わってきている
  -- オペレーションの秘密は守らないといけない
  -- 情報な情報が、USBなどを通じて持ち出されてしまう

7. エスピオナージとIP攻撃は大きなリスクである

• 核の秘密が、サボタージュなどで漏れる可能性がある
• オペレーション上の情報や、Designに関する情報が漏れる

8. Deterrenceは役割を可能にするが。。。

• Cyberハイジーンや法の執行でなどで、ある程度対応可能
• Cyber Deterrenceは、ある一定の状況では効果がある
• Cyber攻撃の手法よりも影響をみるべき
• 攻撃の前段階をできるだけキャッチする

9. サイバ攻撃は、最も危険なクライシス

• 国家アクターであれば、相手の能力を無効化して、攻撃を準備する
  -- 早く攻撃しないと負けてしまうので、先制攻撃のプレッシャーがかかる
• 非国家アクターであれば、緊張状態に乗じて情報を撹乱し、誤った判断を導き出すこともできる
• 事前にハッキングしておき、危機の際に実行する
  -- 状況によっては、大きな問題にエスカレートする

10. Cyber戦場と全く切り離すことは現実的ではない

• 他の軍の武力とともにCyberを使う
  -- 道具の一つに過ぎない
  -- 武力を組み合わせて使うということを考えないと行けない
  -- 新しい高度な戦略非核兵器と捉える必要がある
  --- 確実に戦闘の中での役割がある
  -- 戦略的な核のレベルに近づいてきている
• 陸海空宇宙にAIまで使われるようになった
• 一つの部門である

11. ハッキング・ザ・ボムが警告すること

• Stuxnetは、同盟国の仕掛けたものだと言われている
• これまで1時間かかる攻撃（ミサイル発射から被害まで）が、300msで行えることができる
• サイバー攻撃で先制攻撃をかける
• 悪い前例になるかもしれない。目に見えない戦力
• Cyber攻撃を先制的に使うことで、相互不確証攻撃になるかもしれない

推奨事項

• 今は複雑なネットワークシステムの中にいる
• 脅威の特質性を理解する共通理解が必要
• Cyberハイジーンや良好なベストプラクティスは効果がある
  -- 攻撃を諦めさせる可能性がある
• 人間が関わっているということを留意する必要がある
• 規範やモラトリアムから、みんな合意できる内容で合意する
• 世界的な新しい枠組みが必要になるだろう(法規約)
• 更に複雑なシステムが生まれる中で、できるだけ核システムをシンプルなものにして、隔離する

QA

純粋なCyber戦争は起こり得るのではないか？

• 未来のことはわからない
• アメリカで進められているインターネットEnableシステムは良くない

フェイクニュースによって意思決定を侵害することはあると思う
Cyber戦争としての考え方は？

• 脅威は段階がある
• 外交、諜報、欺瞞工作の役割があって、狙った効果をもたらそうとする
  -- Cyberは、その手段の一つである
  -- 選挙結果に影響をもたらすのは、新しい話ではない
• FBを使って、人々の行動を変容させることができる
• Cyberは、多目的なツールである

基調講演：ソフトウェアサプライチェーンの透明性：SBOMの実現

アラン・フリードマン

SBOMとは、Sofware Bomのこと
ソフトウェアは、様々なコンポーネントでできている

• オープンソースで作られたものも含まれる

VXWorks

• リアルタイムOS
• 衛生や医療機器で使われている
• 脆弱性がある

所有するシステムに脆弱性があることに対して、影響をあるか否かは簡単に答えられない

• これってクレイジーなこと
• 食べ物の成分表はわかる。アレルギーを持っているなら知りたいだろう

BOM

• Build of Materialは、製造業のもの
• CVEは、脆弱性に名前をつけたもの。それだけでは、脆弱性は治らないけど、対処を取ることはできる

サプライチェーン

• どのようなソフトウェアが組み込まれているという透明性が必要
• ソフトウェアを作成、購入、運用するのに各役割が必要
• セキュリティに限ったことではなく、収益性に関わる。公衆衛生にも関わる
• 材料表を持っていることは、健全なことであるが、行われていないのはなぜ？

GPL

• どのようなライセンス体系か理解しているか？
• ライセンスを確認するツールがある
• 要求されないので提供されない
• 市場が提供しなければならない
• もしくは規制によって強制される必要がある

Multiステークホルダー

• すべてのセクターで網羅していく必要がある
• 業界がこの問題を自身の問題として対応していく

問題の解決

• ルーティンワークにし、自動的にできるようにする
• 手作業は誤ってしまう
• これはイノベーションの鍵
• 需要はあるので、起業のチャンスである

SBOMとは？

• ２つのフォーマットがある
• SPDX
• SWID
  -- 自動的にトラッキングしてくれる

フォーマット間の翻訳

• パイロットは積極的に行われている
• この２つのフォーマットを使うとパーフェクトに回せる

米国の銀行では、SBOMを既に要求にしている

• SBOMを作れないのであれば、10-20%のディスカウントを要求してくる
• SBOMは、セキュリティというより効率に根付いている

ソフトウェアを購入する人は、その材料についても関心を持っている

• OSは最新であるか？
• EOLは近くないか？
• ソフトウェアのメンテナンスが継続可能であるか？
• リスク解析が容易か？
• どのような脆弱性があるのか？
• SBOMがあれば、先手を打って脆弱性の対応が可能になる(顕在化の前に)
• CVEがいくつか出ているものと、全く出ていないものはどっちを選ぶ？
  -- CVEがいくつか出ているものが信用できる
  -- ユーザーベースで活発であるということ

ソフトウェアサプライチェーンの信頼は来ている

• PoCは既に行われている
  -- いくつかの病院や医療メーカーは、やりたいと言っている
  -- 資産管理、脆弱性管理、意思決定の助けとするため
  -- 完全に自動化するところまでは行っていないので、参加企業を増やして進めようとしている

次のステップ

• 何をどのようにというドキュメントは進んでいる
• SBOMを共有する仕組みはどうするか？
• 攻撃について心配がないことの証明
  -- 古いライブラリでも、攻撃にはかからないということを証明してほしい
• ツール。今あるものと、これから必要になるものを共有する
• 自動車や金融セクターでも進めていきたい

QA

２つのフォーマットを統一するなどのアクティビティはあるのか？

• できたらいいんだけど
• それぞれは水と油のようなもの
• 将来的には、それぞれを変換して、別のデータにするというものが出るかもしれない

コピペされたコードは、どう考える？

• そのようなコードは、コピペした人が責任を持つ
• SBOMは正直な人は、正直であり続ける事ができる
• Synopsisは、SBOMの検証を行うサービスがある

抵抗は無駄-防御できないサプライチェーン攻撃

スンティン・サイ
リンダ・クオ

Cyberエスピオナージや国家から行われる攻撃について、サプライチェーン攻撃が増えてきている

台湾や韓国での実例

• 2016年にはATMに対して攻撃が仕掛けられて、現金が引き出された
• 2019年にはラップトップのライブアップデートにマルウェアが混入された

ASUSのラップトップでの重要アップデート通知が来たらどうする？

• アイテムやバージョンがないのは怪しい
• 証明書で署名はされている
• ダウブルチェックしても問題がないので、インストールしたらマルウェアだった
  -- ShadowPad
• ASUSの正規のダウンロードサイトに公開されていた
• これをどうやって探す？

サプライチェーン攻撃

• デバイス、Application、システムのそれぞれのサプライヤがいる
• 自分の組織の防衛には関心があるが、

eClientの事例

• 公共のドキュメント交換システム
• Firefryという中国のマルウェアが使われた

KMPlayerの事例

• アップデート通知に応じて実行すると、ニセのアップデータが落ちてくる
• 正当な証明書で署名されている

EmEditor（日本の事例）

• プロフェッショナル版ともう一つのバージョンが侵害された
• 特定のIPを狙って攻撃された
  -- MOJ,JAXA,MOIT,名古屋大学
• 正当な証明書で署名されている

Nestarang

• Xmanager,Xshell
• 金融機関を始め、幅広く利用されている
• バックドアが仕掛けられた
  -- ShadowPadと同時期に流行ったバックドア

平昌オリンピック

• 閉会式の日に数時間サイトが落ちた
• オリンピックデストロイヤー
  -- ATOSが侵害された

2020のオリンピックのための学び

• エアギャップは100%ではない
• エアギャップの内側にも目を向ける
• インシデント発生時は、迅速な回復プランが鍵を握る

サプライチェーン攻撃に気づくまでの機関

• CCleanerは一ヶ月かかった
• すべてのセキュリティプロテクトをバイパスした
• セキュリティ企業のデジタル署名が使われていた
• エンドポイントプロテクションツールは、1ヶ月後でも11製品だけが対応するに留まった

Cyber Kill Chain

• 侵害前：Firewall,IPS,WAF
• 侵害：アンチウィルス,EDR
• 侵害後：＜サプライチェーン攻撃はここを突いてくる＞

侵害後のDefenceはどう講じたら良いのか？

• 侵害に気づくのは平均100日後くらい
• 環境をブロックしたり、感染端末をクリーンナップするのでは対応できない
• いかに期間を短縮するか
• どれだけサプライヤを信用するか？

信用しない。明日にでも攻撃されると考える

• 発見できるようなアプローチが必要
• プロアクティブな脅威の発見
• リカバリプラン：サービス、データ、システム、ハードウェア
• 法律の問題：GDPRなど、影響の受ける規制の指示に従う必要がある
• 公共の関係：情報公開プロセス
• サーバー保険

プロアクティブな発見

• システムも必要だけど、チームも必要
• 敵も人間
  -- 敵を理解して、どのような攻撃をしてくるのか、どういう脆弱性を標的としているのかを切り口に対応する
• 戦略を立てて、行動するチームに投資をする
• インテリジェンスを管理して、敵を知って、対応をする
• 事象が発生する前に対応する

QA

サプライヤーへの攻撃は、通常のAPT攻撃の手法が用いられるか？

• サプライヤによっては、簡単に侵害される場合もある
• ある攻撃グループの手法
  -- 一つのサプライヤを踏み台に、他のサプライヤを侵害していく
  -- それに対する手段は、企業におけるサイバーセキュリティである

アジア地域における最新のサプライチェーン攻撃概要

ボリス・ラリン
アレクサンダー・リスキン

サプライチェーン攻撃とはなにか？

• 顧客の手に渡る前に侵害される
• 製造元、配送中の可能性もある

メカニズム

• 永続的なマルウェア
• ファームウェアの改ざん(UEFI rootキット)
• ハードウェア高度な改ざん(Bad USB:キーロギング)

ハードウェアのサプライチェーン攻撃

• イベント配布物で配られた

ソフトウェアサプライチェーン攻撃のメカニズム

• アップデートプロセスの侵害
  -- 中間者攻撃で、途中で悪性コードを埋め込んだものを渡す
• ビルドプロセスを侵害して、ビルドすると悪性コードが埋め込まれる

サプライチェーンから渡されたソフトウェアが信頼できるのは誤り

• アップデートすれば侵害されるかもしれない
• アップデートしなければ、侵害されるかもしれない
• 大問題である
• IOSシステムはマルウェアの影響を受けないと言われていたが、ビルドプロセスで悪意のあるコードが埋め込まれて、AppStoreにに公開された
• 韓国のアーカイブソフトの例では、行政のシステムの個人情報流出まで発展している
• macOSを対象とした攻撃は、トランスミッション(BitTorrentアプリ)に対して複数の侵害が行われた
  -- 通常なるべく隠れてスパイ活動するので、これは珍しい例

Wintiグループの例

• ゲーム会社の事例
• 別のゲーム会社の証明書を持っていた
• それを使ってなりすまして、幾つかのゲームを侵害した
• ゲームのソースコードを盗み出すことに関心を持っていた
• トロイの木馬でサーバーのメモリを破壊する
• ゲーム内の通貨を盗み出す
• ゲーム産業だけではなく、幅広い業界で攻撃を進めている

ShadowPad

• 2017年発見
• NetSarang(sftpやxmlなどのツール)に埋め込まれていた
• 基本的なシステム情報を送るだけだったけど、ファイルを持ち出すこともできるようになった
• ドメイン名を変更する機能も付いている
• 2017/7/7に発動し、すぐに見つけている

CCleaner

• 実行ファイル内に悪性のコードを含んでいた
• 感染は第２ステージがあって、感染した４０台のPCはすべてアジアのPCであった

Shadow Hummer

• ASUSとは違うアプローチが取られているケースがあった
• それらは、全てゲーム会社を標的としていた
• ロシア語のデータが含まれていたら、何もしない。そうでなければ、ファイル内のデータをすべて抽出する

ShadowPad BackDoor 2018

• プラグインベースのBackDoor
• 難読化されている
• 攻撃した上で、痕跡を消そうとした
• WindowsのHTTPサーバAPIを起動する
• IIS10.0ベースでポート80で通信する

このリスクを軽減するには？

• さまざな形で攻撃されている
• Applicationに悪性コードを埋め込むのは、攻撃者にとっても難しい
• 開発者によって発見されてしまう
• ソースコードにふれるのではなく、コンパイラやlinkerに対して攻撃してくるアプローチもある
• サプライチェーン攻撃の中でMITMを使って攻撃するアプローチもある
• デジタル署名がされているので信じてしまう
• 正規品であっても、動きが怪しいものは分析が難しい

サプライチェーン攻撃の武器として使われないようにするには？

• 変更に関わる透明性を確保する
• 誰が、コードを変更できるのか、コンパイルできるのか
• Application Engineerがやるべきことは多い

QA

ユーザーのソフトウェア利用状況に耳を傾ける必要があるというが、自分で実際に使うことはできるのではないか？
自分の環境とエンドユーザーの環境で挙動が違う事例があるのか？

• マルウェアは、環境によって振る舞いを変える
• マルウェアは、自分が入りたい環境でなければ、なにもしないで自分自身を消去する
• ソフトウェアEngineerの目標は、開発インフラのリスクを特定して、対応する取り組み、可視化して取り組むこと

tknk_scanner v2:community-based integrated malware identification system

中島 将太
野村 敬太

サンドボックス環境でよくわからない物は、アンチマルウェア使ったりVirusTotal使ったりする
一度解析したマルウェアは、もう一度解析したくない
自動的にマルウェアを認識する

• yaraルールを使う
• ネットワークスキャン機能も対応した

実行するとコードはメモリに展開されることがわかったので、それをチェックすれば良いのではないか

• RestAPIでmongoDBにデータを格納する
• WebUIで内容を格納する
• hallows_hanter
  -- 全プロセスをなめて、メモリの領域毎にダンプしてスキャンする

Quereに貯めることができるので、CLIで登録しておいて、朝起きたら終わっているということもできる

ダンプしたデータを静的解析に回せるので、解析者としても楽

制限

• オープンソースのルールを使ってほしい
• マッチするルールが無くても、静的解析でなにか出るかもしれない
• ダンプデータが出てこない時は、理由がわかれば追加実装できるかもしれない

IoTの脅威、そしてIoTに対する脅威に対抗する家電メーカーアプローチ

林 彦博
大澤 祐樹

背景

• NICTの研究で、IoT機器が攻撃の半数を占め、更に増加する事が予想される
• カスペルスキーの研究でもIoTを狙ったマルウェアが３倍に増加している
• 収束の気配は無い
• IoT機器が乗っ取られていくと、Control配下となった機器が悪意を持った人によって、攻撃に利用されてしまう
• NOTICEという取り組みを通じて、国による注意喚起が行われている

パナソニックが従来から行っている取り組み

• コーポレートリスクとして、サイバー攻撃が重要と位置づけている
• ３つのサイバーセキュリティ
  -- 情報システムを対象としたCSIRT
  -- 製品セキュリティを対象としたPSIRT
  -- 工場・生産技術関連を対象としたFSIRT
  -- これらが連携してサイバーセキュリティに対応している
• ２つの柱
  -- リスクの最小化
  -- インシデント対応
  -- ベースラインとしての意識向上や啓発がある
• セキュリティ活動
  -- 脅威分析
  -- セキュリティDesign
  -- セキュアコーディングと静的解析
  -- 脆弱性テスト（セキュリティテスト）
  --- 自分たちの機器をハックして脆弱性を見極めてから出荷している（10年以上続けている）
  --- サービスサーバーやハードウェア、ソフトウェアそれぞれに対して行っている
  --- ここまでやっても７割８割
  -- 出荷後はインシデント・レスポンスとして、対応していく
• PSIRTは、窓口として外部と各部門とのやりとりを仲介している
  -- 各国に専門家を配置して、有事の際は各員が責任を持ってハンドリングしている

パナソニックのプロダクトセキュリティ

パナソニックセキュリティのチャレンジ

• 社外から情報をもらうだけではなく、自分たちでも情報を収集している
• マルウェアに乗っ取られない製品づくりとは
• プロダクトセキュリティのコストバランス
• IoTマルウェアの爆発的増加
• これらからIoT攻撃インテリジェンスプラットフォームコンセプト
  -- やられ環境を公開しての情報収集
  -- 挙動分析と情報収集を自動化
  -- リアルタイムで開発チームへのフィードバック
  -- 他メーカーへの情報提供

３つのフェーズ

IoTの脅威を収集する

• 物理的に自分たちの実製品をハニーポットとして用いている
  -- リアルタイムに情報を収集、分析、可視化している
• ハニーポット観測拠点を２箇所から増やす
  -- シンガポール
  -- 中国、インド

IoTの脅威分析

• 収集したマルウェアを分析している
• IoTマルウェアの挙動をリアルタイムで分析している
• ２年弱続けている
• ２億件くらいの攻撃件数
• マルウェアは22000件
• IoTマルウェアは4700件
• 悪性サイトへのアクセスに8.8.8.8を用いている
• 接続先のトップ３
  -- アメリカ、中国、日本
  -- 日本はレンタルサーバーが使われているのではないか
• 攻撃元の国トップ３
  -- 中国、アメリカ、ロシア
  -- この３つで総量の半分を占める
• 狙われるIoTアプリケーション
  -- セキュリティカメラ、ドアホン
  --- 狙われやすいポートを開けている機器が攻撃されている
• 2019年の攻撃トレンド
  -- 総件数は、２つのピーク
  -- 4月と７月
  -- どちらもupnpd
  -- 脆弱性の公開を受けて、増加している
  -- 3つ目のピーク
  --- SQLServer
  -- 攻撃元は中国、アメリカが多かった
• 既知のマルウェア
  -- 75%
• 未知のマルウェア（VirusTotalに掲載されていない）
  -- 25%
  -- それ以外のトレンドは見られなかった
• アーキテクチャの分類
  -- Linux
  -- ARM/MIPSを狙ったものが多かった
• 攻撃された実例
  -- IoT家電に不審ファイルが設置された
  -- Windowsマルウェアを設定されたケースも有る
  -- ネットワークを探索して、ファイル共有を見つける
  -- 認証無しでファイルを置けるところにマルウェアを配置する
  -- sambaサーバーからファイルを実行するペイロードを流す
  --- 成功したら、リモートシェルを実行するようなものだった
  -- そのあと、痕跡を削除する10個中5つのファイルが削除されていた
• IoTマルウェア分析
  -- Hakai_pb
  --- Miraiの亜種で、パスワードをブルートフォースする

次のステップ

• 最新の攻撃をリアルタイムで観測することで、対抗していきたい
• B2Cセキュリティの強靭化
  -- アップデートの迅速化の仕組みづくり

動画Demo

技術者以外の人達にインパクトを伝える可視化動画

• NIRVANAに似ているUI
• しきい値を超えた攻撃に対して警告マークが付く
• 攻撃を受けた機器は、ショールームでも赤くランプが付く

スパイウェア、ランサムウェア、ワーム。 次のSAP悲劇を防ぐ方法

ジョーダン・サンタルシエリ

SAP NETWEAVER

• 重要なアーキテクチャ
• SAPビジネスロジック
• SAPアプリケーションレイヤー
• バックエンドでJavaが動いている

どこから接続されるのかが重要

• SAP GUIはFATクライアントを使う
  -- 1.4Gb
• SAP Webアプリケーション

チャプター２

ARSAPプロジェクト

• バージョン情報を取得することで、どんな攻撃に脆弱であるかと言うのを調べる
• 14000ものSAPがインターネットに公開されている
• SSL証明書が設定されていないものもある。自己署名証明書のものもある
• 37%のSAPシステムのオーナーが誰で、どこにホスティングされているかが分かる形で公開されている

CODEBLUE専用の調査結果

• URL公開するよ！

27%の環境が、任意にデータをダウンロードできる状態であった

• マルウェアが仕掛けられた環境もあった

チャプター３

伝統的なマルウェアの提供

• 攻撃者の立場に立って考えよう
• インターネットに公開しているSAPを探して、バージョンを取得する
• 会社もわかった
  -- おそらく全面的に使っている
  -- おそらくたくさんの従業員がいる
  -- SSOを使ってるだろう
  -- 一つのパスワードで複数のシステムにログインしていることが推測できる
  -- そこでEmailを送る
  --- ダブルクリックするとSAPのクライアントが起動する
  --- ユーザーの権限を確認する
  --- ユーザーのVLAN上で事は行われる
  --- SAPポートはおそらく空いているだろう

チャプター４

SAP GUI スクリプトを軽減するには

• GUIを止めてしまうという手がある

ランサムウェアアプローチ

• マルウェアには共通項がある
  -- 横断的侵害
  -- フロントエンドSAP Javaシステム〜バックエンドSAP ABAPを通じて、内部ネットワークに侵入する
  -- フロントエンドSAP Javaシステムでクレデンシャルを窃取する
  --- いくつかのやり方がある
  --- javaの脆弱性が残っている環境が20~30%ある
  --- ユーザーデータベースを持っているので、ユーザー情報を取得することもできる
  --- Invoker Servletは全体では無効化されている
  ---- これを有効化してしまう
  -- DMZ内を横断的侵害する
  -- ハードコードされたキーがあれば、javaを復号化することは簡単である
  --- SAPシステムの管理者パスワードは、この方法で取得できる
  -- マスタパスワードは、SAPの関連パスワードで使うのはデフォルト設定である
  --- 95%の環境でマスターパスワードを使っている

ランサムウェアアプローチ - ボーナストラック

• SAPはDMZに配置されている
• SOAPメッセージを使って、SAPシステム利用ユーザーにメッセージを送る
• fishing URLを含んでおけば、攻撃できる

まとめ

• 覚えておいてほしいこと
  -- 本当にSAPシステムをインターネット公開する必要があるかを考えてほしい
  -- SAPのバッチを当てること
  --- 停止を伴うが必要なことである
  -- 防御防御防御
  --- 必要な情報を引き渡さないようにする

Chromebookのカーネル特権を得るためのDRMサブシステム攻撃

ディ シェン

Chromebookは、各メーカーから出ている

• HP, IBM, ASUS...
• 文書編集やウェブブラウジングに使える
• とても安くて売れている
• セキュリティが高い
  -- おそらくラップトップの中でもトップレベルでセキュリティが高い
• Chromeブラウザ
• サンドボックス
• 安全なファイルシステム
  -- ルートパーティションは閲覧
• bootとdm検証がなされている
• SELinux
• セキュリティアップデートが定期的に行われる

サンドボックス

• minijail0を使っている
• SELinux Policyにも制限が懸かっている

bootの検証

• ファームウェアは、システムパーティションの検証があできる
• カーネルは、dm-verityが検証している
  -- Androidでも使われている
  -- システムパーティションを保護している
  -- システムパーティションの改ざんをチェックサムで検証していて、違うとクラッシュする（起動しない）

Chrome OSの永続性への対応

• リナックスセキュリティモジュール
• 書込み可能なデータパーティションの実行禁止
• dm-verity

リナックスセキュリティモジュール

• symlinkを拒否する
  -- 永続化を狙った攻撃を拒否する
• 信頼されているモジュール以外をロードできない

Chrome PWNium

• バグハンティングプログラム
• 15万USD
• 要件
  -- ChromeブラウザレンダラのRCE
  -- 永続化

5つの脆弱性があった

• サンドボックス回避のためのdbの利用
• 特権昇格（カーネルモード、ユーザーモード）
• ChromeOSの永続化バグ
• これらをすべて使って、要件を満たすことができた
• 今の段階では、CVE-2019-16508まで公開している
• 次はソウルでもう一つの脆弱性を公開予定である

攻撃面の選択

• カーネル脆弱性を見つける必要はなかった
• ベンダーバグを参照に標的になりそうなものを見つけ出した
• lenovo s330
  -- mediatekであれば、バグハントは容易であるのでこれを目につけた
  -- ボード名はhana(花)らしい

エクスプロイトは簡単であるか？

• ARMのCPUを使っている
• ハードウェアにミティゲーションが一部しか有効になっていない
  -- PXN,PANのみ有効になっている

次にやったことは？

• アマゾンUKでS330を購入した
• 届くまでに脆弱な部分を探してみた
• DRMが攻撃しやすそうだ
  -- drivers/gpu/drmで情報を出力する応答機能がある
  -- MT8173はPowerVRを使っている
  --- 普通は使われないものなので、脆弱性があると思った
• io デバイスControlが、ユーザーに開示されていた

DRMはベンターによるプライベートコマンドがサポートされていた

• プライベートハンドラを確認することにした
• pvr_drm_ioctl()
  -- ブリッジIDは25個設定されている
  -- その他に300のブリッジファンクションIDが見つかった

ファザーを作る

• ファジングルールを定義する
• PowerVRをターゲットにする
• 一晩実行してテストさせる
  -- たくさんのクラッシュ
  --- スタックトレースが出力されたので解析された
  --- ブリッジID2にブリッジファンクションID8を設定するとアクセスできる
  --- ユーザーデータサイズの検証ができずに、ヒープバッファオーバーライトが発生した
  --- オーバーフローすると小さな領域が割り当てられる

ヒープOOBエクスプロイト

• 50%の確立でカーネルがクラッシュしていた
• 2000バイトのデータを128バイトに書き込むために、カーネルAddress(20バイト)をコピーすることにした

Demo

• ゲストモードでログインしている
• インターネットをブラウズするくらいしかできない
• 開発者モードで実行する
• ヒープスプレーを実行すると数秒でrootが取れた

QA

ほかにどんなクラッシュが見つかったか？

• パニックやノーポインタ等が発生した
• もっとファジングすれば、他の切り口が見つかったかもしれない

UAOが使えたらどうする？

• カーネルAddressの書き込みができないので失敗するだろう

[U25]アンチウイルスをオラクルとしたWindows Defenderに対する新しい攻撃手法

市川 遼

サイドチャネル攻撃

• キャッシュされるタイミング
• 情報をスペクトラムから補足する
• コンテント監査
  -- XSS Audite

アンチウィルスソフト

• ファイルの内容をチェックする
• ファイルが操作するタイミングで何らかの情報を混ぜることができたら、ご動作できるのでは？

Windows Defender

• 動作はブラックボックス(いつ、どんな動作をするかは不明)
• 対応しているマルウェアリストは出ているが全ては出ていない
• 検出すると、ユーザーに通知してくれる
• 何度か試していると、Base64や悪意のあるコンテンツ、Zip圧縮、実行可能なものを検出することがわかった
  -- ブラックボックスで動作を試すのは本当に骨が折れた
  -- どうやって調査するか・・・

demo

• EICARテストVirusを使う
• 悪意はなく、マルウェアを示す署名である
• これを読み出そうとすると、Windows Defenderが検出した

tabosp/loadlibrary

• デバックモードで内部の挙動をトラックすることができる

シグネチャは.vdm
Windows Defenderは、Luaaを使っている

• 最終的にシグネチャ名と定義を見つけることができた
• 特定の文字列が含まれていることを判別できた

エクスプロイトを作ってみる

• シグネチャを書き換えることで検知を免れるように聞こえたけど、難し過ぎました。。。

情報漏えい事件の謝罪対応の裏側

[フューチャー株式会社(ディアイティ株式会社)]
青嶋　信仁

2018年インシデントトップ10

• 管理ミスや、不正な情報持ち出しが1件づつ
• 8件が不正アクセスによるもの
• 情報通信業の件数が多い傾向にある

不正アクセス事件イメージ

• 最近は影響や範囲の特定が難しくなってきている
• クレジット情報や国家機密、痕跡の破壊や、多様な攻撃面への攻撃
• 高度なツールや手法が使われている

公開までかかる時間

• 情報漏えいの認知から調査完了まで平均1.6ヶ月かかっている
• 情報漏えいの認知から公開まで3.6ヶ月かかっている
  -- クレジット情報については、公表まで2ヶ月くらいの時間がかかる傾向がある
  -- 公開にはクレジット関係会社等影響が出る組織との調整に時間が係る

クレジット会社からの連絡がほとんど

• 自分からは気づけ無い（この時点でイニシアチブは自分で持ってない）
• フォレンジックを行う調査会社への依頼
  -- 認定を受けた会社でしか実施できない
• 調査会社からの最終報告
  -- 攻撃が高度かつログの設定不足などで、解明には至らないので、最大被害を想定する
• 捜査機関や監督機関などの第三者への届け出
  -- 最終報告が無いと、着手は難しい
  -- 海外だと腰が引ける場合もある
• 関係各所との公開時期の調整
• 謝罪方法の設定
  -- 本人確認方法の決定など手間がかかる

問い合絵が来る組織は、全て事前準備が必要

• 被害会社
  -- コールセンターの整備、QA
• クレジット会社
  -- コールセンターの整備、QA
  -- 金銭対応、関係機関調整
• サイト運営会社
  -- QA
• 関係団体
  -- QA
• お金が関わると悪質なクレーマー対策も必要である
• コールセンターの開設には時間がかかる

公開文書

• 他事例を研究して真似る
  -- 下手に凝ると炎上する
• メールや郵送では、通知先に届くタイミングでWeb公開する
  -- 月曜に送って、火曜公開とか
• 経過説明は月日まで入れる
• 捜査機関や関係組織に対して公開文書と日程の調整を取る
  -- 調整不足すると揉める
  -- 書き方とか確認と合意をする

謝罪の目的の明確化

• 誰に対して公開して、何を謝罪するのか
  -- 顧客？株主？国民？官庁からの命令？
  -- なんでもかんでも公開するものではない
  -- 対象が限定される場合は、トップページに掲載しないことが増えている
  --- IR情報のお知らせ欄に掲載するとか
  --- 会社概要の中にわざわざお知らせ欄を作ってそこに掲載するとか
  --- 変なところに置いておくと、記者が見落とす場合もある
  --- 必要なところに必要なだけ届け出ることが大事

会見をやる場合、想定されること

• 危機発生時の初動の整理
• 被害者への影響と対応
  -- 被害者があ！って思わないようにする
• 公式見解の作成
• 謝罪文面と会見の整合
• 想定QAも想定した会見内容
• 記者会見通知
  -- 会見実施
• 記者から電話での事後問い合わせ
  -- 記者が記事を正確にかけるようにする
  -- 時間や質問数で切ったりしない
• 明示された問い合わせ先買いの社員などの問い合わせの統制
• 電話（コールセンター対応）

記者会見は練習が必要

• 事実と推測の明確化（ツッコミどころ
• 想定QAは複数用意する
• 想定がいまたは回答の影響が多い場合の逃げ手
  -- 会見支援者の配置、札出し(言うな！)
• 服装、会見場所(印象)
• 時間を限定しない(印象)
• 会見後の質疑応答対応

ソーシャルリスニング

• 公開後の報道を見て、ネガティブな内容で報道されているかなどを調査して、今後の対応方針にリンクさせておく
  -- 記者のマーキングなども必要
  --- 記者のクセなどを考慮して、出す情報もControlする
  --- 正確な記事がかけるようにする

求められるセキュリティ危機管理

• リスク管理から危機管理へ
• リスクとは
  -- 企業など、個々にとっての潜在機器
• 危機とは
  -- 上記リスクが実際に顕在化した状態
  -- 危機管理から見えるセキュリティ対策実施が信頼を向上させる

[Panasonic]PSIRTにおける「〇〇」との付き合い方(パネルディスカッション)

昨年からの振り返り

• ソフトウェアサプライチェーンセキュリティの議論が活発になる
  -- 使っているOSSの脆弱性対応
  -- SBOMの話
• CVE採番問題
  -- VLCメディアプレイヤー問題
• CVSSv3.1が公開された

イントロダクション

• メーカーのPSIRTは色んなものと関わりながら活動している
  -- さまざまな付き合いについて話していきたい

テーマ１: 脆弱性との付き合い方

• 今使っているコンポーネントでの脆弱性が公開されたものに着問
  -- コンポーネントの洗い出しはどうしていく？
• 能動的？受動的？
• 対応のタイミングは？
• 深刻度に依存する？

誰が調べる？

• コンポーネントがどういう構成であるかは、把握している前提で進めている
• ライセンスとして把握していないといけない

特定のフォーマットはある？

• 特に指定はしていない
• ビジネスによってやりやすいものは違う

立ち上げたあとで収集してる？

• 手動で集めているところや、ツールで集めているところでまちまち
• 製品によって強弱はつけている
• 管理は事業部主体でやっている
• 社内標準を用意しているPSIRTもある
  -- 20年前から動いているものはどうする問題はある
  -- 製品によって、優先順位は強弱をつけている

顧客に提供している？

• 顧客が対応を要するものについては、提供しないといけないと思う

SBOMの提供をすることの賛否

• 国内外で議論されている
• 使いやすければ使うかな？

そもそもCVSS使ってる？

• 半々くらい
• 深刻度の指標ではない
  -- そのスコアリングは、リスクのスコアではない
• なんらかの濃淡はつけるのに使う？みんな納得してすすめる？
• それだけではなく、他の情報と合わせて利用している
  -- 使いやすいと思ったときに使う
• 自分の製品に対するものと、コンポーネントに対するものでまた違ってくる
  -- 属性をみて対応を決めている
• メディアに出るとか、利用されているとか、上層部が騒いでいるとかをトリガーでその速度で評価する場合がある

使っているコンポーネントの脆弱性を能動的に探しに行くのか？フィードから受動的に受信するか？

• ニュースは見ている
• みんな担当決めてやってる？みんながそれぞれやってる感じ？
  -- すごく見てくれている人たちトリガーでやってる場合もある
• はじめは、気づいた人が上げる方式だったけど、今は組織的にやっている
  -- 物によってコミュニティに入って情報を収集するケースはあった
• 事業によっては、能動的にやっている
  -- 全体としては、共通的なものをベースラインとして展開している

CVEが振られない脆弱性の考え方はどう考える？

• CVEはCNAという組織がナンバリングする機関で、その尺度を以て採番される
• その尺度に当てはまらないものは、採番されない
• すべての脆弱性をナンバリングするものではない

仕様の限界や、曖昧なものについてはどうやって決めるのか？

• 製品を意図しないところで使われたものを脆弱性とされる場合は、設置条件をはっきりしないといけないと思う
• 外から報告された場合は、ある程度は尊重する
  -- 厄介なのは、自分たちでみつけたもの
  -- そんな時は、微妙な判断があったりするかもしれない
• 届け出者フレンドリで対処するべきだと思う
  -- まずは脆弱性であるものとして考え始める
• 事象だけではなく、複合的なものもあるので、ある程度は判断する
  -- ただ脆弱性と言われたから直すのはPSIRTとしては、存在する意義がないのではないか

テーマ２：カンファレンス・コミュニティとの付き合い方

CODEBLUE

• オープンな場で気楽に話せるのは有益？
• 他にもこういう場があったほうが良い？
• こういう場だからこそ聞きたい話はある？

FIRST

• 加盟しているPSIRTが増えている
• PSIRT Service Frameworkが公開されている

会場でなにか聞きたいことがある？

• なにもないところからベースラインを作るのは大変。そういったものを共有できるといい
• はじめは事故ドリブンで始まることがある
• 何もない状態で、情報を公開して、受け手に何かしら対応してもらうのは大変だった

事業部は、これ脆弱性ですと言われたら、素直に聞いてくれるか？

• オマケ的な共通モジュールに脆弱性がある場合は、コストをかけることについて議論が発生する
• 脆弱性の対応の仕方やとりかかりについて、リードする必要がある時代があった
• 脆弱性はあるけど、利用できるかどうかで判断が分かれる事はある

事業部と仲良くなる方法は？

• 飲みニケーション
• マネージャーが変わったときに会を模様すことはある
• PoCミーティングと呼ばれる窓口の連絡会が四半期に一回あるので、日頃からやり取りしている

最後に

• 相談貰えれば答えるので、今後ともよろしくおねがいします
• 立ち上げ間もないですが、丁寧にやっていきたいと思います
• 顧客やサプライチェーンが参加者にいるので、まだ見ぬPSIRTと繋がりたいです
• 四人で喋るのはいつでもできるけど、こうやってパネルすことで、どういった人間が中でやっているかが分かるようになる
  -- これによって繋がって、協力してやっていきたい
• 今後もこういう場はやろうとは思っているので、PSIRTやっている人は一緒にやりましょう！

NSAのように企業イントラネットへ侵入：主要SSL VPNでの事前認証RCE

オレンジ・ツァイ
メ・チャン

今日は、皆さんのSSL VPNがどのようにダメになるかを紹介します
今日のハイライト

• FortinetのSSL VPNのRCEエクスプロイト
• 認証前のrootRCEエクスプロイト
• どのように２FAをバイパスするか

イントロダクション

SSL VPN

• より幅広くつかわれている
• もっとも利用されている企業へのアクセス経路
• セキュアでネットワークに接続する唯一の方法と思われている

なぜ、SSL VPNにフォーカスするのか？

• トップ３のベンダーが市場の75％を占めている
• SSL VPNはインターネットに暴露されている
• これをハックすれば、世界中をハックできる

サイレントに修正されたケース

• パロアルトの認証前RCEが１dayエクスプロイトだった
• 他の製品にも脆弱性があると思われた
• 通知したら、CVEがアサインされていないので、問題ないと言われた
• 高い重要度のCVEを見渡すと、pulse ScureやFortinetやパロアルトが最も安全なもののように思われた

攻撃指向性

• WebVPN
  -- クライアントレスであらゆる通信のプロキシーになる
  -- ブラウザをクリックするとすべてのリソースにアクセスできる
  -- これらには高いセキュリティ要求がある
  -- 自社開発では重いので、OSSをコピーして用いる
  --- バグもコピーされる
  -- 最も深刻な脆弱性
  -- C/C++で文字列のエンコード、デコードのバグを見つけるのはは非常に難しい

どうやって成功させるのか

• 皆さんのSSL VPNを可能な限り早くアップデートしてください

Fortigate SSL VPN

• すべての機能を一つのバイナリに格納している
• Apacheが含まれているが、これは2002年のものである
• 認証画面を、認証前にRCEする
  -- ユーザーパスワードをマジックキーで修正できるバグを利用する
• sprintfの機能を使って、どんなファイルでも読めるようになる
• セッションファイルには、ユーザー名やパスワード(平文)が含まれている
• ヒープが不安定であるのでControlできない

JeMallocアロケータの制限

• サーバーをFazzするとクラッシュさせることができた

SSLストラクチャ(OpenSSL)

• オーバーフローリクエストで簡単にクラッシュさせることができる
• クラッシュさせた場所に偽のSSLストラクチャを登録する

別のドアを見つけてみる

• マジックBackDoorを見つけることができる
• magicというキーを使ってユーザーパスワードをリセットできる

デモはこちら

• https://m.youtube.com/watch?v=Aw55HqZW4x0&feature=youtu.be

SSL VPNの話

Pulse Secureは新しくHTML5の機能を追加した

• バリデーションがルーズになった

コマンドインジェクション

• 認証前にコマンドインジェクションができる脆弱性
• CVE-2019-11539

Pulse Secure

• さまざまな手法でハードニングされている
• DSSafe.pm

引数インジェクションはうまく行かなかった

• 標準出力は使えなかった
• 標準エラーでスクリプトを書くことはできないか？と考え直した
• 標準エラーをキャッシュファイルにリダイレクトして、tcpdumpにPerlスクリプトを載せた

ツイッターのハッキング

ツイッターのSSL VPNはシンプルなもので、脆弱性があるものであった

• ハックしようとしたら二段階認証が出てきた
• バイパスする方法を探した
• ローミングセッション機能を使ってバイパスすることができた
  -- デフォルトアドミニストレータは、制限されていた
• マネージャの管理者パスワードのハッシュを見つけたので、大きいインスタンスで３時間クラックしたらパスワードを解析d慶太
• これはツイッターにおける初めてのRCEかもしれない

ワークショップ：Exposing Medical Devices Vulnerabilities using Reverse Engineering

医療機器デバイスの脆弱性をリバースエンジニアリングを使って攻撃するワークショップです

解析

ファームウェアの抽出

• 蓋を開けて、コネクタに接続
• シェルはbusyboxのように見てた
• 標準ツールtar + ncを使ってファームウェアを自分たちの検証用PCに抜き出す

次のステップ

• 通常はここで攻撃面をマップイングして、プリミティブを収集する
• nmapでネットワークスキャンして、　telnetサービスが台部分にあり、23ポートを開けていた
• IDAProを使ってバイナリが独自の認証モジュールを持っていることがわかった
  -- これは危険なサイン。よく使われているOSの認証スイートは専門家で構築されて、厳格な審査を受けている

第一の脆弱性

• ハードコードされたユーザー名supervisorに対する認証モジュールのテスト
• このBackDoorのユーザー名に対して5文字のパスワードが生成される
• パスワードは簡単なアルゴリズムが使われていた

結局のところ

• この種類のデバイス全てで同じことが言える
• telnetバナーに表記された年月日でわかる

BackDoorユーザーの脆弱性

• ハードコードされたパスワードを持つ、ハードコードされた湯〜あー
• 何がハッシュ化されているのか？ハッシュ化されているが強度は弱い
  -- 数時間でクラックできる

システムシェルコマンドのプリミティブ

• インタプリタのバイナリを掘り下げる
• システムシェルコマンドを実行する方法がすぐに見つかる
• 単に'SYS;CMD:'というプレフィックスを付けるだけだった
• telnetプロセスは、rootとして実行されるため、必要な物はすべて揃っている

手順

本体に対する手順

• バックドアユーザとしてログイン
• SYS:CMD:/sbin/telnetd使って、標準のtelnetdを起動
• 標準のルートユーザーを使って、ログイン

子機に対する手順

• 算出したパスワードはここでも使える
• 子機はtelnetサービスは公開されていないので、ネットワークから見える状態にはなっていない
• 子機の検査結果h臨床サーバに移す必要がある
• 子機が本体に接続されると、本体のイーサネットにつながってデータ通信される
• このデバイスは、通信に標準のXMLベースのPOCT1-Aプロトコルを使用している
• protocol特定だけではなく、医療機器製造メーカー独自のprotocol拡張APPTがあることに気がついた
• この名称は昔からあるアプリケーションシェルの名前と同じ
• 新しいパスワードを入力すると、SYS:CMD:構文を使える
• 同じ日時情報を基に算出下パスワードが利用されている
• パスワードの算出には、POCT1-Aプロトコルの初段でやり取りされる時刻年月日が使われている

攻撃手順

• DMSサーバーとして設定（ARPポイズニング）
• 本体からの接続を待つ
• 通知されたPOCT1-A protocolの交換で日付を読み出して算出したパスワードと共にAPPTコマンドを生成
• 注目点
  -- ニセDMSのサーバとして機能するコンピュータを攻撃する
  -- 子機を移動させると本体を通して攻撃者が接続する
  -- 攻撃者は日付と時刻情報を使ってパスワードを算出する

医療機器の現状

• 幾つもの要因が重なっている
• デバイス開発設計時にサイバーセキュリティ専門家が関与していない
• パッチサイクルの問題(システム停止は、患者にも影響を与える)
  -- サードパーティ製ソフトウェアのクライアントへのインストールが禁止されている(Virus対策,ファイアウォール)
• デバイスライフサイクルは、一般的に長い
  -- インターネットに繋がらない時代から、急激につながるようになってしまっている
  -- 可用性優先と標準化が問題になっている
• 多くの医療機器が同じようなバグを抱えている
• 標的型攻撃を観測している
  -- リバースエンジニアリングによって得られたデバイスに関する知識を悪用している
  -- 標準医療プロトコルのメーカー固有の拡張を悪用している
  -- 古いOSをベースに下多くのデバイスは、あまり洗練されていない攻撃に対して脆弱
  --- Windows XPのEternalBlue脆弱性の悪用に対して脆弱
• 研究者が脆弱性を発見して好評しても、パッチ適用が完了するまでに時間を要する場合がある。
  -- どう対策するか。

適用可能な緩和策

• 医療機器メーカーによるもの
  -- 開発設計時にサイバーセキュリティの専門家を参加させる
  -- フロントゲートファイアウォールプロセッサを追加する
  -- 標準化する
  --- 医療機器メーカーのインセンティブが働かない。。。
• 環境上のリスクの低減
  -- デバイスへにおアクセスを制限することで、攻撃面を最小化
  -- 正しく設定するのは難しい（可用性優先。。。）

QA

発見した脆弱性はどのように伝えているか？

• メーカーの窓口を通じて伝えている
• 第三者が介在して、深刻度を渡している

医療機器メーカーの標準化に対するモチベーションがないという話であったが、法規制に動きはあるか

• ゆっくりだけどある
• 古い機器がたくさんあるので、急には進められない
• カリフォルニア州法など、先進的な取り組みはその一部

終わりに

超盛りだくさんの一日目でした。
最新の動向からディープな話までインプットの嵐です。
明日もがんばります

今日はここまでです。
お疲れ様でした。