ÆTERNITYのセキュリティ監査報告を読んでみる13(終)

本稿について

ÆTERNITYのメインネットリリース前から行われているセキュリティ監査報告のv0.5について見ていきます。今回の範囲は「7. Findings」です。

原文はこちらになります

スポンサードサーチ

今回のまとめ

• 本文にて十分に整理されているため、本文を確認のこと。
• なお、調査結果の初出はそれぞれÆTERNITYのセキュリティ監査報告を読んでみる10（調査結果No.1～5）、11（調査結果No.6）、12（調査結果No.101、103）であり、こちらに監査対象の仕様なども書かれているため必要に応じて参照されたい。

※以下、今回まとめた範囲の和訳になりますので詳細をご覧になりたい方は読み進めてください。

7. 調査結果

7.1 概観

本章ではアセスメント結果を一覧で示す。調査結果は紐づくリスクに従って分類する。

高リスクに分類されたものは可及的速やかに取り除く必要がある。

中リスクに分類されたものは対処する必要があるが、時期はあまり重視されない。

低リスクに分類されたものは改善の余地があることを示すが、セキュアなシステムにするために修正する必要があるわけではない。

7.2 調査結果詳細

• No.1
  • 領域：REST API：定義されていないレスポンス
  • 見解：2018/10/15。/key-blocks/height/{height}に対するHTTP GETリクエスト。サーバは数値でないテキスト入力に対して"400 - Bad Request"を返す。このレスポンスはswagger.jsonファイルに定義されていない。
  • リスク：低リスク；クライアントによる予期せぬ挙動。
  • コメント：特になし（空欄）
  • 推奨：あらゆるケースに関するエラーを定義する。
• No.2
  • 領域：REST API：内部サーバエラー
  • 見解：2018/10/15。/key-blocks/height/{height}に対するHTTP GETリクエスト。サーバは負の数値に対して"500 - Internal Server Error"を返す。これは全てのエラー状態が適切に処理されているわけではないことを示している。これは予期しないサーバの挙動を引き起こす可能性がある。
  • リスク：中リスク；予期せぬノードの挙動。重要なエラーメッセージの欠如によるセキュリティに関わる未発見の状態。
  • コメント：特になし（空欄）
  • 推奨：全てのエラー状態に関してエラーハンドリングを実装する。
• No.3
  • 領域：REST API：サーバからの応答における情報の喪失
  • 見解：2018/10/15。SQLインジェクション脆弱性のテストのためにgetリクエストを送ると、サーバは通常"400 - Bad Request"を返す。サーバのレスポンスではクライアントに情報を送っている（"reason":"worng public key" for HTTP GET request on /v2/accounts/（"理由":/v2/accounts/に対するHTTP GETリクエストに用いる"公開鍵が間違っている"））。しかしいくつのリクエストについては、サーバはレスポンスに情報を全く含めない。
    例えば、以下のようなレスポンスが返ってくる。
    - /v2/accounts/'%20or%20username%20like%20'%
    - /v2/key-blocks/height/'%20or%20uid%20like%20'%
    テストは以下のパスに関して行った。
    - /v2/coounts/
    -/v2/key-blocks/height
  • リスク：低リスク；不完全なエラーメッセージによる未知のセキュリティに関わるエラー。
  • コメント：特になし（空欄）
  • 推奨：一貫しているエラーメッセージを実装する。
• No.4
  • 領域：REST API：矛盾しているサーバの応答
  • 見解：2018/10/17。URLのパラメータとして文字列を持つHTTP GETリクエストを例えば以下に送信するとして、
    - /v2/coounts/
    -/v2/key-blocks/height
    "＼（半角のバックスラッシュ）"を含んでいる場合、サーバは次のような応答をする。
    > HTTP/1.1 404 Not Found
    > connection: close
    > content-length: 0
    > date: Wed, 17 Oct 2018 13:32:45 GMT
    > server: Cowboy
    その他全ての無効な文字列については、レスポンスは次のようになる。
    >HTTP/1.1 400 Bad Request
    > connection: close
    > content-length: 31
    > content-type: application/json
    > date: Wed, 17 Oct 2018 13:34:03 GMT
    > server: Cowboy
    >
    > {"reason":"Invalid public key"}
  • リスク：低リスク；不完全なエラーハンドリングによる未知のセキュリティに関わる問題。
  • コメント：特になし（空欄）
  • 推奨：矛盾のないエラーハンドリングを実装する。
• No.5
  • 領域：REST API：暗号化されていないAPIアクセス
  • 見解：2018/10/24。標準の設定では暗号化されていないHTTPプロトコルを介してREST APIを利用できる。もしウォレットがこのプロトコルを使ってノードに接続すると、プライバシーに影響を及ぼす恐れがある。ネットワーク（パブリックWiFi）の攻撃者にはプライバシーが筒抜けであり、ウォレットの検索を行っている。また攻撃者が例えば偽りの残高を知らせるためにHTTPレスポンスを改変してしまう危険性がある。
  • リスク：中リスク；プライベートな情報への不正アクセス、データの不正な改変。
  • コメント：プロジェクトによりHTTPSプロキシをセットアップすることが推奨されているため、リスクは単に"中"とする。
  • 推奨：標準のプロトコルとしてHTTPSを利用する。
• No.6
  • 領域：Epoch：ディスクにおける鍵の保護不足
  • 見解：2018/10/24。現時点で個別のパスワードを使って鍵（ピア鍵と署名鍵の両方）を保護するという選択肢がノードの運営者にない。
  • リスク：中リスク；鍵への不正アクセス。
  • コメント：現在の設定ででノードの鍵の重要性は限られていることからリスクは単に"中"とする。
  • 推奨：パスワードで鍵を暗号化するという選択肢を用意する。これはノードの立ち上げにパスワードを求めるようにすることで実装可能と思われる。
• No.101
  • 領域：ベースウォレット：弱点のあるキーストレージ
  • 見解：2018/11/13。ベースアプリではウォレットの鍵はユーザのパスワードに由来する鍵で暗号化されている。パスワードについて強制される最低限の要件がない。このベースアプリはPWA（プログレッシブウェブアプリ）であるので、追加的な保護（ハードウェアキーストアなど）は用いられていない。攻撃者が単純なパスワードでブルートフォースアタックを行う危険性がある。
  • リスク：中リスク；資金への不正アクセス。
  • コメント：ベースウォレットは小額の資金についてのみの利用が推奨されていること、ユーザは強いパスワードを選ぶことができることからリスクは単に"中"とする。
  • 推奨：オフラインのブルートフォースアタックから保護するのに十分なパスワードの長さを必須とする。
• No.102
  • 領域：ベースウォレット：暗号ストリームの安全でない再利用
  • 見解：2018/11/13。ベースウォレットはHDウォレット（階層的決定性ウォレット）の仕様に従って決定論的に鍵を生成するために秘密鍵とチェーンコードを用いる。ウォレットの秘密鍵とチェーンコードのストレージに関して、AES-CTRモードでの暗号化が利用されている。現行の実装では2つのデータフィールドの暗号化に同じカウンタが用いられている。この結果、攻撃者は鍵を知らなくても次の計算により秘密鍵を復号できてしまう。
    privkey = chaincode XOR encPrivkey XOR encChaincode
    HDウォレットの仕様によるとチェーンコードは公になっている情報と考えられる。
    2018/11/16。異なるカウンタを利用するように実装が変更された。従ってこの問題は解決した。
  • リスク：解決済み；資金への不正アクセス。
  • コメント：特になし（空欄）
  • 推奨：それぞれのデータセットに異なるカウンタを利用する実装となっていることを確認する。
• No.103
  • 領域：ベースウォレット：認証されていない暗号モード
  • 見解：2018/11/19。このベースウォレットはAES-CTRモードを使って秘密のデータを保存している。このモードはストリーム暗号と似た特性を持つ。データについてMACは計算されないので、攻撃者は（鍵について何も知らなくても）単に暗号文に改変するための文字列をXOR演算するだけで選択的にデータを変更できてしまう。
  • リスク：低リスク；暗号データの不正な改変。
  • コメント：この手法で保存されるのはランダムな鍵だけであるのでリスクは"低"と考えられる。構造化データが同じ手法で暗号化された場合は問題である点を付記しておく。
  • 推奨：データの改変を検出するため、データの暗号化に関してMACを使うか権限付きのモードのオペレーションを利用する。

（ÆTERNITYのセキュリティ監査報告を読んでみる12　←←　前）｜（最初に戻る　→→　ÆTERNITYのセキュリティ監査報告を読んでみる1）

免責

邦訳には誤りがある場合がございます。予めご承知おき下さい。

確実な情報を知るためには冒頭に示した原文をご参照くださいますようお願いいたします。