その証明書、安全ですか？
2023年01月25日 水曜日
CONTENTS
はじめに
いまやWebサイトはすっかりHTTPSが常識になりました。ほんの数年ほど前は「常時SSL」というキーワードをよく目にしましたが、それが実現した今となってはまったく見なくなりました。
平文のHTTPが安全でないのはわかるとして、HTTPSならばほんとうに安全なのでしょうか。
事例1: MyEtherWallet
2018年4月、MyEtherWalletという仮想通貨事業者の権威DNSサーバへの経路がBGPハイジャックされました。myetherwallet.comのDNS問い合わせに対して、偽の権威DNSサーバが偽のWebサーバにアクセスさせるような応答を返し、結果として、偽MyEtherWalletにアクセスすることになったユーザから15万ドル相当の仮想通貨が奪われました。
ユーザが誘導された偽のWebサイトはHTTPSで動いていましたが、いわゆるオレオレ証明書が使われており、ブラウザは証明書エラーの警告を出していたようです。そのため、被害にあったのはブラウザの警告を無視してアクセスしてしまった、いわば「うかつな」ユーザだけだったようです。
偽サイトにアクセスしてしまってもちゃんと検知、警告されたこの事例は、TLSの有用性を示す典型的な例といってもいいでしょう。
証明書の発行手続きの安全性
TLSの目的は「通信を解読されないようにする」ことではありません。「特定の相手以外に通信を解読されないようにすること」です。「特定の相手」というのが極めて重要です。間違った相手を本物と思いこんで通信したら、その間違った相手に対して機密を漏曳することになってしまいます。暗号通信をおこなう前には、相手が間違いなく本物であることを保証するための手続きが必須です。
相手が本物であることを確認するために絶対にやってはいけないのが、「自称」をそのまま信用することです。夜の飲み屋街でふらふらしてるおっさんの「だーいじょーぶ俺酔ってなーいから」という言葉を信用する人なんかいませんよね。それと同じです。いわゆるオレオレ証明書がよろしくないのは、まさに「自称」だからです。
ではどうするかというと、信頼できる第三者(Trusted Third Party; TTP)によって「たしかに間違いない」というお墨つきを与えてもらい、そしてそのお墨つきが偽造されたり改竄されたりしていないことを検証するのです。「消防署の方から来ました」という怪しい人が自宅に訪問してきたら、行政機関(TTP)が発行した身分証明書を提示してもらって、ほんとに消防署の人なのか、ただ消防署のある方角から来ただけの人なのかを判断するということですね。TLS(PKI)では認証局(CA)がTTPにあたります。事例1のケースは、認証局により正規に発行されたものでない証明書を使っていたために、ブラウザが警告したものです。
Web PKIでは、証明書を発行する前にドメイン認証のため認証局から該当サイトへのアクセスがおこなわれます。しかし、事例1では経路ハイジャックによりユーザからのアクセスが偽サーバに誘導されています。そして経路ハイジャックされているならば、ドメイン認証する認証局からのアクセスもまた、同じように偽サーバに誘導されると想定するべきでしょう。
ドメイン認証のためのアクセスは平文のHTTPやDNSなどが使われるため、なりすましで偽サーバに誘導されてしまっても、認証局がそれを検知できるとはかぎりません。つまり、なりすましに成功している場合、攻撃者は認証局を欺いて正規の証明書を誤発行させることもできる可能性が高いのです。
そうして発行させた正規の証明書を偽サイトに設置していれば、そこにアクセスしてもブラウザは警告を出すことはなく、「うかつ」でないユーザを信じさせることもできるでしょう。「TLSがあればなりすましされていても検知することができる」というのはかならずしも間違いではありませんが、これが正しいと言えるのは「認証局に対してはなりすましていなかった場合」という条件つきでしかありません。事例1はTLSが役に立った典型例ですが、攻撃者が認証局をも騙していれば、TLSが役に立たなかった典型例にもなったかもしれない危険なケースだったのです。
証明書の発行に数日ほどかかっていた数年前までと異なり、いまやLet’s Encryptをはじめ多数の認証局で証明書の発行手続きが自動化され、発行には数分もかかりません。攻撃者はほんのわずかな時間だけでもなりすますことができれば、正規の証明書を入手して偽サイトに設置し、ユーザを騙すには十分です。
そして、これは「理屈の上ではありうる」といった話ではありません。残念ながら、実例があります。
事例2: Celer Bridge
2022年8月、Celer Bridgeという仮想通貨事業者のサーバへの経路がハイジャックされました。事例1では権威DNSサーバへの経路がハイジャックされましたが、この事例ではWebサーバへの経路が直接ハイジャックされたようです。
そして、本事例の攻撃者は、事例1のようにオレオレ証明書は使いませんでした。認証局を欺いて正規の証明書を誤発行させ、偽サーバに設置したのです。ブラウザは警告を出すことはなく、「うかつ」でないユーザも含めて23.5万ドル相当の仮想通貨が奪われました。
事例3: KLAYswap
2022年2月にターゲットになったのはKLAYswapという仮想通貨事業者でした。この件で利用されたのも経路ハイジャックでした。
しかし、この事例でハイジャックされたのはKLAYswap自体ではなく、KLAYswapが利用するJavaScriptのライブラリが置かれていた外部のサイトでした。KLAYswapにアクセスしたユーザは、偽の外部サイトから改竄されたJavaScriptファイルをダウンロードし、それを実行して仮想通貨を奪われました。被害額は190万ドル相当。
事例2と同様に、この事例でも認証局が騙されて正規の証明書が誤発行させられていて、ブラウザが警告を出すことはありませんでした。KLAYswap自身の証明書が差し替えられたわけではない、つまりブラウザのアドレスバーに表示されているURLの証明書はKLAYswap自身が取得したものに間違いなく、ユーザがこれを検知するのは極めて困難だったと思われます。
経路ハイジャックってそんな多いの？
ここまで挙げた3件の事例は、すべて攻撃手法として経路ハイジャックが使われています。経路ハイジャックは残念ながらありふれていて、twitter上でbotが毎日つぶやいてるぐらいには日常茶飯事です。
ただし、観測される経路ハイジャックの大半は攻撃ではなく、設定ミスなどにより不正な経路が意図せず外部に流出してしまったものだろうと言われています。ハイジャックされる側も脆弱性を放置していたなどの過失はありません。しかし逆に言えば、わざわざ凝った細工などしなくても、定常的におこなわれるごく一般的な作業をちょっと間違えるだけでハイジャックできてしまうということであり、また、ありふれているからこそ悪意によるものかどうか判断しづらいとも言えます。性善説でなりたっていたころのインターネットが今もそのまま残っている部分ですね。
いちおうRPKIという対策はありますが、残念ながらあまり普及していません。また、AS(雑に言うと、ネットワーク運用者)が実施すべきものであって、ドメイン所有者や認証局の意思で実施することはできません。
事例4: Coincheck
偽サイトに誘導できるなら、攻撃手段は経路ハイジャックにかぎりません。2020年6月のCoincheckの事例は、事例1-3とは異なり経路ハイジャックではなく、ドメインレジストラのアカウントが奪われたようです。先に書いておくとこの件では証明書の誤発行はありませんでした。
経路ハイジャックの場合、かならずしもすべての人が同じ経路を使ってアクセスしてくるとはかぎらず、ハイジャックされていない経路が使われることもあります。したがって、この方法で認証局を欺いて証明書を誤発行させようとしてもかならず成功するとはかぎりません。
しかし、ドメインハイジャックは違います。そのドメインに関するあらゆる権限が奪われます。「偽物が本物になりすます」のではなく、「どれが本物なのか攻撃者が決める」のです。ユーザからのアクセスも、認証局からのドメイン認証のアクセスも自由に誘導できてしまいます。アクセス先は攻撃者が決めた「本物」なので、RPKIもDNSSECも対策になりません。
Coincheckの事例では証明書を発行させようという試み自体がなかったようですが、攻撃者がやろうと思えば100%確実に証明書取得に成功し、それをWebサイトに設置していればユーザへの金銭的被害が確実に発生していたはずです。それがなかったのはまさに不幸中の幸いとしか言いようありません。なぜ攻撃者がしなかったのか謎でしかなく、誤発行がなかったからといって忘れていい事例ではないでしょう。
まとめ
TLSで重要なのは、クライアントとサーバの通信だけではありません。証明書を発行する際の認証局によるドメイン認証の部分も同様に重要であり、ここを攻撃されてなりすましサーバが正規の証明書を入手できてしまうとTLSの恩恵はありません。この記事では、実際にここを突かれて攻撃者に正規の証明書が誤発行されてしまった事例2件と、攻撃者がやろうと思えば発行されていたかもしれない事例2件を紹介しました。4件とも仮想通貨事業者でしたが、たまたまです。どんなドメインでも起きる可能性はあります。
相手が本物であることを確認するために絶対にやってはいけないのが、「自称」をそのまま信用することだと前述しました。しかしながら、認証局によるドメイン認証は、なりすましされてるかどうか調べることのできない平文通信で「本人ですか」と確認するものでしかなく、「自称」をそのまま信用しているのと大差ありません。
経路ハイジャック対策になるRPKIや、DNS改竄の対策になるDNSSECなどの技術もありますが、認証局業界やブラウザベンダーはなぜかこれらの導入には及び腰のようで、認証局の最低規準を定める文書にも規程は見当たりません。認証局は自分自身がTrusted Third Partyであるため、それ以外のThird Partyを信頼することはできないと考えているのかもしれませんが…。
筆者は昨年6月のDNS Summer Day 2022にて、この件に関する発表をしています。発表資料をぜひご覧ください。ただ、この時点では実際に誤発行のあった事例は認識しておらず、そのときは「実際の事例はまだないけどいつ起きてもおかしくないから気をつけてね」ぐらいのつもりでした。しかし、その2ヶ月後に事例2のインシデントが発生し、それを調べる過程で過去に事例3が起きていたことを知りました。こちらが認識していないだけで、他にも事例はあるかもしれません。今後も起きるでしょう。起きない理由がありません。TLSがちゃんと意味のあるものにするために、関係者の尽力を期待します。
