office氏不正アクセス事件の公判内容が明らかに 90
ストーリー by Oliver
不正アクセスの定義を探す 部門より
不正アクセスの定義を探す 部門より
Anonymous Coward曰く、"2月のストーリー「ACCS事件でoffice氏逮捕」で話題となった、不正アクセス禁止法違反の罪で起訴されたoffice氏の第2回公判の様子をレポートする記事がITmediaニュースに「ACCS不正アクセス事件裁判、一部非公開に」と出ている。この記事によると、証人が「自社のサーバ構造などを公開法廷で話すと、サーバを狙い打ちにした不正アクセス行為を誘発する」と主張したため、証人尋問以降はすべて非公開となったもようだ。
一方、ひとりの傍聴人「ちせ」氏による第一回公判と第二回公判のレポートが提供されている。
これらによると、弁護側は、「サーバ全体にIDやパスワードがかかっていたかどうかということより、特定の行為ごとに不正アクセスであるか否かを判断すべきである」と主張し、「CGIというものは、設定者の主観の通りにではなく、記述された指示の通りに動くものである」とし、「office氏のやったことは、ファイル名を指定してそのファイルを読んだだけである」としているようだ。また、ITmediaの記事によると、「倫理面の問題は法改正で解決できる」という理由により、無罪にすると社会に悪影響を及ぼすから有罪にするというような判断は不要だとする主張もあったようだ。"
てやんでい! (スコア:4, おもしろおかしい)
主観のとおりに動いてもらっちゃ、プログラマはおまんま食い上げでい!
Re:てやんでい! (スコア:5, 参考になる)
「プログラムはあなたが思ったようには動かないが、あなたが書いたようには動く」
Re:てやんでい!(オフトピ) (スコア:1)
PHP5にはしてやられた・・・
Re:てやんでい! (スコア:1)
#アセンブリ言語でチェックしないと分からないので、けっこー面倒。
Re:てやんでい! (スコア:1)
確か昔アセンブラで68881でだっけな?痛い目にあった覚えが。
Re:てやんでい! (スコア:1, 参考になる)
Re:てやんでい! (スコア:1)
「プログラムは思ったとおりに動かない。ただプログラムした通りに動く」
っていうのが、マーフィーの法則にあったように記憶しています。
chomy
それで結構です。 (スコア:1)
OS書いた人が会社辞めちゃったからなんてのはなしね。
Re:てやんでい! (スコア:4, おもしろおかしい)
Re:てやんでい! (スコア:2, すばらしい洞察)
プログラマは注文主の主観の範囲内でうまく動いているように見せるのが仕事ですもんね。
Re:てやんでい! (スコア:1, すばらしい洞察)
Re:てやんでい! (スコア:0)
隠蔽によるセキュリティ (スコア:3, すばらしい洞察)
Re:隠蔽によるセキュリティ (スコア:3, すばらしい洞察)
Re:隠蔽によるセキュリティ (スコア:1, 興味深い)
これで安全と思ってしまい、チェックが不十分になってしまう
ことが弊害なのです。「隠蔽することそれすなわち悪」では
ありません。
また、実際問題ソース公開によって穴を付かれることはあるで
しょうから、隠蔽もある程度のセキュリティ向上にはなり得ます
(最終目的を穴がないことではなく、穴を付かれないこと、と定義
した場合)。
ソース公開というのは、短期的にはマイナスだけど、長期的には
プラスになるかもよ、という戦略なのです。
あと、世の中セキュリティが全てではありません。ソース公開に
よりノウハウを盗まれたりする場合もあります。これはソース公開
戦略のデメリットの一つと言えるでしょう。最終的にはメリットと
デメリットを天秤にかけ、当事者が判断すべき事柄です。
Re:隠蔽によるセキュリティ (スコア:1)
今回の件での隠蔽によるセキュリティって、ディレクトリ構造の隠蔽って意味なんじゃないんでしょうか?
もちろん、もっと低水準な、実装依存のセキュリティもあるでしょうが…
Re:隠蔽によるセキュリティ (スコア:1)
隠蔽することそのものは一応安全になるけど、 それでぐらつくようなセキュリティはセキュリティではない、 よって公開しても問題がないレベルのセキュリティにすべき、 よって公開しても問題がない、っていう話だと思います。 特に、情報っていうのは盗んでも、モノがなくなるわけじゃないんで、気付かないっていう性質も関係してると思います。
オープンソース云々ってのは反例であって、世の中全てにオープンソースを勧めてるわけじゃないです。 オープンにしてもセキュアなような暗号化その他の技術が必要ではあるけど。
Re:隠蔽によるセキュリティ (スコア:1)
なのです。例えばデイレクトリ構造を隠蔽しているとしてパスを秘密鍵だと解
釈すると、それは鍵としてどうですか?cgiのクエリー文字列にパスが含まれ
たりしてたらどうですか?
だから、
>隠蔽することで
>これで安全と思ってしまい、チェックが不十分になってしまう
>ことが弊害なのです。「隠蔽することそれすなわち悪」では
>ありません。
これは全然関係ありません。んで、
>オープンにしてもセキュアなような暗号化その他の技術
これが鍵によるセキュリティの典型的な例。というわけ。
Re:隠蔽によるセキュリティ (スコア:1)
違います。ダメなプログラムは公開しても勝手に強くなってくれたりはしません。私の知る範囲では。
隠すこともセキュリティの為になる方へ一票投じます。公開した方が…という論者には、それを検証する手段が増えるだけだという言葉を贈りたいと思います。
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:隠蔽によるセキュリティ (スコア:1, 興味深い)
Re:隠蔽によるセキュリティ (スコア:2, すばらしい洞察)
の話であって、そこで「ソフトウェアのソースコードの公開」
の話を持ってくるのはたとえ話以上の何物でもないと思います。
# たとえ話はフレームのもとって言うじゃありませんか。
Re:隠蔽によるセキュリティ (スコア:1)
裁判とは言ったつもりがなくても、読み取った人がどう解釈するかで決着します。
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:隠蔽によるセキュリティ (スコア:1)
>はしません。私の知る範囲では。
勝手に強くなって欲しい…
切に願う…
ごめんなさい。IDです。
----------------------------------------
You can't always get what you want...
Re:隠蔽によるセキュリティ (スコア:1, すばらしい洞察)
何でもかんでも「隠蔽は無意味」とか言ってると、セキュリティの教育を受けてないんだろうなってのが垣間見えますよ。
サーバの構造を非公開とすることによって、不正侵入を企てようとする者は、サーバの構成を知るために(既に知っている場合に比べて)より多くの足跡を残す可能性が高まり、それだけ検挙につながる可能性が高くなります。
無論、隠蔽だけで安全になるわけではありませんが、隠蔽が全く無意味な訳ではありません。
訳の問題 (スコア:2, 参考になる)
別の枝でも補足しましたが、obscurity に頼ったセキュリティは全体としてセキュリティがないも同然という話です。
余談ですが、パスワードも一つでも弱いのがあると、システム全体の脆弱性になります。一般のユーザに設定させると、辞書語と数字の組み合わせを選ぶことが多く、制限や監視がなければクラックできます。
自動生成された長いランダムなパスワードをユーティリティで保存して使うか、非対称暗号を使うなど方法が勧められており、 従来の「パスワード」によって得られるセキュリティはだんだん 無いよりはマシだけど安全ではないってレベルになってきてると思います。
Re:隠蔽によるセキュリティ(余計なもの (スコア:1, おもしろおかしい)
「我々はスーパーハカー。隠蔽は無意味だ」
#ちゃちゃなのでAC
Re:隠蔽によるセキュリティ (スコア:1)
> 無論、隠蔽だけで安全になるわけではありませんが、隠蔽が全く無意味な訳ではありません。
パスワードなどがかかっていたのならともかく、ファイル名をスキャンするだけならそもそも検挙できるのかねえ?
って、今回したのか!?
Re:隠蔽によるセキュリティ (スコア:1)
…どちらにしても、証人の発言には不可解な部分があるように思うのですが。
法律ができそこない (スコア:2, 興味深い)
ということかなと思う。
アクセス制御機能の有無で線引きするところに無理があったのではないか。今のようなウェブが主流になる前の知識で作られた法律のように思えるが、どうか。
そこで裁判員制度ですよ (スコア:2, 参考になる)
俺もだ。
主張の解読を試みる (スコア:1, 興味深い)
不特定多数を相手にするサービスは保護対象外との主張でしょうかね。
#HTTPやSMTP、anonymous FTPは全て保護対象外になってしまいそうです。
> 「CGIというものは、設定者の主観の通りにではなく、記述された指示の通りに動くものである」
実装上の脆弱性は全て保護対象外という主張のようですね。
> 「office氏のやったことは、ファイル名を指定してそのファイルを読んだだけである」
XSSやSQL injectionを試みても同様のことが言えそうですね。
攻撃する立場から言えば、非常にうれしい解釈ですが、守る立場から見ると「不正アクセス禁止法の存在の否定」に映りますね。
解説(Flamebait? -1) (スコア:3, 参考になる)
>不特定多数を相手にするサービスは保護対象外との主張でしょうかね。
>#HTTPやSMTP、anonymous FTPは全て保護対象外になってしまいそうです。
全て保護対象外です。
原則、HTTPやSMTP、anonnymous FTPはアクセスを識別符号によって制限していないからです。
>> 「CGIというものは、設定者の主観の通りにではなく、記述された指示の通りに動くものである」
>実装上の脆弱性は全て保護対象外という主張のようですね。
識別符号によらない情報を入力して制御を奪うことは禁止されていますので、これはそうですね。
>> 「office氏のやったことは、ファイル名を指定してそのファイルを読んだだけである」
>XSSやSQL injectionを試みても同様のことが言えそうですね。
否。
アクセス制御が行われていないディレクトリ以下のファイルをHTTPで読み出すことは、不正アクセス禁止法の処罰の対象外ですが、
それに対してXSSやSQL injectionはアクセス制御機構を無効化するような情報を入力する行為なので処罰の対象になります。
参考
http://www.ipa.go.jp/security/ciadr/law199908.html
>攻撃する立場から言えば、非常にうれしい解釈ですが、守る立場から見ると「不正アクセス禁止法の存在の否定」に映りますね。
守る立場の人は、どこまで法律の守備範囲か知らないと。
「きちんと守ってくれなかった」と後で非難されることにもなりかねません。
# フレームのもとっぽいのでAC
Re:解説(Flamebait? -1) (スコア:2, 参考になる)
XSS はクライアント側で任意の JavaScript を動かせる場合があるというものですよ。その結果として、クッキーを盗めることがあって、さらにその盗んだクッキーを使うとセッションハイジャックができるって話。
「アクセス制御機構を無効化するような情報を入力する行為」というのは、盗んだクッキーを使う行為の部分。
XSS があるかどうかは、そういう攻撃が起き得るかの可能性を示しすだけなわけで、それ自体がアクセス制御機構を無効化するわけじゃない。
SQL injection も、もろにアクセス制御機構を回避する攻撃に使う場合(パスワード欄にシングルクオート+云々を入れるとか)もあるけど、それ以外の攻撃もあるね。
Re:解説(Flamebait? -1) (スコア:2, 興味深い)
アクセス制御をしている「ツモリ」(主観)の
運営者、製造者がいたとします。
しばしば、SQLinjectionやXSSは【非常に単純な】
設計上もしくは実装上の漏れです。素人でも見つけられますね。
このような単純ミスの場合には、ディレクトリ丸裸と同様に
アクセス制御機構が働いていたとは見做しにくいものです。
CGIやWebアプリを作成した時に、未知のXSS脆弱性や
未知のSQLinjectionを作りこんでしまった、、ということは
考えられません。タネはとっくの昔に割れているものです。
設計者や製造者、運営者は、既知の基本的なセキュリティー上
の防止策を実装すべきです。
>XSSやSQL injectionはアクセス制御機構を無効化するような
情報を入力する行為
アクセス制御機構が働いていないように作ってしまっていながら
不正アクセス禁止法で守ってもらえると考えるようならば
そのようなサイトは個人情報を扱うべきではありません。
問題になっている森川氏のCGIもとっくの昔にネタばれしている
ような古典的な注意点を守っていない点で罪が重いものです。
なんでもかんでもhiddenな属性に格納して保護しているつもり
になっているなんて、あなたの目には見えないが機械には丸見え
ですよ?と森川氏に言いたいですね。
、「CGIというものは、設定者の主観の通りにではなく、
記述された指示の通りに動くものである」とは、このことです。
アクセス制御をしている「ツモリ」(主観)ではなく、アクセス
制御機構そのものが働かないような作りこみをワザワザしていた
のですから。
さて、一方において、Webアプリ構築時点では未知であった、
ブラウザの脆弱性によりXSS脆弱性が露呈し、攻撃者が悪用
したとしたらどうでしょう。もしも攻撃者がクッキーを盗み出し
たとするならば、この時点で法の定める不正アクセスです。
クッキーはユーザIDとパスワードの代替物でありそのことを
もって個人を特定しているわけですから。不正に鍵を入手した
段階でアウト。
もうひとつの別な角度からの観点を併せて書いておきます。
とあるサイトの馬鹿げた作りこみによるXSS脆弱性を悪用。
攻撃者は犠牲者のブラウザ上にてクッキーを盗み出さずに
ニセ画面を表示するだけのXSSによるHTMLインジェクション
を行ったらどうでしょう。
例えば、株式など経済的な問題のある風評を流す目的で
エセニュースページを犠牲者に見せる事が可能です。
この場合には、攻撃者は単純な防衛もしていないサイトの
XSS脆弱性を踏み台にし、被害者を騙すことになります。
肝心なことは、このケースではユーザIDやパスワードとは
無関係であることです。いかにも悪事なのですが、現行法の
定めるところの不正アクセスではありません。別な法の運用が
はかられるべきでしょう。適切な法があるかどうかは不明です。
事例もないですし。
| 慈愛こそ慈愛
自己レス追加 (スコア:1)
おおざっぱにいえば、URL(URI)はプロトコル別にRFCで定義されて
いますし、実はRFCで未定義であって別途定めるW3Cの規定により
定められるURLもあります。
このたび問題になったCGIのだらしない作り方を詳しく調べましたら
次のようなことがわかりました。すなわち、上で書いた標準的な書法
で記述されたURLの形式で、晒された個人情報に到達できてしまうの
です。言い換えますと、代表的なブラウザであれば、あなたがブラウ
ザを起動後、このURLをアドレスバーにいれてエンターキーを叩けば
問題の個人情報がブラウザの画面に表示されるのです。
このようなシステムが果して個人情報へのアクセス制御をしていたと
言えるでしょうか?まさしくディレクトリ丸見えの延長上にあるので
す。どこか不特定多数が訪問する掲示板やフォーラムなどで、この
URLを晒したり、あるいはリンクを作っておいたりしたら、不特定
多数がアクセス制御を侵犯したことに、、ならないですよねぇ。。。
そのぐらい今回の森川氏謹製のCGIはだらしないものなのです。
ちなみにこのCGIはmethod=POSTであることは上の論議に折込済みで
す。
あ、余談ながら、この際ですので言っておきましょう。Web画面から
メールを飛ばすFORMのCGIを良く見かけます。HTMLソース表示をして
みたら宛先がform内に書いてあることが極めて多いですよね。もう、
その瞬間スパム送り放題なのですがいいのですかねぇ。これなども
異常に古典的なものなのですが。もし皆さんがたまたま使おうとした
そのようなCGIが変な作りになっていたら、作成者に是非メールで
注意してあげてください。
office氏の場合には、メールの宛先ではなく、ファイル表示パスが
FORM内に書いてあっただけですが、ヨワヨワですねぇ。
| 慈愛こそ慈愛
Re:自己レス追加 (スコア:1)
ぜんぜん話が違うような。
Re:自己レス追加 (スコア:1)
>>あなたがブラウ ザを起動後、このURLを
>>アドレスバーにいれてエンターキーを叩けば
>>問題の個人情報がブラウザの画面に表示されるのです。
>そういう嘘を平然と書けるってのはどういう神経してるんだろうなぁ。
あ、これは複数の人に確認をとってあってもらっているんで
大丈夫ですよ。私のバカな法律の解釈論とは異なりましてPoCですので。(^^)
Proof of ContentなURLが実在するんです。
>そういう嘘
という名前の予想をくつがえす反例を作ることは
しばしば予想を証明することよりも簡単です。
かたや全面戦争ですし、かたや、運が良ければ一点突破でOKですので。
| 慈愛こそ慈愛
Re:解説(Flamebait? -1) (スコア:1)
法文からすると、アクセス制限をしているところに、
人のパスワードを使って入ったり、セッションハイジャック等のなりすまし行為をすることを言うのでしょう。
単純ミスによる脆弱性をもつソフトを使ったことによって、
パスワードがばれたり、クッキーを取られたりしても、
不正アクセス行為をされたら、不正アクセス禁止法で処罰されるべきです。
重要な他人の情報を持つものは、
少なくとも既知の脆弱性をもつソフトを使うべきでないというのは、
不正アクセス禁止法とは関係なく、また別の倫理上の話でしょう。
Re:解説(Flamebait? -1) (スコア:2)
>>単純ミスによる脆弱性をもつソフトを使ったことによって、
>>パスワードがばれたり、クッキーを取られたりしても、
>>不正アクセス行為をされたら、不正アクセス禁止法で処罰される
>>べきです。
そりゃそうでしょ。 だから?
論点は、公知の脆弱性をついて情報を閲覧する行為が不正アクセス
禁止法にひっかかるかどうかでしょ?
問題は、旧来のパソコン通信や専用線による通信等で想定されていた
不正アクセス行為という定義で、現在の状態をカバーできなくなった
ことにあるんだけど。
ただ、不正アクセス法を強化するんなら、管理者などへ対する
管理責任を明確に定義して、管理放棄や管理不行き届きを処罰対象
にしてほしいね。
Re:解説(Flamebait? -1) (スコア:1)
>禁止法にひっかかるかどうかでしょ?
裏技とセキュリティホールの境界を誰が決めるんだろう。という思いがずっと引っかかっています。
Re:解説(Flamebait? -1) (スコア:1)
違います。
| 慈愛こそ慈愛
Re:解説(Flamebait? -1) (スコア:1)
といっても論拠だせないでしょうから、かわりに法律を引用しておきます。
つまり、
1. 他人が所有しているパスワードを使ってはならない
2. 他人にパスワードを知らせてはならない
という簡潔な結論が導き出せるはずなのですが、どうですか?
そんなわけで、両人とも微妙に間違っていて、#580587のACさんの
「使ったとき」というのは、それだけではないという話になります。
stwo さんの間違っている点は「不正に鍵を入手した段階でアウト。」で、
アウトなのは入手した側ではなく教えた側。
ただしこの法文から見るに、意図して教えた場合に限定されるでしょう。
これでも論拠を出さない「ちがいます」の応報をしたいのなら、
日記なりでどうぞ。
バカだけどIDで。 (スコア:1)
====
三 電気通信回線を介して接続された他の特定電子計算機(ブラウザ)が有するアクセス制御機能(サーバとの間のクッキーのやりとり機構)によりその特定利用(クッキーにより本来ステートレスなHTTPを介して通信者の同一性を保証することで特定利用可。)を制限されている特定電子計算機(サーバ)に電気通信回線を通じてその制限を免れることができる情報又は指令を入力(あらかじめ防衛することが不可能であったブラウザの未知のXSS脆弱性を悪用)して当該特定電子計算機(サーバ)を作動させ、その制限されている特定利用(個人認証用の特定のクッキーを得る)をし得る状態にさせる行為
====
クッキーのやりとりの仕組みはアクセス制御機構の一部。
未知のXSS脆弱性によりやりとりの仕組みの穴をつき
クッキーを盗んだら既にアウト。
クッキーを使って、さらに個人情報を盗んだらもっとアウト。
ダブルプレー。
【。。。をし得る状態にさせる行為 】
というところがポイント。ここでワンナウト。
。。。をし得るだけでなく、したら、ツーアウト。
篠沢教授に10000点。
| 慈愛こそ慈愛
Re:バカだけどIDで。 (スコア:1)
サーバとは異なる実装をしていますが、やはり「誰かが」「その権限で」
使っていると思われてなりません。
| 慈愛こそ慈愛
Re:主張の解読を試みる (スコア:2, 興味深い)
それはそれで間違ってないと思いますよ。
そもそも「不正アクセス」の定義が充分じゃないのですから、
攻める立場でも守る立場でもなく、
スクリプトの設定ミスを指摘して逆切れされた経験を持つ者から見ると、
ノーガードでうろうろしてる馬鹿に肩が当った程度で、
「アクセス管理者の許諾を得ていない接触だ!」と
因縁付けられる事体の心配はしたくないので、
「二条三項」はきっちり押さえておいて頂きたい。
法律はノーガードにお墨付きを与えているワケではない。
Re:主張の解読を試みる (スコア:1)
私が示す事実は、私達が(たとえばIE)などのブラウザの
アドレスバーにRFCとW3Cのコモンな文書で規定された正当なURLを
入力してエンターキーを一回押したときに、
くだんのCGIは個人情報を暴露しまくりだったのです。
| 慈愛こそ慈愛
Re:主張の解読を試みる (スコア:1)
知っていたにもかかわらず、めんどくさいので
ローカルにダウンロードしてHTMLソースを書き換えて
アクセスしてみただけですね。おんなじことです。
| 慈愛こそ慈愛
Re:主張の解読を試みる (スコア:1)
POSTとGETの違いも分かっていないのか…。
上でまじめに書いてしまった私がバカみたいです。
一部非公開 (スコア:0)
防御対策を施したけど、興味本位のアタックをされるのが嫌ってのなら納得。
Re:一部非公開 (スコア:2, すばらしい洞察)
「piblic_html以下」とか「cgi-bin以下」の「ディレクトリ構成」の事ですよね?
それ以外の意味での『サーバー構造』なんて、この際誰も問題にしてないでしょうから。
然るべきパーミッションを設定しているか、
然るべきユーザ認証を設定しているか、
然るべきCGIスクリプトへの修正を施しているか、
その辺りに未だに自信が無いんじゃないでしょうか。