以下の内容はhttps://micro-keyword.hatenablog.com/entry/2020/08/17/193339より取得しました。


Alexaの脆弱性と悪用の方法について

f:id:micro_keyword:20200817193237j:plain:w400

セキュリティベンダーのCheckPointより、Alexaの脆弱性を悪用した攻撃手法の解説記事が公開されました。

research.checkpoint.com

脆弱性自体は、すでにAmazonによって修正済みだとのことですが、脆弱性がどういうものでどういった攻撃手法が使われたのかという点は、今後IoTデバイスと呼ばれる機器に起こりうる脅威を知る良いきっかけになると思うので、簡単にまとめてみます。


目次


脆弱性の概要とユーザへの影響

CheckPointの研究者によると、AmazonおよびAlexaが利用するサブドメインにCORS(Cross-Origin Resource Sharing)の設定不備があり、XSS(クロスサイトスクリプティング)の脆弱性が存在していました。

そして、XSSを悪用することで、最終的にCSRF(クロスサイトリクエストフォージェリ)トークンを取得し、被害者のAlexaにおいて任意のアクションを実行できるというものでした。

具体的には、次の章で記載します。

結果、これらの脆弱性により、攻撃者は以下のアクションを実行できます。

  • ユーザのAlexaアカウントにスキル(アプリ)をサイレントインストールする
  • ユーザのAlexaアカウントにインストールされているすべてのスキルのリストを取得する
  • インストールされているスキルをサイレントに削除する
  • Alexaで被害者の音声コマンドとその応答履歴を取得する
  • 被害者の個人情報を入手する

攻撃者が、ユーザが細工されたリンクを一度クリックするだけで攻撃に成功します。

脆弱性については、概要動画が公開されています。

www.youtube.com


攻撃の流れ

CORSポリシーの設定不備

Alexaのモバイルアプリには、通信の解析を妨げるための仕組みとして、SSL Pinningが実装されています。

そのため、CheckPointは、FridaのSSL universal unpinning scriptを利用してトラフィックを分析したようです。

トラフィック解析の結果、CORSポリシーの設定不備があるアプリから複数のリクエストが確認でき、Ajaxリクエストを別のAmazonサブドメインに送ることが可能になっていました。

このことから、攻撃者によって正規のサブドメインではないAmazonサブドメインに対して、リクエストが送れる状態だったことがわかります。

Web通信の際は、各社のブラウザにてXSSを防ぐために異なるドメインへの通信を拒否するような仕組みが実装されているのですが、例外的に、その通信を許可するのがCORSという技術です。

https://cdn-ssl-devio-img.classmethod.jp/wp-content/uploads/2012/09/cors-007.png

図はクラスメソッドが運営する技術メディアサイトDevelopers.IO参照。

dev.classmethod.jp

もちろん、その設定に不備がある場合、事実上のXSSを許可することになってしまい、脆弱性となるわけです。

レスポンスにCSRFトークンが含まれてしまう

トラフィック解析で確認された複数のリクエストのうち、いくつかのリクエストは応答として、「Alexaにインストールされたすべてのスキルの一覧」や「CSRFトークン」を応答として返すものもあるため、その後の、攻撃の幅を広げてしまっています。

Alexaのスキルというのは、Alexaのビルトイン機能で、いわゆるソフトウェアのプラグインみたいな位置づけです。

CSRFトークンを取得することで、攻撃者は遠隔から被害者の代わりにアクションを起こすことが可能になり、新しいスキルをインストールしたり、有効にしたりできてしまうわけです。

コードインジェクションの実行

今回の検証では、track.amazon.comへ送ったリクエストの応答として、paginationTokenとpageSizeが含まれていました。

https://research.checkpoint.com/wp-content/uploads/2020/08/alex-4-e1597177469231.jpg

pageSizeを変更すると、サーバー側からステータスコード500とJSONを応答と指定受け取れるのですが、応答のコンテンツタイプはapplication/json ではなくtext/htmlでした。

そのため、パラメータを加工することで、コード実行が以下のように可能になってしまっています。

https://research.checkpoint.com/wp-content/uploads/2020/08/alex-5-e1597177493823.jpg

これにより、被害者に成りすまして、skillstore.amazon.comAjaxリクエストが送れてしまいます。

さらに、以下に示す、すべてのCookieをskill-store.amazon.comに送信させるリクエストを実行することで、レスポンスとして、csrfTokenが取得できます。

https://research.checkpoint.com/wp-content/uploads/2020/08/alex-6-1.png

このcsrfTokenとインストールさせたいスキルのスキルIDを利用することで、被害者のAlexaにスキルを仕込むことができます。

同様にして、削除も可能です。

これらを組み合わせて、スキルをサイレントインストールで差し替えておくと、Alexaに声で命令した時に、攻撃者の用意したスキルを実行させることもできます。

例えば、「Alexa、エアコンつけて」って言ったら、「銀行の口座情報をLINEの特定アカウントに送る」みたいな。

スキルは、認証情報そのものは取得できなくても、認証情報を用いて取得できる情報(例えば、登録している情報や利用履歴など)は取得できてしまうので、注意が必要ですね。

実際の攻撃の例については、CheckPointの記事にも記載があるのでご参照ください。


まとめ

簡単な紹介ではありましたが、Alexaのスキルを遠隔から操作できてしまう脆弱性でした。

これからIoTデバイス向けのアプリケーションはたくさん作られていくかと思いますが、Webアプリケーション同様、しっかりとしたセキュリティ実装が必須になってくると思われます。

使うスキル自体は変わらないかもしれませんが、対象となる製品やサービスの幅が広がっていくことをそうていすると、セキュリティエンジニアはまだ需要がありそうですね。

具体的にいうと、アプリケーションのセキュリティ実装レビューができる人、ペネトレーションテストができる人、パケット解析ができる人なんかは引き続き重宝されそうですね。




以上の内容はhttps://micro-keyword.hatenablog.com/entry/2020/08/17/193339より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14