CODE BLUE 2019 参加レポート Day1, Main Trak

2019年10月29日から10月30日の2日間で開催されていた『世界トップクラスの情報セキュリティ専門家による最先端の講演と、国や言語の垣根を越えた情報交換・交流の機会を提供する国際会議』であるCODE BLUE 2019に参加してきたレポートです。
4回に分けたうちの1/4、Day1, Main Trackの内容になります。

Day1, Main Track

基調講演：核兵器とハッキング
Keynote:Hacking the Bomb - Cyber Threats and Nuclear Weapons
Presented by : Andrew Futter

講演者は英国レスター大学 国際政治学准教授でワシントン DC 軍備管理不拡散センター客員研究員などを歴任しており、本講演は安全保障に関する視点からのサイバー空間の脅威と核兵器との関係性に関するもの。
2018年に「Hacking the Bomb: Cyber Threats and Nuclear Weapons」という書籍を執筆しており、この内容にも準じるものである。
講演にて話があったポイントは以下の11点。
・「Cyber」は現在混沌とした状況にある
・「Cyber」と核は大きく異なるもの
・「Cyber Threats」は多様である
・ネットワーク分離=安全という考え方には誤解がある
・「Cyber」におけるいくつかの課題は核にはないもの
・人間に起因する問題が大きい
・スパイ活動やなりすましの問題は大きなリスクをはらんでいる
・演じる役割が変わっている
・「Cyber Threats」はクライシスにおいて最も危険性をもつ
・「Cyber」だけを分離して考えることはできない
・「hacking the bomb」の考え方に則る新たな規範が生まれる

前提として「Cyber」の意味する所の定義をし、それを共通認識として持つ必要がある。
核には戦略核と戦術核でレイヤが異なるが、今回の講演は戦術核に対してのサイバーについての考察、将来的には戦略核とレイヤを同じくするサイバーの考え方も出てくるかもしれないが、現状ではわからない。サイバーはあくまでも１つの手段であり、道具箱である。

ソフトウェアサプライチェーンの透明性：SBOMの実現
Transparency in the Software Supply Chain: Making SBOM a Reality
Presented by : Allan Friedman

SBOM：Software Bill of Materialとはソフトウェア部品管理表である。
ソフトウェアがどのようなコンポーネントをもち、バージョンはいくつで、どのような依存性をもっているのかを可視化するもの。これを用いて、ソフトウェアサプライチェーンの透明化を図る。
SBOMは⽶国NTIA(国家電気通信情報管理庁)で議論、作成されているもので、現在では２つのフォーマット（SPDX, SWTD）が利用できる。

米国金融業界ではすでに取り入れられており、ソフトウェアを導入する際にSBOMを要求してくる状況になっている。

小さなコンポーネントのバグほど、利用しているソフトウェアのアップデートまでに時間を要する。CVEがたくさん出ている方が、セキュリティへの関心が高く、セキュアにしようとする活動が活発であると言えるため、脆弱ではないとも言える。

サプライチェーンの関するセキュリティのため、資産管理、脆弱性管理として、SBOMをもつことが必要。

今は、米国金融業界が取り入れているだけのようだが今後米国の他の業界や、米国以外にもSBOMが広がることは明らかと思う。対応できるように準備が必要と思った。

参考
・NTIA Software Component Transparency | National Telecommunications and Information Administration
https://www.ntia.doc.gov/SoftwareTransparency

日本では、経済産業省にて
サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォースでの検討がなされている。
・「サイバー・フィジカル・セキュリティ対策フレームワーク」策定後のWG1の進め⽅（案）
https://www.meti.go.jp/shingikai/mono_info_service/sangyo_cyber/wg_seido/pdf/005_08_00.pdf

抵抗は無駄-防御できないサプライチェーン攻撃
Resistance is Futile – The Undefendable Supply-Chain Attack
Presented by : Sung-Ting Tsai, Linda Kuo

サプライチェーン攻撃においては、インターネット分離はシルバーブレットになり得ず、
100%信頼できるサプライヤーもない状況である。
どれだけ迅速に回復ができるかのレジリエンシーが重要となってくる。すなわち、早期検知、迅速な対応が重要ということ。

サイバーキルチェーンに対して、セキュリティサービスは次の３段階で考える。
・pre-compromise(攻撃前)
・compromise(攻撃時)
・post-compromise(攻撃後)
多くのセキュリティサービスはcompromiseを守るように設計されているが、サプライチェーン攻撃はpost-compromiseを狙うものである。そのため、サーバー攻撃に対する多重防御の最終防衛ライン（The Last Line）をpost-compromiseにおく必要がある。

以下のような用意が必要となる。
・何らかのインシデントが起こる前提でインシデントレスポンスのplaybookを用意する
・常時、能動的なスレットハンティングを行う
・敵をよく知ること(どんなツールを使っているのか、どんな脆弱性を狙っているのか)

アジア地域における最新のサプライチェーン攻撃概要
Overview of the latest supply chain attacks in Asia region
Presented by : Boris Larin, Alexander Liskin

サプライチェーン攻撃とは、利用者の手に渡る前に攻撃することであり、信頼されているメカニズム自体に毒を入れることである。

以下の３点での攻撃が考えられる。
・ソフトウェアインプラント(マルウェアを仕込む)
・ファームウェアインプラント(rootkitを仕込む)
・ハードウェアインプラント(BadUSBなどを用いて攻撃する)

攻撃はインストールの前だけではなく、アップデートサーバのデータに対しての攻撃、開発会社のソースコードへのハッキングなども考えられる。
サプライチェーン攻撃が蔓延する時代ではアップデートパッチを適用すればいいだけではなくなった。事例としては、CCleanerやASUSなどがあげられる。ASUSの事例では、アップデートサーバのダウンロードデータが書き換えられていたがデジタル署名はASUSの正式なものだった。サプライチェーン攻撃だとデジタル署名が正式であっても疑う必要がある。

リスク軽減の策としては、完全な開発インフラの可視化をすることが重要である。

[U25]わたしはあなたが昨夜に何をしたかを知っている：最新のIoT Hubへの侵入手法
Understanding the IoT threat landscape and a home appliance manufacturer's approach to counter threats to IoT
Presented by : Hikohiro Y Lin, Yuki Osawa

IoTが普及するにつれ、IoTのデバイスが増える。それぞれを管理するのではなく、IoT Hubで集中管理をするようになってきている。攻撃者の目線で言えば、IoT Hubをハッキングできれば、管理下の全てのIoTデバイスを自由にコントロールすることができる。

ハッキングするにはまずはIoT Hubのファームウェアを取得して解析をしてみる。
・ベンダーのホームページに公開されていないか
・アップデートファイルをダウンロードする際にデータをスニッフィングできないか
・エンベデッドシテムをデバッグする際に利用するシリアル通信を流用できないか
上記ではファームウェアの取得ができなかったため、Desolderingやサイドチャネルアタックにて試行する。

・Desoldering
eMMC, NAND Flashを基盤から取り外し、データ取得を試み、取得成功。
・サイドチャネルアタック
IoT Hubのブートローダーとして利用されていることが多いU-bootで解析
-> カーネルをロードする前にエラーが発生したらカスタムシェルを動かせる脆弱性を発見

得たデータをさらに解析し、脆弱性を見つける。発見した脆弱性の１つは次のようなもの
・ポートスキャンにより、8443番でhtttpが動いていることがわかる
・コードからログインに利用するのはアカウント：admin、パスワードはMACアドレスとシリアルナンバーと判明
・ログインしてみるとプラグインの管理ができることが判明
・プラグインとしてbackdoorを仕込むことができ、これに利用して盗聴なども可能となる

IoTもだんだんとセキュアになって来てはいるが、まだまだ脆弱な箇所が多い状況である。
よりセキュアにするためには、IoT機器のメーカーにもバグバウンティプログラムの整備を勧める。このプログラムは大部分を占める好奇心で動くハッカーたちが貢献できる場となる。

[U25]アンチウイルスをオラクルとしたWindows Defenderに対する新しい攻撃手法
[U25]Let's Make Windows Defender Angry: Antivirus can be an oracle!
Presented by : Ryo Ichikawa

アンチウイルスソフトは普段最も使うソフトウェアであり、悪意ある試行から防御するものであるが、攻撃者がデータを部分的にコントロールできる場合、攻撃者は誤検知を引き起こせる。誤検知を引き起こせるということは、誤検知がおきたかどうかで、データをためて解析ができ、検知回避を探すことができる。
アンチウイルスはオラクル(神託、託宣、神命)になりうる。すなわち、悪用できる。

Windows DefenderはWindows OSに含まれている最新のウイルス対策の保護を提供するソフトウェアである。これを解析する。
アンチウイルスの動作を検証するファイル(http://www.eicar.org/)を利用する。このファイルに含まれる署名をWindows Defenderは悪意のあるものと認識する。
Windows Defender on Linuxが可能となっているため、この環境を用意し解析を実施する。解析に利用できるツールもGitHubにて公開されている。
(https://github.com/0xAlexei/WindowsDefenderTools)

以下が可能だった
・情報窃取
ユーザ入力とsecret keyを同時に保持するアプリケーションであれば、secret keyのリークが可能なことを確認
・痕跡除去
アンチウイルスのファイル除去の動きを利用して、痕跡となるログを除去することが可能なことを確認

呼称するならば「アンチウイルスオラクル攻撃」で、Windows Defenderは他のアンチウイルス製品より賢すぎるという穴をついた攻撃である。汎用的な対策は存在せず、通常の動作であるため脆弱性ともいえない。

[U25]Semzhu-Project – 手で作る組込み向けハイパーバイザと攻撃検知手法の新しい世界
[U25]Semzhu-Project – A self-made new world of embedded hypervisors and attack detection methods
Presented by : Yoshifumi Shu (Yiwen Zhu)

SecHack365において進めていたプロジェクトの結果報告の講演。
組み込み向けの柔軟に利用できるハイパーバイザを開発(Semzhu-Visor)、また組み込み向けセキュリティ機能の研究・開発(AsROP、AsCOP)を実施した。

脅威モデルとして以下２つを想定。
ROP(return oriented programming)：ret命令を悪用
COP(call oriented programming)：call命令を悪用

セキュリティ機能実装の上での制約として以下２点
・プロプライエタリなソフトウェアに適用できること
・リアルタイム性を保持すること
どちらの制約も満たすことのできる先行研究がなかったので、CPU命令を擬似拡張することで新規に実装する方法を開発した。カーネル空間に対しても適用可能で、ゲストOSの運用も楽になるとのこと。

AsROPはROPに対するセキュリティで、ret命令の箇所を擬似拡張し検知する。オーバーヘッド削減のため、アセンブリで実装し検知対象とするret命令を削減した。
AsCOPはCOPに対するセキュリティで、blr命令実行時に分岐先が関数の先頭であるかを確認し検知する。リターンアドレス保存処理のチェック、ret命令先行性のチェックにおいて、例外となる関数のみをリスト化し、照合することで、オーバーヘッドを大幅に削減した。

APIに起因するSSRF：Apple PayがWeb全体にいかに脆弱性をばらまいたか
API-induced SSRF: How Apple Pay Scattered Vulnerabilities Across the Web
Presented by : Joshua Maddux

SSRFが最近ホットトピックとなっている。キャピタル・ワンが攻撃された際に利用された手法でもある。よく狙われているのは、クラウド上のインスタンスのメタデータを窃取することである。

Apple PayがSSRF脆弱性をWEBにばらまいている、Apple Pay決済を利用するサイトにSSRFを作ってしまう状況がある。
ApplePayとサイトを連携させた際に、Apple Pay決済を利用するサイトのサーバから、Apple側のMerchant Validation URL（https://apple-pay-gateway-*.apple.com）に接続する処理が決済フローの中で発生する。このURLをApple側が検証せず利用するため、SSRF脆弱性が存在することとなる。Appleは「開発者が気をつけるべき問題」として修正はせず、開発者向けAPIドキュメントに注意事項として記載した。webhookなどでもSSRFを悪用することは可能。

インスタンスのメタデータ取得に関してのセキュリティに関しては各クラウドの状況は以下となっている。
・Azure：HTTP headerの付与が必要
・GCP：メタデータの取得を無効にする設定が可能
・AWS：特になし

対策としては、同じステータスコードが連続する時には警告を出すなどが考えられる。

NSAのように企業イントラネットへ侵入：主要SSL VPNでの事前認証RCE
Infiltrating Corporate Intranet Like NSA: Pre-auth RCE on Leading SSL VPNs!
Presented by : Orange Tsai, Meh Chang

SSL VPNはポータブルで便利なものである。利用しているユーザも多い。
PaloAltoのSSL VPN機器でRCE脆弱性を発見したが、SilentFixされてしまった。この脆弱性により、Uberが被害にあっていることが判明している。CVE採番もされていないため、脆弱性と認められていない状況である。
Cisco、F5のSSL VPN機器は採番されているCVEが多く、セキュアであるといえる。
Pulse Secure, FortigateのSSL VPN機器も多く利用されているが、CVEは多くなく、比較的脆弱であるといえる。
SSL VPNの問題として３点(Integer Overflowの可能性、Type Confusionの可能性、Multitier architectureの問題)が挙げられる。

事例としてFortigateの脆弱性を取り上げる。

CVE-2018-13379とCVE-2018-13382を組み合わせた認証前のリモートコード実行
なお、２要素認証のバイパスもローミングセッションを有効化することで可能となる。
攻撃者はSSL VPNを武器化していっている。

対策として以下の２点をあげる。
・クライアント証明書を利用
・多要素認証を利用