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

高木浩光@自宅の日記

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

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サイト運営者から状況を発表せよというのは酷な話ではないだろうか。

本日のTrackBacks(全69件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20080603]

Information Security ネットワーク 攻撃手法*3 ARPスプーフィング 攻撃対象となる2つのホスト(端末)に対し嘘のARP応答パケットを送り込むことでARPテーブルを汚染し、攻撃対象間の通信を傍受したり改ざんしたりする攻撃。 対策 WindowsXPでのARPスプーフィング対...

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

高木氏が良いこと言った。 通信路上の改竄攻撃発生に、Webサイト運営者が説明責任を負うのか? そもそもインターネットとはそんなものなのだから、 (中略) すべてのWebサイトはSSLを用い、すべてのページを https:// で提供しなければならないことになる。それは現実的で..

about 高木浩光@自宅の日記 - 通信路上の改竄攻撃発生に、Webサイト運営者が説明責任を負うのか? HTTPSを導入してもアクセラレータとかが噛んでればどこかで剥けたりするわけだし、the InternetにはHTTP以外にもプロトコルはある。(いわゆる、「インターネット(笑)」..

Cnetブログ

高木浩光@自宅の日記 - 通信路上の改竄攻撃発生に、Webサイト運営者が説明責任を負うのか?

検索

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

最近のタイトル

2024年12月02日

2024年11月24日

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

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|
<前の日記(2008年05月31日) 次の日記(2008年06月08日)> 最新 編集