大規模DDoS攻撃で暗号化メッセージアプリ「Threema」が数時間にわたりダウン

セキュアメッセージングサービスのThreemaは、大規模なDDoS攻撃によりホスティングプラットフォームへのアクセスが妨害され、約4時間にわたりオフラインとなりました。

水曜日の午前中にサービス障害が再発しましたが、その日のうちに通常運用が再開されました。攻撃者はキャンペーン中トラフィックパターンを絶えず変化させており、同社が通常は目立った支障もなく対応している日常的なDDoS活動と比べ、今回のインシデントは封じ込めが難しいものとなりました。

影響の程度は、顧客がサービスをどのように導入していたかによって異なりました。

OnPrem導入環境は稼働を継続

ホスティング型を利用していたユーザーは支障を受けましたが、顧客のインフラ上で自己管理していたOnPrem導入環境は稼働を続けました。

Threema Workを利用している法人顧客には、水曜日の午前中にサービスが不安定である旨のメール通知が送られ、アカウントマネージャーが個別の問い合わせに対応しました。同社のインシデントレポートによれば、自己管理型の導入環境はインシデントの間ずっと利用可能な状態を保っていたとのことです。

攻撃者がシステムやユーザーデータにアクセスした形跡は確認されていません。暗号化は無傷のまま保たれ、今回の攻撃はサービスの可用性のみを妨害しました。

防御に合わせて変化し続けた攻撃パターン

Threemaにとって、繰り返し発生するDDoS攻撃の試みは珍しいことではなく、そのほとんどはほとんど、あるいはまったく目立った支障を引き起こしません。しかし8月のこのキャンペーンは、攻撃が長期間にわたって継続し、トラフィックパターンが何度も変化したため、封じ込めがより困難なものとなりました。

サービスは火曜日の夜に完全にオフラインとなり、水曜日の午前中に攻撃が再発してより短時間の中断を引き起こした後、正午頃に通常運用が再開されました。

別の技術的な問題により、ステータスページの更新が一時的に妨げられたため、同社は障害情報の発信にソーシャルチャンネルを使わざるを得ませんでした。

サービス安定化後、同社は悪意のあるトラフィックが自社インフラに到達する前に上流でフィルタリングする、追加の防御策を導入しました。こうした制御は、フラッド型トラフィックがネットワーク容量を消費するのを防ぐのに役立つもので、DDoS攻撃の予防・対策の一環として一般的に用いられています。また、ステータスページにインシデント履歴とRSSフィードを追加する計画もあるとのことです。

障害発生後も攻撃者は特定されず

このキャンペーンの犯人については、依然として不明のままです。ThreemaのコロケーションプロバイダーであるNineも標的にされており、Threemaが主たる標的だったのか、それとも複数の標的の一つに過ぎなかったのかは判然としていません。

暗号化メッセージングが組織のサイバーインシデント対応の一部を担っている場合は、同一のプロバイダーやインフラに依存しない第二の通信手段を確保しておくべきです。この予備手段をインシデント対応計画に組み込み、障害が発生して現場の担当者が場当たり的な対応を強いられる前に、切り替え手順をテストしておくことをお勧めします。

プロバイダーを評価する際は、暗号化に関する管理体制だけでなく、DDoS対策や障害時のコミュニケーション体制についても確認すべきです。フィルタリングがどこで行われるのか、主要なステータスシステムが機能しなくなった場合に管理者はどのように警告を受け取れるのかを、あらかじめ確認しておく必要があります。

OnPrem環境が中断なく稼働し続けたからといって、自己ホスティングが常に安全であるとは限りません。とはいえ今回の事例は、プロバイダー側で障害が発生した際に、導入アーキテクチャの違いがリスクの度合いをどう左右し得るかを示しています。

関連ニュース: SafePalの顧客約40,000人の情報が漏えいした事件が発生しており、この情報が標的型攻撃を狙う詐欺師にとってより説得力のある材料を与える可能性があります。