はじめに
こちらの最近話題になった記事に対して、どうしても「単なるIP攻撃では？」という疑念が湧いてしまい、自分で検証するかと思って調査を進めていると、既にかなり詳細の調査を行っている論文を見つけることができましたのでご紹介です。
背景
インターネット上では常時、
- masscan
- zmap
- Shodan系スキャン
- ASN sweep
- IPv4全域スキャン
などが大量に行われています。
そのため、
「公開直後にアクセスが来た」
という事実だけでは、
- CT Log監視
- IPv4全域スキャン
- ASN sweep
- ランダムヒット
などを区別できません。
特に、
「CT Log が原因」
と説明されるケースでも、
- Hostヘッダー
- SNI
- IPv4スキャンとの差別化
などが十分に整理されていないケースが多く、個人的には以前から少し懐疑的でした。
そこで、過去の研究論文や文献を調査してみたところ、USENIX Security 2022 にかなり興味深い論文が存在していました。
概要
今回読んだ論文は、USENIX Security 2022 で発表された以下のものです。
Uninvited Guests: Analyzing the Identity and Behavior of Certificate Transparency Bots
本論文記事
この論文では、Certificate Transparency Log を監視しているBotの存在を実験的に検証しています。
USENIX Security は、コンピュータセキュリティ分野におけるトップクラスの国際学会の一つであり、査読付きの研究論文が発表されるカンファレンスです。
特に重要なのは、「公開直後にアクセスが来た」という観測ではなく、
- ランダムな未公開FQDNを生成
- CT Logにのみ露出
- timing correlation を分析
- 通常のIPv4スキャンBotとの差異を分析
という形で、かなり慎重に実験設計されている点です。
論文では以下のような規模で観測が行われています。
- 4,657 certificates
- 10週間
- 約150万リクエスト
- 約3万IPアドレス
そして結論として、
CT Log を監視して新規FQDNへ即アクセスするBot群は実在する
ことをかなり強く示しています。
内容
CT Log とは何か
Certificate Transparency は、HTTPS証明書の不正発行を検知するための公開監査システムです。
HTTPS証明書が発行されると、その情報はCT Logへ登録されます。
つまり、
証明書発行
↓
CT Logへ登録
↓
誰でも取得可能
という流れになります。
本来の目的は、
- 不正CAによる証明書発行
- 国家レベルのMITM
- 誤発行
などを検知することです。
しかし副作用として、
「新しくTLS化された公開FQDN一覧」
としても利用可能になっています。
論文が重要な理由
インターネット上では常時、
- masscan
- zmap
- Shodan系スキャン
- ASN sweep
- IPv4全域スキャン
などが大量に行われています。
そのため、
「公開直後にアクセスが来た」
だけでは、
- CT Log起点
- 単なるIPスキャン
- ランダムヒット
を区別できません。
ここが従来の記事で曖昧になりやすい部分です。
この論文では、その点をかなり意識しています。
どうやってCT起点だと検証したのか
論文では、推測不可能なランダムFQDNを大量生成しています。
例えば以下のようなイメージです。
x8f2-example.com
k2j7-example.com
これらは、
- 新規作成
- 未公開
- 検索エンジン未登録
- GitHub等にも未掲載
- wordlist非該当
という条件です。
つまり、
CT Logを見ていない限り、発見が極めて困難
な状態を意図的に作っています。
その上で、
証明書発行
↓
CT Log登録
↓
数十秒〜数分でBotアクセス
を観測しています。
さらに論文では、
CT Bot と通常のhost-scanning bot の overlap は 2% 未満
と分析しています。
これは非常に重要です。
つまり、
- IPv4スキャンBot群
- CT Log監視Bot群
は、かなり別集団である可能性が高いということです。
結論
今回の論文から読み取れる重要なポイントは、以下の通りです。
- CT Log を監視しているBot群は実在する
- 単なるIPv4全域スキャンだけでは説明しづらい
- ランダムかつ未公開なFQDNでも短時間でアクセスが発生する
- CT Bot と通常のIPv4スキャンBotは別集団である可能性が高い
- 「公開直後にアクセスが来た」だけではCT起点とは断定できない
特に重要なのは、
「CT Log監視Botは存在する」
と
「自分が観測したアクセスがCT起点である」
は別問題である点です。
そのため、
- Hostヘッダー
- SNI
- IPv4スキャンとの差別化
などを考慮した上で分析する必要があります。
私が以前から懐疑的だった点
以前から私は、
「CT Logを見てBotが来る」
という説明に対して少し懐疑的でした。
理由は主に以下です。
Hostヘッダーを見ているのか
本当にFQDN targetingなのかを判断するには、
Host: example.com
を確認する必要があります。
単なるIPスキャンであれば、
Host: 203.x.x.x
のようなアクセスもあり得ます。
またHTTPSでは、Hostヘッダー以前にSNIも重要です。
つまり、
本当にFQDNを認識してアクセスしていたのか
を確認する必要があります。
IPv4スキャンとの差別化
インターネットでは常時大量のIPv4スキャンが存在します。
そのため、
「公開直後にアクセスが来た」
だけではCT Log起点の証明にはなりません。
この点について、今回の論文はかなり丁寧に実験設計していると感じました。
終わりに
今回の論文を読んで感じたのは、
「CT Log監視Botは実在する」
という点については、かなり強いエビデンスがあるということです。
一方で、
「自分が観測したアクセスが本当にCT起点なのか」
は別問題です。
特に、
- Hostヘッダー
- SNI
- IPv4スキャンとの差別化
を考慮せずに、
「CT Logが原因」
と断定するのは少し危険だと感じています。
一言
今回の記事を書くきっかけとなった論文著者の Yusuke Kawabata 様にも感謝致します。
この記事を読んだことで、「本当にCT Log起点なのか」という点が気になり、過去の研究論文や文献を調査する流れとなりました。
もしこの記事が気に入って頂けたらここでのいいね＆フォローとX( @___nix___ )でのフォローもお願い致します。
参考
-
Uninvited Guests: Analyzing the Identity and Behavior of Certificate Transparency Bots
https://www.usenix.org/system/files/sec22-kondracki.pdf -
USENIX Security 2022
https://www.usenix.org/conference/usenixsecurity22/presentation/kondracki -
Certificate Transparency
https://certificate.transparency.dev/ -
crt.sh
https://crt.sh/ -
When Certificate Transparency Is Too Transparent: Analyzing Information Leakage in HTTPS Domain Names
https://www.researchgate.net/publication/337175410_When_Certificate_Transparency_Is_Too_Transparent_Analyzing_Information_Leakage_in_HTTPS_Domain_Names