優技録

バグ２つ

• 高負荷状態でサイト側とmonacoind側の通信タイムアウトを誘発し、DBのトランザクション処理をロールバックさせることで同一のギフトコードから複数回利用が可能なバグ
• サイト側でロールバック処理されても、monacoind側では送金処理が行われてしまっていたバグ

この２つのバグにより、同一ギフトコードからn回の送金処理が可能になった

事象

• ホットウォレットの保有コインすべての盗難

発覚の経緯

• 2018年9月1日午前11時、今回とは別件の攻撃に関する注意喚起を受けたのを期に改めて調査したところ、サーバ上にあるホットウォレットがユーザの残高に対して不足していることを確認
  この件を受けてすぐにサーバを切断し確認作業を行っておりましたが、調査の結果ほぼすべてのMonacoinが盗難されていることが判明しました。
• 2018年9月2日午前1時、検証の結果攻撃に至った原因が高負荷時におけるギフトコード機能の不備であることを確認

• 従来よりセキュリティ対策としてサーバへのアクセス制限、各種の脆弱性テストなどを実施していた

原因(推測原因)

• 悪意あるユーザのギフトコード機能を悪用した攻撃
• モニタリング体制の不備
• テストや確認の不備

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

現時点で推測される攻撃の流れについては上記の通りです。

恒久対応

※後で書く

原文

Monappyへの攻撃についてのお詫びとお知らせ (2018年9月2日 午前4時40分更新) いつもMonappyをご利用いただきありがとうございます。 この度、弊サイトに対して外部からの攻撃が発生し、調査の結果ホットウォレット内のMonacoinが盗難されていることが判明いたしました。 全残高の54.2%を保管しているコールドウォレット内のMonacoinについては影響はありませんでした。 詳細な攻撃の内容に関しては現在サービスを停止して調査を進めております。 ユーザーの皆様をはじめ、ご関係者の皆様に多大なるご迷惑をおかけしていますことを深くお詫び申し上げます。 なお、本件についてはblock withholding attackなどによるものではないと思われることを確認しました。 本文章の初版において誤解を招く表現をしてしまっていたことをお詫び申し上げます。 1. 発覚の経緯 2018年9月1日午前11時、今回とは別件の攻撃に関する注意喚起を受けたのを期に改めて調査したところ、サーバ上にあるホットウォレットがユーザの残高に対して不足していることを確認しました。 この件を受けてすぐにサーバを切断し確認作業を行っておりましたが、調査の結果ほぼすべてのMonacoinが盗難されていることが判明しました。 2018年9月2日午前1時、検証の結果攻撃に至った原因が高負荷時におけるギフトコード機能の不備であることを確認いたしました。 従来よりセキュリティ対策としてサーバへのアクセス制限、各種の脆弱性テストなどを実施しておりましたが、今回の攻撃を許してしまう結果となってしまいました。誠に申し訳ございません。 現在も攻撃の内容について調査を行っております。 なお、この件につきましてメールアドレスやパスワードなどユーザー情報などの流出は確認されておりません。 2. 攻撃の経緯 2018年8月27日から2018年9月1日にかけて、攻撃者と見られる複数のユーザーがギフトコードを大量に発行しました。 同8月29日から9月1日にかけて外部受け取り機能（ログインせずにギフトコードを受け取れる機能）を利用してギフトコードを受け取る際、高い頻度でリクエストを行うことで一つのギフトコードに対し数回の送金が行われてしまい、今回の攻撃に至りました。 MonappyからMonacoinを送信する際は、monacoindという別のサーバ上のアプリケーションと通信する仕様になっています。 この通信がタイムアウト等で失敗した場合はサーバダウンなどで送金に失敗しているとみなして、取引をロールバックする仕様となっていました。 また、ギフトコードの処理に関してはデータベースのトランザクション機能等を利用しており、本来同じギフトコードを二重に使用することはできないようになっていました。 しかし、高負荷状態でギフトコードを連続して使用しようとした場合、通信を受け取ったmonacoindの応答に時間がかかり、サイト側ではタイムアウトとなってロールバックされたあとにmonacoind側では送金が行われていました。 この結果、一つのギフトコードから複数回送金されたものと考えられます。 また、この攻撃に際し少額のMonacoinを大量に送付しておくことでcoind送信時の負荷を増大させようとする試みも確認しました。 現時点で推測される攻撃の流れについては上記の通りです。今後も引き続き調査を進めて参ります。 3. 原因 上記の通り、悪意あるユーザのギフトコード機能を悪用した攻撃が直接の原因となります。 また、当方の平時のモニタリング体制の不備、テストや確認の不備などが根本的な要因と認識しております。 4. 影響 Monappyに残高をお持ちの全ユーザー様が対象となります。 5. 今後の対応について まずは今回の攻撃に関する詳細の調査を最優先として、誠実に対応させていただきます。 その後、詳細のご報告、皆様へのご対応、再発防止策などについて対応を進めて参ります。 6. ご注意のお願い ・本件の対応を理由に、Monappyからメール・電話・郵便等でメールアドレスやパスワードなどをお伺いすることはありません。 ・本件に関するメールにファイルを添付してお送りすることはありません。 ・monappy.jp以外のドメインにてmonappyのメールアドレスやパスワードを入力させることはありません。 不審なメールなどには十分ご注意いただくようお願いいたします。 6. 本件に関する連絡先 Monappyサポート support@monappy.jp 7. 変更履歴 2018年9月1日 初版公開 2018年9月2日 午前2時30分 文章の推敲、誤解を招く表現の訂正しました。また、攻撃の詳細について調査結果を追記しました。 2018年9月2日 午前4時40分 攻撃の詳細が確定しました。また、よりわかりやすい表現になるよう追記しました。 皆様には本件においてご迷惑、ご不安をおかけしておりますことを改めてお詫び申し上げます。 今後も引き続き対応を進めて参ります。 2018年9月2日 monappy.jp

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76

Monappyへの攻撃についてのお詫びとお知らせ (2018年9月2日 午前4時40分更新)   いつもMonappyをご利用いただきありがとうございます。   この度、弊サイトに対して外部からの攻撃が発生し、調査の結果ホットウォレット内のMonacoinが盗難されていることが判明いたしました。 全残高の54.2%を保管しているコールドウォレット内のMonacoinについては影響はありませんでした。 詳細な攻撃の内容に関しては現在サービスを停止して調査を進めております。 ユーザーの皆様をはじめ、ご関係者の皆様に多大なるご迷惑をおかけしていますことを深くお詫び申し上げます。   なお、本件についてはblock withholding attackなどによるものではないと思われることを確認しました。 本文章の初版において誤解を招く表現をしてしまっていたことをお詫び申し上げます。     1. 発覚の経緯 2018年9月1日午前11時、今回とは別件の攻撃に関する注意喚起を受けたのを期に改めて調査したところ、サーバ上にあるホットウォレットがユーザの残高に対して不足していることを確認しました。 この件を受けてすぐにサーバを切断し確認作業を行っておりましたが、調査の結果ほぼすべてのMonacoinが盗難されていることが判明しました。 2018年9月2日午前1時、検証の結果攻撃に至った原因が高負荷時におけるギフトコード機能の不備であることを確認いたしました。   従来よりセキュリティ対策としてサーバへのアクセス制限、各種の脆弱性テストなどを実施しておりましたが、今回の攻撃を許してしまう結果となってしまいました。誠に申し訳ございません。 現在も攻撃の内容について調査を行っております。   なお、この件につきましてメールアドレスやパスワードなどユーザー情報などの流出は確認されておりません。     2. 攻撃の経緯 2018年8月27日から2018年9月1日にかけて、攻撃者と見られる複数のユーザーがギフトコードを大量に発行しました。 同8月29日から9月1日にかけて外部受け取り機能（ログインせずにギフトコードを受け取れる機能）を利用してギフトコードを受け取る際、高い頻度でリクエストを行うことで一つのギフトコードに対し数回の送金が行われてしまい、今回の攻撃に至りました。   MonappyからMonacoinを送信する際は、monacoindという別のサーバ上のアプリケーションと通信する仕様になっています。 この通信がタイムアウト等で失敗した場合はサーバダウンなどで送金に失敗しているとみなして、取引をロールバックする仕様となっていました。 また、ギフトコードの処理に関してはデータベースのトランザクション機能等を利用しており、本来同じギフトコードを二重に使用することはできないようになっていました。 しかし、高負荷状態でギフトコードを連続して使用しようとした場合、通信を受け取ったmonacoindの応答に時間がかかり、サイト側ではタイムアウトとなってロールバックされたあとにmonacoind側では送金が行われていました。 この結果、一つのギフトコードから複数回送金されたものと考えられます。 また、この攻撃に際し少額のMonacoinを大量に送付しておくことでcoind送信時の負荷を増大させようとする試みも確認しました。   現時点で推測される攻撃の流れについては上記の通りです。今後も引き続き調査を進めて参ります。     3. 原因 上記の通り、悪意あるユーザのギフトコード機能を悪用した攻撃が直接の原因となります。 また、当方の平時のモニタリング体制の不備、テストや確認の不備などが根本的な要因と認識しております。     4. 影響 Monappyに残高をお持ちの全ユーザー様が対象となります。     5. 今後の対応について まずは今回の攻撃に関する詳細の調査を最優先として、誠実に対応させていただきます。 その後、詳細のご報告、皆様へのご対応、再発防止策などについて対応を進めて参ります。     6. ご注意のお願い ・本件の対応を理由に、Monappyからメール・電話・郵便等でメールアドレスやパスワードなどをお伺いすることはありません。 ・本件に関するメールにファイルを添付してお送りすることはありません。 ・monappy.jp以外のドメインにてmonappyのメールアドレスやパスワードを入力させることはありません。 不審なメールなどには十分ご注意いただくようお願いいたします。     6. 本件に関する連絡先 Monappyサポート support@monappy.jp     7. 変更履歴 2018年9月1日 初版公開 2018年9月2日 午前2時30分 文章の推敲、誤解を招く表現の訂正しました。また、攻撃の詳細について調査結果を追記しました。 2018年9月2日 午前4時40分 攻撃の詳細が確定しました。また、よりわかりやすい表現になるよう追記しました。       皆様には本件においてご迷惑、ご不安をおかけしておりますことを改めてお詫び申し上げます。 今後も引き続き対応を進めて参ります。   2018年9月2日 monappy.jp

@see

• http://monappy.jp/index.html

先に結論

下記を考えて問題がない場合、手作りLANケーブルの規格外による不具合を疑う

クライアント(人)

• 障害時にクライアントが何かトリガーをひいていないかの確認
  ・抜けたLANケーブルをスイッチに接続することで、お客様が一時対応した(ループ)
  ・机を移動させた、
  ・セキュリティソフトを新規導入した
  ・UTMを導入した
  ・サーバを増設した、
  ・ビルの停電
  ・…etc

ネットワーク機器(ルータ, スイッチ)

• LAN接続の接触不良
• ハードウェア破損
• コンフィグミス
  ネットワーク機器とクライアント端末のAuto-Negotiationと固定設定の不一致など
• ログ
  ループやエラーパケットの有無

クライアント端末

• LAN接続の接触不良
• 異常設定
• アプリの不具合
• セキュリティソフト、スキャン
• ネットワークファイルシステム

ISP プロバイダ

• 工事
• 通信障害など

ネット上で公開されているので確認する

障害報告事例  手作りによる規格外のLANケーブルによる不具合

障害内容

• ネットワークの中で一部のパソコンの通信が出来ない

事象

• ネットワークの中で一部のパソコンの通信が出来ない、LANスイッチのリンクランプは点灯する。
• パソコンのLAN機能を10メガ・イーサネットに固定すれば，不調のパソコンでも通信できる
• 配線はケーブルチェッカで確認、リンクアップも問題ない
• 自作ケーブルをすべて市販のケーブルに取り替えた。するとすべてのパソコンが100メガで通信できるようになった。

原因

• 手作りによる規格外のLANケーブルによる不具合

イーサネット・ケーブルは，内部に2本の心線をよって組にしたより対線が4組入っている。10メガ/100メガ・イーサネットでは，4組のうち2組をそれぞれ送信と受信に使って通信する。具体的には，コネクタのピン番号が1番2番の組と3番6番の組を使う。

信号線をより対にするのはノイズ対策のため。100メガ・イーサネットでは10メガに比べて高い周波数の電気信号を使って通信するので，外部からのノイズの影響は10メガより受けやすい。そのため，100メガ・イーサネット用のLANケーブルは，コネクタ部分でよりを戻す長さが13mmまでと規格で決まっている。また，実際に送受信に使うピン番号1番2番と3番6番が，それぞれ1組のより対線に接続されていなければ意味がない。

しかし，奥田さんは「作業を楽にするため，よりは多めに戻していた記憶があります。また，より対線は1と2，3と4，5と6，7と8のように隣り合わせで配線していました」という。この配線では，3番6番の組がより対の組にならない。コネクタ部分も含めて，通常よりノイズの影響を受けやすいケーブルが出来上がっていた。規格に合致しないケーブルがトラブルの原因になっていたのである。

恒久対応

• 手作りのLANケーブルを市販のLANケーブルに交換を行った

原文

ネットワークを利用したり，運用するとき，残念ながらトラブルは避けて通れない。そこで今回は，そんなトラブルの事例を一つ見ていこう。

2003年の春のこと，イベント制作会社の新入社員だった奥田 敦司さんは，翌日から学会が開かれる会場の一角で原因不明のネットワーク・トラブルと格闘していた。このネットワークは，来場者に資料を印刷したりインターネットで調べものをするための環境を提供するもの。インターネットに接続された回線をLANスイッチで分配し，机に並べた10台くらいのノート・パソコンとプリンタをつなぐ小規模なネットワークである。

そのネットワークで，なぜか一部のパソコンがうまく動かない。LANスイッチのリンク・ランプは点灯するのに，通信できないのだ。

奥田さんは最初，パソコン側の設定ミスを疑って，LAN機能の設定をいろいろ変更して試していた。そのうちに，パソコンのLAN機能を10メガ・イーサネットに固定すれば，不調のパソコンでも通信できることに気づいた。100メガ・イーサネット対応のパソコンは，LANの速度の自動認識機能を持っている。この機能をオフにして，通信速度を10メガに設定すると通信できたのだ。

奥田さんは試しに，10メガでしか通信できないパソコンを別のLANケーブルにつないでみた。すると，ちゃんと100メガで通信できるではないか。ここで奥田さんは，LANスイッチとパソコンを接続するLANケーブルに疑いを持った。

パソコン・コーナーで使っていたLANケーブルは，市販のものと奥田さんたちが会場で手作りしたものが交ざっていた。トラブルを起こしたパソコンは例外なく自作ケーブルを使っていた。とはいえ，ケーブルの長さはどれも3～5mで過剰に長いわけではない。作った後にケーブル・チェッカで確認したので，配線ミスもないはず。接続するとリンク・ランプも点灯する。

半信半疑だったが，奥田さんたちは自作ケーブルをすべて市販のケーブルに取り替えた。するとすべてのパソコンが100メガで通信できるようになった。

このトラブルの原因はケーブルの作り方にあった。

イーサネット・ケーブルは，内部に2本の心線をよって組にしたより対線が4組入っている。10メガ/100メガ・イーサネットでは，4組のうち2組をそれぞれ送信と受信に使って通信する。具体的には，コネクタのピン番号が1番2番の組と3番6番の組を使う。

信号線をより対にするのはノイズ対策のため。100メガ・イーサネットでは10メガに比べて高い周波数の電気信号を使って通信するので，外部からのノイズの影響は10メガより受けやすい。そのため，100メガ・イーサネット用のLANケーブルは，コネクタ部分でよりを戻す長さが13mmまでと規格で決まっている。また，実際に送受信に使うピン番号1番2番と3番6番が，それぞれ1組のより対線に接続されていなければ意味がない。

しかし，奥田さんは「作業を楽にするため，よりは多めに戻していた記憶があります。また，より対線は1と2，3と4，5と6，7と8のように隣り合わせで配線していました」という。この配線では，3番6番の組がより対の組にならない。コネクタ部分も含めて，通常よりノイズの影響を受けやすいケーブルが出来上がっていた。規格に合致しないケーブルがトラブルの原因になっていたのである。

このトラブルでは，何台かのパソコンでたまたま問題なく通信できたために，真の原因にたどり着くのに時間がかかった。奥田さんは「100メガ・イーサネットがデリケートだと知っていたけど，これほどとは思っていませんでした」と語った。

（山田 剛良）

@see

• https://tech.nikkeibp.co.jp/it/free/NNW/NETHOT/20041008/151033/

事象

処理遅延が続いた後に処理が出来ず、サービス不稼働の事態に至った

原因

再起動したら消える暫定のコンフィグのまま本番稼動し、再起動した結果、暫定のコンフィグが消えて障害に至った。

恒久対応

• メモリに入った暫定設定を永続ファイルに忘れずに書き込む
• 設定後のダブルチェック
• 本番運用前に動作テスト

>通信できなくなった理由は運用管理サーバーが外部接続サーバーとの通信に必要な「経路の情報」（三橋執行役員）を失ったからだ。みずほ証券は定期メンテナンスのため運用管理サーバーを2カ月に1回の頻度で再起動している。6月23～24日の週末に再起動したところ、経路情報が消えたという。

>みずほ証券は18年5月上旬、それまで使っていた外部接続サーバーが老朽化してきたため、入れ替え用の新たなサーバーを追加し、2系統での運用を始めた。53社分の外部接続機能を段階的に旧サーバーから新サーバーに移行する計画だった。

　ここで新サーバーについて、「暫定的な経路を設定するコマンドで設定してしまった」（同）。この設定だと運用管理サーバーの再起動で経路情報が消えてしまう。新しい外部接続サーバーは二重化していたが、同じ設定方法を採っていたため、再起動で本番機と待機機とも情報が消えた。

本来は再起動しても設定が消えない「正式なやり方」（同）で設定する必要があった。だが、53社の接続機能を全て移行するまで新サーバーは暫定的なものであると誤って認識し、暫定で設定するコマンドを使ったという。

>設定作業は関連会社に委託したが、三橋執行役員は「当社が確認した作業内容に沿って作業してもらった」と話し、障害の責任は自社にあるとの認識を示した。「チェックの甘さがあった」と反省し、今後、漏れがないチェック体制を確立していくとしている。

https://www.nikkei.com/article/DGXMZO33562260Q8A730C1000000/