10/4の報道でタリーズの情報が流出したという報道があった。今回はその原因を考察・解説してセキュリティに関して活かしていけたらと思う。
Togetterまとめにはある程度の情報があったのだが、もう少し整理、深堀りして、エンジニアっぽい解説をしていく。
※僕はエンジニアではあるものの今回の件は専門外の領域であり、調べながら書いている部分もある。誤解や間違いもあるとは思うので、ご指摘の声はお問い合わせからしていただけたらと思う。
1.事件の概要
5月30日タリーズオンラインストアにて不正アクセスによってシステム障害が発生。
その後第三者委員会によって被害件数を調査したところ、約9万件の個人情報が流出し、うち5万件がクレジットカード情報が漏洩している可能性があることが分かり、発表したとのこと。
タリーズオンラインストアの本文は下記サイト参照。
2.攻撃手法（Xの情報を元に）
motican2010という方がタリーズオンラインストアのアーカイブを見てみると難読化された謎のコードがあることを発見。
難読化されているコードを解除すると、とあるサイトにデータを飛ばしていることを確認。
つまり攻撃者はサーバーに何らかの方法でJavaScriptを書き換え、入力したデータをそのまま別のサイトへ流していたとのこと。
サーバーへの侵入方法は、SSHやRDPなどのパスワードや秘密鍵が漏れて侵入できたのか、ファイルを書き換えたり遠隔で操作できるようなウィルスにかかっていたのかなというのが推測。だけど、正直その先は分からない。
XSSではない
X上では、「クロスサイトスクリプティング(XSS)では？」という声もあったが、IPA非常勤講師で「体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践」の著者である徳丸浩氏がこれを明確に否定。
徳丸氏は、サーバー側のJavaScriptファイルの改ざんとどうやって判断したのだろうか。
恐らく、該当のスクリプトが埋め込まれていたページはユーザーの入力を表示したり、操作するようなページではないからだろう(別に確認した訳じゃないけど)。
XSSについては、僕がちゃんと書いた記事が一応あるので、そちらを参照いただけたら。
何が言いたいかというとXSSは、ユーザーが入力したデータを表示するページで、データにスクリプトを埋め込むことで、そのページを開いたユーザーのブラウザ上でスクリプトを実行する攻撃である。
つまり、ユーザーによって埋め込まれたスクリプトでないので、XSSには該当しない。
水飲み場攻撃
また、XSSとは別に、「水飲み場攻撃では？」という声もあった。
水飲み場攻撃とは、ユーザーが普段使用しているWebサイトを改ざんし、マルウェアに感染させるというもの。
水飲み場攻撃の本来の目的としてはユーザのデバイスをウィルスに感染させることなので、ユーザーの情報を盗んだ今回の事例だと、若干用語のニュアンスが異なるが”水飲み場攻撃的”と言えるかもしれない。
データベースが漏洩？
また、クレジットカードの情報が漏洩したのはデータベースの情報が漏洩したからでは？という声もあったが、徳丸氏によると2018年6月の改正割賦販売法の施工により、現在は、クレジット情報を非保持化の目標達成のためにECサイトではデータベースに保管しないのがほとんどと言います。
データベースの漏洩によってクレジット情報が盗まれたのは2013年まで遡る必要があるのだとか。
3.その他の用語
とりあえず、直接的な要因は何らかの方法でサーバーに侵入しJavaScriptを書き換えたということだろうというのが有力だ。
ただ、それ以外の用語が飛び交い、あたかも原因かのような印象を受けたので、それらの用語について整理したいと思う。
slick.min.js
JQueryの画像スライドで使用されているプログラムファイル。このファイルが書き換えられたことで、個人情報が攻撃者のサーバーに送られていた。しかし、このファイルが元々悪性のプログラムだった訳ではなく、このファイルの脆弱性をついた攻撃であった訳ではない。
このプログラムの脆弱性の有無は知らない。
eval
JavaScriptの関数で、String型のスクリプトを無理矢理、計算する機能。攻撃者に悪用される可能性があり非推奨である。今回は攻撃で確かに使用はされていたが、そもそもJavaScriptが書き換えられていたので直接的な原因ではない。
Content Security Policy(CSP)
CSPを該当のページにつけておくべきであったなどの声も見掛けられた。
Contet Security Policy(CSP)とは、ブラウザ上で、信頼できるリソースに対してのみ参照や通信を許可することのできる仕組みである。
HTTPレスポンスにCSPヘッダを加えることで許可しているリソース以外の通信や参照を防ぐことができるので、例えば、カード決済代行社以外との通信を遮断したり管理者に通知するようなことができる。
ただ、今回の攻撃の場合はサーバー内に入り込んでスクリプトを書き換えている攻撃であるため、そもそもCSPヘッダーを付与していたところで該当のプログラムを書き換えられていた可能性はる。
その点で比較的効果はあるものの根本的な防御策や解決策にはなりづらいかなと考える。
4.対策
本件は、2点の対応すべき点がある。
サーバーへの侵入させていたということとプログラムが改善されていたことである。その二点への対策を述べていこうと思う。
サーバーへの侵入への対策
まずはサーバーへの侵入への対策である。
ここについては、どういう手段で侵入されたのかは不明だが、取り敢えず基本的なことを。
サーバーへのリモート接続を使用している場合は、秘密鍵やパスワードは漏洩させない、定期的に変更する、余計な通信プロトコルは許可しない、接続元となるIPを制限することなどが挙げられる。
また、OS、ミドルウェア、プログラミング言語に脆弱性が発見された場合はなるべく早く更新を行い、発見された侵入経路となりうる穴を塞ぐことが必要だろう。
プログラムの改ざんについて
次はプログラムの改ざんについてである。
純粋にプログラムが書き換えられていたことが原因であるなら、プログラムが書き換えられていないかを逐一チェックすればいい。意図していないプログラムファイルの変更があればそこは書き換えられている可能性がある。
ただ、ライブラリの中身が書き換えられていたということを考えると、目視で確認するのはまあまあ手間がかかる。どのタイミングでどの粒度で確認するか、それが果たして現実的な策なのか。
そのように考えた時に、僕的には解決策は2つあるかなと思っている。1つ目は、ライブラリの中身までGitで管理して、リリースの度に想定外の差分が生まれてないかを確認すること。
デメリットとしてはライブラリのソースまで管理しないといけなくなるため管理範囲が広がり、デプロイに時間がかかる。
2つ目はCDNを使用すること。サーバ内部にライブラリのソースを置くのではなく、CDNを使用すること。ただ、これは原因を転嫁しているだけで、ネットワークを使用した攻撃やそもそも配布しているソースが書き換えられる可能性は捨てきれない。（実際過去にCDNを狙って攻撃があったのかは知らない。)
以上が考えられる対策である。
一応攻撃者が外部にいることを前提で書いているが、開発者および運用者の中など身内に攻撃者がいる場合は上記の対応策も無意味になってしまう。
なんかファイル書き換えた時のログやアラートを出して、ファイルの変更を管理したり、デプロイを完全に自動化してサーバーにはリモート接続すらできない運用にするみたいな方法はあるかは知らないが、できれば有効かもしれない。
