Subdomain Takeover 概観

この記事を書いている 6 日ほど前に, HackerOne のブログで, A GUIDE TO SUBDOMAIN TAKEOVERS という記事が出ました。結構昔から(知る範囲では 2014 年から?) 存在している攻撃な割には, 日本語だと Subdomain Takeover に関するめぼしい記事はなさそうなので, 軽くまとめておきます。

Subdomain Takeover とは

Subdomain Takeover とは, 名前の通り, ある legitimate なドメインの下の Subdomain を乗っ取る攻撃のことです(多少語弊はありそう)。

自分の管理しているドメインに対して CNAME レコードを設定し, GitHub Pages や AWS などを使うケースはしばしばあるかと思います。 例えば GitHub Pages では, 次のように CNAME レコードを設定してね, と言っています:

docs.example.com.              3592    IN      CNAME   YOUR-USERNAME.github.io.

この状況下で, YOUR-USERNAME.github.io が存在しなくなった場合(YOUR-USERNAME さんがアカウントを削除した時) を考えてみましょう。 この時悪意のある人間が YOUR-USENAME という GitHub アカウントを取得し, 適当に YOUR-USERNAME.github.io を docs.example.com で公開する ということが可能なわけですよね。 これが Subdomain Takeover という攻撃になります。

近年は各種 CDN サービスなんかを含めて, 色々と CNAME/A レコードを向けておくといい感じにできる, という類のサービスが増えました。またそれらは disposability が高いこともしばしばだと思います。結果的に使われていない CNAME レコードも残りがちになってしまい, それが上記の HackerOne のブログで次のように言われている現状を生み出しているようにも思います(ただ A レコードで向けている場合, この様な攻撃をするのは難しそうですね):

HackerOne’s Hacktivity feed — a curated feed of publicly-disclosed reports — has seen its fair share of subdomain takeover reports.

Web セキュリティ的な観点から見ると?

この攻撃がただ phishing だけに留まるなら良いのですが, Web セキュリティの観点から見ても, だいぶ実害は大きそうです。例えば任意の HTTP (Response) Header が送出できるようになりますよね。これが効いてくる攻撃シチュエーション, 1 つ思い当たるものがあるのですが, これはまた別のお話にしたいと思います。

またより広く考えてみると, Subdomain での自由を XSS, あるいは Subdomain Takeover により獲得できる場合, そこそこいろいろな攻撃バリエーションが得られそうですね。挙げようと思えばいくらでも挙げられると思いますが, 大きく 2 つほど挙げてみます。

Same-Origin-Policy bypass with weakdocument.domain setting

legitimate なドメイン使用の際においても, サブドメイン間での SOP の緩和のために, document.domain が緩めてある場合は往々にしてあります。こういうときは Subdomain Takeover の後, 素直に document.domain をその上位に設定してやることで, SOP を部分的に bypass できる場合がありますよね。

SameSite attribute bypass

あと最近はだいぶ実用的になってきたかな, と思われる Cookie の SameSite attribute ですが, これも Subdomain Takeover (XSS でも十分です) によって bypass できますね。そもそも SameSite の定義は Same-Site Cookies draft-ietf-httpbis-cookie-same-site-00 で次のように述べられている通り, Origin よりもゆるいです:

A request is “same-site” if its target’s URI’s origin’s registrable domain is an exact match for the request’s initiator’s “site for cookies”, and “cross-site” otherwise.

Preventing CSRF with the same-site cookie attribute や Cross-Site Request Forgery is dead! のようなブログでは, CSRF 対策としてこの SameSite Cookie が強いぞ, なんてことも言われています。僕も確かにとても手軽で便利な対策方法ではあると思っています。しかし, ある CSRF 攻撃をしたい対象の Origin に対して, “the target’s URI’s origin’s registrable domain” が共通しているようなドメイン (e.g. example.com が target なら, それに対しては subdomain.example.com など) に XSS があったり, Subdomain Takeover が出来る場合には, 次の 2 つの事実に注意しなくてはいけません:

  • CSRF Token による対策は, document.domain 設定がゆるい場合に, CSRF 攻撃を防ぎきれない可能性がある (SOP bypass が出来ると CSRF Token が読めるため)
  • SameSite Cookie による対策は, document.domain がゆるくなくても, CSRF 攻撃を防ぎきれない可能性がある

ここらへんは僕の理解と検証が甘いところかも知れませんが, Origin と Site だと Site の方が広い概念であることは, 多少考慮すべき事項でしょう。

実例

新鮮な実例としては Starbucks における以下の 2 つの例をまず上げておきます:

2014 年からこういう攻撃の存在は言われていました:

一時期ある TLD では, Subdomain に限らず, TLD 全体が hijack されうる状態だったこともありました:

対策とまとめ

現状要らない CNAME レコード残しとかない, とか, そういうのしかないような。かしこい対策があればご教示頂きたいです。

もしかしたら全体的に僕の理解に間違いがあるのでは, という気もするので, ぜひ References を眺めていただければと思います。マサカリをお待ちしております。

References

Written on August 21, 2018