本稿について
ÆTERNITYのメインネットリリース前から行われているセキュリティ監査報告のv0.5について見ていきます。今回の範囲は「5. Nodes」の「5.3 Tests on Epoch Implementation」です。
原文はこちらになります
スポンサードサーチ
今回のまとめ
- EpochのAPIインタフェース（HTTP/REST）に対するテスト
- 行ったテスト：セキュリティツールによる自動スキャンとテスト、HTTPインタフェースに対する手動テスト、APIに対する手動テスト（不正なデータ型及びデータフォーマット、想定していないデータ値、SQLインジェクション、XSS）
- 強み：通常の攻撃に対する脆弱性はない、内部/外部外APIそれぞれの呼び出しに使うTCPポートが分かれている、内部APIを利用できるのはローカルホストだけである
- 弱み：数値以外のテキストに対する未定義の応答、負の数値に対する不正な応答、GETリクエストのエラー応答における情報喪失、バックスラッシュを伴うGETリクエストに対する予期せぬ応答、暗号化されていないHTTPの利用
- EpochのP2Pインタフェース（Noiseプロトコル）に対するテスト
- 行ったテスト：Noiseプロトコルに対する基本的なファジング
- 強み：著名なNoiseプロトコルの利用、適切な暗号セットNoise_XK_25519_ChaChaPoly_BLAKE2bの選択、著名な暗号ライブラリlibsodiumの利用
- 弱み：まだテストは残っているが現時点で発見された弱点はない
※以下、今回まとめた範囲の和訳になりますので詳細をご覧になりたい方は読み進めてください。
5. ノード（続き）
5.3 Epoch実装のテスト
ÆTERNITYが実装するリファレンスノードをEpochという。Epochはネットワークにつながる2つのインタフェースを持つ。ノードはNoiseプロトコルを使ってピアノードと接続する。ノードを運営しているユーザはHTTPを介してREST APIにアクセス可能だ。このREST APIを利用することでノードにブロックやトランザクション等に関する情報を求めることができる。ウォレットはネットワークの現在のステートに関する情報を入手するためにこのAPIを利用できる。
現時点ではこのAPIは何の追加機能（トランザクションの存在証明など）は実装されていない。現行の設定ではユーザは自身のノードをセットアップするか、完全に信頼するノードと協力する必要がある。
APIインタフェース（HTTP/REST）
HTTP/REST APIはErlangで書かれたCowboyウェブサーバを使って実装される。内外API機能向けに2つのTCPポートが用意されている（基本的に内部APIにはポート3113、外部APIにはポート3013）。
外部APIはネットワークを介して利用でき、公開されているブロックチェーンステートに関する情報、例えば最新のブロックや特定のトランザクションについての情報等を提供する。現行の実装ではTLSを使わないHTTPがデフォルトで有効になっている。内部APIはローカルホストからのみアクセス可能だ。
この領域では以下に示すテストが行われた。
- ウェブセキュリティツールを使った自動スキャンとテスト
- HTTPインタフェースに対する手動テスト
- APIに対する手動テスト
- 不正なデータ型及びデータフォーマット
- 想定していないデータ値
- SQLインジェクション
- クロスサイトスクリプティング（XSS）
強み
- このAPIは一般的な攻撃（SQLインジェクションやXSS）に対して脆弱ではない。
- 内部API呼び出しと外部API呼び出しが厳密に分離されている（TCPポートが異なる）。
- 内部APIは"ローカルホスト"だけが利用できる。
弱み
- サーバは数値でないテキスト入力に対して"400 - Bad Request"を返す。このレスポンスはswagger.jsonファイルに定義されていない。（Finding1）
- サーバは負の数値に対して"500 - Internal Server Error"を返す。これは全てのエラー条件が適切に処理されているわけではないことを示している。これは予期しないサーバの挙動を引き起こす可能性がある。（Finding2）
- SQLインジェクション脆弱性のテストのためにgetリクエストを送ると、サーバは通常"400 - Bad Request"を返す。サーバのレスポンスではクライアントに情報を送っている（"reason":"worng public key" for HTTP GET request on /v2/accounts/（"理由":/v2/accounts/に対するHTTP GETリクエストに用いる"公開鍵が間違っている"））。しかしいくつのリクエストについては、サーバはレスポンスに情報を全く含めない。（Finding3）
- URLのパラメータとして"＼（半角のバックスラッシュ）"を含む文字列をHTTP GETリクエストともに送信すると、サーバは予期しない応答をする。（Finding4）
- 標準の設定では暗号化されていないHTTPプロトコルを介してREST APIを利用できる。もしウォレットがこのプロトコルを使ってノードに接続すると、プライバシーに影響を及ぼす恐れがある。ネットワーク（パブリックWiFi）の攻撃者にはプライバシーが筒抜けであり、ウォレットの検索を行っている。また攻撃者が例えば偽りの残高を知らせるためにHTTPレスポンスを改変してしまう危険性がある。（Finding5）
P2Pインタフェース（Noise）
ノードは（暗号化された）Noiseプロトコルを使って他のノードと通信する。Noiseチャネル内部では比較的シンプルなカスタムゴシッププロトコルが使われている。ノードはゴシップメッセージを介してトランザクションやブロックヘッダなどをやりとりする。各ノードが全てのオブジェクトを集め、ローカルでオブジェクトをハッシュツリー内に対応付けることでブロックチェーン表現を構築する。ノードはトランザクションID（トランザクションのハッシュ）を参照することで特定のオブジェクト（1つのトランザクションなど）について他のノードに求めることができる。現時点で完全なローカルのブロックチェーン表現を同期するための複雑なプロトコルは使われていない。
Noiseインタフェースは2つの理由からとりわけ関心が高い。まず第一に、Noiseインタフェースを利用するノードは常にネットワークに曝されねばならない（オーナー自身のウォレットへのアクセスを制限する方法でこのAPIを限定するだろう）。第二に、未知の信頼していないピアとの接続がある。
cipher spec（鍵生成をするための擬似ランダム関数）として"Noise_XK_25519_ChaChaPoly_BLAKE2b"を選択した。cnlabは、これは適切であると考えている。
ErlangのNoise実装はÆTERNITYプロジェクトにより作られたものである点は重要であるので付け加えておく。これまでにErlangの実装は存在しなかったためである。全ての暗号操作は"libsodium"実装で実行され、"eNaCl（"Erlang NaCl"）"ラッパーを通じてアクセスされる。Daniel Bernsteinらが作成した"libsodium"ライブラリはシンプルなAPIを提供するという設計目標で知られている。モチベーションはチェックミスや不適切なパラメータ選択に起因するありふれたエラーを避けることにある。
この領域では以下に示すテストが行われた。
- Noiseプロトコルに対する基本的なファジング（筆者注：テスト手法の一つ）
次のテストは保留中である。
- Noiseプロトコルに対するより高度なファジング
- 暗号化されたNosieトンネル内部のアプリケーションプロトコルのファジング
強み
- トランポートセキュリティに（カスタムソリューションよりも）よく知られているNoiseプロトコルが利用されている。
- 適切な暗号セットが選択されている。
- 暗号操作に著名なライブラリが利用されている。
弱み
現時点でこの領域における弱点は見つかっていない。さらなるテストが行われる予定である点には留意されたい。
（ÆTERNITYのセキュリティ監査報告を読んでみる9 ←← 前）｜（次 →→ ÆTERNITYのセキュリティ監査報告を読んでみる11）
免責
邦訳には誤りがある場合がございます。予めご承知おき下さい。
確実な情報を知るためには冒頭に示した原文をご参照くださいますようお願いいたします。