hackneyでプライベートCAの固定が破られる脆弱性、修正版あり
Erlang・Elixir向けHTTPクライアントのhackneyに、プライベートCAだけを信頼する設定が効かなくなる脆弱性が見つかりました。該当するのは、ssl_optionsでcacertsかcacertfileを指定して社内CAなどに固定している利用です。hackney 4.9.0以降へ更新し、まず自社の依存関係に該当の設定があるかを洗い出してください。
急ぎ度: 早めに
CVSS v4は9.1と高い一方、悪用には通信経路上の位置と対象ホスト名の公的な証明書が必要で、影響が特定の設定に限られ、修正版4.9.0が出ています。
関係があるか
hackneyで、プライベートCA（社内CAなど）だけを信頼するようssl_optionsを設定している、ErlangやElixirのアプリケーションが対象です。hackneyを直接使う場合だけでなく、依存ライブラリ経由で使っている場合も、設定の渡し方しだいで該当します。
| 製品 | 影響を受ける版 | 直った版 |
|---|---|---|
| hackney（Hex） | 1.24.0以上4.9.0未満 | 4.9.0 |
| hackney（GitHubのソースを直接取り込んでいる場合） | コミットd8a9afcf5c3849904274e2eba1df56c63d1a1a0c以降、915eb5737e9c489d8fc22eec8cdae30e9b027be4より前 | コミット915eb5737e9c489d8fc22eec8cdae30e9b027be4以降 |
確かめ方
- 1ロックファイル（mix.lockやrebar.lock）でhackneyの版を確認し、1.24.0以上4.9.0未満なら次の手順に進みます。依存ライブラリ経由で入っているものも対象です。
- 2自社のコードと設定で、
ssl_optionsにcacertsまたはcacertfileを渡している箇所を探します。hackneyの設定を共通化している場合は、その設定モジュールも見てください。 - 3該当箇所に、自前の
partial_chainの指定があるかを見ます。指定がなければ影響を受けます。hackney標準のcertifiの信頼ストアをそのまま使っている接続は対象外です。
何が起きたか
hackneyでcacertsやcacertfileを指定してプライベートCAだけを信頼するようにしても、公的に信頼されるルート証明書につながる証明書チェーンを受け入れてしまいます。信頼先を絞ったつもりの接続で、その絞り込みが効いていません。
原因は、hackneyがTLS接続のすべてのverify_peer設定にpartial_chainのコールバックを加えていることです。このコールバックは、相手が送ってきた証明書チェーンのうち、公開鍵が同梱のcertifiストアのルートと一致する証明書を信頼の起点として返します。クロス署名されたルートで終わるチェーンを通すための仕組みです。
OTPは、設定されたcacertsより先にこのコールバックを参照します。ところがhackney_ssl:merge_ssl_opts/3が呼び出し側の設定を既定値に重ねるとき、cacertsやcacertfileは置き換わるのに、対応する指定のないpartial_chainは残りました。その結果、固定したはずのプライベートCAは検証に使われません。
ホスト名の検証は引き続き動くため、チェーンの受け入れだけが緩んでいる状態です。
攻撃の流れ
-
1
経路上に位置取り
攻撃者が、クライアントとプライベートCAに固定されたサーバーの通信経路の途中に入ります。
-
2
証明書チェーンを提示
対象ホスト名の公的な証明書を含み、公的なルートで終わるチェーンをクライアントに見せます。
-
3
検証をすり抜ける
hackneyのコールバックが公的ルートを信頼の起点とし、固定したプライベートCAは確認されません。
-
4
通信を盗み見・改ざん
サーバーになりすました攻撃者が、送受信される内容を読み、書き換えます。
どう悪用されるか
認証は要らず、利用者の操作も不要です。ただし、攻撃者はクライアントとサーバーの通信経路の途中にいる必要があります。さらに、固定先のホスト名に対して公的に信頼される証明書を持っていなければなりません。ホスト名の検証は生きているためです。CVSS v4の攻撃複雑度が高、攻撃要件が存在とされているのは、この前提によるものです。
条件がそろった場合、攻撃者はサーバーになりすまし、クライアントが送受信する内容を読み、書き換えられます。機密性と完全性への影響が高く、可用性への影響は示されていません。
今すぐやること
-
1
hackneyの版と該当設定を洗い出す
ロックファイルで版を確認し、
cacertsやcacertfileを渡している接続先を一覧にします。内部APIや取引先との接続など、固定が前提の通信を優先して見てください。grep hackney mix.lock -
2
hackneyを4.9.0以降に更新する
依存関係を更新して修正版に上げ、ロックファイルを反映したうえで再ビルドし、再デプロイします。ほかのライブラリ経由で古い版に固定されている場合は、そのライブラリ側の更新も確認します。
-
3
更新後にプライベートCAの固定を試験する
テスト環境で、固定先とは別のCAが発行した証明書を持つサーバーに接続し、接続が拒否されることを確認します。
-
4
更新できない系統は回避策を適用する
互換性の都合ですぐ上げられないアプリケーションには、下記の回避策を先に入れておきます。
すぐ更新できないとき
ssl_optionsにcacertsやcacertfileと並べて、自前の{partial_chain, Fun}を渡します。呼び出し側の指定はhackneyの既定値より優先して残るため、Funがunknown_caを返すようにしておけば、OTPは設定したcacertsだけで検証します。固定を使うすべての接続箇所に入れる必要があります。
背景
hackneyは、ErlangとElixirのアプリケーションが外部のHTTP APIを呼ぶときによく使うクライアントライブラリです。社内サービス間の通信や取引先との接続では、公的なCAを信頼せず、自前のCAだけを信頼する設定が選ばれることがあります。今回の脆弱性は、まさにその設定の守りを崩します。
問題のpartial_chainは、クロス署名されたルートで終わるチェーンを通すための、利便性を意図した既定の仕組みです。それが、呼び出し側が信頼先を絞る指定と並んで残ったため、絞り込みより優先されました。既定の振る舞いは、利用者が上書きした設定と衝突しないかを確かめないと、制限を無効にしかねません。今回の例はそのまま当てはまります。
よくある質問
Q.社内専用のホスト名にだけ接続している場合も、急いで直すべきですか。
Q.hackneyを使っている全アプリが修正の対象ですか。
cacertsやcacertfileで信頼先を絞り、自前のpartial_chainを指定していない接続だけが影響を受けます。hackney標準のcertifiの信頼ストアで動いている接続は対象外です。まだ分かっていないこと
- 実際の攻撃での悪用が確認されているか、また攻撃の兆候を検知する方法は、公表されていません。
- 4.9.0より前の系統（2.xや3.xなど）にも修正が提供されるかは、公表されていません。最新の状況はhackneyのリリースページ（https://github.com/benoitc/hackney/releases/tag/4.9.0）で確認してください。
この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。
影響パッケージ
| 種類 | パッケージ | 影響を受ける版 | 直った版 |
|---|---|---|---|
| benoitc | hackney |
d8a9afcf5c3849904274e2eba1df56c63d1a1a0c 以上 915eb5737e9c489d8fc22eec8cdae30e9b027be4 未満 |
915eb5737e9c489d8fc22eec8cdae30e9b027be4 |
| Hex | hackney |
1.24.0 以上 4.9.0 未満 |
4.9.0 |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Improper Certificate Validation vulnerability in hackney_ssl in benoitc hackney allows an on-path attacker to impersonate a server pinned to a private certificate authority via a certificate chain that ends in a publicly trusted root. hackney adds {partial_chain, fun hackney_ssl:partial_chain/1} to every verify_peer configuration. The callback returns any certificate in the peer chain whose public key matches a root in the bundled certifi store as the trust anchor, and OTP honours that callback over the configured cacerts. hackney_ssl:merge_ssl_opts/3 kept the callback when the caller replaced the trust store with cacerts or cacertfile in ssl_options, so a connection pinned to a private CA still accepted any chain that carried a publicly trusted root.
The hostname check still applies, so the attacker needs a publicly trusted certificate for the pinned hostname.
This issue affects hackney: from 1.24.0 before 4.9.0.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- package hex.pm
- web github.com
- web cna.erlef.org
- web osv.dev
- web github.com
- web github.com
- web github.com
- web nvd.nist.gov
- web github.com