Monappyに対する攻撃をFISC安全対策基準に基づいて考えてみる

Monappyに対する攻撃をFISC安全対策基準に基づいて考えてみる

※この記事は、2018年9月3日14:00時点の「MonappyにおけるMonacoinの不正出金につきまして」をベースに記載しています。このサイトでは、数回の更新が行われていますが、更新履歴は記載されていますが、更新箇所が特定できない記載となっています。このため、今後の更新内容によっては、報告書の内容と、以下の記事の内容が一致しなくなる可能性があります。この記事においては、更新内容は箇所と時刻を明記した上で記載して参ります。

Monappyにて、ホットウォレット内の仮想通貨が盗難の被害にあっていることが分かりました。この記事では、現状把握できている状況から、FISC安全対策基準への準拠状況について解説します。

 

経緯が報告されているのは以下のサイトです。
(※今後、事象の推移に伴って内容が変更された場合、必ずしも以下の引用とは一致しない可能性があることに注意してください)

MonappyにおけるMonacoinの不正出金につきまして

MonappyからMonacoinを送信する際は、monacoindという別のサーバ上のアプリケーションと通信する仕様になっています。この通信がタイムアウト等で失敗した場合はサーバダウンなどで送金に失敗しているとみなして、取引をロールバックする仕様となっていました。また、ギフトコードの処理に関してはデータベースのトランザクション機能等を利用しており、本来同じギフトコードを二重に使用することはできないようになっていました。しかし、高負荷状態でギフトコードを連続して使用しようとした場合、通信を受け取ったmonacoindの応答に時間がかかり、サイト側ではタイムアウトとなってロールバックされたあとにmonacoind側では送金が行われていました。この結果、一つのギフトコードから複数回送金されたものと考えられます。また、この攻撃に際し少額のMonacoinを大量に送付しておくことでcoind送信時の負荷を増大させようとする試みも確認しました。

 

経緯をわかりやすくすると、以下のようになります。

<当時の仕様(前提)>

  1. Monappyにおいては、Monacoin用のサーバに実装されたmonacoindというアプリケーションが存在していた。
  2. Monacoinを送信する際は、monacoind(以下、monacoindサーバ)を使用していた。
  3. monacoindの通信がタイムアウトした場合は、(送信失敗と判断して)取引をロールバック(元の状態に戻す処理)していた。
  4. ギフトカード機能では、データベースでコードの未使用・使用済みを判定しており、1つのコードは1回限り利用可能としており、再利用はできないようにしていた。
  5. このため、通常であれば、以下の処理フローとなる。
  • 【正常終了】monacoindサーバからMonappyサイトに対して正常終了が通知され、直ちにデータベースのギフトカードの使用不可状態が確定する。
  • 【異常終了】monacoindサーバからMonappyサイトに対して異常終了が返却され、直ちにデータベースがロールバックされるため、再利用が可能となる。
  • 【タイムアウト】monacoindサーバに処理を依頼したMonappyサイトでのタイムアウト検知により、直ちにデータベースがロールバックされる。

これを、図解するとスライド1のようになります。

ところが、高負荷となった場合、monacoindの処理は結果的に正常に終了したものの、タイムアウト(所定時間内に結果が通知されないこと)となり、Monappyサイトはタイムアウト処理に遷移し、ギフトカードは再度利用可能な状態に戻ってしまいました。

こちらは、図解するとスライド2のようになります。

 

  • 攻撃者は高負荷状態を生み出すため、多数の取引を生成します。
  • Monappyは高負荷状態となったたことで、取引のタイムアウトが発生します。結果として、タイムアウト処理によりギフトカードを再利用可能とします。
  • Monappyはタイムアウト後の処理結果を処理するロジックを実装しておらず、タイムアウト後の送金成功後も、ギフトカードは利用可能なままとなっていました。
  • 攻撃者は同じカード番号による送金が可能となり、これを繰り返しました。

この原因に、FISC安全対策基準を適用すると、以下のようになります。

1.タイムアウトが多発した状態が検知されず、取引が継続可能となっていたこと。

【実92】テスト段階におけるソフトウェアの品質を確保すること。
システムテストにおける、各機能が高負荷になった場合のシナリオが存在していなかったか、負荷レベルが低かったことが想定されます。高負荷試験が正しく実施されていた場合、今回の不具合は検出される可能性は比較的高かったのではないかと推測されます。

【実101】負荷状態の監視制御機能を充実すること。
報告書では、8月29日から9月1日にかけて、ギフトカードからの送金を指示していると記載されていることから、この負荷状態は長時間継続したものと考えられますが、9月2日に別件調査の際に発覚したと記載していることから、検知されていなかったものと推定されます。
ただし、FISC安全対策基準でも、タイムアウトが多発する場合は「入力電文を制限することで回復することが多い」という記載にとどまっており、次の【統5】の記載が反映されておらず、こちらはこちらで記載の改善が求められます。

【統5】サイバー攻撃対応態勢を整備すること。
この基準には、「サイバー攻撃の発生直後はシステム障害と区別ができない可能性も想定されるため、システム障害時にサイバー攻撃の可能性を考慮する」と明確に記載されています。数日間にわたるシステムの負荷が継続していること、タイムアウトが発生していることが検知されれば、「別件での調査中に発覚」という事態は防げたものと推測されます。

2.タイムアウト後に処理結果が到着した場合の処理が実装されなかったこと。

こちらは業務的な問題なので、FISC安全対策基準には記載がありません。しかし、金融庁も指摘しているとおり、まずは利用者の保護を優先すべきであり、タイムアウト処理後に「成功」または「失敗」の通知が来た場合であっても、データベースを更新する必要がありました。
この実装があれば、少なくともタイムアウト後に「成功」が到着した場合、ギフトカードの利用ができなくなることから、ある程度の被害軽減が可能だったのではないかと推測されます。実際には、高負荷状態が継続していたため、この実装だけで被害を軽減させることは難しいでしょうが、上記1の対策と組み合わせることで、被害を軽減することは可能であったと推測されます。
(金融機関間の送金においては、プロトコルが明確となっていることから、通常は発生しませんが、ギフトカードというのは、金融機関間の送金では存在しませんから、この点については金融機関とは異なる点かもしれません)

良かった点としては、「コールドウォレットに保管していた」ことです。この点については(コールドウォレットの管理が十分であるという前提で)非常によかったと思っています。

まとめ

FISC安全対策基準の適用ができていなかった、というのは、ある意味では結果論かもしれません。それでも、正しい試験が実施できていたら、監視状態が正しく設定されていたら、今回の事象を防ぐことはできたものと推測されます。金融機関では、サービス提供に向けたチェックリストのようにFISC安全対策基準を利用しています。

CRYPTOMOでは、FISC安全対策基準を準用するためのコンサルティングサービスを提供しています。適用にあたって不安がある、どのように考えれば良いかわからない、そういったご相談に応じております。ぜひ一度ご相談ください。