TLS フィンガープリントの現状 : メリットと課題、今後の方向性について

Fastly Security Research Team

Fastly Security Research Team, Fastly

Xavier Stevens

Staff Security Researcher, Fastly

2022年7月20日

セキュリティ

概要

TLS フィンガープリントは、サーバーインフラと通信しているクライアントをセキュリティの防御側が特定するツールとして、広く使われるようになりました。この着想は当初、Lee Brotherston 氏が2015年に発表した研究から生まれ、彼のブログ投稿や Derbycon での講演でその内容が紹介されました。同氏は個々のクライアント (およびサーバー) による TLS ネゴシエーションの方法には十分な違いがあり、それらを区別することは可能であると説明しました。それ以降、こうした発想の実現を目指してさまざまなメソッドやプロトコル対応が登場しました。

このブログ記事では、3つのフィンガープリントのメソッドと、各アプローチに関するインサイトや注意事項を紹介します。

JA3 という先駆者

2017年に John Althouse 氏、Jeff Atkinson 氏、Josh Atkins 氏の3人の Salesforce 研究者が、JA3 と呼ばれる TLS フィンガープリントの新たな受動的メソッドを発表しました。JA3 は TLS クライアントのフィンガープリントに、JA3S はサーバーのフィンガープリントにそれぞれ使用されます。この方法はマルウェアのクライアントやサーバーだけでなく、Web API のクライアントとブラウザの特定にも役立つことがわかりました。

JA3 フィンガープリントを計算するために、TLS Client Hello パケットを受信または観測し、TLS のバージョン、受け入れられた暗号、拡張リスト、サポートされるグループや楕円曲線フォーマットを抽出できます。抽出プロセスは非常にシンプルです。これらのフィールドのバイトの10進値を取得し、メソッドの仕様に従ってそれらを連結します。

JA3 のフィンガープリントとハッシュの例

このフィンガープリントは、JA3 文字列と呼ばれることもあります。共有とサイズの縮小が簡単に行えるように、JA3 実装ではこのフィンガープリントの MD5 ハッシュを計算します。これは他者との共有を容易にし、データベースで検索しやすくするためのコンパクトな形式です。

JA3S も同様のプロセスを使用します。Client Hello の代わりに Server Hello パケットを利用して、TLS のバージョンや暗号、拡張を抽出します。特筆すべきは、Server Hello が Client Hello に応じて変化する点です。つまり Client フィンガープリントと同等の一意性は提供しませんが、JA3 クライアントハッシュと合わせて利用することで有用性が向上します。

JA3 は、ブラウザのユーザーエージェントと特性が似た部分があります。JA3 チームのブログ記事で指摘されている通り、誤検知が生まれる可能性があります。これはクライアントが同じハッシュ値を取得するほど似た動きを見せたり、あるいは意図的に偽ったりした場合に起こりえます。攻撃者とボット開発者はどちらもフィンガープリントについて把握しているので、検出を避けるために「正しい」クライアントの TLS ネゴシエーションを模倣しようとする場合があります。しかし、JA3 を使用したコントロール機能を欺くために色々なプロセスが必要になるので、攻撃者にとってはコストが増大することになります。

JA3 の公開データベース : 利便性と注意点

チームや組織の間で事実上の標準となるフィンガープリントを共有できると、検出のエンジニアリングや脅威の調査の分野でさまざまなメリットが生まれます。JA3 は近年、数多くのプラットフォームやサービスで十分にサポートされています。よく参照されるサービスとデータベースは ja3er.com です。

しかしこれらのデータベースは完璧とはいえません。2021年10月に Fastly の SOC チームは、ja3er と、JA3 フィンガープリントを計算する目的で開発した内部実装の間で不一致を特定しました。入念な調査の後に、TLS Application-Layer Protocol Settings Extension (IANA には未登録ですが、Google の BoringSSL 実装には含まれています) の処理に問題の原因があると特定しました。ja3er サービスでこの拡張の値が使用されないことで、無効なフィンガープリントがシステム内で計算されることになります。

異なるツールセット間でフィンガープリントの計算に不一致があると、組織間でフィンガープリントを共有する意味が失われます。Fastly は、この問題がどこまで広がる可能性があるかを把握するために、不一致を生み出すパラメーターが他に存在するかどうかを特定する実験をセットアップしました。具体的には、TLS ネゴシエーションの際に送信するパラメーターを正確にコントロールする uTLS を使用して、カスタムクライアントを実装したのです。そして、そのクライアントから ja3er と Fastly サーバーの両方に Client Hello パケットを送信して結果を比較しました。その結果、ハッシュの不一致が再び発生したことを確認しました。

Wireshark を使用して、その出力が私たちの出力と一致し、両方のフィールド値が正しいことを確認できました。Fastly のシステムからの完全な JA3 フィンガープリントと、ja3er の出力を比較した際、単一の楕円曲線である x448 が不一致の原因であることを特定しました。このフィールドは、IANA レジストリ では「30」の10進数の値で表されています。一方、理由は不明ですが、ja3er ではこのフィールドに対して「1035」の10進数の値が使用されます。

JA3 差分スクリプトからの出力

この調査結果が判明して間もなく、Fastly は GitHub の公式 JA3 レポジトリを調べました。その際、別のユーザーも昨年10月に不一致を発見していたことがわかりました。GitHub はすでに問題を報告し、そのユーザーに連絡を何度も試みましたが、返信は無かったようです。

本記事を執筆している時点でも、この問題は解決されていません。そのためセキュリティ担当者の方は、ja3er のサービスやデータベースの結果を利用しないよう強くお勧めします。

残念ながら、お勧めできる代替方法は今のところありません。Abuse.ch には JA3フィンガープリントのデータベースがありますが、主にマルウェアクライアントを対象としています。また、オリジナルの JA3 リポジトリには参照リストがありますが、数年間更新されておらず、情報も包括的ではありません。サードパーティのリポジトリが利用できない場合、ご自身のユースケース向けに独自のリポジトリを作成した方がよいかもしれません。

改善されたサーバーフィンガープリント : JARM

2020年11月、John Althouse 氏は Andrew Smart 氏、RJ Nunnally 氏、Mike Brady 氏らと共に、JARM というサーバー TLS フィンガープリントのための新たなメソッドを発表しました。JARM はサーバーをスキャン、識別する目的に使用され、JA3S よりも多くの一意性を提供できます。また、受動的な観測を利用する JA3S とは異なり、サーバーから情報を得るために能動的なスキャンを実行します。JARM は特別に設計された10個の TLS Client Hello パケットを送信し、そのレスポンスの特定の属性に基づいてハッシュを実行します。このメソッドではスキャンを実行するため、JARM はインターネットの大部分をプロアクティブにフィンガープリントすることができます。こうしたスキャン機能は業界で広く導入され、現在さまざまなツールやサービスでサポートされています。

JARM フィンガープリントの例

JA3 や JA3S と同様に、防御者は JARM ハッシュだけに依存しないように注意が必要です。例えば Cobalt Strike の JARM フィンガープリントは、実際には Java の JARM フィンガープリントです。つまり組織は、悪意のある Cobalt Strike インストールのフィンガープリントを利用して接続をブロックしようとして、悪意のない他の Java ソフトウェアもブロックしてしまう可能性があるということです。このトピックに関しては、Raphael Mudge 氏が秀逸な記事を発表しています。特に Cobalt Strike サーバーを見つけようとしている場合は、悪意のあるサーバーに遭遇したことを確認するためにさらに調査を行うか、少なくてもその確証が持てるようにする必要があります。

CYU という新技術

JA3 の発表から数年後、QUIC プロトコルの採用が急速に広がりました。しかしその結果、目の届かない部分が発生し、これらの接続に対して同様にフィンガープリントを受動的に取得する必要性が生じました。Caleb Yu 氏は、参加していた Salesforce のインターンシップの一環として、CYU ハッシュというソリューションを提案しました。現時点で、CYU は JA3 ほどは一般的ではありません (Zeek や Suricata など、人気のあるツールの一部で実装されているケースはあります)。しかし HTTP/3 が新たなスタンダートとなった現在、CYU や同様のメソッドの採用が広がると考えられます。

Yu 氏と Althouse 氏が発表した取り組みには、QUIC を使用した単一の攻撃ツールの例である C2 フレームワークの「Merlin」に関するものが含まれます。多くの標準的な Web クライアントで QUIC のサポートが実装されていることを考えると (Web ブラウザや curl を含む)、Merlin の使用が今後さらに拡大することが予想されます。

今後の方向性

John Althouse 氏と彼のチームは過去数年間、暗号化を伴うフィンガープリント技術の推進において中心的な役割を担ってきました。彼らによるこれまでの素晴らしい功績とその努力は称賛に値します。今後は、こうしたソリューションが抱える課題の解決を目指してより多くの人たちがコミュニティに参加し、そこから多くの成果が生まれるでしょう。こうした取り組みは、完全な標準化のレベルまで到達する必要はありません。ただし、さまざまな入力に対して、それぞれ異なる実装でも正しい結果が得られるようにするためには、仕様書や共通のテストスイートの存在が役立ちます。

私たちはセキュリティを担当される方々に対して、フィンガープリントを悪意のあるクライアントとサーバーを特定・追跡するツールのひとつとして検討することをお勧めします。特定されたフィンガープリントを他のチームとも共有することで、インターネット上の悪意と闘うすべての人たちがより高い検出能力を得ることが可能になります。ただし、データを共有しているチーム全員が、使用しているツールのフィンガープリント出力を検証しているか、少なくてもフィンガープリントの生成に共通のツールを利用していることを必ず確認してください。フィンガープリント出力への信頼性がなければ、それらの情報を共有しても期待できる結果を得られない場合があるからです。

Fastly のプラットフォームで JA3 ハッシュを使用したい場合は、VCL や Compute のライブラリからアクセスできます。