モバイルバンキングからお金を盗むことは可能ですか？ パート2

私たちは、モバイルバンキングセキュリティのテーマを継続します。 おそらく、多くの人がすでに推測しているように、この記事のスピーチは「中間者」攻撃であるMitMに焦点を当てます。 この攻撃は偶然ではありませんでした。 モバイルバンキングアプリケーションとサーバー間のデータ転送チャネルが攻撃者によって制御されている場合、攻撃者はクライアントのアカウントからお金を盗むことができます。つまり、直接的な金銭的損害を引き起こす可能性があります。 しかし、まず最初に。





一般に、この研究を実施する動機は2つの理由にあります。 最初に、プロジェクトからプロジェクトへと、脆弱性についての悲しい絵が繰り返し見られます。 監査によると、顧客向けのビデオハッキングMBを含む別のショートフィルムが判明しました。 次に、2つの非常に興味深い出版物が発表されました。 「世界で最も危険なコード：非ブラウザソフトウェアでのSSL証明書の検証」と「応用世界でのSSL開発の再考」です。 しかし、まず最初に。

中間者

「MitM」攻撃を実装するための主なシナリオ：

-ユーザーを偽のWi-Fiアクセスポイントに接続する。 これは、最も一般的で実際のMitM攻撃シナリオです。 カフェ、ショッピング、ビジネスセンターで簡単に再現できます。 この攻撃のソフトウェアは、パブリックドメインで簡単に見つけることができます。

-偽のオペレーターベースステーションへの接続。 このスキームは、ハードウェアとソフトウェアの豊富な選択とその低コストにより、大衆にとってよりアクセスしやすくなっています。 状況は可能な限り迅速に制御下に置かれる必要があります。

-感染したネットワーク機器の使用。 ネットワーク機器の感染は、その上での悪意のあるコードの実行だけでなく、たとえば脆弱性を介した標的となる悪意のある再構成としても理解されます。 このような攻撃の実装の多くの例はすでに知られています。

これらは、考えられる多くのシナリオのほんの一部にすぎないことを言う価値があります。 攻撃者が必要とする主なことは、被害者からサーバーへのネットワークトラフィックが、被害者が制御するホストを通過するようにすることです。

悪意のあるSOHOルーター



Team Cymruのメンバーからのすばらしい発見と研究 -彼らは、内部ネットワークに侵入してDNS設定を独自のものに変更したマルウェアを発見しました。 これはどういう意味ですか？ 現在では、内部のマシンだけでなく、WiFiを介してこれらのルーターに固執しているすべてのモバイルデバイスも、攻撃者によって制御されているサイトにリダイレクトされています。 そして、ここにはそのような複雑なMiTMがあります。

Wi-Fiネットワークを備えたモバイルデバイスの詳細：

-既知のWi-Fiネットワークに自動的に接続（PNL、優先ネットワークリストに基づく）

oどこでも簡単な方法で無効化または構成できるわけではありません

-ネットワークIDは、SSID（ネットワーク名）とセキュリティ設定に基づいています

-複数の既知のネットワークがある場合、各OSの接続の選択は異なります



攻撃者は、モバイルデバイスの既知のネットワークと完全に同一の独自のWi-Fiネットワークを展開できます。 その結果、デバイスはそのようなアクセスポイントに自動的に接続し、それを介して機能します。 たとえば、 KARMAプログラムを使用します。 このようなスキームと信頼できるネットワークの単純な管理の欠如により、攻撃者に対する「MitM」の実装が簡素化されます。

チャンネル保護

中断する前に、これができない原因を調べてみましょう。

セキュアチャネルとは、データ転送を保証するために暗号化と整合性制御が使用されるチャネルを意味します。 ただし、すべての暗号化アルゴリズムが永続的であるわけではなく、暗号化が常に正しく使用されるわけではないことを忘れないでください。



チャネルは、3つの主要なグループに分類できます。

-オープン

攻撃者は、被害者と同じネットワーク上にいるため、すべてのクライアントとサーバーの相互作用をオープンな形で見ることができます。

-非標準の方法で保護されています

私たちの実践が示すように、これは最良の解決策ではありません。送信されたデータの侵害につながる多くのエラーにつながります。

-標準的な方法で保護されています

最も一般的なオプションはSSL / TLSです



証明書検証プロセス



このスキームの操作性を確保するために、デバイスには信頼できるルート証明書の特別なストアに保存される多くのルート証明書（CA）があり、署名するものはすべてデバイスに対して信頼されます。



証明書は次のように分類されます。

•system-システムにプリインストールされています

•カスタム-ユーザーが設定

証明書の検証は、デバイスに送信されたものからデバイスが信頼するルート（CA）まで、チェーンに沿って進みます。 次に、ホスト名、失効などのチェックがあります。 ライブラリ、OSなどの実装に応じて、さらにチェックが異なる場合があります（これについては、アプリケーションを攻撃するときにもプレイできます）。

SSLとAndroid

バージョン4.0までのAndroid OSでは、すべての証明書は単一のファイル-Bouncy Castle Keystore Fileに保存されていました。



ファイル：/system/etc/security/cacerts.bks



ルート権限なしに変更することは不可能であり、OSはそれを変更する方法を提供しませんでした。 証明書の変更（追加、取り消し）には、OSの更新が必要です。

Android 4.0以降、証明書を使用する方法が変わりました。 これで、すべての証明書が個別のファイルに保存され、必要に応じて、信頼できる証明書から削除できます。



格納されるシステム：/ system / etc / security / cacerts

カスタム保存場所：/ data / misc / keychain / cacerts-added



Android OSで証明書を表示するには、[設定]-> [セキュリティ]-> [信頼できる証明書]（[設定]-> [セキュリティ]-> [信頼できる資格情報]）に移動します。

Androidのさまざまなバージョンのシステム証明書の数：

-Android 4.0.3：134

-Android 4.2.2：140

-Android 4.4.2：150

証明書の数は、メーカーごとに、デバイスのモデルごとに異なる場合があります。

Android OSにユーザー証明書をインストールするには、ルート証明書をSDカードにアップロードし、設定->セキュリティ->メモリカードからインストールするか、AndroidのMDM（DevicePolicyManager）からバージョン4.4以降でインストールする必要があります。 ソーシャルエンジニアリングを使用してユーザーに証明書を強制的にインストールすることは可能ですが、それほど単純ではありません。

SSLとiOS

iOSでは、組み込みの証明書は表示できず、 Apple Webサイトからのみそれらの情報を取得できます。 ユーザー証明書を表示するには、設定->一般->プロファイルに移動します。



格納されるシステム：/System/Library/Frameworks/Security.framework/certsTable.data

カスタム保存場所：/private/var/Keychains/TrustStore.sqlite3

iOSのさまざまなバージョンのシステム証明書の数（証明書の数は更新可能）：

-iOS 5：183

-iOS 6：183

-iOS 7：211



iOSには、ユーザー証明書をインストールする方法がいくつかあります。

-Safariブラウザーを介して-拡張子が.pemの証明書または拡張子が.profileの構成プロファイルがあるリンクに移動する必要があります

-証​​明書を電子メールに添付する

-MDM API経由



iOSでのソーシャルエンジニアリングによるユーザー証明書のインストールは、Androidよりもはるかに簡単であることがわかります。



ソーシャルエンジニアリングを通じて証明書をインストールするための可能なベクトル：

1）ユーザーは無知のために自分ですべてを行います。 たとえば、特定の証明書をインストールした後、特定のアクセスポイントで無料のインターネットアクセスが約束されます;）

2）悪意のある証明書が組み込まれた中古電話を購入する

3）証明書がたまたま攻撃者の手にある場合（たとえば、彼が電話するように頼んだ場合）、iOSを搭載した電話機に証明書が数秒でインストールされます。

4）「良好な」証明書を持つネットワーク機器-ここではNSAとすべてのもの。 システム証明書を表示する過程で、日本とアメリカの証明書に気付きました。 つまり、彼らはMiTMを実行し、自分自身で証明書に再署名することができ、デバイスは攻撃を「拾い上げる」ことさえしません（そして暗号化にバックドアは必要ありません）。 私たちのものはありません=（

Vulns、バグ、エラー、...

このセクションでは、クライアントアプリケーション（この場合はモバイルバンキング用のアプリケーション）とサーバー間のやり取りの間にどのような問題が存在するかを検討します。

ここに挙げた例はすべて現実のものであり、モバイルバンキングのアプリケーションのセキュリティ監査の過程でこの情報を入手しました。



-HTTPS（SSL）の欠如

どんなに驚くかもしれませんが、1年前、金融取引を含むすべての通信がHTTPプロトコルを使用して行われるモバイルバンキングのアプリケーションに出会いました：認証、転送データ-すべてが明確でした。 これは、金銭的な利益を得るために、攻撃者が被害者と同じネットワーク上にいて、最低限の資格を持っている必要があることを意味します。 その後、攻撃が成功するためには、宛先のアカウント番号と、必要に応じて金額を修正するだけで十分でした。

アプリケーションとサードパーティのサービスとの相互作用については、状況は昨年に比べて少し良くなりましたが、以前のように、それらのほとんどは、攻撃者が簡単に影響を与えることができるオープンチャネルを通じて操作に関する追加情報を求めています。 原則として、この情報は次のものに関連しています。

•銀行ニュース

•ATMの場所

•為替レート

•ソーシャルネットワーク。

•開発者向けのプログラムの統計。

•広告



最良のシナリオでは、攻撃者は被害者に誤った情報を伝え、最悪の場合、被害者のデバイスで実行される独自のコードを挿入することができます。これは、将来認証データやお金を盗むのに役立ちます。 その理由は、Android OSではインターネットからコードをダウンロードして実行できるからです。 特定の状況下では、攻撃者はそのようなコードを開いているチャネルに挿入できます。 または、開発者がオープンチャンネルを介してクラッシュダンププログラムを送信する別の状況では、MBなどの興味深い情報からユーザー名とパスワードを見つけることができます。



-ネイティブ暗号化

また、実際と研究プロセスの両方でこのオプションを満たしました。 私たちはその使用法を理解していませんが、私たちの仮定によると、銀行の確立された内部プロセスに関連している可能性があります。 同時に、SSLのトラフィックは開発者によって追加開発されません。

私たちの実践が示すように、独自の暗号化を使用することは良くありません。 これは暗号化でさえない場合もありますが、単に独自のバイナリプロトコルであり、一見すると暗号化されているように見えます。 したがって、少し手動で分析した後、MiTMも可能です。



-SSLの誤った使用

最も一般的なエラークラスは、SSLの誤用です。 ほとんどの場合、次の理由に関連しています。

•顧客のテストインフラストラクチャの欠如

顧客は、何らかの理由で適切なテストインフラストラクチャを提供できない場合があります。 そして、これは開発者がアプリケーションの正しい動作を検証するために多くのトリックに行かなければならないという事実につながります。

•開発者の不注意

この項目は以前の項目に部分的に関連しており、開発プロセスがさまざまなデバッグコードを使用してテストプロセスを高速化するという事実につながります。 そして、プログラムのリリース前に、彼らはこのコードを忘れています。

•脆弱なフレームワークの使用

多くの場合、開発者はさまざまなフレームワークを使用して単純化します。 言い換えれば、彼らは他の誰かのコードを使用しますが、その低レベルの部分はしばしば隠されていてアクセスできません。 このコードには脆弱性も含まれており、開発者はこれらの脆弱性を推測することさえありません。 これは、モバイルデバイス向けのアクティブなクロスプラットフォーム開発の観点から特に当てはまります。 例、OpenSSLのAppcelerator TitaniumまたはHeartbleed（CVE-2014-0160）の脆弱性（ エクスプロイトでクライアントを攻撃することもできます）。

•開発者エラー

開発者は、SSLを操作するためにさまざまなライブラリを使用できます。各ライブラリには独自の特性があり、考慮する必要があります。 そのため、ライブラリからライブラリへの移行では、開発者が初期化中に定数を誤って使用したり、関数を独自に再定義したりする可能性があります。



SSLを使用する場合の主なエラー：

-チェックを無効にする（デバッグAPI）

-独自の標準ハンドラーの誤った再定義

-API呼び出しの誤った構成

-弱い暗号化設定

-脆弱なバージョンのライブラリを使用する

-呼び出し結果の誤った処理

-ホスト名検証の欠如、または検証するための無効な正規表現の使用



無条件のクラシック-証明書の検証を無効にします！





無条件クラシック-証明書のホスト名検証を無効にします！

ルート証明書の侵害

SSLを使用する場合、ルート証明書に依存します。 彼らの妥協の可能性を排除することはできません-たとえば、Bit9、DigiNator、Comodoの最新の事件を思い出してください。 他の国、トラフィックがオープンであると言える企業の証明書を忘れないでください。

既に示したように、デバイスには多数のCA証明書があり、それらのいずれかが侵害されると、デバイスのほとんどすべてのSSLトラフィックが侵害されます。



CA証明書が侵害された場合：

1）ユーザーは信頼済みから証明書を削除できます

a。 Android OSでは、ユーザーは組み込みの証明書とユーザー証明書の両方でこれを行うことができます。

b。 iOSでは、ユーザーはユーザー証明書のみを削除できます

2）OS開発者はアップデートをリリースできます

3）証明書の発行者は、証明書を取り消すことができます。 証明書検証エンジンはこれを動的に検証できます

a。 AndroidはCRLもOCSPもサポートしていません

b。 iOSはOCSPを使用します



ユーザーが自分でルート証明書を管理することを期待するのは困難です。 したがって、唯一の方法はOSの更新を待つことです。 OCSPはどこでも実装されていません。 システムのセキュリティ侵害と更新の間のユーザーは脆弱です。

CA証明書にはさまざまな種類があります-より正確には、さまざまな目的（メールの暗号化、コード署名など）に役立ちますが、通常は1つの安全なストアに格納され、HTTPS接続の信頼性を確認するために使用できます。 残念ながら、証明書割り当ての正しい検証が常に実装されているわけではありません。 したがって、攻撃者は1つの目的で発行センターから正当な証明書を取得し、それを使用してMitM攻撃中にHTTPS接続を確立できます。

さらに、ユーザーがブラウザで作業している場合、アドレスバーの赤いロックアイコンにより、疑わしい証明書のアクションに気付く場合があります。 同じ状況で、アプリケーションを介して作業する場合、開発者が事前にこれを予測していないため、攻撃が隠されていない限り、ユーザーには通知されません。

SSLピンニング

SSL Pinningアプローチを使用して、侵害されるルートシステム証明書と特別に組み込まれたユーザー証明書から保護できます。

ピンニングは、ホストを期待されるX509証明書または公開キーに関連付けるプロセスです。 アプローチは、アプリケーションでサーバーと直接やり取りするときに信頼する証明書または公開キーを埋め込み、組み込みの証明書ストアの使用を拒否することです。 その結果、サーバーで作業する場合、アプリケーションは、フラッシュされた暗号プリミティブに基づいてのみ証明書の有効性をチェックします。

開発者はアプリケーションが接続するサーバーを正確に把握しており、そのようなサーバーのリストは少ないため、MBアプリケーションはSSLピニングの使用に最適です。



SSLピニングには、主に2つのタイプがあります。

-証​​明書のピン留め：

o実装が簡単

oアプローチの柔軟性が低い

-公開キーの固定：

o一部のプラットフォームでの実装に関する問題

o優れたアプローチの柔軟性



それぞれのアプローチには長所と短所があります。

利点は、次の機能も使用できることです。

1）自己署名証明書

2）プライベートCA発行証明書



SSLピニングを実装するには、いくつかの標準機能を再定義し、独自のハンドラーを作成する必要があります。 AndroidでWebViewを使用し、iOSでUIWebViewを使用している場合、それらの仕様のためにSSLピンニングが機能しないことに注意してください。





SSLピンニングエンジン

App1は有線証明書または公開キーのみを使用して、証明書の有効性を検証します。

証明書の有効性を確認するApp2は、システム証明書ストアに移動し、すべての証明書を順番に確認します。

最近のSSLピニング



Googleサービス向けChrome 13で初めてテクノロジーが広く普及しました。 次はTwitter、Cards.ioなどでした。

現在、モバイルアプリケーションのすべてのストア（Google Play、App Store、WindowsPhone Market）は、すでにこのアプローチを使用してデバイスを操作しています。

SSL Pinningを実装するためのコードは、Android、iOS、および.NETのOWASP Webサイトにあります。 Android 4.2以降、SSLピンニングはシステムレベルでサポートされています。

SSLピンニングバイパス



モバイルデバイスにジェイルブレイクまたはルートアクセスが存在する場合、SSLピンニングをバイパスまたは無効にすることができます。 原則として、これは研究者がネットワークトラフィックを分析するためにのみ必要です。 Androidで切断するには、iOS用のAndroid SSL Bypassプログラム、iOS SSL Kill SwitchおよびTrustMeプログラムがあります。

理論的には、マルウェアはこれらと同じアプローチを使用できます。

他のコードと同様に、SSLピニングチェックは正しく実装されない可能性があるため、これに注意する必要があります。

分析

十分な理論、練習と結果に移りましょう！

この調査では、iOS 7を搭載したiPhoneと4.0.3を搭載したAndroidの2つのデバイスを使用しました

使用したツール：Burp、sslsplit、iptables、openssl。 ここにそのような単純なセットがあります。 ご想像のとおり、動的分析が使用されました-アプリケーションを介して銀行との認証を試みただけです。 すべてのアプリケーションがストア（Google PlayとApp Store）で無料で利用できるのは面白いことです。すべての銀行（いくつかの例外があります）に登録済みのアカウントは必要ありません！ そのため、この実験は、ある程度の知識と「ストレート」な手腕を持つ人なら誰でも実行できます。



次の2つの側面をテストしました。

1）クライアント側でのSSL証明書の検証はどの程度有効ですか：

-自己署名証明書を使用しました

-信頼できるCAが別のホスト名に発行した証明書を使用した

2）SSLピンニングは機能しますか？

-このホストにCA証明書を使用しました。



アクティブな攻撃「MitM」を実施しました。 これを行うために、被害者に、証明書を操作した制御されたゲートウェイを介してインターネットにアクセスするように強制しました。

自己署名証明書を使用して作業をテストするために、独自の証明書を生成しました。

SSL Pinningの存在とホスト名検証の正確さを検証するために、独自のルート証明書を生成し、モバイルデバイスにインストールしました。



結果は次のとおりです。

IOSには6％のアプリケーションがあり、Androidの11％には独自のプロトコルがあり、この相互作用のセキュリティには詳細な手動分析が必要です。 トラフィックの視覚的分析から、明確で読み取り可能なデータと、圧縮/暗号化されたデータの両方が含まれていると言えます。 私たちの実践と世界的な経験から、これらのアプリケーションは「MitM」攻撃に対して脆弱である可能性が高いと言えます。

iOSアプリの14％とAndroidアプリの15％は、自己署名証明書に対して脆弱です。 これらのアプリケーションの資金を盗むのは時間の問題です。

iOSアプリケーションの14％およびAndroidアプリケーションの23％は、CA署名付き証明書ホスト名に対して脆弱です。 また、ホスト名を確認するときに、多くの検証エラーが発生する可能性があることにも注意してください。 このチェックは1つの名前のみで実行されたという事実により、これらの結果は脆弱なアプリケーションの数の下限のみと見なすことができます。

iOSとAndroidの脆弱なアプリケーションを同時に持っている銀行は1つだけであることに注意してください。

SSLピニングは非常にまれです。iOSのアプリケーションの1％、Androidのアプリケーションの8％です。 SSLチェックに関連しない他の理由でこのチェックに合格しなかった可能性があり、このメカニズムを使用しているアプリケーションの割合はさらに少ないことに注意してください。 また、この保護メカニズムを回避しようとせず、その実装の正確さを分析しませんでした。

モバイルアプリケーションのセキュリティ分析の経験からわかるように、ほとんどの場合、証明書の検証を無効にするコードがあります。 関数は通常、Fake *、NonValidating *、TrustAll *などの精神で呼び出されます。 このコードは、テスト目的で開発者が使用します。 この点で、開発者の不注意により、コードはプログラムの最終リリースに落ちる可能性があります。 したがって、あるバージョンでは証明書検証の脆弱性が現れ、別のバージョンでは消滅するため、この脆弱性はバージョンごとに「変動」します。 その結果、このコードのセキュリティは、開発者が編成したプロセスの正確さに依存します。

結論

SSLの不適切な動作は、銀行の顧客の口座からのお金の盗難につながる脆弱性の1つにすぎません。 他の脆弱性（場合によってはそれほど重要ではない）とそのチェーンの使用も、金銭的損失につながる可能性があります。 同時に、サーバー側でも、すべてがうまくないこともありますが（ ABSは時々それ自体を招きます）、これはまったく別の話です。



PS同様の脆弱性が作者によって発見され、 さまざまな BugBountyプログラムに参加する過程で発見されたことは注目に値します;）

PSS膨大な数のプログラムの分析を支援してくれたEgor Karbutov、Ivan Chalykin、Nikita Kelesisに感謝します！