Skip to content

Instantly share code, notes, and snippets.

@hal0taso hal0taso/CODE BLUE 2017
Last active Nov 12, 2017

Embed
What would you like to do?

T1-2

@Robert_Lipovsky @cherepanov74

Industroyerについて、解析

変電所への攻撃

停電を引き起こした

  • Stuxnet
  • Havex...(2014)諜報用
  • Blackenergy...(2015)
    • ICSを標的としたわけではない
    • 標的ネットワークへのリモートアクセスを可能にする
    • アクセス後、手動で停電を発生させる
    • 有名な動画のやつだ!
  • Industroyer...(2016)
    • ウクライナでの停電を引き起こす
    • ESETが解析
    • 2017年12月公開

詳細

メインのバックドア

C&Cへの接続

感染したマシンからファイルの複製、アップロード

main backdoor -> vbs -> mySQL -> vbs

credentialがアプリケーションの中でハードコードされてた -> これはマズイ!!!w

再起動後にも起動するためのコマンド

追加のバックドア

予備のバックドア

windows notepadになりすました -> dragonflyでも使われていた手法

ポートスキャナーとDOSツール

payload

ハードウェア自体を直接コントロール

ハードウェアとは、プロテクションリレー(ブレーカの開閉、などを行う)

スケーラソフトウェア

後述

プロトコル

プロトコルを悪用する (not 脆弱性の悪用)

Payload

  • ランチャーコンポネント
    • 個別のpayload module
    • デバイスを制御できるモジュールを特定(独自のconfigurationを持ったdll)

101

104ペイロード

  • TCP/IP
  • オペレーションのモード
    • range
    • shift
    • sequence

brute forceのように総当たりでコマンドを送る

ログを取る機能もある

61850ペイロード

  • TCP/IP
    • IPアドレスが指定されてなくてもいい
    • ネットワーク中のデバイスをスキャンして接続する
    • ブレーカー、スイッチに対応する
    • ブレーカーの開閉が目的

OPC DAペイロード

  • OPCサーバを発見
  • 特定のタグを検索する

特に難読化されているわけではないので、容易に解析可能

いずれもブレーカの開閉を目的としたpayloadになっている

オーロラ発電所での停電

物理的なハードウェアが破壊される

DOS

プロテクションリレーを機能不能にする

USPパケットを5万のデバイスに送る

データの消去

ワークステーションを攻撃する

通常はランチャーで送ったペイロードを1,2時間後に停電するようにする

マシンのレジストリを破壊して、システムが起動不能にする

ワークステーションで作業をしようとしても起動することができない -> バックアップが重要

まとめ

どのベンダにも有効なモジュール、特定のベンダに特化したモジュール

特定の国、特定のベンダではなく、広い範囲に影響する攻撃

攻撃者の能力、ターゲット(産業制御システム)への深い理解

事前調査が多くなされていることがわかる

質疑応答

  • これはゼロから構築されたものか?

    • そう。このような能力のマルウェアを使って1時間の停電というのは影響が低い。なぜ??
    • 全体としては攻撃者の目的は達成されたなかった??それとも大きな攻撃へのテストだったのか??
  • 攻撃者は誰??

    • 明確な答えはない。経済的な利益というのはない。力の誇示??国が後ろにいるというのは断言できないが、可能性はある。
  • 日本は海外とは異なる特有なシステムを用いている。どれくらい解析できている?バックアップを用いるということは、ローカル環境で何が起こっていたのか、原因究明ができないがどうする?

    • 攻撃者は痕跡を多く残したため、悪意のあるファイルやログを取得できた。基本的なインシデント対応で十分なのでは?ワークステーションはwindowsなので、windows向けのforensicsで大丈夫
    • モジュールを用いるので、攻撃者が日本に向けたモジュールを利用する可能性もある。日本が標的になる可能性もある。
  • 最後のペイロードに使われるファームウェアを注入するという話だった。それは実現している??

    • GEのコードについて。目的はわからない。実際に使われたかどうかもわからない。発見したコードはcleanで、改ざんされていなかった。リフレッシュしてリプログラミングするというのもある。
  • どうやってそれが可能になる??インジェクションをロックする機能はどう解除した?

    • ドキュメントを集めることができる。プロトコルは認証がないため、設計に欠陥があった。
  • GEから事前に情報を摂取する必要があったのでは??デフフォルトの設定などに関して事前に必要とされる知識が多い。

  • 攻撃者は当該産業システムに対してよく知っていた。働いていたのか?それとも似た環境でテストを繰り返していたのか?

    • 随分前に侵入済みで諜報活動をしていた可能性もあるが、実際の攻撃は5日間
    • 証拠はない。前の攻撃からずっといたということもある。2015年の停電と2016年の停電の攻撃者を結びつけるようなヒントはまだ見つかっていない。
    • 2回ともウクライナ。関連性がありそう。
    • プロテクションリレーをebayで買うことは可能だが、システムのインフラ全体像を理解するためには、その全体の設計に関して、などの実際の現場を見る必要がある
    • そのための何重にも保険がかけられたペイロードだったことがわかる。
  • Blackenergyとの関連の証拠は?

    • 特にない。

d2-t1-1 @h2spice アンサンファン

  • イントロ
  • WBCとは
  • OSSWBC実装への攻撃
  • 商用WBC実装への攻撃
  • まとめ

イントロ

アカデミックなWBC実装には多くの攻撃が成功している

商用WBC実装には未だ攻撃が成功した事例は多くない

サイドチャネルアタックを使って攻撃した

WBCとは

  • アプリケーションセキュリティ
    • 鍵はアプリケーションに保存されていて、その鍵を見つけることは容易である
    • 攻撃者はエンドポイントを直接攻撃することによって暗号システムを完全に制御することが可能となる
    • デバイス、コンテンツの所持者が攻撃者となってしまう

WB脅威モデル

  • バイナリは攻撃者に見える
  • 攻撃者はアルゴリズムにアクセス可能
  • 攻撃者は実行環境を完全に制御できる
  • 何度でも実行できる

TEEはほぼ安全だが、サポートされているデバイスが少ない

WB脅威モデルのソリューションとしてのWBC

  • 学術的なレベルの実装は破られている
  • 商用WBCへの攻撃の事例はない

数学的な展開や難解化によるアルゴリズム自体の難読化が施されている

鍵はデバイスの中にあり、鍵を含めた暗号化の方式を実装している

Chouの方法をベースとした実装が多い。

partial evaluation

encoding

partial evaluationだけでは足りない。キーの抽出ができないように、encodingを行う。T-boxを守る。

IN-OUTまでのテーブルの間にA A^{-1}をかける

WB-AES実装-外部エンコーディング

WB-AES実装

暗号スキームを難読化することによって、攻撃者が鍵を抽出するのが困難になる

既存の攻撃手法

  • table-decomposition

  • BG-attackに対する対策をベンダーは開発している

    • 実装は公開されていない
    • REする必要性が出てくるため、解読コストの上昇に貢献
  • power analysis

    • 途中の計算結果を記録して、シュミレートされたデータを比較
    • この手法はBlackhat Eur 2016で提唱されてる
    • ソフトウェアベースでのこの手法のいいところは、ノイズがないこと
    • Correlation power analysis
  • Differential fault analysis

    • 中間データを変更する
    • faultのある出力とfaultのない出力を比較する
  • 商用WB実装では保護された鍵を復元することは困難

    • 鍵のリカバーには成功した
    • サイドチャネル攻撃(CPA,DFA)を使って解析した
    • 制御フローを視覚化する手法

商用WBC実装に対する攻撃

2つのモード

  • パフォーマンスの高いシンプル暗号モード
  • セキュリティの高いコンプレックス暗号モード

シンプルcipherの視覚化マップをOSSのものと比べて見る

ラウンドパターンを見出すことはできない

experiment

  • taint analysis
  • CPA
  • reverse engineering
  • DFA

taint analysis

inputA,inputBとタグをつけ、アクセスを追跡する

シンプル暗号のCPAでキーリカバリーできた

complex cipherのtaint analysis

難しい

cryptograohy primitive

DFAを用いるため、(フォルトをinjectするための)ReverseEngineeringするしかなかった。

計算の整合性をチェックするための処理があったため、フォルトの注入ができなかった

まとめ

  • no single key
  • no hardcoded key
  • no static IV
  • use external encoding
  • Use asymmetric crypto algorithm based on WBC(RSA, Elliptic curves, Diffie-Helman)
  • Use tamper resistant
  • Use device binding
    • ユーザー識別子、デバイス識別子
memo of CODE BLUE 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.