HTTPサイトのドメインを奪われてHSTSを有効化されたら

はじめに

最近lovelive-anime.jpドメインが何者かによって移管され一時的にその者の手に渡った。もともとの管理者によってすでに取り戻されたが、攻撃者は一時的にこのドメインに対する全権を握った。この記事では、あくまでも思考実験として攻撃者が他人のHTTPサイトを運用しているドメインの全権を握ったときに、攻撃者が**HSTS(HTTP Strict Transport Security)**を有効にしてしまった場合どうなるかについて考える。まずはHSTSについて簡単に説明し、そしてその後で今回筆者が考えた攻撃について議論し、最後にまとめを述べる。

この記事を読んでわからないことや改善するべき点を見つけた場合は、気軽にコメントなどで指摘してほしい。

攻撃者によるHSTSの有効化

ここではHSTSに関する説明と、筆者が考える攻撃（？）について説明する。

HSTSとは

HSTSとは、HTTPのレスポンスにおいてStrict-Transport-Securityというヘッダーを付与することで、そのヘッダーに基づいてアクセスしたブラウザに次回以降HTTPの代わりにHTTPSを使うように伝達するセキュリティ機構である。

HSTS有効化攻撃（？）

攻撃者は今ドメインを完全に掌握していることから、次の手順でHSTSを有効化する。

1. 攻撃者のHTTPサーバーを用意し、次のようなStrict-Transport-Securityヘッダーを返すように設定する

   • includeSubDomainsはサブドメインに対しても次回からHTTPS通信を強制させる
   • max-age=31536000の数値は適当に1年としたが、長ければなんでもよい

Strict-Transport-Security: max-age=31536000; includeSubDomains
```
2. 奪ったドメインへのHTTPアクセスが（1）で用意したサーバーへ到達するようにDNSを編集する

このようにすると、ユーザーが一度でも奪われたドメインへアクセスしてしまえば、次のアクセスからHTTPSを強制させることができる。HSTSはユーザーのブラウザに保存されるため、ドメインの管理者はたとえドメインを取り戻したとしても、このときにアクセスしてHSTSが有効となってしまったユーザーのためにHTTPSのサイトを運用するなどをしなければならなくなる。

攻撃が実行された後

このような攻撃が実行されてしまったとき、ドメインの正当な管理者はどうすればいいかについて議論する。

HSTSの停止

HSTSはmax-age=0としたレスポンスヘッダーをブラウザへ返すことで無効にすることができる。ところがユーザーのブラウザはすでにHTTPSにしかアクセスしないようになっているため、ドメインの正当な管理者はドメインを取り戻した後に次のような操作を行う必要がある。

1. 正当な管理者はHTTPSのサイトを作成し、それが次のようなレスポンスヘッダーを返すようにする

Strict-Transport-Security: max-age=0; includeSubDomains
```

ただし、攻撃者はincludeSubDomainsを付与したHSTSレスポンスをばらまいてしまったので、次のようなユーザーを救済しなければならない。

1. ユーザーは、攻撃者によって奪われたattacked-domain.comにアクセスしてしまい、HSTSがサブドメインに対しても有効な状態になってしまった
2. ユーザーは普段video.attacked-domain.comを利用しており、attacked-domain.comすることは少ない
   • ドメインの正当な管理者はこのドメイン上のサービスをHTTPS化することに技術上の課題を抱えており、直ちにHTTPS化ができない
3. ユーザーのブラウザはhttps://video.attacked-domain.comへアクセスしてしまい、サービスを利用できない

このような場合は、まず*.attacked-domain.comのどれにアクセスしてもStrict-Transport-Security: max-age=0というヘッダー付きのHTTPSレスポンスを返すゲートウェイを作り、そのうえで適切なHTTPサイトへリダイレクトするといった方法を講じる必要がある。

奪ったドメインの証明書発行と中間者攻撃

lovelive-anime.jpの上ではHTTPのサイトであるhttp://lovelive-anime.jp¹が運用されていた。攻撃者はドメインを奪取した後にLet's Encryptを利用して証明書を発行したとみられる。攻撃者が発行したとみられる証明書は下記で確認できる。

• https://crt.sh/?id=1349848557 (lovelive-anime.jp, www.lovelive-anime.jp)

Let's Encryptなどであればドメインを奪ってから証明書を作るということがすぐさま可能である。とはいえLet's Encryptで作成できる証明書は短命であることも同時に考えなければならない。

さて、もし正当なドメインの管理者がHTTPによるサイトをHTTPSへ変更した場合について考える。ただし、攻撃者は一時的にドメインを得ていた時間を利用して証明書を入手している可能性がある。その場合は中間者攻撃を受ける可能性がある。証明書の無効化（リボーク）の方法について軽く調査してみても、他人によって発行された証明書をリボークする手立ては見つけられなかったので、恐らく認証局に事情を説明してリボークしてもらうことになると考えられる。このリボークが終了するまでの間は、たとえHTTPSサイトを作成したとしても若干の不安が残る状態になる。

まとめ

ここではHSTSを利用した攻撃（？）について述べたが、たとえばフィッシングなど他の悪意のある行為が無数に存在するだろう。DNSのMXレコードを書き換えてメールを盗むといった行為も考えられる。ドメインの管理はセキュリティの中でとても重要な部分であるということを考えさせられる出来事であった。ドメインが奪われたとき、攻撃者はDNSにどのようなレコードを登録していたか、またそれの証明書を発行したか？といった攻撃者の行動をきちんと残しておくことも重要かもしれない。

参考文献

• HTTP Strict Transport Security (HSTS)

1. この記事では公式が現在はアクセスしないようにと要請していることから、念のためhttp://lovelive-anime.jpという文字列からのリンクが機能しないようにした。 ↩