Voltage Fault Injection をやってみた

こんにちは。技術部の中尾です。

奇跡的?に8月はアサインされた案件が少なかったので、夏休みの自由研究として以前からやってみたかった Voltage Fault Injectionをやってみました。 この攻撃は、サイドチャンネル攻撃の一種で、プロセッサの電源にグリッチを印加する、すなわち一瞬だけ電圧を下げることで誤動作させるというものです。

例えば、あるスマートキーに以下のようなCプログラムが実装されているとしましょう。

result = (input_key == correct_key);
if(result)
    unlock();
else
    lock()

1行目で、入力された鍵を検証し、2行目で正しければ解錠するという条件分岐があります。 攻撃者は、誤った鍵を入力し、2行目の条件分岐を実行されるタイミングでグリッチを入力します。この時、間違った鍵が入力されている(resultがfalse)にもかかわらず、unlock()が実行されてしまうことがあります。

このように、グリッチによって誤作動する事を利用した攻撃が、Voltage Fault Injection Attackです。

正直、これは研究室レベルの話でだと思っていたのですが、近年、Nintendo Switch[1]のSecure Bootのバイパス手法として実際に使われたことが報告されています。

攻撃対象

今回の攻撃対象は、Atmel社のマイコンATMega328のArduino互換ボードを使用しました。クロックは16MHzです。基板とパーツ合わせて500円くらいでした。

マイコンで動作するプログラムはこんな感じにしました。

volatile bool flag = true;
volatile bool once = true;
volatile const unsigned WAIT = 0xEFFF;

snip...

#pragma GCC optimize ("O0")
void loop() {
  volatile unsigned k;
  volatile unsigned i;

  while(flag){
    k = 0;
    Serial.print("Loop");
    for(i=0; i<WAIT; i++)
      k++;
    flag = (k==WAIT);    
  }
    if(once)
      Serial.print("\n\rSuccess!!");
    once = false;
}

このプログラムは、Loopという文字列を無限ループで出力するプログラムです。グリッチが印加されることで、Voltage Fault Injectionが成功すると、変数kが想定外の値になり、無限ループを抜け、"Success!"という文字列を出力します。

この攻撃は、とにかくタイミングが命です。攻撃が有効な時間をとにかく広げるような作りにしています。また、コンパイラによる最適化を抑制するpragmaも追加しています。

Glitcher

CPUに印加する電圧を一瞬下げるための装置(Glitcher)を作成しました。というとなんかすごそうですが、実際は転がっていたZybo Z7というFPGAボードで、グリッチの素になるパルスを作って、トランジスタで電圧変換＆電流増幅しただけです。

Glitcher外観

Zybo Z7には、4つのスライドスイッチ、6つのプッシュボタンが使えるので、プッシュボタンを押した時にGlitchが出るようにしています。 また、スライドスイッチその組み合わせでグリッチの長さを変えられるようにしてあります。

Glitcherの出力波形を下図に示します。 ブレットボードにそのへんにあった部品で適当に電圧変換＆電流増幅回路を実装したので、あまりきれいな波形ではないですが、200ns程度のGlitchはできているようです。（パルス回路はむずかしい...）

Glitcher出力波形

攻撃開始！

それでは、実際に攻撃してみます。プログラムが実行されると、シリアルポートに、Loopと表示され続けます。この時にGlitcherのプッシュボタンを連打すると...

攻撃結果

攻撃成功！

上の写真は、Glitcherの出力をCPUボードのVcc端子に接続して、Glitcherの出力をオシロスコープでモニターしながら、グリッチを入力した時のものです。Success!という文字列が出力されたことから、グリッチにより無限ループを抜け、Voltage Fault Injection攻撃が成功したことがわかります。

おわりに

この攻撃手法をはじめて聞いた時、ハードウェアの電源ラインにアクセスして、大量の Try & Error をやらなきゃいけない攻撃手法なんて、実際の攻撃にはつかえないと正直なところ思っていました。

しかし、IoTデバイスが攻撃対象となった場合、攻撃対象のハードウェアは攻撃者の手の内にあります。すなわち、これまで使えそうもなかった攻撃が現実的なものになりうるということでもあります。

今回はシンプルなCPUボードと、攻撃が簡単なファームウェアを用いた検証でした。また時間を見つけて、次はLinuxが動いているARMボードといった、もう少しリアリティのあるものを対象にしたいと考えています。

参考文献

1. https://media.ccc.de/v/33c3-8344-nintendo_hacking_2016

Black Hat USA 2018 & DEF CON 26レポート(1)

Black Hat USA 2018 & DEF CON 26レポート(1)

こんにちは、情報分析部の中島です。

8/4～8/12に開催されたBlack Hat USA 2018 & DEF CON 26の参加レポートです。私は、インシデント対応やフォレンジック調査の中で、主にマルウェア解析を担当しています。そのため、マルウェア解析関連技術にフォーカスして参加しました。他の内容については、別のメンバーがブログにする予定ですのでご期待ください！

Black Hat Trainings

私は、FireEyeのFLAREチームが開催する「MALWARE ANALYSIS MASTER CLASS」を受講しました。

トレーナーは、Practical Malware Analysisの筆者を含む、FLAREチームの3名でした。トレーニング形式は講義半分、演習半分という感じで、講義で学んだ内容を演習で手を動かして実践し、疑問があれば質問するという形式でした。

取り扱った内容は、

• Malware Stealth
• Shellcode
• Anti-Disassembly
• Scripting IDA Pro
• Anti-VM
• Packers
• 64 Bits
• Encryption, Encodeing, and Compression
• Microsoft .NET

でした。

コースのSTUDENT REQUIREMENTSに Designed for the experienced malware analyst, a robust skill set in x86 architecture and the Windows APIs is essential. と記述されていたこともあり、基礎的な内容を飛ばして実践的な演習に取り組むことができ、満足度が高かったです。

講義の最後で、講師から「これはボーナスだからみんな写真撮って帰れよ～」的なセリフとともに教材フォルダのディレクトリリスティングと読めないように加工されたQRコードが表示されました。興奮したまますぐにホテルに戻り、QRコードを編集し読み込んだところ、釣り動画へのリンクでした＼(^o^)／

講師側に釣られたと報告したところ、 lol, you'll have to keep an eye out for BH next year. current thinking is a doc and exploit analysis focus. and/or kernel/rootkit/bootkit analysis. とコメントを貰いました。

非常に充実した内容でしたので、来年のトレーニングも是非受けたいです。

Black Hat Briefings

Briefingsでは2日間で115件の発表があります。 同時並行数が多くなるため、見たい発表が被ることも多々あります。 Black Hatでは、公式サイトでプレゼンテーション資料が公開されているので、講演のまとめや見れなかった発表内容の確認などに役立ちます。

私が気になった発表をいくつか紹介します。

Title: "Finding Xori: Malware Analysis Triage with Automated Disassembly"
Speaker: Amanda Rousseau, Richard Seymour
Tracks: Reverse Engineering, Malware

発表者のAmanda Rousseau氏はmalwareunicorn.orgの人です。 既存のディスアセンブラには、大規模な解析に使えるディスアセンブラがないため、Rustで高速かつ自動化が容易なディスアセンブラを実装したという内容した。

コードはgithubで公開されています。

Title: "Decompiler Internals: Microcode"
Speaker: Ilfak Guilfanov
Tracks:  Reverse Engineering,  Malware

発表者はHex-RaysのCEOで世界中のリバースエンジニアが大好きIDA Proの開発者、Ilfak Guilfanov氏です。Hex-Rays DecompilerとDecompilerの内部で使用される中間言語であるマイクロコードの実装についての発表でした。

Title: "Windows Offender: Reverse Engineering Windows Defender's Antivirus Emulator"
Speaker: Alexei Bulazel
Tracks:  Reverse Engineering,  Malware

アンチウィルスバイナリエミュレータ(Windows Defender Antivirus)のリバースエンジニアリング結果とその方法に関する発表でした。アンチウィルスソフトの実装についてここまで細かく記載されている資料はみたことがなかったので非常に興味深かったです。

Title: "DeepLocker - Concealing Targeted Attacks with AI Locksmithing"
Speaker: Dhilung Kirat, Jiyong Jang, Marc Ph. Stoecklin
Tracks:  Malware,  Exploit Development

ディープラーニングを使った高度な標的型攻撃の手法のコンセプトを発表していました。ディープラーニングを使い、ビジュアル、オーディオ、環境情報、ユーザアクティビティなどを標的の識別に活用します。顔認証を使って本人を認識すると、ペイロードをデコードしてマルウェアに感染するデモがありました。DeepLockerは通常のエンコードと違い、デコードのためのキーがあるわけではないため、解析が非常に困難になります。

Black Hat その他

Arsenal

Arsenalでは、様々なオープンソースのセキュリティ関連のツールが発表されます。今回は私の所属するチーム、nao_secからEKTotalが出展していたため、見学兼お手伝いにいきました。

EKTotalは、ドライブバイダウンロード攻撃のトラフィックを自動的に解析できるツールです。EKの入り口サイトにアクセスしたときの、pcapかsazファイルをアップロードすることで使用されたExploit Kitの種類や脆弱性のCVE番号、マルウェアの抽出、抽出したマルウェアのVTの解析結果を確認することが可能です。

コードはgithubで公開されています。

Business Hall

Business Hallでは、各企業がブースを出展しています。日本で開催されるカンファレンスや展示会では出展が見られない企業のデモや展示がありました。出展側もラフな格好ですし、ビールを無料で配布している企業もあって、日本とは雰囲気が違うなと感じました。おみやげにTシャツやステッカーもたくさんいただけました!気になればすぐに商談に移れるように、個室の商談ブースも用意されていました。

DEF CON 26

Black Hatへの参加＆飛行機の関係で、DEF CONは2日目のみ参加しました。DEF CONには様々なジャンルの出展があるのですが、弊社の若手エンジニアと他社の若手エンジニアでチームを組み、オンサイトで開催されるOpenCTFにほとんど参加していました。(この話は別の記事で)

CTF参加のため、あまり見学できなかったのですが、前から興味があったLockpicking villageを覗いてきました。Lockpicking villageでは、物理ロックのピッキングのデモンストレーションや体験コーナーがあり、参加者は物理ロックがどのように機能し、どのように危険にさらされるかを学ぶことができます。私もピッキングを体験し、物理セキュリティについて理解を深めることができました。簡単なロックだと専門知識をほとんど必要とせず、解錠できてしまうとは恐ろしいですね。

おわりに

Black HatのTrainingsからDEF CON2日目まで7日間毎日がエキサイティングな日々でした。普段はネット上でしか交流がない海外のエンジニアと直接会うことができよかったです。また、レベルの高い発表を聞くことでアウトプットへのモチベーションが上がりました。

DEF CONは1つ1つがとても濃く、一日だけでは回りきれなかったので参加する人は全日程参加することお勧めします。

セキュリティエンジニアなら誰しも憧れるハッカーの祭典、夏のラスベガスでの一週間でした。

Midnight Sun CTF 2018 Finals参加記

Midnight Sun CTF 2018 Finalsに参加した感想と記録です。

まえがき

こんにちは、技術部の松隈です。

ネットワーク診断やバイナリ系のものが関わる診断に携わっています。すこしだけバイナリ系のexploitationに興味があります。
週末には業務兼趣味としてCTF(Capture The Flag、コンピュータセキュリティに関連するスキルの競技で、問題を解いて"flag"というキーワードを手に入れることで得点を得ます)に参加したりしていなかったりします。
競技ではWeb、バイナリ、暗号など様々なジャンルに渡って出題されますが、私は主にPwnというバイナリの脆弱性を攻撃するジャンルを担当しています。

先日、いつものようにCTFの参加に関する出張申請をしたためていたところ、

「いやさあ、、きみ何度も海外CTF参加してるし、、、さすがにそろそろブログ記事とかでアウトプットとかね…(｡ŏ﹏ŏ)」

というお気持ちを頂戴してしまいました。
たしかにここ数年を振り返ってみると、幾度となく海外CTFの参加を出張にしてもらっていたにもかかわらず、ブログでのアウトプットはゼロでした。記事のネタがあるのなら書くべきですね。。

…というわけで、肩書きが「技術部 穀潰し」になってしまう前に先日参加したMidnight Sun CTF 2018 Finalsの参加記を投稿したいと思います。

Midnight Sun CTF 2018 Finals

6月16日(現地時間)から2日間、スウェーデン/ストックホルムで 開催された Midnight Sun CTF 2018 Finals に、チーム TokyoWesterns として参加しました。

学生の部と社会人の部の二部構成となっており(ただし問題は共通)、わたしたちは社会人枠として出場しました。

最終的なランキングは下のようになります。TokyoWesterns は 🥉3 位 でした。
日本から参加していた scryptos は、惜しくも 🏆1 位 の LC↯BC と僅差で 🥈2 位 でした。終了1分前の逆転劇は本当にすごかったです…！

Place	Team Name	Score	Student Team?
1	LC↯BC	6687	✘
2	scryptos	6660	✘
3	TokyoWesterns	5239	✘
4	p4	4874	✘
5	Made In MIM	3260	✔
6	RedRocket	2582	✔
7	dcua	2517	✘
8	GYG	2244	✘
9	/upb/hack	2098	✔
10	Perfect Blue	1892	✘
11	KTHCTF0x1	1214	✔
12	showeremoji	1005	✔
13	VSS	883	✔
14	LiUhack	870	✔

解いた問題の解説

競技中にバグを探すなどの手伝いをしたものが以下の通りで、

• Gissa (Pwn: 468pts)
• Flitbip (Pwn: 485pts)
• Onion browser (Pwn: 468pts)

個人としては次の問題が解けました。

• Onion browser (Pwn: 468pts)

Onion browser (Pwn: 468pts)

まずは、CTFで問題を解くときの基本の問題文です(Pwnの場合はあまり関係ないですが。。)

Onion Browser is a minimal and super secure browser! Fortunately, our boys at FRA/NSA left a backdoor in the source code. If only we knew someone skilled enough to exploit it :(

Solves: 4

Service: nc pwn.midnightsunctf.se 31337 | nc 34.254.34.57 31337

Download: onionbrowser.tar.gz

Author: likvidera

ミニマルなブラウザをexploitするチャレンジみたいですね。

詳細なwrite upは別の記事で載せるため(あくまでも「つもり」です、強靭な気力があればいつかきっと。。。)、ここでは簡単な流れの解説のみを行います。

概要
Onion browserは、JavaScriptエンジン(以下、「JSエンジン」とします)に埋め込まれた脆弱性をexploitするタイプのPwn問題(以下、「js pwn」と呼びます)です。js pwnの問題は、ここ最近の大きめのCTFではちょくちょく出題されている形式で、大抵は主要ブラウザの大規模JSエンジン(V8やSpiderMonkeyなど)がターゲットになります。今回のターゲットはWebブラウザを模したx86 ELFバイナリで、JSエンジンにはduktapeが採用されていました。

このバイナリの挙動は、

1. ユーザーが指定したURLに対してlibcurlでアクセスしてリソースを取得
2. アクセス先のURLの拡張子によって次の処理を行う
   • .htmlの場合: 取得したリソースをレンダリングをせずに表示
   • .jsの場合: 取得したリソースをduktapeで実行した結果を表示
   • それ以外の場合: 対応していない旨のエラーを表示

というものでした。

つぎに、ターゲットのバイナリに施されている保護機構を示します。

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      FORTIFY Fortified Fortifiable  FILE
No RELRO        Canary found      NX enabled    No PIE          No RPATH   No RUNPATH   Yes     0               21      (censored)

続いて、問題の脆弱性の解析とそのexploitについて軽く解説します。

解説
js pwnの問題には、脆弱性を埋め込むためのパッチファイルが添付されています。題意としては「脆弱性を作り込むパッチが当たった状態のJSエンジンをexploitしなさい」というものです。Onion browserにも次のようなパッチが用意されていました。

diff --git a/duktape/src-input/duk_bi_buffer.c b/duktape_patch/src-input/duk_bi_buffer.c
index 9b2f6d7..ac78ea2 100644
--- a/duktape/src-input/duk_bi_buffer.c
+++ b/duktape_patch/src-input/duk_bi_buffer.c
@@ -1591,6 +1591,24 @@ DUK_INTERNAL duk_ret_t duk_bi_nodejs_buffer_copy(duk_hthread *thr) {
*  See test-bi-typedarray-proto-set.js.
*/

+#if defined(DUK_USE_BUFFEROBJECT_SUPPORT)
+DUK_INTERNAL duk_ret_t duk_bi_typedarray_midnight(duk_hthread *thr) {
+       duk_hbufobj *h_this;
+       h_this = duk__require_bufobj_this(thr);
+       DUK_ASSERT(h_this != NULL);
+       DUK_ASSERT_HBUFOBJ_VALID(h_this);
+
+       if (h_this->buf == NULL) {
+               DUK_DDD(DUK_DDDPRINT("source neutered, skip copy"));
+               return 0;
+       }
+       h_this->length = 31337;
+       duk_hbuffer * buf = h_this->buf;
+       buf->size = 31337;
+       return 0;
+}
+#endif
+
#if defined(DUK_USE_BUFFEROBJECT_SUPPORT)
DUK_INTERNAL duk_ret_t duk_bi_typedarray_set(duk_hthread *thr) {
        duk_hbufobj *h_this;

diff --git a/duktape/src-input/builtins.yaml b/duktape_patch/src-input/builtins.yaml
index d4c4225..0e79be8 100644
--- a/duktape/src-input/builtins.yaml
+++ b/duktape_patch/src-input/builtins.yaml
@@ -974,6 +974,7 @@ objects:
        id: bi_array_constructor
        attributes: "wc"
        present_if: DUK_USE_ARRAY_BUILTIN
+
    - key: "toString"
        value:
        type: function
@@ -4071,6 +4072,12 @@ objects:
        typedarray: true
        es6: true
        present_if: DUK_USE_BUFFEROBJECT_SUPPORT
+      - key: "midnight"
+        value:
+          type: function
+          native: duk_bi_typedarray_midnight
+          length: 0
+        present_if: DUK_USE_BUFFEROBJECT_SUPPORT
    - key: "subarray"
        value:
        type: function

さて、このパッチを読むとターゲットのduktapeでは、

• TypedArrayに対してmidnight()というメソッドが実装されている
  • 対象のTypedArrayのsize、これに対応するArrayBufferのlengthフィールドをそれぞれ31337に設定する

ということがわかります。
ちなみにTypedArrayによる値の読み書きは、内部的に対象のTypedArrayに対応するArrayBufferのindex番目に対してta.BYTES_PER_ELEMENT分の読み書きを行います。

midnight()を呼び出した場合、実際に確保されているサイズはそのままの状態で、対象のTypedArrayのsizeと当該ArrayBufferのlengthが書き換わってしまいます。例えばそのArrayBufferの元々のlengthが更新後の値よりも小さい場合は、領域外のアクセス(Out-of-bound Read/Write: OOB R/W)が可能となります。Onion browserで問われている脆弱性はこれでした。

以下に脆弱性を再現するためのPoCを示します。

let ta = new Uint32Array(1);    // Any type is Ok :)  
console.log(ta.byteLength);     // => 4
ta.midnight();                  // Update the length of `ta`'s internal buffer to 31337
console.log(ta.byteLength);     // => 31337

とても意図的でシンプルな脆弱性ですね。このようなArrayBufferに関するOOB R/Wは強力なものですが、exploitationの目的である"/bin/sh"の起動の実現をするにはまだすこし弱いです。

さて、オーバーフローの発生する箇所の後方に任意のオブジェクトを配置可能な場合の攻略方法として、TypedArrayのサイズに関するフィールドを上書きして任意アドレスの読み書き(Arbitrary Address Read/Write: AAR/AAW)を実現するというものがあります。
この脆弱性をexploitして、OOB WriteのあるArrayBufferに隣接する他のTypedArrayと当該ArrayBufferのlengthを(1<<32) / ta.BYTES_PER_ELEMENTに上書きすることで、当該プロセスの全メモリ空間で読み書きをすることが可能となります。
実際にAAR/AAWを実現するためには、書き込み対象のアドレス(targetAddress)が上書き対象のTypedArrayのArrayBufferの存在するアドレス(addressOfArrayBuffer、OOB Readにより取得・計算可能)よりも小さい場合は、addressOfArrayBufferをオフセットとして考えてtargetAddress += (1<<32) - addressOfArrayBufferを行ってから書き込む必要があります。

以上でAAR/AAWが手に入りました。あとは書き込み先を考えるだけです。先に述べた保護機構の情報から以下のことがわかります。

• RELRO: No RELRO
  • RELRO(RELocation Read-Only)がないためGOTの領域が書き込み可能である。GOT OverwriteによりEIPの奪取が容易に実現可能である
• PIE: No PIE
  • PIE(Position Independed Executable; 位置独立実行形式)ではない。バイナリのロードされるアドレスは固定であるため、書き込み対象のアドレスをリークする必要はない

今回は次の手順で攻略しました。

1. 脆弱性の発火により得たOOB R/Wを利用して、AAR/AAWを実現する
2. AARよりGOTのエントリから適当なlibc上のアドレスをリークして、__libc_systemのアドレスを計算する
3. AAWより、第1引数が制御可能なlibc関数のGOTのエントリを(1)で求めた__libc_systemのアドレスに上書きする
4. 第1引数に"/bin/sh"を設定した状態で上書きした関数を呼ぶことでシェルを起動する

あとがき

まずは個人的な感想ですが、久々の決勝参加と初のヨーロッパで純粋によかったです！また、最近はCTFでflagのサブミットがめっきりできていなかったのもあって、Onion browserに時間はかけてしまったものの解けた点に関しては安心しました。

チームとしては、上位に入ることができたのでよかったなあと思っています。ただ、Onion browserが解けたあとで集中が切れてしまい、結果として1問だけしか解けていないという残念な結果になったため個人としての得点への貢献は薄くなってしまいました。次のCTFではうまいことテンポよく解いていきたいと思います。

また、Onion browserの詳細なwrite upも近々(…🤔？)投稿するつもりですので、どうぞお楽しみに！