ソースコードの高リスクの脆弱性、および多くのリモートバンキングシステムの認証および承認メカニズムの深刻な脆弱性により、不正なトランザクションが許可されたり、外部の攻撃者がシステムを完全に制御したりすることもあり、重大な財務上の損失や評判の低下につながる可能性があります。 このような結論は、多くのロシアの大手銀行のセキュリティ分析作業中に2013年と2014年にPositive Technologiesの専門家によって発見された銀行システムの脆弱性の研究に含まれています。 この記事では、この研究のいくつかの結果を紹介します。
この調査では、個人（77％）および法人（23％）向けの28のリモートバンキングサービスシステムを調査しました。 その中には、サーバーとクライアントの部分に代表されるモバイルバンキングシステムがありました（54％）。 システムの3分の2（67％）は（Java、C＃、PHPを使用した）独自の銀行であり、残りは有名なベンダープラットフォームに基づいて展開されました。 リモートバンキングシステムの大部分（74％）は商用運用されており、顧客が利用でき、リソースの4分の1はテストベンチであり、運用準備が整っています。
一般的な結果
明らかになったRBSシステムの脆弱性のほぼ半分（44％）には、高レベルのリスクがあります。 ほぼ同じ数の脆弱性のリスクの程度は中程度と低い（26％と30％）。 全体として、調査対象のシステムの78％でリスクの高い脆弱性が特定されました。
ほとんどの脆弱性（42％）は、開発者がインストールしたリモートバンキングシステムのセキュリティメカニズムの実装におけるエラーに関連しています。 特に、このカテゴリの脆弱性には、識別、認証、および承認メカニズムの弱点が含まれます。 2番目は、アプリケーションコードのエラーに関連する脆弱性です（36％）。 残りの脆弱性は、主に構成の欠陥に関連しています（22％）。
RBSシステムで最も一般的な脆弱性は、使用されているソフトウェアとユーザー識別子の予測可能な形式（システムの57％）を識別する可能性に関連する脆弱性でした。 システムの半数以上（54％）が、「クロスサイトスクリプティング」などのプログラムコードでエラーを検出しました。 システムにこの脆弱性が存在する場合、銀行のクライアントが特別に細工された悪意のあるリンクをクリックすると、攻撃者はこのクライアントの権限でリモートバンキングシステムにアクセスできます。
また、ユーザーセッションに攻撃を実装できる脆弱性も広がっています（システムの54％）。 これには、セッションの不正終了、不正なCookie設定、1人のユーザーに対する複数のセッションの並列操作の可能性、クライアントのIPアドレスへのセッションバインドの欠如などに関連する脆弱性が含まれます。攻撃が成功した場合、攻撃者はその特権でユーザーの個人アカウントにアクセスできます。
最も一般的なものの1つは、システムの46％で発見された高リスクの脆弱性、「外部XMLエンティティの埋め込み」でした。 その操作の結果、攻撃者は脆弱なサーバーに保存されているファイルのコンテンツ、ホストの開いているネットワークポートのデータを取得し、RBSシステム全体のサービス拒否を引き起こし、場合によっては脆弱なサーバーに代わって任意のホストになり攻撃を仕掛けることができます。
調査対象のリソースの半分（52％）でさまざまな脆弱性を使用することにより、RBSシステムのサービス拒否が引き起こされる可能性があります。
RBSシステムの最も一般的な脆弱性（システムの共有）
最も一般的な脆弱性のリスクは中または低です。 ただし、特定のRBシステムの機能の詳細と組み合わせることで、機密データの盗難（システムの89％）や資金の盗難（46％）など、深刻なセキュリティ脅威の実装につながる可能性があります。
調査対象のRBSシステムには、ロジックレベルで多くの重大な欠点もあります。 たとえば、多くのシステムで、数値丸めアルゴリズムの誤った使用に基づく攻撃の可能性が発見されました。 攻撃者が0.29ルーブルを米ドルに換算するとします。 1ドルのコストが60ルーブルの場合、0.29ルーブルの量は0.0048333333333333333333333333333333ドルに相当します。 この金額は小数点以下2桁、つまり0.01ドル（1セント）に丸められます。 その後、攻撃者は0.01ドルをルーブルに戻し、0.60ルーブルを受け取ります。 したがって、攻撃者は0.31ルーブルを「獲得」します。 この手順が自動化された結果、1日あたりのトランザクション数と最小トランザクションサイズに制限がなく、競合状態タイプの脆弱性が悪用される可能性があるため、攻撃者は無制限の金額を受け取ることができます。
開発者の脆弱性
高リスクの脆弱性は、特定の銀行の社内開発システム（40％）よりもベンダーが提供するRBSシステム（49％）の方が大きくなっています。 さらに、プロの開発者が提供するシステムには、アプリケーションコードレベルで、プロプライエタリシステムよりも平均で2.5倍の脆弱性が含まれています。 この事実は、ベンダーのソフトウェアを使用する場合、銀行はコードの品質の点で主にサプライヤーに依存しているという事実によって説明できます。 同時に、RBSシステムの複雑なアーキテクチャ、クロスプラットフォーム、および多数の機能により、ベンダーがアプリケーションコードレベルで適切なレベルのセキュリティを常に提供できるとは限りません。
システムの脆弱性の平均数（開発者による）
セキュリティの脆弱性
RBSシステムを識別するメカニズムの最も一般的な欠点は、アカウント識別子形式の予測可能性です（システムの64％）。 システムに存在するいくつかの識別子を知っている攻撃者は、その形成メカニズムを計算し、正しい識別子を選択できます。 調査したシステムの32％は、システム内の既存のアカウントに関する情報を開示し、入力された識別子の存在に応じてさまざまな回答を返しました。 20％のケースで、リモートバンキングシステムに上記の識別の脆弱性の両方が含まれていました。
調査したシステムの58％には、認証メカニズムの実装に欠陥がありました。脆弱なパスワードポリシー、資格情報に対する不十分な保護、CAPTCHAメカニズムをバイパスする機能、または個人アカウントの入力時に必須の2要素認証がありません。
認証メカニズムの脆弱性（システム共有）
システムの79％には、さまざまな認証およびトランザクション保護の欠陥が含まれていました。 さらに、42％の場合、攻撃者はユーザーデータ（個人データ、アカウントに関する情報、支払いなど）への不正アクセスを取得でき、13％のシステムでは、攻撃者は他のユーザーに代わって銀行業務を直接行うことができます。
認証メカニズムの欠点（脆弱なシステムの共有）
モバイルクライアントの脆弱性
Androidクライアントソフトウェアは、iOSアプリよりも脆弱です。 特に、非常に危険な脆弱性は、Androidのアプリケーションの70％およびiOSのアプリケーションの50％で発見されています。
脆弱なクライアントモバイルソフトウェア共有
平均して、各Androidベースのアプリケーションには3.7の脆弱性が含まれていますが、iOSアプリケーションの場合、この数字は2.3です。
安全でないデータ送信に関連する最も一般的な脆弱性（73％）はモバイルRBSシステムで発生し、その後、不十分なセッション保護（55％）とモバイルアプリケーションでの安全でないデータストレージ（41％）が続きました。
最も一般的なモバイルシステムクライアントソフトウェアの脆弱性
モバイルRBSシステムの最も一般的な脆弱性のリスクは中または低ですが、場合によっては、特定された欠陥の全体が深刻なセキュリティ脅威を実現することを可能にしました。 たとえば、調査したアプリケーションの1つが、銀行から受信したSMSメッセージを含むブロードキャストメッセージを送信し（トランザクションのワンタイムパスワードと共に）、サードパーティアプリケーションによって傍受される可能性がありました。 さらに、このモバイルアプリケーションはユーザーアカウントなどの重要なデータを記録しました。その結果、ユーザーのデバイスが悪意のあるコードに感染した場合、攻撃者はモバイルアプリケーションのユーザーに代わって認証データへのフルアクセスを取得し、トランザクションを実行できます。
この調査のより詳細な結果は、モスクワで5月26日と27日に開催されるPositive Hack Days V国際セキュリティフォーラムで発表されます。 そこで、 ATMやオンラインバンキングサービスをハッキングするためのコンテストに参加できます 。 ウェブサイトwww.phdays.ruの詳細。