(失敗した)CT LogのSANが大量に結びついた証明書を見つけてフィッシングサイトを検知する方法
年末にツイッターに書いたけど、特に記事にしていなかったので供養として一応記事に書いてみます。
CT Log の SAN が異常に多い CT Log は9割 Malicious なんじゃないか?と思って今 CT Log Streaming しながらフィルタかけてみてるけど普通のやつがかかりまくってきて推測が外れた。
— もつに (@akroasis5150) 2022年12月23日
失敗した内容ではあるんですが、おそらくこの観点で調査してる人が国内にいないだろうし、 (多少関連する内容について記載するので) ほんの少しは需要があると思って記載しておきます。
一応以下のやつを考慮に入れて検知を考えたけど失敗したって話です。
- censys で SAN の数を元にした検索(検索がそもそもできない)
- crt.sh で、 SAN の数を元にした検索 (検索がそもそもできない)
- crt.sh が公開している PostgreSQL にアクセスして SAN の数を元に検索する方法(試してすらいない。大変。)
- Certstream を使って SAN の数を元にフィルタする方法(最終的に実施して、このアプローチ自体が失敗したやつ)
CT Log / SAN について
CT Log の説明については、大変わかりやすいこちらの資料を参照ください。
https://www.jnsa.org/seminar/pki-day/2016/data/1-2_oosumi.pdf
SAN は、 Subject Alternative Name の略で、証明書のフィールドとして定義されています。
この SAN ですが、複数個のドメインを関連付けることが可能で、関連づけられたドメインでは、対象の証明書を利用することが可能になります。
(すごく乱雑に言うと)SANにドメインをいっぱい登録すれば、それらのドメインに対して、一つの証明書を使いまわすことが可能で、楽ちんと言うわけです。
参考: jprs.jp
今回の検知アプローチについて
さて、先ほどすごく乱雑に以下のような説明をしました。
(すごく乱雑に言うと)SANにドメインをいっぱい登録すれば、それらのドメインに対して、一つの証明書を使いまわすことが可能と言うわけです。
この説明ですが、実際(一部の)フィッシングアクターは、この SAN を利用して、フィッシングサイトを運営していたりします。
例えば以下の証明書ログを見てみると、 SAN が複数あります。
(メルカリの Phishing サイトで利用された証明書ログ)
この大量の SAN を見ていた時にあるときあるアイデアが出てきました。
それは「SAN がいっぱい紐づいている証明書は高確率でフィッシングサイトなのでは?」と言うアイデアです。
そこで、 SAN の数を元にした検索をして、フィッシングサイトを検知できないかと言うのを試してみた と言うのが今回の記事になります。
手法の検討
冒頭書いた通り、以下のアプローチについて検討し、失敗したり、実験したりしました。
- censys で SAN の数を元にした検索(検索がそもそもできない)
- crt.sh で、 SAN の数を元にした検索 (検索がそもそもできない)
- crt.sh が公開している PostgreSQL にアクセスして SAN の数を元に検索する方法(試してすらいない。大変。)
- Certstream を使って SAN の数を元にフィルタする方法(最終的に実施して、このアプローチ自体が失敗したやつ)
それぞれのアプローチについて簡単にではありますが、書いてみます。
Censys で SAN の数を検索
以下に Censys で検索できる項目等がまとまっています。
ただ、調べたところ SAN の数で検索するのはできなさそうに見えたので諦めました。
次!
crt.sh で、 SAN の数を元にした検索
これも残念ながら検索する方法がなさそうだったので諦めました。
次!
crt.sh が公開している PostgreSQL にアクセスして SAN の数を元に検索
そもそも crt.sh が PostgreSQL を公開していると言うのを知っている人がめちゃくちゃ少ない気がするのでせっかくですし紹介しておきます。
If you have the PostgreSQL client software installed, you can login as follows: $ psql -h crt.sh -p 5432 -U guest certwatch
SQL が書けるならこれでいけるじゃん! って思われる方もいますが、タイムアウト制限が強めだったり、 生成されるレコード数の多さから、脳死で SQL を書くと SlowQuery としてタイムアウトされて終わります。
なので軽い検証程度にやるには大変そうだったのでやりませんでした。
次!
Certstream を使って SAN の数を元にフィルタする方法
Certstream は、CT Log の更新をリアルタイムでストリーム的に取得できるライブラリです。
Python や JS, Go, Java のライブラリ(ラッパー)が用意されているので、容易に CT Log を使った実験ができます。
※CT Log でセンサーを作ろうとされているかたがいる場合は、この辺りの Issue とかも参照しておおくと良いかもしれません。永続的な接続に関する課題について
Censys や crt.sh では検索ができなさそうでしたが、今回の簡易リサーチであれば、 Certstream でいけそうです。 と言うことで、 SAN の数が 20, 30, 40 といっぱい紐づいている証明書ログを洗い出し、そのドメインにアクセスしてみて、フィッシングサイトが検知できないか試してみましょう!
実験の結果
結果は・・・失敗でした!
検知されるドメインの多くはフィッシングサイトではなく、普通のサイトや、ドメインレジストラが売却用のドメインの更新を一括で行うために申請した証明書ログ(ドメイン)ばかりでした。
また、30m 程度の監視ではフィッシングサイトは引っかかりませんでした。
SAN の数も 20 程度だと引っかかる CT Log が多くなりすぎますし、30, 40 程度にしても 今度は Phishing サイトが SAN をそこまでいっぱい紐づけているケースが(体感)少ないので、検知できず と言う感じで、いい塩梅にするのは大変そうと言う印象です。
20 程度に抑えつつ、毎秒 1-2件程度のアクセス / フィッシングサイトの評価を自動でするプログラムを作れば、 多少は検知できるかもしれませんが、結構大変な気がしています。
終わりに
Phishing サイトの検知は長く険しい