最近のセキュリティ関連ブログの中から、気になる話題を取り上げる。最初はロシアのカスペルスキーラボのクラウドコンピューティングに関連した注意喚起だ。

　同社は、サイバー犯罪者がマルウエアツールキットのホスティングに米アマゾンのクラウドサービスを悪用しているとして注意を促した。

　クラウドサービスプロバイダーが無償提供するオンラインストレージは、サイバー犯罪者がマルウエアの保守や拡散に利用しているが、たとえ有償でもこれらサービスはサイバー犯罪者にとって魅力的。アマゾンのクラウドサービスなら、「Amazon S3」（Amazon Simple Storage Service）が都合がいいという。

　カスペルスキーラボの調査によると、サイバー犯罪者はこの数週間、Amazon S3からマルウエアツールキット「SpyEye」のサイトを運営している。

SpyEyeサイト

　Amazon S3を利用するサイバー犯罪者にとって障害の一つは、Amazon Web Services （AWS）アカウントを作成しなければならないこと。アカウント登録には正当なID情報と決済手法が必要となるため、サイバー犯罪者は明らかに盗んだデータを使ってこの難題を克服している。

　アマゾンのクラウドサービスが7月にマルウエアを拡散するために著しく悪用されたことがデータから分かる。以下のグラフは、7月後半にマルウエア拡散に使われたドメインを示している。

　サイバー攻撃者がクラウドストレージなどのサービスを悪用する傾向は既に広がっている。この傾向はオンラインストレージサービスにとって今後を左右する問題であり、特別な対策を講じる必要があるとカスペルスキーラボは警鐘を鳴らしている。

Twitterのトレンド機能を悪用したインジェクション攻撃

　米ウェブセンスは、Twitterを悪用した大量インジェクション攻撃を検出したと報告した。この攻撃により、既に1万以上のWebサイトが被害を受けているという。

　同社が注目したのは、埋め込まれた不正コードが6000Kバイト超と大きいサイズであること。これほど大きいと多くの悪意あるコンテンツを含むことができ、攻撃者は最終的なリダイレクトコードを隠ぺいするために5層の手法を使用していた。リダイレクト先はTwitterのトレンド機能に応じて決定され、それは毎日変化し、昼と夜でも異なる。

インジェクションコードの一部

　リダイレクトコードは、Twitterのトレンド機能に問い合わせ、2〜3日中のトレンドデータを取得する。トレンドデータの7時または18時の上位トレンドワードをキーとして使用し、複雑な計算を実行したのち、最終的なリダイレクトURLを生成してiFrameタグに埋め込む。

リダイレクトURLを埋め込んだコード

　コードは毎日、二つのURLを計算する。これら二つは、不正コードを埋め込まれたサイトにユーザーが訪問する時間によって使い分けられている。一つは5時から16時、もう一つはそれ以外の時間帯向けだ。

　これらURLは攻撃ツール「Blackhole Exploit Kit」が仕込まれたサイトにユーザーを誘導し、偽ウイルス対策ソフトをインストールするよう促す。ウェブセンスは、Blackhole Exploit Kitをホスティングしている以下の7件のIPアドレスを特定している。

46.165.192.232
46.20.119.80
66.135.59.143
216.155.147.12
64.150.187.129
200.35.147.150
108.59.2.202

IPv6のフラグメンテーション

　最後に、米アーバーネットワークスが紹介しているIPv6におけるフラグメンテーション（断片化）について。いわゆるインシデントに関する内容ではないが、重要なテーマなので紹介しておく。同社がこのテーマを解説しているのは、フラグメンテーションがIPv4ではしばしばセキュリティ上の脆弱性の元になってきたため。フラグメンテーションによって、ファイアウォールやルーターといった中継ノード、パソコンなどのエンドノードで、予期しない現象が起こることがある。これがIPv6ではどう変わるかを解説している。

　IPv6ではパケットを断片化できないという誤解があるが、ルーターやファイアウォールなどの中継地で断片化できないという点では合っている。しかし発信元ではパケットを断片化できる。そのため受信ノードと中継ノードは、断片化したパケットを適切に処理できなければならない。

　IPv6でパケットの断片化が行われる場合に、注意すべき重要な問題が二つある。一つは、断片化拡張ヘッダーを使う必要があること。断片化拡張ヘッダーを使用するため、レイヤー4ヘッダーのバイトオフセットは8バイトに変換され、各ノードはレイヤー4ヘッダーを特定する方法を心得ている必要がある。二つ目は、IPv4と同様に、一つの断片だけがレイヤー4ヘッダーを持ち、他の断片が持たないこと。中継ノードはレイヤー4ヘッダーを持つ断片のレイヤー4情報とほかの断片を関連付けるか、あるいは、断片が関連する結合パケットのレイヤー4情報を認識せずに断片を転送しなければならない。

　IPv4と異なり、IPv6では中継ノードは断片化を行わないため、発信元は回線の最大転送ユニット（MTU）を超えないサイズのパケットまたは断片を送る必要がある。

　IPv4では「あれば便利」だったパス最大転送ユニットディスカバリー（PMTUD）は、IPv6では極めて重要だ。パスのMTUに対して大きすぎるパケットを中継ノードが受け取った場合、パケットを破棄し、「パケットが大きすぎる」というICMPv6メッセージを発信元に返す。これはとても大事なことで、もし発信元がパケット過大メッセージを受け取らなければ、目的地に届かないパケットを送り続けることになり、重大なリスクが生じる。

　PMTUDを実行しない場合には、発信元はIPv6の最小MTUである1280バイト以内でパケットを送らなければならない。一部のインターネットサービスでは、PMTUDによって起こる問題を回避するために、1280バイト以内でパケットを送信する。1280バイト以内で送信すれば、パケットは決して破棄されることがなく、送信元はパケット過大メッセージに頼る必要がない。この方法は安全だが、世界規模のIPv6トライアル「World IPv6 Day」の期間中に判明したように、議論の余地が大きい。