<前の日記(2008年05月31日) 次の日記(2008年06月08日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 3029   昨日: 6103

2008年06月03日

通信路上の改竄攻撃発生に、Webサイト運営者が説明責任を負うのか?

セキュリティホールmemoにまとめられているように、レンタルサーバのさくらインターネットのLAN上で、ARP spoofing攻撃が発生したのではないかとの疑いが浮上している。しかし、現時点でさくらインターネットは公式にそれを認めておらず、誰も確かな情報として伝えることができない状態にある。

昨今、Webサイトのコンテンツを改竄されて、ウイルスファイルへのインラインリンクを埋め込まれる手口の被害が多発しており、その際、Webサイトを改竄されたサイト運営者は、サイトを訪れた一般利用者に対してウイルス感染に注意を呼びかける告知を出すというのが、慣例になりつつある。これは、サイト運営者がサイト管理の不備を詫びる意味も含めて、行われている発表であろう。

しかし、ARP spoofingによる「改竄」は、Webサイトのコンテンツが改竄されるわけではない。これは、通信路上での通信データの改竄の一種である。

元々、SSLの必要性が語られるときによく言われるように、インターネットでは通信路上で通信データを盗聴されたり改竄されたりする危険がある。通信路上のどのあたりで盗聴や改竄が行われるかは、いろいろなケースがあるだろうが、危ういのは通信の端点に近いところであろう。

図
図1: 通信路上の攻撃ポイントと影響の範囲

図のA、B、E、Gの矢印は、通信路上の攻撃され得る場所を表す。Gはブラウザ利用者の最も近いところで攻撃されるケースを表しており、たとえば、公衆無線LANやホテルのインターネット接続サービスを利用しているときに、偽アクセスポイントに繋いでしまったり、ホテルの他の部屋から攻撃を受けるケースなどが該当する。この場合、改竄の影響を受けるのは図中の「ブラウザ」のユーザだけとなる。

図のC、D、Fの矢印は、「サーバ」の内容を閲覧する他のユーザに向かう通信の分岐点を表している。「ブラウザ」のユーザは、Fのユーザと比較的長い経路を共有する(同じ経路を使う)が、Cのユーザとは共有している経路が短いことを表している。

レンタルサーバ事業者内ネットワークでのARP spoofingは、Aのポイントでの攻撃である。その影響は、「ブラウザ」のユーザだけでなく、C、D、Fのユーザにも同様に波及し得る。どこから見てもWebページが改竄されているように見えることから、Webサイト運営者が「お詫び」を発表せざるを得なくなることがあるかもしれない。

しかし、Gのポイントで攻撃が行われたときに、Webサイト運営者が「お詫び」を発表するということはないだろう。この場合、信頼性の低い接続で、https:// でないページを閲覧した「ブラウザ」ユーザにも責任がある。

ならば、Eのポイントで攻撃が行われたときはどうなのか。何割かの多数の人々に影響を及ぼしたとき、サイト運営者が「お詫び」を発表しなくてはいけないのだろうか? サイト運営者には何の過失もないのに? なら、Bのポイントで攻撃されたときはどうなのか?

そもそもインターネットとはそんなものなのだから、SSLの必要性が説かれる。盗聴されて困る情報を送信したり閲覧するときは、ユーザ自身が https:// のページであることを確認して使う。

しかしすべてのWebページが https:// で提供されているわけではない。通信路上で盗聴されたり改竄されても「まあ、いいだろう」というサービスではそのような判断がなされている。

そうすると、通信路上で <iframe>などでウイルスファイルへのインラインリンクを埋め込まれる可能性があることを、放置してよいのかということになる。もし、「放置してはならない」とする考え方を選択するなら、すべてのWebサイトはSSLを用い、すべてのページを https:// で提供しなければならないことになる。それは現実的でないだろう。

じつのところ、ウイルスファイルへのインラインリンクを埋め込まれることは、さして重大なことではない。なぜなら、ウイルスファイルへのインラインリンクが埋め込まれていても、Webブラウザ側に脆弱性がないならば、ウイルスが起動することはなく、無問題だからだ。

それなのに、Webサイトのコンテンツを改竄された企業が「お詫び」を発表するのが慣例になりつつあるのは、ウイルスのことというよりも、サーバの管理に不備があって侵入を許したこと自体が重大であるからであるはずだ。同じ原因によって個人情報の漏洩等も生じ得る状態にあったのではないかという点から、サイト運営者に責任が問われている。

それに対比すれば、ARP spoofingによって通信路上の改竄でHTMLを差し替えられる被害に遭ったWebサイト運営者に対して「お詫びを出さなければならない」とする世論があるとしたら、それはおかしいのではないか。

さくらインターネットは、今回の件について現時点では次のように発表している。

[6月3日追記]

同一ネットワーク内に収容された一部サーバにおいてネットワーク設定の誤りにより、本障害が引き起こされました。

該当のサーバを隔離することにより、障害は解消しております。

[6月3日追記2]

弊社技術者により該当のサーバを調査しましたところ、上記サーバにてクラッキングされていたことが判明いたしました。そのため、影響範囲のお客様サーバへ WEBによるアクセスを行った場合、改竄されたウェブページが表示される事象がございました。状況によっては、ウイルス等による被害をうけられる可能性がございました。

影響を受けられたお客様へは、別途状況の連絡をさせていただきます。

障害発生のお知らせ, さくらインターネット

Webサイト運営者から状況を発表せよというのは酷な話ではないだろうか。


<前の日記(2008年05月31日) 次の日記(2008年06月08日)> 最新 編集

最近のタイトル

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|12|
2025|01|02|03|04|05|06|10|11|12|
<前の日記(2008年05月31日) 次の日記(2008年06月08日)> 最新 編集