Mail.ru CorporateMailの監査方法-大企業向けの新しいサービス

多くの場合、企業データは企業秘密です。それらを漏らすと、評判に打撃を与え、経済的損失、さらには破産につながる可能性があります。したがって、B2B製品のセキュリティ要件は非常に高くなければなりません。新製品の作成-CorporateMail Mail.ru-私たちは、そのセキュリティの問題に特別な注意を払いました。



Corporate Mail Mail.ruは、おなじみのB2CメールMail.ruのオンプレミスバージョンです。それと比較すると、新しい環境で動作するように多くの変更が含まれています-顧客回路。



お客様に安全をご安心いただくために、サードパーティ企業で監査を実施し、発見したすべての欠陥を修正してから、製品を市場に提供することにしました。これを行うために、彼らは情報セキュリティの分野で最も評判の良い会社の1つであるデジタルセキュリティに目を向けました。



監査結果はカットされています。

uWSGIでのリモートコード実行

PythonWebアプリケーションを構築するためのさまざまなフレームワークがあります。通常、Python Webサーバーゲートウェイインターフェイス（WSGI）は、WebアプリケーションとWebサーバー間の通信に使用されます。さらに、WSGIを使用すると、ミドルウェアコンポーネントを実装できます。



Python WebアプリケーションとApacheやNginxなどのWebサーバー間の通信を標準化するために、PEP 0333が開発され、続いてWSGIインターフェイスを説明するPEP3333が開発されました。 WSGIがどのように機能するかについては詳しく説明しませんが、WSGIインターフェイスをサポートする一般的なサーバーであるuWSGIについて説明します。







uWSGIサーバーは、通常のWebサーバーモードと「WSGIモード」の両方で動作し、Nginxなどの別のWebサーバーとデータを交換できます。同時に、Nginxは同じ名前のバイナリプロトコルを使用しますuwsgiは、その豊富な機能によりサイバー犯罪者にとって興味深いものです。ソリューションの「内部」を分析すると、製品のすべての内部コンポーネントがアクセスできるuWSGIサーバーが見つかりました。



問題は、uwsgiプロトコルが、uWSGIサーバーを動的に構成できるいわゆるマジック変数を使用できることでした。これらの変数の中にはUWSGI_FILE、変数でファイルへのパスを指定すると、新しい動的アプリケーションをロードできるものがあります。それが判明したように、uWSGI-サーバーには、例えば、このように異なる回路を扱うことができsection、fd、call、または最も興味深いです- exec。したがって、変数を値として渡すことができますexec://<cmmand>任意のbashコマンドを実行します。この問題を分析するために、githubで入手可能なエクスプロイトが作成されました。





コマンドを実行するクエリの例。



この脆弱性は、攻撃者が次の場合にのみ悪用される可能性があります。

• すでに製品の内部ネットワーク上にあります。たとえば、コンポーネントの1つが侵害されています。これにより、彼は新しいコンポーネントを乗っ取り、新しいデータにアクセスし、攻撃を続けることができます。
• 持っているSSRFを（使用して例えばTCP上で任意のデータを送信する機能でgopher://）。このシナリオでは、攻撃者は製品の内部にアクセスできます。

他のプログラミング言語またはフレームワークのCGIインターフェイスの実装も脆弱である可能性があることに注意してください。たとえば、FastCGIの同じリポジトリからの悪用などです。これは、これが通常の意味での脆弱性であると言っているのではなく、CGIサーバーの機能であるため、そのようなサーバーへのアクセスを可能な限り制限する必要があります。

CSRF保護をバイパスする

ブラウザにさまざまなセキュリティメカニズムが導入されたことで、最新のWebに対するクライアント側の攻撃は徐々に消えつつあります。これはCSRFにも当てはまります。ブラウザはSameSitecookieのサポートをすでに実装していますが、正しく構成されていない場合でも、抜け穴が存在する可能性があります。さらに、多くの一般的なフレームワークを使用すると、開発者はCSRF保護を簡単に構成できますが、いくつかのバグや重大ではない脆弱性がCSRF攻撃につながる可能性があります。このようなエラーは、当社の製品に含まれているカレンダーアプリケーションで見つかりました。



このアプリケーションには、ユーザーのイベントやカレンダーに対して、たとえば編集、表示、削除などのアクションを実行できるAPIがあります。オブジェクトを参照するために、UIDパラメータがURLパスで渡されます。これは、カレンダーまたはイベントのIDを担当します。次のようになります。

example.com/api/calendar/{UID}/action?
example.com/api/event/{UID}/action?

デフォルトでは、UIDはランダムに生成され、ユーザーの影響を受けることはありません。しかし、アプリケーションでは、ユーザーがUIDを変更できる場所が2つ見つかりました。



1つは、ファイルをICS形式（カレンダーとイベント用の特別な形式）でインポートすることです。ファイルには、インポート時にユーザーが制御する特別なUIDフィールドがあります。この場合、イベントをインポートした後、それらのUIDはファイルで転送されたものと同じままになります。また、このパラメーターにはフィルタリングがありません。したがって、ユーザーは任意のUIDでイベントを作成できます。



2つ目は、編集時にUIDカレンダーを変更する機能です。これは、カレンダーを編集する要求をインターセプトし、UIDフィールドを変更するだけで実行できます。ここにもフィルタリングはありませんでした。



もう1つの重要な機能：このAPIはCSRF保護を実装します。このため、特別なパラメーターがGETパラメーターで渡され、APIのキーとCSRFトークンの両方の役割を果たします。 JavaScriptを介してすべてのAPIリクエストに追加されます。 CSRFトークンをGETパラメーターで渡すことはお勧めできません。この場合、トークンが参照元、アプリケーションログ、またはブラウザーの履歴からリークする可能性があります。



すべてを一緒に入れて。攻撃者は、アプリケーション内のオブジェクトUIDを制御し、イベントとカレンダーの両方へのアクセスを他のユーザーと共有できます。この場合、ユーザーには同じUIDが表示され、そのようなオブジェクトの操作を開始すると、攻撃者によって制御されているUIDを使用して要求が実行されます。これを使用して、攻撃者は次のようなUIDを持つオブジェクトを作成できます。

../../../AnyPathTo?anyparam=value&

これで、ユーザーがオブジェクトに対してアクションを実行すると、リクエストが生成されます。

example.com/api/event/../../../AnyPathTo?anyparam=value&/action

次に、トークンもそれに追加され、CSRFトークンの役割を果たします。

example.com/api/event/../../../AnyPathTo?anyparam=value&/action&token=abcdef

そして最後に、リクエストを行うと、ブラウザはシーケンス " ../"を正規化し、その結果、リクエストが送信されます

example.com/AnyPathTo?anyparam=value&/action&token=abcdef

これで、攻撃者は、任意のパラメーターと正しいCSRFトークンを使用して、任意のパスに沿ってユーザーにアプリケーションに要求を送信させることができます。実行できるリクエストメソッドを理解する必要があります。



編集時はPUT、削除時はDELETE、表示時はGET（POSTは作成に使用され、被害者に強制的に使用させることはできません）という単純な結果になりました。攻撃者はDELETEを使用することにより、ユーザーのブラウザに、ユーザーからオブジェクトを削除する要求を実行させることができます。攻撃者にとってのもう1つのボーナスは、ユーザーがオブジェクトを編集すると、PUTリクエストがリクエスト本文とともに送信されることです。カレンダーを編集する場合、リクエストの本文には、現在のカレンダーのすべてのパラメーターを含むJSONが含まれます。つまり、「悪意のある」カレンダーを作成した攻撃者がこれらのパラメータを制御します。攻撃者が編集リクエストを「悪意のある」カレンダーからユーザーのプライベートカレンダーにリダイレクトすることに成功した場合、「悪意のある」カレンダーのすべてのプロパティが被害者のユーザーのカレンダーのプロパティに適用されます。これは、JSONで指定されたカレンダープロパティの1つであるため、カレンダーへのアクセスを上書きする可能性があります。

MITM攻撃能力

侵入者が会社の内部ネットワークに侵入することは危険な状況であり、深刻な結果を招きます。したがって、製品の監査中、私たちのタスクの1つは、攻撃者がドメインを上に移動したり、外部からの攻撃を改善したりするのに役立つ可能性のあるシステムアーキテクチャの欠陥を見つけることでした。



この製品の主な機能の1つは、ActiveDirectoryとの統合です。LDAPを介した認証と、Exchangeサーバーからのメッセージの収集のために実装されています。この例では、ActiveSyncに焦点を当てます。攻撃者にとって、これは非常に興味深いターゲットです。接続中にユーザーアカウントとパスワードが製品とActiveDirectoryの間で渡されるためです。攻撃者は接続にアクセスすることでアカウントを乗っ取ることができ、ドメインの侵害に一歩近づきます。



内部ソリューションや企業のサーバーでは、TLSの誤った使用やその欠如に問題があることがよくありますが、サービスにTLSを実装することは難しくありません。これは通常、会社の内部ネットワークがより安全であると見なされ、会社の管理者が正しいPKIインフラストラクチャを作成してすべてのサーバーに証明書を発行する時間を無駄にしないという事実の結果です。



企業ネットワーク内で最も一般的な攻撃はMITMです。このタイプの攻撃は、ほとんどの場合、企業のActiveDirectory内へのアクセスを許可します。同時に、攻撃者が会社のネットワーク内のサーバー間の相互作用を攻撃することが常に可能であるとは限りません。ほとんどの場合、侵入テスト中に、攻撃者または彼のモデルは、Exchangeサーバーまたはドメインコントローラーがないユーザーネットワークセグメントに分類されます。さらに、私たちの場合、製品はNBNS、LLMNR、mDNSなどのブロードキャスト名解決プロトコルを使用しないため、これらのプロトコルのスプーフィングではMITMを実装できません。したがって、ソリューションと他のサーバー間のMITMを成功させるには、攻撃者がこれらのコンポーネントの1つがインストールされているネットワークにアクセスできる必要があります。この目標を達成できる場合もあります。脆弱なルーターまたはサーバーがあります。これにより、最終的に特定のネットワークにアクセスできるようになります。



私たちの場合、分析中に、ActiveDirectoryとの統合はMITM攻撃に対して脆弱であることが判明しました。



ユーザーがユーザー名とパスワードを入力すると、システムは2つのLDAP要求をドメインコントローラーに送信します。最初のリクエストはメールアドレスのリストを返し、ユーザーのログインがこのリストに存在する場合は、2番目のリクエストであるSimpleLDAP認証が送信されます。データはSSL / TLSを使用せずにクリアテキストで送信されます。つまり、LDAPS（LDAP over SSL）は使用されません。これにより、攻撃者は、パッシブMITM攻撃が発生した場合でも、製品で現在許可されているユーザーアカウントを取得できます。







2番目の問題：ActiveSyncプロトコルを使用してExchangeサーバーに接続して着信メッセージを収集するときに、システムがサーバーのTLS証明書の信頼性を検証しませんでした。この場合、攻撃者はアクティブなMITM攻撃を実装し、接続を受信すると、自己署名証明書を与え、接続を確立し、データをExchangeサーバーにプロキシする可能性があります。その場合、MITMは非表示になり、攻撃者はActiveSyncプロトコルで送信されるユーザー資格情報を取得できます。







これらの脆弱性を悪用することにより、攻撃者は理論的にはユーザーアカウントを取得し、それらをActiveDirectoryドメインへの攻撃に使用する可能性があります。これとは別に、TLSを正しく使用することは、ソリューションを実装する企業にとって必要なタスクであることに注意してください。

結果

私たちは常にハッカーの攻撃に直面しており、それらを撃退する方法について確かな経験を積んでいます。私たちは、お客様の境界に置く製品は、独立したチェックの結果を含め、可能な限り安全である必要があると考えています。 Corporate MailMail.ruはまさにそのような製品です。



多くのマイクロサービスを含む大規模なコードベースを顧客のインフラストラクチャに転送して、障害や管理者の介入なしにメールがほとんどの時間で単独で機能するようにするという、骨の折れる作業に直面しました。



変更された承認（Corporate Mailは顧客のADを使用）とメインのメールAPIに最も注意を払うように監査人に依頼しました-これらのコンポーネントのソースコードは詳細に分析されました。その結果、見つかった欠点は主に、ネットワークトポロジの変更と、オンプレミスソリューションに固有の変更に関連していました。



残りのコンポーネント（calendar、ビジネス管理インターフェイスのMail.ru）には、グレーボックスモデルが使用されました。監査人は通常のユーザーの権限でサービスと対話しましたが、実行中のアプリケーションでコンテナに接続でき、APIソースコードを部分的に所有し、開発者に詳細を確認できました。



監査は私たちにとって非常に役に立ちました。一部のコンポーネントにはいくつかの欠点があり、安全な製品を市場に出すためにすぐに修正しました。同時に、他のほとんどのコンポーネントが高レベルで保護されていることを確信しました。私たちは定期的にこのような監査を実施する予定です。私たちの意見だけでなく、独立した監査人の意見においても、当社の製品が常に最も安全な国内ソリューションのトップにあることを望んでいます。



Corporate Mailのセキュリティは、製品自体のセキュリティとクライアントのインフラストラクチャの組み合わせです。つまり、企業データの安全性に対する責任は、私たち、開発者、およびクライアント自身にあります。さらに、インフラストラクチャを欠陥から保護するためのベストプラクティスに関する推奨事項を策定し、製品のインストール中は常にお客様にアドバイスします。