botnet感染時に活躍したCarrier Grade Captive Portalのはなし
BSI(ドイツ連邦政府の情報通信・セキュリティを取り扱う部門)の方から，Carrier Grade Captive Portalの話があったので書き留めておきます．一般的にCaptive Portalは公衆無線LANにおけるケースが広く認知されているので，それと区別をつけるため，「Carrier Grade」と言っていると思われます．
ドイツ国内でのbotnet感染
BSIが国内のISPに対し，botnetの一部になっているユーザーのIPアドレス，タイムスタンプ，その他ユーザー情報を報告しました.(BSIにとってISPの力を借りなければ，動的アドレスを持つユーザー個人に接触することが難しいからです)
この時，ISPはユーザーに感染を通知するための手段として，メール，郵便またはCarrier Grade Captive Portalの3つを持っていました．この状況下で最も効率的にユーザーに感染を通知し，システムをクリーンにしてもらう方法はCaptive Portalだったそうです．
NetCologne社の"ForcedPortal"
上記のような事態に対し，ドイツのISPのうちの一つであるNetCologneは以下のような「Forced Portal」を設けました．これは以下のような動作をします．
- 管理システムがユーザーの感染を検知すると，CPE顧客ルーターの接続(PPPOE接続)が切断され，すぐに新たなPPPOE接続が開始されます．
- 新たなPPOE接続と共に，CPE顧客ルーターは新たなDNSサーバーのアドレス，ゲートウェイを取得し，Carrier Grade Captive Portalに接続します．
- この新たな接続ネットワーク内では，全てのトラフィックはHTTP/HTTPS proxyでCaptive Portalへ向けられます．Captive Portalはインフォメーションページとして機能し，今回の場合では，感染の状況やシステムをどのようにクリーンするかの説明が，Captive Portalに誘導された顧客に対し表示されます．
# ComcastのCaptive Portalと似たタイプのCaptive Portalかも？(IETF97におけるプレゼン参照)
問題
HTTP接続はだいたい問題ありませんが，HTTPS接続時に問題があるそうで，特にGoogle Chromeにおいて，顧客がHSTSまたはHSTSプリロードでドメイン名へ接続しようとした際に，最初のHTTP接続がされないそうです． HTTPS接続をする際，ブラウザがMITM(中間者攻撃)を検知し，顧客向けの情報ページが表示されず，顧客にエラーページが表示されることもなく，代わりにカスタマーサポートセンターへ大量のCallがかかってくるという事態に...
また，各OSベンダーによるDetection StrategyはCarrier Grade Captive Portalでは全く機能しないとのことです．なぜなら，公衆無線LANなどとは違い，上記の状況下では，CPE顧客ルーターが新たなPPPOE接続を開始した時に，インターネットへの全ての接続がルーターにより切断されているため，クライアントによるCaptive Portalの検知機能が動かないそうです．
以上，事件簿みたいになっちゃいましたが，公衆無線LAN以外の場面でも使われているCaptive Portalがあるということを知っていただけるといいかな，と思い書きました．
Captive Portal(CAPPORT) APIについて
ユーザーのデバイス(以下UE)とCaptive Portalが対話できる仕組み，CAPPORT APIというアイデアが現在インターネットドラフト段階でIETFのcapport WGで標準化されようとしています．これは現在ユーザーがCaptive Portalアクセス時に手動でメールアドレスなどの個人情報をブラウザから入力するのを自動化する取り組みです．今回はこちらについてまとめてみました．
実際の無線LANの認証・認可のフローから見ると，下記の部分で使われる予定です．
This figure is deprived from here.
CAPPORT APIを用いた際のフロー
前提: DHCP optionまたはIPv6 RAsが提供されなければならない．
- 第一段階: DHCP optionかIPv6 RAsを用いて，UEがIPアドレスの取得・ローカルのCAPPORT APIサーバーのURLを取得します．
- 第二段階: まず，UEがCaptive Portalでアクセス制御がされているネットワークにアクセスするために必要な条件を，第一段階で取得したURLを用いてCAPPORT APIサーバーに問い合わせます．そして，必要なプルーフをサーバーに送ります(自分の名前やメールアドレス等).
- 第三段階: UEがネットワークへのアクセスを許可され，CAPPORT APIサーバーにステータスを問い合わせることができます．
(各フェーズを下記に描いてみました)
UEとCAPPORT APIサーバーは，JSONのデータフォーマットでやりとりします．
上記の図の中の該当箇所で下記のようなやり取りが行われます．
{ “networks” : {},
“session-token” : “”
}
❹UEからの問い合わせに対し，CAPPORT APIサーバーは使えるネットワーク，条件，セッショントークンを返します．
{"networks" : {
"DEFAULT": {"conditions" : [ {"id" : "...”,"type" : "t&c”,"requirement_details" : {"text" : “I will do whatever you say”} } ],"state" : {"permitted" : false}} },"session-token" : "…“}
❼提示された条件をUEが満たす
{ “networks” : {“DEFAULT” : {“conditions” : [“id” : “...”,“satisfaction_details” : {“text” : “1e173b7bb0d114bb38438c15b9eb9736”}]}},“session-token” : “…”}
ここまでの一連の流れは繰り返されます．
❽CAPPORT APIサーバーがUEのインターネットへのアクセスを許可します
{"networks" : {"DEFAULT": {"state" : {"permitted" : true,“expires” : “2036-01-01T00:00:00Z”,“bytes_remaining” : 987654321},"session-token" : "…”}
インターネットアクセスを得るための条件
インターネットアクセスを得るために個人情報を入力したり，一定時間広告を見せられたり...いろんな条件があると思います．それぞれの条件は，個別に"type" string, requirement_details, its satisfaction_detailsの3つを定める必要があります．
最も一般的だと思われる，利用規約に同意するケースと，パスコードを入力するケースがドラフトの下の方に載っています．
補足
ユーザーが公衆無線LANでインターネットアクセスを得るために，Webブラウザを用いて必要な手順を入力するという手順がありますが，このやりとりを自動化する手法が CAPPORT APIです．このメカニズムは, ユーザーにHTMLフォームを提示するよりも安全性が高いという条件を満たします．ただ，やりとりに含まれる情報にはメールアドレスや名前などの個人情報が含まれる可能性があるため，暗号化されていないセッション上での，UEとCAPPORT APIサーバーの通信は危険だと言えるでしょう．
IETF98 Hackathonで実際に実装されたものがあるので興味のある方はこちらも．
I-Dを読む。#1 Captive Portal Problem Statement
もう何回も読んでるI-Dだけどブログで改めてまとめてみる。
I-D : Captive Portal Problem Statement(draft-nottingham-capport-problem-01)
Author : M.Nottingham(Akamai)
この方はIETFだけでなくW3C界隈などでも非常に有名。HTTP WGで活発に活動されている方で、Captive Portalのためのステータスコード511の提案をしたお方でもあります。最近はQUIC WGが忙しいようでcapportにはあまり顔を出してくれない。。orz
タイトルは”Captive Portal Problem Statement”なんてかっこいい横文字を書きましたが、つまりcapport WGにて「Captive Portalの問題点はどう定義されてるの？」って話をします。 前置き的な話はこちらやこちらでしています。
実は私が以前IETF報告会で発表した資料もありまして、今回の内容はそれと被りますのでご了承を。
0 : 問題の概要
まずCaptive Portalで、一番問題とされているのが、ユーザーの通信に割り込み認証ページに強制的に誘導することです。実質ブラウザのHTTPセッションを横取りし、強制的にWebページにリダイレクトさせるという挙動はMan-in-the-middle-attack(MITM/中間者攻撃)と大差がなく、ユーザーエクスペリエンスが損なわれると言えます。
そこでcapport WGの目的は以下のようになっています。
- Captive Portalとユーザーデバイスのブラウザ間とのやりとりをシンプルにする
- できるだけCaptive Portalと人とのやりとりを少なくする(やりとりが多くなるとユーザーにとって混乱の原因となるから)
1 : 現在定義されている問題点
-
False Negatives(偽陰性) : Captive Portalの検知にはOSによって様々な方法が使われているが、検知に失敗することがよくある。その場合、Captive Portalがあるにも関わらず、OSのブラウザは今接続しているネットワークがOpenなネットワークだと捉えてしまうため、そもそもCaptive Portalにアクセスできない
- Longevity(コネクションのタイムアウト) : 大抵のCaptive Portalには「1回30分、1日3回まで」とアクセス回数や時間の制限がついていることが多い。作業途中であっても突然タイムアウトになってしまい、一度ネットワーク接続は切断され、ネットワークに再度ログインしなければならない。
- Interoerability Issue(相互接続性) : Captive Portalは特定のOSやブラウザの性能や挙動に依存することがある。しかし、各OSやブラウザ間でそういった挙動の共有等はされていないため、特定のOSでは検知されるが、他のOSでは検知されない、といった挙動の違いが出てしまう。
- Confusion(混乱) : Captive Portalの挙動は中間者攻撃と大差ないため、ユーザーやユーザーエージェントを混乱させることがある。
- TLS : Captive PortalがTLSセッション(HTTPSやIMAPS等)に割り込もうとすると、証明書エラーが発生してしまう。このようなエラーの許諾をクリックしてしまうという悪い習慣をユーザーにつけてしまう。
- Unexpected Configuration(予想外の設定) : クライアント側でCaptive Portalにとって予想外な設定(固定IPアドレス/DNSサーバー/HTTPプロキシ等)をしていた場合、正しく動かない場合がある。例えば、通常Captive Portalでは、DNSサーバーはDHCPを用いて動的に設定されることが予想されているが、あらかじめクライアント側で特定のサーバーを静的に指定していた場合は動かないことがある。
- Stealing Access(なりすまし) : Captive Portalのようなオープンなネットワークでは安全なネットワークを設定することが難しい。このような安全な通信が保証されていない状況下で攻撃者が認可されたユーザーのフリをすることも可能である。(Captive PortalはユーザーのMACアドレスをひも付けて認証することがあるため)
- Connectivity Interruption(接続中断) : CelluarとWi-Fiなど複数のネットワークインタフェースを持つデバイスの場合、片方がCaptive Portalのネットワークに繋ぐため、もう片方のインタフェースを落としてしまうことがある。この場合、Captive Portal Login Processを終えるまでインターネットへの接続が得られない。
これに補足、というわけではないのですが、スマートフォンブラウザでCaptive Portalが認証なしでインターネットへの接続が成功してしまうといった問題のある挙動も観測されています。
2 : Captive Portal Detectionによって生じる問題点
-
False Positives(偽陽性) :ログインするためにWebブラウザを用いないネットワークもあり、ネットワークにアクセスするためにVPNが必要となるケースがある。この場合、現在主流となっている、HTTP redirectionに依存したCaptive Portalの検知は逆効果である。
- Non-Internet Networks(非インターネットネットワーク) : 社内ネットワークのような外に出ることがでいない非インターネットネットワークの場合、ユーザーデバイスにCaptive Portalの認証を通過したことを知らせる術がない。よって、認証・認可されたとしてもインターネットに接続できない状況が続いてしまう。
- Sandboxing(サンドボックス) : Captive Portalを検知した際に、サンドボックス化されたブラウザで開くOSもある(Captive Portal Detection)。これはユーザーのプライバシーを保護するための機能でもあるが、実際この環境下では以下のような問題もある。(通常のブラウザとは別に開かれるこんな画面↓)
- APIへの限られたアクセス
- 完全に孤立したブラウザのため、ユーザーがステートを持つことができない
- Captitve Portalは様々なプラットフォーム上でアドホックに実装されているため、挙動にバラツキがある。
- 上記のようなUXを損なう問題を避けるために、Captive Portalのオペレーター側が、Captive Portal Detectionを回避するようCaptive Portalに設定することもある。
3 : Captive Portal Detectionを回避することで起こる問題
- Captive Portal Detectionを回避することでSection 2にあるような問題を起こしてしまう・・・というようににわたま問題感があります。例えば、回避の方法として、Captive Portalの設定で、検知に使用されるURLをCaptive Network下でもアクセス可能なホワイトリストに入れておくという手法があります。しかし、これはOSにとってCaptive Portalをオープンなネットワークだと認識させてしまうので、Section 2のFalse Negativesのような問題にもなってしまうのです。
Captive Portal Detectionについて
今回はCaptive Portal Detection(キャプティブポータル検知)についてお話しします。
手っ取り早く言うと、コレ↓ですね。こんな画面見たことあるでしょうか？
公衆無線LANに接続すると、ブラウザが突然開かれるアレです。海外だと、「pop-up window」や「splash window」などと呼ばれています。
Captive Portal Detectionとは
ユーザー保護の目的でOSに実装されている仕組み。通常のブラウザとは別にその場限りのincognito modeなウィンドウで開かれる。incognito modeで開かれることによって、ユーザーが普段使っているブラウザのセッションやクッキーの情報が漏れる心配がない。
各OSのCaptive Portal Detection方法
では、実際にどのようにCaptive Portalを検知するのでしょうか？
基本的には、それぞれのOSには「Well-Known Web Page」と呼ばれる、インターネットアクセスの有無を検証するためのWeb Pageを用意しており、そこへのアクセスがあるかないかでCaptive Portalがあるかどうかを検知します。Captive Portalが検知され、レスポンスとして返ってきた302 redirection urlをfetchし、ユーザーを認証ページに誘導します。
各OSにはCaptive Portal Detection Strategyという検知のための手法があり、以下の表の通りです。
- iOS/macOS : メカニズムは非常に単純。「Success」というレスポンスが返ってくる、captive.apple.comなどのWell-Know Web Pageにアクセスし、「Success」が得られない場合はCaptive Portalと検知している(タイムアウトは除く)。
- Windows : Windowsには2段階の判断ある。まず、dns.msftncsi.comにDNS lookupし、IPアドレスをチェックする。これはCaptive Portalがあるのか、またはそもそもネットワークの接続性の問題のため、インターネットアクセスが得られないのかを判断するためである。そして、http://www.msftncsi.com/ncsi.txtにリクエストを送り、「Microsoft NCSI」というレスポンスが得られなかった場合、Captive Portalと見なされる。
- Android : AndroidはHTTP/HTTPS両方の接続を確かめるページを用意しているが、Captive Portalの特性上HTTPS Probeはほぼ失敗してしまう。HTTP Probeを確認する場合、http://google.com/gen_204にアクセスする。このWebページは、インターネットアクセスがある時に204 & No Contentを返す。Androidは公衆無線LANに接続すると、まずこのページへのアクセスをチェックし、「204 & No Content」以外のレスポンスを得た場合Captive Portalだと認識する。
＊Android7.0からの変更点
上記のAndroidの説明を見て、HTTP/HTTPS両方確認する必要はないと思った方もいると思いますが、Android7.0からは、
- HTTPS probeがSuccessしなかった場合、自動的にそのネットワークに接続しない。
- ユーザーが自分で使うかどうか「Manual」に選択する。
というように変更されたので、一応意味はあるっぽいです。従来はCaptive Portalを検知すると、自動的にincognito windowで開くというメカニズムでしたが。しかし、そもそもユーザーを安全ではないネットワークに自動的に接続させるのはいかがなものか、とGoogleは考え上記のようにポリシーの改定を行ったみたいです。
AndroidのCaptive Portal Detectionは他にもいろいろと細かく設定がされており、複雑ですが、興味のある方はここからソースを読んでみてもおもしろいかもしれません。「204」と「No Content」両方チェックしている理由なんかも記されています。700行目前後から読むのがオススメだとか(by Googler)。
Captive Portalって何？
Captive Portalとは
「キャプティブポータル」と読みます。
某コーヒーショップや空港などの無線LAN認証時によく見かけるコレです。
ユーザーのブラウザのHTTPセッションを横取りして、特定のWebページ(だいたい認証や同意ページ、時々課金など)に強制的に誘導する仕組みです。
無線LANのユーザーのアクセスコントロールによく使われています。
具体的な挙動としては、
- 自分のデバイスでSSIDを選択
- Wi-Fiネットワークに接続
- ブラウザを開いて、適当にapple.comとかを検索すると認証ページにリダイレクトされます。
- メールアドレスを登録したり、SNSでOAuth認証する
- 完全なインターネットコネクションを得ることができます。
自分は、このCaptive Portalの一連の流れを ”Captive Portal Login Process”と勝手に名前をつけて呼んでいます。基本的にこのプロセスを全て終えないと、自由にインターネットを使うことができません。
ちなみに3の時点では限られたWebページやドメイン下にしかアクセスできません。
例えば、一番有名なオープンソースのCaptive Portal 「Coova Chilli」ではFacebookのアカウントで認証させたい時はそのドメインへのアクセスはホワイトリストに入れ、アクセス可能にしたり...といった設定が可能です。(ただ、これは一例でそれぞれの仕様によると思います)
一般的に広く使われているCaptive Portalですが、実は「様々な技術を無理やり詰め合わせた」みたいなものなので、実装や設計に問題があり、ユーザービリティやセキュリティに悪影響を与えることも多いと言われています。実際、Captive Portalを排除しようという動きもあり、そういったコミュニティが次世代ホットスポットとしてNext Generation Hotspot(NGH)を提案したりしています。
しかし、Captive Portalは広告やユーザーの情報を得ることができるというマーケティング的な役割も持っているため、ビジネス界としてはまだまだ手放したくないようです。
最近では、インターネット技術の任意標準化団体のIETFで、Captive Portalのユーザーインテラクションを改善するためのワーキンググループ capport WG が作られ、議論が行われています。興味のある人はチラ見してみるといいかも。
Captive Portal Interaction (capport) -
具体的なCaptive Portalの問題点は次回触れたいと思います。
今日はここまで\(・-・)/
