Security

CODE BLUE 2017レポート(DAY2中篇)

こんにちは、ひろかずです。
前回に引き続き、CODE BLUE 2017のDAY2をレポートします。

お品書き

  • "商用ホワイトボックス暗号方式" に対する "鍵回復攻撃"
  • LG vs. Samsung スマートTV: あなたを追跡できるのはどちら?

=== 今回はここから ===

  • インサイドShell:.NETハッキング技術を応用したPowerShell可視性の向上
  • 国産IT資産管理ソフトウェアの(イン)セキュリティ

=== ここまで ===

  • Trueseeing: Effective Dataflow Analysis over Dalvik Opcodes
  • OSSによる自動車の自動運転化

インサイドShell:.NETハッキング技術を応用したPowerShell可視性の向上

丹田 賢 - Satoshi Tanda -

サンプルコードはGit(DotNetHooking)を参照とのこと

個人的な動機

悪意のあるペイロードは小さなダウンローダーからダウンロードされてくる。
JSダウンローダーを使ったスクリプトの配布にシフトしてきている
スクリプトベースのマルウェアは、EXEより見つけにくい
PowerShellを使った、攻撃的なエクスプロイトツールの存在に気づいた。

今日の目的:どうやってPowerShellを使った攻撃から身を守るか

PowerShell攻撃への対応の難しさとAMSI

PowerShellは、攻撃に頻繁に使われている。
AVソフトウェアでの検知は難しい

  • exe自体はデジタル署名されている正当なアプリケーション
  • スクリプトファイルも簡単に改変できる(コメント、変数、ブロックのスワップ)ので同様に検知が難しい
  • スクリプト自体も使われていない可能性(コマンドラインとか)
  • PowershellエンジンはDLLなので、任意のプロセスに読み込まれて、そこで動作してしまう
  • どのコメント読み込まれて実行されるのか、テキストだけでは分からない
  • エンコードされた文字列を実行することもできるので、更に検出が難しくなる

これらが効果的な検知を妨げている

AMSI

Windows10からの新機能
- PowerShell v5であることも必要
AMSIプロバイダとして、アプリケーションを登録
スクリプトを評価する

  • スクリプトファイルの内容がわかる
  • デコードされた後の文字列が分かる
  • PowerShellエンジンが実行される間は常に有効

が、しかし

  • 一部の難読化は解読できない(正規表現で回避可能)
  • 最初のコマンドが通ると、それ以上は読み込まない
  • 管理者権限不要で無効化できる

では何ができるか?

  • セキュリティベンダーは何をしているか?

.NETネイティブコードフック

生成されたネイティブコードを書き換えることで、マネージドプログラムの動作を実行時に変更する

  • 評価の結果、非常に効果的だと言われている

マネージドプログラムの基礎

C#等の言語で書かれたプログラムは、MSILにコンパイルされる(これをマネージドプログラムと言う)
MSILは、バイナリプログラムに変換される

マネージドプログラムは.NETフレームワークを通してDLLと会話する

  • アンマネージドプログラム(C++等)は、直接DLLと会話する
  • .NETフレームワークにHookする

アドレス特定について

ソースコード実行時アクセスの際に、リプレクションでマネージドプログラムは.NETアセンブリやメソッド、フィールドなどを修得する

フックするコードの実行について

フックをインストールするために、プロセス内でマネージドコードを実行する必要がある

  • アンマネージドプログラムからホスティングAPIを使用する(bootstrapコード)

UPPDOMAINMANAGERの利用がおすすめ

  • 独自のUPPDOMAINMANA独自のを実装するフック用.NETアセンブリを事前に登録
  • AppDomainが作られる時、CLRがとうr腐れたAppDomainManagerを読み込み実行

利点はコードが小さいこと
欠点は環境変数に依存すること

PowerShellはマネージドプログラム

PowerShellはC#で書かれたSytem.Management.Automation.DLLで実装されている

  • AMSIと同様の機能をWindows8.1以前に実装、Powershenn以前に実装できる

古いWindows+PS V5については、SMA.dllのメソッドをフックすることでAMSIをエミュレーションできる

  • SMA.dllではAMSIプロバイダの呼び出しはAmsiUtils.ScanContentメソッドで実装されている
  • このメソッドを独自のスキャンロジックで上書きする

古いPowerShell

  • 困難
  • AmsiUtilクラスは存在せず、オープンソース実装もないので、リバースエンジニアリングを通して、適切なメソッドを探す必要がる
  • 利点
  • 無料の.NETデコンパイラがあるので、読みやすいコードを生成できる
  • デバッガはソースがあるように動作する
  • オープンソース版のそれに近い動作をする

AMSIバイパスの無効化

System.Management.Automation.dllにhookしているので、AMSIバイパスの影響を受けない

PowerShellに対する可視性の向上

コマンドレッドの実行により、難読化が解除された状態のパラメータにアクセスできる
コマンドレットが実行される時、ProccessRecordメソッドが呼び出される
thisポインタに全てのパラメータを保持している

まとめ

Windows10を利用する
Constrained Language ModeとApplockerまたはデバイスガードを導入する

  • ほとんどの攻撃を防げます

PowerShellv2を削除する
PowerShellからのGetFunction Pointerに注意する

  • ほとんどの攻撃は、これを活用する

質疑応答

制約の中に攻撃者が同じ手法を使ってhookを解除できると思うけど、耐タンパー性はありますか?

  • ちょっと難しい
  • 最初に動作したものがクリーン(検出できない)
  • このテクニックを使った良い検出方法は思いつかない。

図があると更に判りやすいと思います!
資料の公開が待たれますね!

国産IT資産管理ソフトウェアの(イン)セキュリティ

西村 宗晃 - Muneaki Nishimura -

国産IT資産管理ソフトウェアの(イン)セキュリティ

西村 宗晃 - Muneaki Nishimura -

製品名は公開しません。

  • 名前が挙がらなかった製品が脆弱でないというミスリードを与える
  • 批判が目的ではない
  • 広く使われているものの、脆弱な場合についての気付きを知ってほしい

2015年のCODE BLUEで登壇
2年間の変化

  • 日曜バグハンターから
  • セキュリティ品質グループのマネージャ

社内RED TEAMを発足

  • 国内ユーザー企業で設置されたのは初
  • 能動的にグループ会社の脆弱性を探し出す
  • サードパーティの脆弱性が見つかることもある

脆弱性を探し始めたきっかけ

きっかけは3月のあの事件
JPCERTから公表されたが、全国紙でも展開された。

悪用された脆弱性

  • Agentの待受ポートに偽の管理機からの命令を実行してしまう
  • USBトングルを使っている場合、グローバルIPが振られるケースがある。インターネットから攻撃を受けるケースがある。

危機感

  • この成功体験で、国産ソフトウェアを研究して、脆弱性を狙った攻撃が増える可能性
  • 社内の競合製品でも同様の脆弱性があるかも
  • RED TEAMを発足

見つかった脆弱性

  • 社員PCの遠隔操作と任意コード実行
  • 管理機のファイルやDB改ざん
  • 社員PCから収集した機密情報の漏洩

IT資産管理ソフトウェアとは

ITガバナンスのために社用PC導入された情報収集ツール

  • インストールソフトウェア情報の収集
  • 閲覧サイトやアップロードしたファイル情報
  • PC上のデバイス利用制限
  • ファイルやプログラムの遠隔配布と実行
  • PCのデスクトップのリモート操作

これって合法的に導入されたMeterPriter

主な通信と脆弱性

管理者からの通信

  • 管理画面へのアクセス(管理指示ポートのアクセス制御不備)

管理機からの通信

  • 管理機変更通知(管理通信の偽装)
  • 画面共有や遠隔操作(ポートのアクセス制御不備)

社員PCからの通信

  • インベントリ情報の定期送信(管理機を攻撃、管理機を踏み台にして別のPCを攻撃)

管理通信の偽装

管理機からのリクエストをキャプチャ

  • だいたい暗号化されている
  • パケットを観測していると規則性がある
  • はじめはlength、次はマジックナンバー、次は決まって01、その後はか鳴らす16byteの倍数
  • クライアントに鍵ファイルがあるのかも(ファイル名で分かるものがあった)
  • AES128-CBCで暗号化されていた
  • インストーラに埋め込まれた固定鍵だった(社内端末は全て同じ暗号鍵)
  • 他社はどう?(同じだった)
  • 偽の管理機情報に書き換えて別のPCに投げたら通信が来るようになった
  • 計算機を起動する司令を投げたら刺さった。
  • 他社にも刺さった

遠隔操作ポートを待ち受けているプロセスを調査

  • VNCの起動オプションに-noauthと書かれていた
  • 繋いでみたたらバージョン不一致エラー
  • サーバーはVNCバージョンを送ってくる
  • クライアントも合せてみるが、バージョンを合せてもエラーになる
  • バージョンをインクリメントしたら一つだけ応答が違う
  • GithubからVNC Viewerを拾ってきてバージョンを書き換えたら、遠隔操作できるようになってしまった

管理端末から管理機への通信をキャプチャ

  • 認証してそうなパケットから、認証を取ってみたら通った
  • wherestringsに+or+1を足したらインジェクションできた
  • インベントリ情報から、デバイス禁止動作、クリップボードの情報まで取れた

PCから管理機への通信のキャプチャ

  • 暗号化の過信(通信やファイルの暗号化のみで攻撃を防ごうとしている)
  • 鍵やアルゴリズムを知らなくても解ける暗号もある
  • オートフィル機能で、ローカルに暗号化された文字列が書かれたファイルがある
  • パスワードの情報をID欄に書き換えるだけで表示されてしまう
  • 同じ機構は、同一製品上のいたるところで利用されてします。
  • ログインフィールドは暗号解読のガイドとなりうる
  • 体験版は自由に入手できる(暗号ヘルパーを見つけ出して攻撃に繋いていく)

暗号が解けると

  • エージェントが作る一時ファイルを観察すると、SQLバッチファイルが出てきた
  • Delete文に書き換えてみたら、管理機DBをDeleteできた
  • 入手したポート番号とパスワードで他の社員のPCを遠隔操作できた

ディレクトリトラバーサル

  • テンポラリファイルのパスを書き換える事ができた
  • ディレクトリ名に管理IDが含まれていたので、管理IDを../../と入れたらできた

さいごに

IT資産管理ソフトは権限が高い
が、脆弱性対策がなされていない製品が多い(結構初歩的)
JPCERT/CCとの連絡窓口を持たないベンダーも多い
体験版は個人でも入手可能(屋号でも手に入る)
サイバーテロ組織も同様の方法で体験版を入手しているのかも

  • 海外のペンテスターも体験版を入手していた

このようなことを減らしていくために

自社で導入するソフトウェア製品のセキュリティ品質に関心を持つこと

  • 導入時にセキュリティ評価(脆弱性検査)を実施する
  • 脆弱性に対する取り組みをベンダーにヒアリングする

セキュリティ研究者にも注目して欲しい

  • 目を増やすことで、意識を高める

質疑応答

市販製品にはリバースエンジニアリングを禁止するライセンス条項があるがどう考えるか?

  • リバースエンジニアリングに依存しない方法で行っている(技術的にできないとも言う)

見つけた後の社内の対応はどうしている?使い続けるのはどう?

  • 待受ポートの遮断したりの対応をする
  • 時間を見つけて洗い出していくしかない

次回が最後になります。