責任ある情報公開:Amcrest View Web ポータルの例
2017 年 1 月 18 日 編集部記事
私は最近、脆弱性調査プロジェクトで使う目的で、数台のデバイスを購入しました。その中の 1 台である、Amcrest の IPM-721S 無線 IP カメラは、縦横首振り機能付きの無線のカメラで、Amazon.com で 6,381 件ものレビューを集めていました(この執筆時は、なぜか 1,425 件になっていました)。
カメラの設定
カメラの初期設定は、Android アプリの Amcrest View Pro を使って簡単にできました。設定では、カメラにシリアル番号の QR コードをスキャンして、カメラのデフォルトピアツーピア(P2P)無線ネットワークにアプリを参加させてから、新しい管理者パスワードを設定し、カメラを家の無線ネットワークに追加しました。
カメラの設定の完了後に、www.amcrestcloud.com へのコールホームで、コマンド、FTP、メディアなどの各種サービスのアドレスとポートを含む短い XML(eXtensible Markup Language)設定ファイルを受信しました。その後に、カメラは TCP ポート 8443 でのコマンドサーバへの接続を開始しました。
このコールホームによって、Amcrest の「クラウドビューア」アプリケーションの 1 つにカメラを簡単に追加できました。Amcrest は、ブラウザベースのリモートカメラ表示用の 2 つのオプション、amcrestcloud.com と amcrestview.com を提供しています。Amcrest Cloud が録画されたビデオのクラウド保存を可能にする新しいアプリケーションのようであるのに対し、Amcrest View はリモート表示用の単純なレガシーアプリケーションのようです。最初のテストでは、この単純な Amcrest View の Webアプリケーションを集中的にテストしました。
Amcrest View アプリケーションは、未署名の ActiveX プラグインを使用して、ブラウザとユーザのアカウントに関連付けられている任意のカメラとの間の P2P 接続を処理します。カメラの初期設定時に設定した、ラベルとして使用するデバイス名、カメラのシリアル番号、管理者の資格情報を入力して、カメラをアプリケーションに追加します。アカウントが Amcrest View に追加されると、このアプリケーションで、カメラの状態(オンラインまたはオフライン)を表示し、カメラのライブ画像にアクセスできるようになります。
最初のテスト
私は最初に、自分のアカウントに関連付けられていないカメラを表示できるかテストしてみました。このテストのために、自分のカメラをアカウントに追加してから、テストで使用する2つ目のアカウントを作成しました。
実施した調査のほとんどで、Burp Suite のプロキシを使用して、Web アプリケーション、さらには、Burp Suite のリピーターツールへのブラウザ接続を仲介しましたが、サーバへの要求を簡単に変更し、送信できました。
カメラにアクセスするには、最初に、POST 要求を使ってシリアル番号を https://www.amcrestview.com/equipment/equipment_goToEquipmentWeb.action に送信して、カメラの P2P ポートと Base64 エンコードのパスワードを含む接続の詳細を受信します。
要求:
応答:
ブラウザアプリケーションが受け取った Base64 エンコードのパスワードをデコードするための別の要求を送信することで、すべての詳細が最終的に ActiveX プラグインに渡されることになります。
未認証セッションと 2 つ目の認証済みユーザを使って同じ接続情報の取得してみたところ、失敗したため、Amcrest が接続の詳細を提供する前に認証済みユーザによってシリアル番号の所有者を認証していることを確認できました。
自分が所有者ではないカメラを表示できないのであれば、単純に、カメラの所有者であるアカウントを乗っ取るという方法はどうでしょうか。
未認証アカウント変更の脆弱性
Amcrest View には、ほとんどの Web アプリケーションと同様に、関連する電子メールアドレスなどのアカウント設定を変更する機能があります。アカウントに関連付けられた電子メールアドレスを変更するには、ブラウザが https://www.amcrestview.com/account/users_modifyUserInfo に POST 要求を送信します。編集が成功すると応答の本文に “true” が返され、編集が失敗すると応答の本文に “false” が返されます。
要求:
応答:
POST 要求には、user.userName や user.email などのいくつかの重要なパラメータが含まれます。要求を成功させるには、Amcrest View に対して、user.userName パラメータのユーザ名の電子メールアドレスを user.email パラメータの値に設定します。その結果、user.userName パラメータが現在認証済みユーザセッションのユーザ名と一致していない場合も、この要求が成功することがわかりました。
要求:
応答:
TestUser2 アカウントにログインし、TestUser1 の認証済みセッションを使用して作成した要求によって、関連付けられた電子メールアドレスが変更されたことを確認できました。私が悪意のある人間だったとしたら、この脆弱性を利用してアカウントに関連付けられた電子メールアドレスを変更し、パスワードリセットを発行してアカウントを乗っ取って、カメラにライブアクセスできるようになったはずです。
この脆弱性を悪用するには、相手のユーザ名を知っている必要がありましたが、可能性のあるユーザ名を取得できる、Amcrest の公開フォーラムなどのいくつかの方法があります。
ストアド XSS の脆弱性
未認証アカウント変更の脆弱性を確認したのと同時に、user.email パラメータで渡された入力が検証されていない、あるいは完全には消去されていないこともわかりました。これは、他のユーザのセッションへの任意の JavaScript のインジェクションに悪用される可能性がある、クロスサイトのストアドスクリプトの典型的な例です。
要求:
証拠:
結論:
上記の 2 つの脆弱性を確認後すぐに、私は報告書を作成して、 Amcrest に提出しました。Amcrest は報告したこれらの脆弱性をすぐに確認し、30 日以内に脆弱性の修正プログラムを自社の Web ポータルに公開しました。
この調査の経緯
2016 年 11 月 3 日 – 脆弱性を発見
2016 年 11 月 4 日 – 製造元に報告
2016 年 11 月 8 日 – 製造元が報告を確認
2016 年 12 月 7 日 – 製造元が脆弱性を解決