しまたろさんの掃き溜め

免責事項

それなりに勉強して書いたつもりではありますが、書いた本人は法律家ではありません。

本記事の内容に誤りがあり、何らかの損害等が発生した場合も筆者は責任を負いかねます。

この記事を情報ソースとして引用するのはおすすめしません。

ざっくり言うと

URL直打ちで未公開情報にアクセスできてしまった事案。
その情報が未公開情報であることを知りながらアクセスしたのであれば不正アクセスに該当すると思われます。
「他人の家だと知っていたが、鍵が開いてたから入りました」が違法であるのと同様です。
一方、アクセスログがあっただけでは故意性はわからず、もし今後これが犯罪かどうか議論になるとすれば、故意性が争われると思われます。

PR TIMES情報流失事案について

PR TIMESは、企業のプレスリリースの配信を専門にする情報配信サービスです。

自社サイトでの配信との違いですが、まずSEOに強いことが挙げられると思います。実際、個人的な経験として、企業に関してGoogle検索したときにニュース欄の一番最初がPR TIMESであることは少なくないです。

また、PR TIMESによると、今や40％超の国内上場企業がPR TIMESを利用しており、ニュースメディアも今やPR TIMESでネタ探しをしていることが多いかと思います。この2つの要因により、自社サイトでプレスリリースを配信するよりも圧倒的に注目度を上げられるというメリットがあります。

さて、そんなPR TIMESで、「不正アクセス」事案が発生したことが発表されました。以下のリンクがPR TIMESによるプレスリリースになります。

https://prtimes.jp/common/file/20210709_PRTIMES_incident.pdf

上記プレスリリースによると、発表前のプレスリリースに添付されたzipファイルやpdfファイルに適切なアクセス制限がかけられておらず、推測が容易なURLを直打ちすることで誰でもダウンロード可能な状態になっていたとのことです。そのため、発表前のzipファイルやpdfファイルを部外者がダウンロードし、PR TIMES会員企業の発表前情報が流出しました。

本件に関して、（特に技術者界隈に）衝撃を与えたのは、PR TIMESが本事案を不正アクセスとして扱い、「特定 IP アドレスの不正行為についてプロバイダへ申告いたしました」としていることです。というのも、本件において、攻撃者は、アクセス制限を突破したわけではなく、ただ公開されている情報にアクセスしただけだ、という見方もできるからです。おそらく実行者も不正アクセスとは思っていなかったのではないかと思います。

そこで、本記事では、本件が不正アクセスと言えるかどうかの判断をするべく、不正アクセス禁止法と、関連する判例についてまとめます。

不正アクセス禁止法

不正アクセス行為の禁止等に関する法律（不正アクセス禁止法）は、不正アクセスを禁ずる法律です。ここで、不正アクセスとは以下の3つのうちのいずれかに該当する行為として定義されています。（同法第二条4）

一　アクセス制御機能を有する特定電子計算機に電気通信回線を通じて当該アクセス制御機能に係る他人の識別符号を入力して当該特定電子計算機を作動させ、当該アクセス制御機能により制限されている特定利用をし得る状態にさせる行為（当該アクセス制御機能を付加したアクセス管理者がするもの及び当該アクセス管理者又は当該識別符号に係る利用権者の承諾を得てするものを除く。）

二　アクセス制御機能を有する特定電子計算機に電気通信回線を通じて当該アクセス制御機能による特定利用の制限を免れることができる情報（識別符号であるものを除く。）又は指令を入力して当該特定電子計算機を作動させ、その制限されている特定利用をし得る状態にさせる行為（当該アクセス制御機能を付加したアクセス管理者がするもの及び当該アクセス管理者の承諾を得てするものを除く。次号において同じ。）

三　電気通信回線を介して接続された他の特定電子計算機が有するアクセス制御機能によりその特定利用を制限されている特定電子計算機に電気通信回線を通じてその制限を免れることができる情報又は指令を入力して当該特定電子計算機を作動させ、その制限されている特定利用をし得る状態にさせる行為

噛み砕くと、一は「アクセス制御機能が付いているサーバーに他人のパスワードを使ってログインしてはいけません」ということを言っており、二と三は「アクセス制御機能によって制限されている行為を、ログインせずに裏技を使ってできるようにしてはいけません」と言っています。

また、不正アクセス禁止法は故意犯のみが対象になり、過失による行為を罰することはありません。これは刑法38条の規定によるものです。

第三十八条　罪を犯す意思がない行為は、罰しない。ただし、法律に特別の規定がある場合は、この限りでない。

２　重い罪に当たるべき行為をしたのに、行為の時にその重い罪に当たることとなる事実を知らなかった者は、その重い罪によって処断することはできない。

３　法律を知らなかったとしても、そのことによって、罪を犯す意思がなかったとすることはできない。ただし、情状により、その刑を減軽することができる。

不正アクセス禁止法では過失犯に関する規定はありませんので、故意犯のみが罰されるということになります。

よって、今回の一件を不正アクセス禁止法における不正アクセスに該当するかを判断するにあたっては、今回の未発表データへのアクセスが「アクセス制御機能によって制限されている行為だったか」という点、そして「故意であったか」という点が争点になります。

アクセス制限機能によって制限されている行為だったか

前者の「アクセス制御機能によって制限されている行為だったか」という点に関して、今回の件はURLを入力したら見える状態だったんだから制限されていなかっただろう、と思いたくなるのですが、この点に関して重要な判例があるため、紹介します。2003年に発生したACCS事件に関する裁判における判決です。

ACCS事件の概要

とっても簡単に言うと、あるレンタルサーバー上に置かれたCGIメールフォームに脆弱性があり、CGIに対しある文字列をPOSTすることにより、同じくレンタルサーバー上に置かれていたメールフォームのログファイルを表示したという事件です。そのログファイルは、メールフォーム送信者の個人情報を含んでおり、本来部外者のアクセスを想定しないものでした。

被告人側は、CGI自体にはアクセス制限がかかっておらず、被告人の行為が「アクセス制御機能」によって制限されたものとは言えないとして無罪を主張しましたが、実際には以下の理由で認められず、有罪となりました。

判決抜粋

本件サーバの本件ＣＧＩ及び本件ログファイルを閲覧するためには、プログラムの瑕疵や設定の不備がなければ、ＦＴＰを介してＩＤとパスワードを正しく入力しなければならないところを、被告人は、ｃｓｖｍａｉｌ．ｈｔｍｌの内容を書き換えることにより、変更前とは異なるリクエストを本件サーバに送信し、本件ＣＧＩを起動させることで、ＩＤ、パスワードを入力することなく、本件ＣＧＩ及び本件ログファイルを閲覧した

本件においては、前記のとおり、ブラウザで本件ＣＧＩファイル及び本件ログファイルのＵＲＬを入力する方法（ＧＥＴメソッド）によっては、これらを閲覧することができないように設定されていた。他方、本件アクセスは、本件ＣＧＩと組になって使用されていたｃｓｖｍａｉｌ．ｈｔｍｌを改変して、故意にエラーを発生させることで、可能になるものであって、本件ＣＧＩの脆弱性を利用したものであり、あえてその方法を管理者が認める必要性はなく、想定もしていなかったものである。そうすると、本件の各特定利用ができたのは、プログラムないし設定上の瑕疵があったためにすぎないのであり、アクセス管理者が本件アクセス行為のような形で特定利用をすることを誰にでも認めていたとはいえない。よって、本件においても、本件ＣＧＩ及び本件ログファイルの各閲覧は、アクセス制御機能による特定利用の制限にかかっていたものということができる。

（東京地裁平成16 (特わ) 752 - Wikisource、太字は筆者による）

結局、本件ではFTP経由で当該ファイルにアクセスする際にパスワードを要求することをもってサーバーに「アクセス制限機能」があったと認め、またアクセスの方法が「管理者が想定する方法か否か」でそのアクセスを管理者が認めていたかどうかを判断する、という判決が下されました。

PR TIMESに話を戻して

今回のPR TIMESの事案では、未公開情報にアクセスするための正しいインターフェース（例えば会員企業側のユーザーページなど）が何かしら存在したはずで、そこに入るのにはパスワードが必要であるはずなので、これをもって「アクセス制限機能が付いていた」と認められることになります。

そして、今回の方法が管理者の想定外であったことは明らかです。実際、PR TIMESのプレスリリースの中で、（おそらくこの判例を意識してのことと思いますが、）「システム開発段階では想定しなかった（中略）不正利用」と明記されています。

故意性について

ただし、前述したとおり、不正アクセス禁止法に違反するかどうかは故意性が問題になります。

先程のACCS事件の例では、様々な状況から故意性が明らかであるため、有罪となりました。しかし、本件の故意性は明らかではありません。例えば検索エンジンのクローラが今回のPR TIMESの未公開情報にアクセスしても、そこには故意性がないので違法とは言えないということになると思います。また、URLをいじっていてたまたま1回当たってしまったのが未公開情報だった、という状況も故意性は認められないのではないかと思います。

一方で、未公開情報であるということを認識しながら繰り返しアクセスし続けたという状況であれば、違法性が認められる可能性がありそうです。

まとめ

紹介した判例と、いかなるアクセス制御も行っていないサーバーは存在しないであろうという現代の技術的状況を踏まえると、不正アクセスか否かは「管理者が想定していたか」という点において判断されることになります。
よって、アクセスできるからといってなんでもアクセスしていいわけではありません。
これは考えてみれば、「鍵が開いてるからといって他人の家に入っていいというわけではない」のと同じことです。
一方で、故意でなければ違法ではなく、今回のPR TIMESの件において、アクセスログだけでは故意性がわからないことから、今回の件を「違法」と断言するのは現時点では難しく、「特定 IP アドレスの不正行為についてプロバイダへ申告」「不正行為については会員企業様と連携して断固たる措置をとる考え」というPR TIMESの記述は脅し、もしくは会員企業に対するポジショントークに近いものであるという印象を受けました。

注意

この記事は攻撃の実行を教唆する目的で書かれたものではなく、特定の状況におけるセキュリティ上の問題点を指摘するために公開しているものです。この記事に書かれた内容を実行して発生した結果について、筆者は一切の責任を負いません。

はじめに

インターネット上で他人のメールアドレスをmd5で二重ハッシュしたものを公開されている方を見かけたため、解析する実験を行いました。

メールアドレスのユーザー名部分は多くの場合小文字のアルファベットと数字のみ（36文字）のそれほど長くない列で構成されており、ブルートフォース攻撃（総当り攻撃）によって簡単に特定できてしまうと考えられます。

またドメイン部分に関しても、一般の方が使うメールプロバイダが限られていることを考慮すると、サイズの小さい辞書でも十分な確率で当たるものと考えられます。

実験

今回はhashcatという、GPUでハッシュ値を解読するソフトウェアを用いました。

用いたコンピューターは以下のもので、確か8万とかで組んだやつなので十分一般のご家庭にあるコンピューターの範疇だと思います。

GeForce GTX 1050 Ti
Intel Core i5-8400
Ubuntu 18.04.3

解読する対象として、example@example.comをmd5sumコマンドに2度掛けて生成された以下の文字列をhash.txtとして保存しておきます。

9e7bfa73e24be13c18e592d7dedbe793

また、今回はドメイン名が以下の2つのいずれかであることがわかっている状況であると想定し、以下のように辞書ファイルdomain.dictを作成します。

@example.com
@example.jp

この状態で以下のコマンドを実行すると解析が始まります。

./hashcat64.bin -m 2600 -a 7 -i hash.txt -1 '?l?d' '?1?1?1?1?1?1?1' domain.dict

各オプションの意味を説明しますが、詳細はhashcat wikiをご参照ください。

-m 2600 ハッシュ関数の種類を番号で指定しています。2600はmd5(md5(pass))に当たります。
-a 7 モードの指定です。今回はブルートフォースと辞書型のハイブリット（前半のユーザー名部分がブルートフォース、後半のドメイン部分が辞書型）を指定しています。
-1 '?l?d' これを記述しておくことで、この後のマスクパターンで?1がアルファベット小文字と数字の中からどれか1文字、を表すようになります。
'?1?1?1?1?1?1?1' ドメイン名部分で総当りするパターンの指定（マスクパターン）です。今回は英小文字数字の7文字(以下)の列を総当りで解析するように指定しています。

結果

出力の一部抜粋です。

9e7bfa73e24be13c18e592d7dedbe793:example@example.com

Session..........: hashcat
Status...........: Cracked
Hash.Type........: md5(md5($pass))
Hash.Target......: 9e7bfa73e24be13c18e592d7dedbe793
Time.Started.....: Mon Jun  1 22:01:48 2020 (54 secs)
Time.Estimated...: Mon Jun  1 22:02:42 2020 (0 secs)
Guess.Base.......: File (domain.dict), Right Side
Guess.Mod........: Mask (?1?1?1?1?1?1?1) [7], Left Side
Guess.Charset....: -1 ?l?d, -2 Undefined, -3 Undefined, -4 Undefined
Speed.#1.........:   103.0 MH/s (8.73ms) @ Accel:1024 Loops:2 Thr:256 Vec:1
Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 5580521472/156728328192 (3.56%)
Rejected.........: 0/5580521472 (0.00%)
Restore.Point....: 2788687872/78364164096 (3.56%)
Restore.Sub.#1...: Salt:0 Amplifier:0-2 Iteration:0-2
Candidates.#1....: snlsww1@example.com -> 9zv29al@example.jp
Hardware.Mon.#1..: Temp: 50c Fan: 32% Util: 98% Core:1746MHz Mem:3504MHz Bus:16

Started: Mon Jun  1 22:01:00 2020
Stopped: Mon Jun  1 22:02:43 2020

ということで、今回は合計1分43秒でハッシュ値からexample@example.comを当てることができました。

注目するべきはSpeedの行で、今回1秒間で100M個（1億個）のメールアドレスに当たることができました。ここから、例えばユーザー名が英小文字と数字の中から9文字で、ドメインがもともとわかっているようなメールアドレスを解析するには、36⁹/100000000 = 1015599秒、すなわち約11日あればご家庭のコンピューターでも十分に解析できると考えられます。（これは最後の最後まで当たらなかった運の悪い場合なので、実際にはもう少し早く見つかることが期待される）

もちろんクラウドの計算資源を借りるなどすれば、もっと早く計算できる、もしくはこれより1,2文字長いようなメールアドレスの解析も現実的でしょう。

結論

ハッシュだからといってむやみに公開してはいけない
パスワードには大文字記号も使おう
saltとかちゃんとかけよう
md5に掛けた他人のメールアドレスをインターネット上で公開している方は速やかに消すことをおすすめします。

追記

今回の実験では、そもそも既にハッシュ関数としては脆弱であるmd5を用いました。これは、この記事を書くきっかけになった「インターネット上で見かけたメールアドレス」がmd5(md5(m))でハッシュ化されていたためです。

しかし、今回の実験はmd5自体の脆弱性とは関係なく、任意のハッシュ関数で同様の攻撃が成り立つことを補足しておきます。（もちろん関数によってハッシュ化にかかる時間が違うのでその分総所要時間は変わりうるが…）

実際、バリバリ現役のハッシュ関数であるSHA-256(二重ではない)で同様の実験をしたところ、1分34秒で結果が出ています。

ハッシュ関数が何であっても、元データがある程度推測可能なもののハッシュを公開してはいけません。