JTB、標的型メールによる攻撃を受け顧客情報流出 51
ストーリー by hylom
他人事ではない 部門より
他人事ではない 部門より
JTBが14日、同社関連サイトの運営やそこでの商品販売を手がけるグループ会社のi.JTBが標的型メールによる攻撃を受け、最大で約793万人分の顧客情報が流出した可能性があると発表した（NHK、読売新聞、朝日新聞、日経新聞）。
流出の恐れがあるのは、2007年9月28日から2016年3月21日の間に「JTBホームページ」や「るるぶトラベル」「JAPANiCAN」といったJTB関連各サイトおよびNTTドコモの「dトラベル」などの提携サイトでJTB商品を予約した顧客の情報の氏名および生年月日、住所、電話番号、メールアドレス、パスポート番号およびその取得日など。
i.JTBの社員が取引先を装ったメールの添付ファイルを開きPCがウイルスに感染、そこからPC5台とサーバー2台がウイルスに感染したという。これらのPCが遠隔操作され、顧客情報が収集されたようだ。
個人情報へのアクセス制限があれば (スコア:2)
ウイルスに遠隔操作されても個人情報にアクセスできないような気がするのですが。。。
Re:個人情報へのアクセス制限があれば (スコア:4, 参考になる)
http://d.hatena.ne.jp/Kango/20160614/1465925330 [hatena.ne.jp]
サーバも感染していることから、経路としては
のようですね。
Re:個人情報へのアクセス制限があれば (スコア:2)
ウイルスに遠隔監視されてる端末上で、職員が個人情報へのアクセスを行うと……。
Re:個人情報へのアクセス制限があれば (スコア:2)
ウイルスに遠隔監視されてる端末上で、職員が個人情報へのアクセスを行うと……。
監視された状態で個人情報にアクセスすれば遠隔地でその情報を見れるのはわかるんですが、
790万人分にアクセスって相当な量ですので不思議に思って。
遠隔操作もあったにしても790万件のアクセスってなかなかできないですよ。
Re:個人情報へのアクセス制限があれば (スコア:2)
アクセスして得た個人情報それ自体を見ることが重要なのではなく、
その直前に認証してアクセス権限を取得する手続きを見ることが重要なのです。
Re:個人情報へのアクセス制限があれば (スコア:1)
データベースサーバに自由自在にアクセスできる権限のあるPCというのを外部と接触するネットワークから完全に隔離しておけば、漏洩はしなかったはず。
完全隔離と業務の効率化とを両立させるような仕掛けはありえないのでしょうか？
Re:個人情報へのアクセス制限があれば (スコア:1)
自由にアクセスできる端末と、制限付きアクセスを認められた端末で運用する事は比較的容易なはずです。
更に、メーラーをすべての端末に入れる必要はありませんし、すべての端末が同じネットワークに属する必要もありません。
できるできないの二択で考えるから設計が難しくなるのであり、必要な権限を細かく分けて設計することが重要です。
Re: (スコア:0)
具体的にお願いします。
風の息吹を感じれば〜 ですか？
Re: (スコア:0)
具体的にお願いします。
基本的にDBは特定の場所からしかアクセスできないように設計するものです。
ごく普通一般のシステム設計です。
Re: (スコア:0)
システム設計としては一般的かも知れないけれど、
システム運用としては全然一般的じゃないです。
顧客からの問い合わせがある度に専用端末へ出向いて、
調べた内容を紙にメモして自席に戻り返信……とか、
窓口業務の人はやってられないでしょ。
JTBは違った、ってだけだと思う。
Re: (スコア:0)
個人のデスクに専用回線と一般回線の二台の端末を置いて、ってのは
一般的かどうかはさておき現実に存在するパターンではありますね。
JTBの様な業務だと文字列のコピペとかできないとツラいのかもしれないから、そういうシステムが許容されるのかは分かんないけど。
Re: (スコア:0)
>顧客からの問い合わせがある度に専用端末へ出向いて、
>調べた内容を紙にメモして自席に戻り返信……とか、
専用端末に出向かなくてもいいよ。専用端末にアクセスすればいい。
Re:個人情報へのアクセス制限があれば (スコア:2)
システム設計としては一般的かも知れないけれど、
システム運用としては全然一般的じゃないです。
あなたが運用現場を知らないから憶測でのみモノ言っているからそう考えるだけ。
Re: (スコア:0)
クレデンシャルを入力出来るのは、シェル上で手動で実行した時に限る、
みたいな仕組みは、SELinuxにもPowerShellにも有るのでは無いでしょうか？
Re:個人情報へのアクセス制限があれば (スコア:2)
シェル上に手動で入力とリモート操作での入力とを区別できるような仕組みは
どうしてもサーバ側ではなくクライアント端末側にソフトウェア実装が必要なので、
結局クライアント端末が自由に改変できる状況下では時間稼ぎにしかならないですね。
とはいえ外部との通信遮断などの対策に必要となる貴重な時間を稼げるのなら
対策としては十分目的を果たしているのかもしれません。
確実（それもある程度でしかない）な対策はハード的に分離する方法しかないですが、
実運用を考えると……というのは他の方がコメントされている通りだと思います。
Re:個人情報へのアクセス制限があれば (スコア:1)
DB操作系と受付業務系の実質隔離としては、
1. VMやsandboxによる一台のPC内での分離
2. (漫画的だけど)DB操作系PCと受付業務系PCの二台使用、受付業務系PCからの文字列のコピペは、画面をカメラでモニタしつつ、OCRして取り込む。受け付業務系PCへは、USBキーボードをエミュレートして、文字列を送信。など。
3. DB操作はコマンドの送信後、そのコマンドの実行を指紋認証で行う。ただし、指紋認証のデバイスはPCとは別のもの、別のネットワーク、あるいは、RS-232C等で行う。PCには指紋認証のデバイスは付属させない、指紋情報が盗まれないように。
などがありうるような気がします。
Re:個人情報へのアクセス制限があれば (スコア:1)
まぁ、システム管理、運用に携わったことがある人にしてみれば「ははぁん……」だけれど、
一般の方々にとっては「ウィルス感染→流出！！」で危険の認識としては問題ないので、
まぁその辺は「お察し」ということで（笑）
＃いろいろずさんだったんじゃないかねぇ……
Re:個人情報へのアクセス制限があれば (スコア:2)
>＃いろいろずさんだったんじゃないかねぇ……
全個人情報がどこからでもアクセスできるサーバー上に置いてあったとかねぇ。
住基ネット漏洩事件の例があるし。
Re: (スコア:0)
何らかの方法で権限昇格したんじゃないですかね。内部から管理者に標的型メールを送るとか…。
Re: (スコア:0)
逆にそれがなければ標的型メールへの対処なんかやりようがないでしょうね。
怪しいメールは開かない、添付ファイルが云々では誰かがやらかす。それは仕方ない。
しかし、旅行会社では個人情報のアクセスは社員全員が必要で、数はまぁふつうは一度に100前後あればいいだろうが、アクセス間隔は予想できない。セクションに分けるのも容易ではない。ビッグデータの分析をするなら全ファイルへのアクセスが必要。
なにより社員の手間を含めて結構なコストがかかる割に、流出の可能性は低く、流出しても批判はそこまで大きくない。
という訳で低コストな次善の策で個人が気を付けるように、となるのだが当然たまに漏れる。
結局、根本的な対策を取らなかったからなのにやらかした社員が責められ、繰り返される。
まぁ仕方ないでしょう。
あるいはブラウザやメーラーを仮想環境なりサンドボックスで動かせばいいのかもしれない。
標的型攻撃 (スコア:2, すばらしい洞察)
スラドのレスを見ても標的型とSPAMを同レベルに考えている人や、
何も考えずにメール開いたんだろみたいに標的型の怖さをわかってない人が一定数いる現状を見ると、
普通の人が標的型の攻撃に対処するのはほとんど無理じゃないかと思うな。
Re: (スコア:0)
確かにその通りですね。
個別にカスタマイズされたプロの攻撃を、一般の人が防げますか、という話ですからね。
自分の勤め先では時々標的型メールの訓練を実施しますが、回を重ねても開封率をゼロにするのは不可能だと思います。開封率を下げつつ、開封されたときのシステム側と経営層のアクションを準備しておかないと。
逃げ出したオレが言うのも何だが… (スコア:1)
だから、OS/2のままにしておけくださいとあれほど…
Re: (スコア:0)
AIXじゃなくて？
いつもの (スコア:1)
793万×500円の金券＝約40億円
最大値で見積もると割とダメージ大きい……かも？
偽装exe？ (スコア:0)
もし偽装exeならちゃんと手口を報道してほしいなぁ。
Re:偽装exe？ (スコア:1)
JTB社員はなぜ、ウイルス入り添付ファイルを開いたのか
http://www.itmedia.co.jp/news/articles/1606/15/news073.html [itmedia.co.jp]
添付ファイルを開いた社員は異変に全く気付かなかったとのことなので、
マクロウィルスを仕込んだドキュメントファイルではないかと。
しかし、実在する取引先を騙った上で、全く不審がられない文面の
メールを送りつけるって、そんなに簡単なこととは思えないんだけど、
JTBの業務に詳しい人間が協力しているのかな？
ウイルス対策ソフトでも検知できなかったようなので、社員が感染して
しまったのは仕方ないと思うけど、19日にセキュリティ会社から通報が
あったのに、遮断は21日よりも後ってのは、対応の不備と言われても
仕方ないね。
Re:偽装exe？ (スコア:1)
Re: (スコア:0)
客商売だから社員は出勤していたはずだけど、上司が休んでて、緊急連絡しなかったのかな？
（ウイルス感染の脅威を十分に認識していなかった、と謝罪しているようなので）
正直、気持ちは分かるんで、他山の石としたいところ。
Re: (スコア:0)
読売の方には「偽装されたＰＤＦ」と質疑応答があったのでまあexeなんだろうと思ってます。
実行させないようにはできると思うんだけど他の細かい事が分からんので…。
http://www.yomiuri.co.jp/science/goshinjyutsu/20160615-OYT8T50004.html [yomiuri.co.jp]
＞ＪＴＢ広報室「解析したところ、ｅｘｅ形式の実行ファイルだと判明した。
＞『ＥＬＩＲＫＳ』と『ＰｌｕｇＸ』の２種類のウイルスに感染させるものだった」
メールリーダをsandbox内で使用とかできないのかな (スコア:1)
そもそもメールソフトでクリックしたコードがパソコンの隅々までアクセスできるってことが問題だよね。Windowsではメールソフト経由のソフトは自動でsandboxで実行とか、メールリーダ自体をsandbox内で実行とかできないのでしょうか？
MultiuserのOSなら、mailはそれしかできない、低権限のuserでアクセスする、とかやれそうだけど。もちろん、皆がそうやって防ぎ始めたら、攻撃側は権限昇格の穴をつくようになるだろうけど。
Re: (スコア:0)
メーラーの起動スクリプトつくって別ユーザで実行するようにしてしまえば、 最小権限での利用ってのは、 昔なら出来たけど、
Windows10では、 別ユーザーで実行すると日本語が使えなくなるからログインユーザ以外じゃ実行するかちがない感じ。
Windowsだとライセンスの都合があるからむずかしいけど、 メール・インターネット環境くらいならVirtualboxを起動しておいてLinux環境でごにょごにょと。するほうが楽な気がする。
メモリなら有り余ってるわけだし。
Re: (スコア:0)
↓には「PDFファイル」って書かれてますね。
http://headlines.yahoo.co.jp/hl?a=20160615-00010000-bfj-soci [yahoo.co.jp]
adobe readerはデフォルトでスクリプト実行が有効になってたと思うので、
それを利用してウイルス本体をダウンロードするタイプの可能性も？
いずれにしろ、こんなの顧客対応窓口の人間が開くのは避けられないですね。
exe形式の圧縮ファイルを送ってくる本物の酷客もいますし……。
本当はexe形式の添付ファイルは、メールゲートウェイで遮断できれば良いと
思うんですけど、不特定多数の顧客からメールが届く窓口では厳しいかな。
Re: (スコア:0)
>しかし、実在する取引先を騙った上で、全く不審がられない文面の
>メールを送りつけるって、そんなに簡単なこととは思えないんだけど、
>JTBの業務に詳しい人間が協力しているのかな？
単に、何も考えずにメールを開いただけだと思う。
セキュリティ意識とか微塵も持って無かったんだろう。
Re:偽装exe？ (スコア:1)
> FROMアドレス 実在する航空会社系列会社のドメイン 日本人のありふれた苗字がアルファベットで表記
> 件名 「航空券控え 添付のご連絡」
> 添付ファイル 「E-TKT控え」 eチケットを「E-TKT」といったファイル名とするのは社内でも使われる表記。
> 本文 次の内容が本文に書かれていたと報じられている。
> ・挨拶の定型文 「お世話になっております」が記載されていた。
> ・「eチケットを送付しますのでご確認ください」「お客様の旅行内容を確認したい」といった内容であり不自然な文面ではない。
> ・実在する取引先の会社名、部署名、担当者名の署名が記載されていた
この内容を見て、セキュリティ意識がみじんもないから開いたとは
私ならよう言えませんけどね・・・
参考: http://d.hatena.ne.jp/Kango/20160614/1465925330 [hatena.ne.jp]
SPFやDKIMはどうなっていた? (スコア:0)
なりすましを防ぐための技術であるSPFやDKIMはどうなってたんでしょう?
Re: (スコア:0)
Microsoftすら無効なDKIM署名付けて or 署名元と違う送信元アドレスで送ってくる現代でそれらをまともに運営できてるのってどこだ
Re: (スコア:0)
いや、Microsoftなんかを出されても…。
[日本郵便] 集荷依頼申込み完了のお知らせ (スコア:0)
作業日報
【要連絡】修繕依頼
etc
最近、この手のタイトルメールが spamフォルダに痕跡だけど入っている。
(添付部分は削除されてる)
。。。これに引っかかったのかな
doc,pdf,xls等をzip圧縮したやつが添付されていたらしい。
やっぱり、オレオレ詐欺と一緒でこんなのに引っかかるのは一定量居るんだねぇ
Re: (スコア:0)
うちにも来たわソレ
速攻削除したけど
Re: (スコア:0)
似たようなのは以前から来てたよ
Fedexで、荷物が届いてるからとかなんとか・・まぁ無視だが
日本語のスパムも増えてきてて、日本語的にも徐々に改善？されてきてるよね。
まだ怪しいものが多いけど、改善が進んで、日本語的にも問題のないもの出てきてるし（まだ不備は多いが）
自分も絶対騙されないとは言えないなぁ
特に取引先を偽装されると・・マイナーな取引先だとさらに騙されそうで怖いねwww
Re: (スコア:0)
こういうITリテラシの低い人がいるから、いつまで経っても出口対策の重要性が認識されないんだろうね。
「JTBを狙い撃ちした標的型攻撃」なんだから、JTBの窓口以外に届いているわけないのに。
ウイルス対策ソフトで検知もできないんだから、spam扱いされるはずもない。
そもそも、JTBの顧客を装って送られたメールを開かないとか、業務上絶対にあり得ないシチュエーションだと
思うんだけど。
本当の顧客だったらどうするつもりなの？
後で問題になって、「なんか怪しいから無視しました！」とか上司に真顔で言うんだろうか？
Re: (スコア:0)
どやぁ!
ってか
最大のセキュリティホール (スコア:0)
最大のセキュリティホールは人間というオチ
Re: (スコア:0)
SPAMフィルタへSVMが応用されているように，添付ファイルを開いてよいか否かの決済を担当するエージェントを，深層学習で作れないものかね．
# そのエージェントがクラックされるところまでがテンプレート
Re:最大のセキュリティホール (スコア:1)
「新製品。高性能な水素水ＡＩがウィルスメールを自動判定。発売記念キャンペーン中。今なら無料！！。詳しくは添付資料を参照下さい。」
という無慈悲なセキュリティ攻撃メールが送られてきそうだなあ。
Re: (スコア:0)
トレンドマイクロ「名前だけそれっぽくしてみたぞ」
Trend Micro Deep Security™
明らかに誤認狙いだろこれ...
親会社の出向者 (スコア:0)
こういう問題って親会社の出向者が絡んでることが多い
社内規則無視しても誰も止められなくて
いざ事件となると感染源の末端が問い詰められて終わり
問題児の出向者はまた親会社に栄転・・・
サーセンでした (スコア:0)
でいつも済んじゃうから、企業のセキュリティ強化はなかなか進まないんだよな。
幹部ら数名がせいせい数ヶ月の減給処分といったところだろうけど、流出された人の不安は数十年先まで続くのに。
どこの企業でも所詮は対岸の火事
Re:サーセンでした (スコア:1)
名ばかりCSIRTを問題視している理由 [cocolog-nifty.com]
みたいな体制のとこばかりだから期待しすぎてもがっかりするだけなのでしょう。