Fox on Security

セキュリティリサーチャー(インシデントアナリスト)で、セキュリティコンサルタントのキタきつねの独り言。専門はPCI DSS

パスワード定期変更不要だけ一人歩きしてないか

内容として決して間違っている訳ではないのですが、記事を読んでいてSP800-63で書かれている事との違和感を感じました。 

tech.nikkeibp.co.jp

 

 「企業IT利活用動向調査2019」速報によると、2018年3月に総務省がパスワードの定期的な変更は不要との見解を示したにも関わらず、これまで通りパスワードの定期変更を行っている」という企業が54.5%を占めた

 総務省定期的な変更がかえってパスワードの単純化や使い回しを助長して脆弱性を増大させるとしてパスワードを変更する必要はないという見解を示した。利用するサービスによってはパスワードの定期変更を求められるものの、実際にパスワードを破られたりアカウントが乗っ取られたり流出した事実がなければ定期的な変更よりも使い回しのない固有のパスワードの設定が求められるとした。

 JIPDECとITRは「企業はパスワード認証の問題点に対する理解と、多要素認証など他の認証方式との組み合わせの採用が望まれる」と指摘している。

(日経XTECH記事より引用)

 

◆キタきつねの所感

この指針が出た当時、大きなニュースとなっていましたが、

参考:

www.asahi.com

 

国民のための情報セキュリティサイトでは、パスワードの定期変更不要の部分についてNIST SP800-63を根拠に、次のように説明しています。

f:id:foxcafelate:20190420103640p:plain

定期的にパスワードを変更しても、結局(ユーザがパスワードを覚えきれないので)脆弱なパスワードを使ったり、他のサイトとパスワードを使いまわしてしまうのであれば、パスワードを定期的に変更する効果は薄いという事を指しているのだと思います。これは、パスワードリスト攻撃を起因とするインシデントが未だに出てくる現状を考えると、その通りだと思います。

 

では何がひっかかったのかと言えば、NIST800-63は、「パスワードの定期変更不要」だけしか書いてない・・・という訳ではないからです。

 

まず大きな変更という意味では、SP800-63Bは「パスワード」という表記から「記憶シークレット」に統一されているという概念変更の部分ですが、冒頭の5.1.1部分で(パスワード)桁数と文字種についても記載があります。

 

NISTの原文では、この様な形で書かれており、

f:id:foxcafelate:20190420161732p:plain


JIPDECの日本語翻訳では以下の形で訳されています。

5.1.1.1 記憶シークレットAuthenticator
記憶シークレットは,Subscriberにより選択されば場合少なくとも8文字とするものとする
(SHALL).記憶シークレットがCSPまたはVerifierによってランダムに選択されたものである場合は,少なくとも6文字であるものとし(SHALL)全て数字でもよい(MAY). CSPやVerifierが,危殆化した値のブラックリストに出現状況に基づいて指定された記憶シークレットを拒否した場合,Subscriberは別の記憶シークレット値を選ぶよう要求されるものとする(SHALL).記憶シークレットの複雑さに関する他の要件を課すべきではない(SHOULD).本件についての論拠はAppendix Aの Strength of Memorized Secrets に記載されている.

 

英語文、特に契約書面をやり取りした事がある人であれば、「SHALL」には敏感かと思います。契約や規定文では一般的な日本語の「~かも知れない」と訳される事はなく、この表現は義務(MUSTと同様)を表します

 参考:Shall, will(英文契約書用語の弁護士による解説)

 

とは言え、前段の8文字以上の部分に関しては、以前からのNISTの定義(推奨)と変わりません。IPAに翻訳文がある、SP 800-63(2006年版)では、『付録 A:パスワードのエントロピーと強度の推定』に次の様な例示があり、この部分がPCI DSSも含む、多くのセキュリティ基準策定の参考として使われてきました。とは言え、翻訳文を見ても『定期的なパスワード変更を要求している』部分がはっきりとしません。(※私の探し方が悪いのかも知れませんが・・・)例示には、例えば、以下の様な記載があったので、定期的なパスワード変更がこの規定(2006年版)で推奨されている事は分かるのですが・・・

  • システムにおいて、3回の試行が失敗したらパスワード認証を1分間ロックし、10年ごとにパスワードを変更することを求めるとすれば、標的を定めたパスワード推測攻撃に対するレベル2の要求事項を十分に満たすことになる。

パスワード関係でよく引用されるのは、以下の部分(上2つ)ですが、こちらは例示ではありますが、この規定(2006年版)に記載されていました。

  • 最低 8 文字のパスワードを使用する。加入者が 94 個の印字可能なアルファベット文字から選択する。
  • パスワードに、少なくとも大文字を 1 個、小文字を 1 個、数字を 1 個、特殊文字を 1個、それぞれ含めることを加入者に求める。そして、
  • 一般的な単語が含まれるのを防ぐために辞書を使用し、ユーザ名の並べ替えをパスワードとして使用することを防止する。

 

もう少し遡って調べてみると、2009年4月に発行され、2016年4月に引退した『SP800-118(DRAFT Guide to Enterprise Password Management)』には、パスワードの定期的変更について推奨する内容が記載されています。この規定が、SP800-63(2017年版)へと吸収されて(移行して)いますので、要求はされていたのだろうと思いますが・・・

 

f:id:foxcafelate:20190420164917p:plain

 

前置きが長くなりましたが、私はSP800-63Bはもっとパスワードに対して要求しているという事が、あまり重要視されてないのは少し問題な気がします。和訳文章が読みにくいのですが、例えばJIPDECの日本語翻訳では5.1.1.2には多くの『SHALL』が書かれています

 

f:id:foxcafelate:20190420220505p:plain

f:id:foxcafelate:20190420220700p:plain

 

パスワードの定期的変更以外で、SP800-63Bに記載がある注目すべき要求事項としては、私は以下の点が気になりました。

①Subscriberが選択した記憶シークレットに対して最低64文字を許可すべきである(SHOULD) 

 ※ユーザ選択のパスワードは、最低64文字を許容すべきである

②記憶シークレットの複雑さに関する他の要件を課すべきではない(SHOULD)

 ※パスワードの複雑性要件(大小英数記号・・・)は要求されない

②すべての印字可能なASCII [RFC 20] 文字(スペースも同様)は記憶シークレットとして許容されるべきである(SHOULD) ※スペースもパスワードとして使えるべきである

③記憶シークレットは,CSP(例えばEnrollment時など)やVerifier(ユーザが新しいPINを要求した時など)によりランダムに選択されるもので,最低6文字であるものとし(SHALL) 

 ※システムで初期パスワードをランダムで生成する場合は6文字以上でなければいけない

④(③は)Approve済み乱数生成器[SP 800-90Ar1] を利用して生成されるものとする(SHALL)

 ※正しい乱数発生でパスワードが生成されなければいけない

⑤記憶シークレットを選択する際,VerifierはSubscriberに対して特定のタイプの情報(例えば,「あなたが飼った最初のペットの名前はなんですか?」といったもの)の入力を求めないものとする(SHALL NOT).

 ※パスワードを忘れた際のヒント(=秘密の質問)は実施してはいけない

⑥記憶シークレットの設定,変更の要求を処理する際,Verifierは候補となっているシークレットの値
を,一般的に利用されている値,予想されうる値,危殆化した値として知られている値を含むリスト
に対し,比較するものとする(SHALL)

 ※容易なパスワード、辞書単語等はパスワード設定時にチェックされなければならない

⑦VerifierはSubscriberに対して,ユーザが強力な記憶シークレットを選択するのを支援するために,パ
スワード強度メーター [Meters] のようなガイダンスを行うべきである(SHOULD)

 ※パスワード強度メータの導入をすべきである

 

いずれもサービス事業者にはインパクトがある内容だと思います。特に⑤の秘密の質問はNISTが禁止(かえって脆弱性がある)している事がもっと深刻に受け止められるべきではないでしょうか。

また、⑥のパスワード登録時のチェックも、

過去に漏洩した語彙集から得られるパスワード
辞書に含まれる言葉
・繰り返しまたはシーケンシャルな文字 (例: ‘aaaaaa’,’1234abcd’)
・サービス名や,ユーザ名,そこから派生するようなものなど,文脈で特定可能な単語

と例示補記されている事から考えると、パスワードリスト(辞書)攻撃でハッカー側が使う”辞書”を防衛側も持ってチェックする必要がある事を示唆しています。

この背景にはパスワードの限界というものをNISTは想定していると思われ、より長くて覚えやすいパスフレーズへの転換をユーザ及びサービス事業者に求めていると見る事も出来るかと思います。

 

総務省は国民に『パスワードの使いまわし』を防ぐ意味で、NISTのSP800-63Bを引用して(定期的な変更は不要)と記載しているのだと思いますが、パスワードを使いまわす立場の国民(ユーザ)に対する説明としては正しいとしても、ここだけ切り出して(サービス事業者が実施すべき部分を語らずに)、だからパスワードは総合的に安全であるとは言えないはずです。

 

参考:SP800-63Bの内容については、以下の説明も分かりやすいかと思います。

www.slideshare.net

 

今回のJIPDECとITRの調査は企業(サービス事業者)向けのものであった様ですが、パスワードの定期的変更だけでなく、『秘密の質問を廃止したか』であったり、『パスワード登録時の辞書チェック実施レベル』や、『パスワード設定桁数』などを俯瞰してNIST(SP800-63B)基準との対比を狙った方が、面白い結果が得られたのではないでしょうか?

SP800-63では『パスワードの定期変更廃止』ばかりに注目が集まりその他の規定(推奨)項目をよく読んでない事が、あぶり出されたのではないかと思います。

 

www.itr.co.jp

 

 

 

èªè»¢è»ã®ã©ã¤ããã¤ãã¦èµ°ã£ã¦ããã¤ã©ã¹ã

 

更新履歴

  • 2019年4月20日AM(予約投稿)

ベルアメールのカード情報漏えい

チョコレートの様に非保持は甘くは無かったようです。またカード情報非保持のECサイトからクレジットカード情報が漏えいした様です。

www2.uccard.co.jp

 

■公式発表 「ショコラ ベルアメール」のオンラインショップへの不正アクセスによる個人情報流出に関するお詫びとお知らせ

 

◆キタきつねの所感

また漏えい事件が発生していた様です。正直、今後も被害を受けるECサイトは毎月定期的に出てきてしまうのではないかなと思います。

(1)原因
 弊社が運営する「ショコラ ベルアメール」のオンラインショップのシステムの一部のセキュリティの脆弱性をついたことによる外部の第三者不正アクセス
(2)個人情報流出の可能性があるお客様
 平成30年8月6日から不正プログラムを除去した平成31年1月21日までの間に、「ショコラ ベルアメール」のオンラインショップにおいてクレジットカード決済をされたお客様1,045名で、流出した可能性のある情報は以下のとおりでございます。なお、お客様ご自身及び商品の送付先様の住所、電話番号、メールアドレス、生年月日等の等情報につきましては、流出は確認されておりません。
 ・カード会員名
 ・カード番号
 ・有効期限
 ・セキュリティコード 
(公式発表より引用)

 

ベルアメールは、QAに今回被害を受けた手口を詳細に公開していました。(※他社への類似被害等を考えると、全ての事件でこうした公開をして欲しいものですが・・・)こちらから引用しますと、偽ページを挟まれる攻撃だった様です。

 

f:id:foxcafelate:20190422175012p:plain

 

では、どうして偽ページを挟まれてしまったのか?と言う部分についてもQAで説明がありました

Q.不正アクセスとは何があったのですか?

A.三者によるアプリケーションの脆弱性を突いた不正アクセスで、管理者権限が不正に用いられたことにより、Webサーバー内の情報が改ざんされ、オンラインショップにおいてお客様情報入力画面とクレジットカード情報入力画面の間にフィッシングサイト(偽のクレジットカード情報の入力画面)が差し込まれたものと考えられます。

管理者権限が窃取されている事が、Webページ改ざんの原因であることが明示されています。

 

少し前のWebページを調べてみると・・現在のWebページのデザインと違ってる事が分かります。これが直接の原因かどうか分かりませんが、ショッピングカートや会員ログインが実装されていましたので、ECサイト構築のパッケージを使っていたのではないかと推測します。

だとすれば、パッチ当て(ECサイト構築パッケージのソフトウェア更新)に失敗したか、管理者のパスワードが脆弱であって破られた・・という様な可能性が高いのではないでしょうか?(恐らく前者では・・・)

f:id:foxcafelate:20190422175458p:plain

 

実行計画2019が出て1か月ちょっとがたちますが、実行計画でも懸念されていた、非保持サービスへ移行する前の、Webサイト管理側が担保すべきセキュリティの不備。かなり深刻なのではないでしょうか?

f:id:foxcafelate:20190422180157p:plain

非保持だから安全であるという隙が突かれている。その認識が薄い様であれば、今後もECサイトのインシデントは数多く出てきてしまうと思います。

ãã¬ã³ã¿ã¤ã³ã®ã¤ã©ã¹ããç®±å¥ããã§ã³ã¬ã¼ãã»ããã

 

更新履歴

  • 2019年4月22日PM(予約投稿)

ななつ星ギャラリーのカード情報漏えい

ななつ星サイトからの個人(カード)情報漏えい事件について少し調べていたのですが、時間が取れずまとめられていませんでした。

www.nikkei.com

 

JR九州は12日、豪華寝台列車ななつ星in九州」の関連商品を販売する通販サイトが外部から不正アクセスを受け、クレジットカードのセキュリティーコードなど最大約8千人分の顧客の個人情報が流出したと発表した。うち、カード情報が含まれるのは最大約2800人分で、カード番号や有効期限も流出した可能性がある。


カード悪用の被害が一部出ており、顧客からカード関連会社に「身に覚えのない支払いがあった」との問い合わせがあり、発覚した。件数や金額は現時点で不明という。

(中略)

JR九州によると、流出した可能性があるのはサイトが開設された2013年10月5日から、閉鎖した19年3月11日までの間に利用した顧客の情報。会員登録した顧客の氏名や住所、電話番号、メールアドレス、生年月日、職業といった情報も含まれるとしている。情報が漏れた対象には、ななつ星に乗った顧客の一部も入っている。

(日経記事より引用)

 

■公式発表 不正アクセスによるお客さま情報流出に関するお詫びとお知らせ

 

 

◆キタきつねの所感

JR九州としては系列のドラックイレブンに続き、1年以内に2件目のインシデントが発生した事となります。重要インフラ企業への攻撃と捕らえる事も出来るかも知れませんが、私としてはサプライチェーン攻撃なのかなという印象です。

 

参考: 地方も攻撃対象であるのは変わりはない - Fox on Security

    ドラックイレブンは2度調査を行う必要があった - Fox on Security

 

このインシデントは、最近多発しているECサイトWebページ改ざんを起因とするインシデントとは性質が違うということです。

 

公式発表から引用しますが、サイト開設(2013年)当初からクレジットカード情報が漏洩しています。

f:id:foxcafelate:20190420064134p:plain

 

このブログで何度も書いていますが、去年の6月1日に改正割賦販売法が施行され、各ECサイト事業者はカード情報非保持かPCI DSS準拠が求められました。※改正割賦販売法のガイドラインが「実行計画

つまり、法令対応で各ECサイトは2018年前半にはカード情報非保持への対応を終わらせていた(システム改修していた)はずなのです。しかし漏洩データには2018年6月以降のカード情報が含まれていると発表されています。これはつまり、非保持ソリューションを導入した(又はPCI DSS準拠)後もカード情報が漏洩していた事を示唆しています。

一方で2013年~2018年前半に漏洩したカード情報には、セキュリティコードが含まれています。セキュリティコードは非保持であろうが、PCI DSS準拠であろうが、ECサイト側が決済終了後に保有が禁止されているデータなので、ななつ星ギャラリー(JR九州)の実装ミス(例:実はログに吐き出していた)を除いては、ECサイト側で保存していたはずが無いデータとなります。

 

そう考えてくると、どういう可能性が残るかと言えば、「サイト開設時からハッカーに侵入されていた」と考えるのが、最もしっくりきます。

ただし、この推測にも1つ辻褄が合わないところがあります。それは2013年から侵入が成功していたとして、何故2019年まで発覚(カード会社への問い合わせ)しなかったのか?という点です。もっと前から不正利用がされていてもおかしくない気がしますが、何かの理由でハッカーが時期を待っていたのだとすると、2件のインシデントは、JR九州へのサプライチェーン攻撃の一環、そんな風に捕らえる事も出来そうです。

 

ななつ星と言えば、贅沢な列車クルージングで人気で、最低でも20万円位の費用がかかったかと思います。この顧客データ=富裕層データと考えると、漏洩件数は約8000件(カード情報約3000件)と、そんなに多くはありませんが、見方を変えれば、ハッカー側には別な事件への活用も考えられる、非常に価値があるデータと見なす事ができます。であればこそ、JR九州側はもっとセキュリティ対策できなかったのかな(脆弱性診断で痕跡を見つけたり、SOCで通信監視できなかったのかな?)、、と思います。

 

 

余談です。今回は長いです

 

公式発表リリースPDF名が・・・平成27年6月24日になっている点。事件にはまったく関係ありませんが、こうした「?」と思った中に、インシデントを紐解くヒントが(極稀に)出てくる事もあるので、気になりました。

f:id:foxcafelate:20190417215826p:plain

以前あったリリース文をひな形にして、今回のリリース記事を書いたのかな?と思って2015年のリリース内容をチェックすると、monoSUGOCAのリリースが6月24日にあったのですが、

 f:id:foxcafelate:20190417220223p:plain

記事テイストが違うので・・・どうした経緯でこの日付がファイル名についたのかは分かりません。

 

 

他に気になった点では、某サイトで過去のWeb魚拓が出てくる(時もある)ので、こちらで調べてみると、会員登録やログインがトップページにある事が分かります。

f:id:foxcafelate:20190417220515p:plain

 

試しに新規登録画面ページを見てみると、当たり前ですが、今回漏えいしたデータのカテゴリーがぴったり合致します。

f:id:foxcafelate:20190417220934p:plain

 

細かい所で気になったのは、パスワードが最小4桁からとなっていた点でしょうか。

f:id:foxcafelate:20190417221121p:plain

今回の手口とは異なるとは思いますが、場合によっては、総当たり(パスワードリスト)攻撃が成功していたかも知れません。

 

もう1つ、利用規約がとても気になりました。何気なくスクロールしてたのですが・・・

f:id:foxcafelate:20190417221319p:plain

 

なかなか普段見る事が無い(?)規約が第10条に定められていました。

 

f:id:foxcafelate:20190417221655p:plain

 第10条 (免責)

1. 通信回線やコンピューターなどの障害によるシステムの中断・遅滞・中止・データの消失、データへの不正アクセスにより生じた損害その他当社のサービスに関して会員に生じた損害について当社は一切責任を負わないものとします
2. 当社は、当社のウェブページ・サーバー・ドメインなどから送られるメール・コンテンツに、コンピューター・ウィルスなどの有害なものが含まれていないことを保証いたしません
3. 会員が本規約等に違反したことによって生じた損害については、当社は一切責任を負いません。

今回の事件を予見したかの様な記述(第10条1)ですが、この自社のセキュリティ構築の努力義務を放棄したとも取れる表現について、流石にどうなのかと思います。

第10条2は、意図しない水飲み場に攻撃になった場合は、仕方がないんです。JR九州の責任を免責にさせて下さいね、といった内容かと思いますが、表現が直接的に映りますし、そもそも利用規約の一番下までスクロールしないと出てきませんので、ほとんどの会員は「知らない」のではないかと思います。

ECサイト側の責任、あるいはGDPRGAFAが責められている観点も加味して考えると、この利用規約にも問題はあったのではないでしょうか?(ハッカーがこれを見て攻めやすいサイトであると考えた可能性もあるかも知れません)

 

 

 

ã¹ã­ãããã·ã³ã®ã¤ã©ã¹ã

 

 

更新履歴

  • 2019年4月20日AM(予約投稿)

USBKillerの正しい使い方

以前書いた事のある『物理攻撃ツール』のUSBKillerを使っている事件が報じられていました。

www.zdnet.com

 

米国のインド人国民は今週、ニューヨークのセントローズ大学で59台のコンピュータを破壊したことを認め、オンラインで購入した「USB Killer」という武器を使ったUSBメモリを使った。

(中略)

容疑者は59台のコンピュータだけでなく、7つのコンピュータモニタとUSBスロットが開いているコンピュータ強化の表彰台も破壊しました。

彼はUSB Killerを使ってそれをしました、それは彼がこれらのタイプの装置を売っている有名なオンラインストアから購入した武装したサムドライブです。

USB Killerデバイスは、USB電源からサムドライブコンデンサを急速に充電してから、USBスロットに電流を放電することで(わずか数秒で)、USB Killerデバイスが接続されているコンピュータを効果的に揚げます。

裁判所の文書によると、Akuthotaが訴訟の一環として支払うことに同意した、破損したハードウェアの調査および交換にかかる従業員の時間に7,362ドルを費やしたため、機器の損傷は51,109ドルに達しました。

(ZD Net記事より引用)※機械翻訳

 

◆キタきつねの所感

以前の記事を探してみたのですが、1月に書いていました。

foxsecurity.hatenablog.com

事件を受けて改めて思うのが、やはり『嫌がらせ』としては最適な破壊ツールと言えそうです。

インド国籍の27歳容疑者は2017年にセントローズ大学のMBAコースを卒業した後に、元学生として犯行に及んだとありますが、、、MBAホルダーであれば、犯行によってその後のキャリアに多大なる影響を与えるであろう事は十分理解していたと思うのですが、それを越える、大学への不満など、強い動機があったのかも知れません。

容疑者は、59台の大学の端末とモニタ7台等を破壊した罪で、最大で懲役10年、25万ドルの罰金が課される可能性があるようです。懲罰罰金が十分に考えられる米国である事、5万ドルの復旧費用がかかった事を考えると、かなり重たい判決が出る事もあり得そうです。

 

余談となりますが、ZD Netの記事を読む限りでは、犯行に使われたUSB Killerはv2.0の様が、改めて調べてみると、USB Killerは既にv3が出ている様です(何が変わったのかは分かりませんが・・・)

 

あまり事件例を知りませんが、かなり人気がある商品である事は間違いないようです。(どこに使われているのやら・・・)

 

 

更新履歴

  • 2019年4月19日PM(予約投稿)

 

両陛下の伊勢神宮ご参拝

両陛下の在位中最後の伊勢訪問に関して、ふと気になったので調べてみました。

www.asahi.com

伊勢神宮参拝のため、JR東京駅を出発する天皇、皇后両陛下。後方は「三種の神器」の剣=2019年4月17日午後1時17分、嶋田達也撮影

 

偶然にも、(両陛下の移動を知らずに)私は1時間後に東海道新幹線に乗って出張先に向かっていたのですが、両陛下の乗られた新幹線は特別(貸し切り)列車だよなぁと思って時刻表をみてみると、

 

東京駅│時刻表:JRおでかけネット

 

17日の運行予定と、

f:id:foxcafelate:20190419105957p:plain

 

18日の運行予定とで、朝日新聞の写真コメントにあった1時17分に近い所で見ると・・・差分がありました

f:id:foxcafelate:20190419105827p:plain

1時20分発の新大阪行きの、のぞみ335号が運休している事が分かります。

 

細かく見てみると、

■13時10分 のぞみ35号(博多行)18番線

【13時20分 のぞみ355号(新大阪行)16番線】
■13時26分 こだま659号(名古屋行)14番線
■13時30分 のぞみ37号(博多行)18番線

両陛下が新幹線に乗られた13時20分頃の前後は、14-15番線、18-19番線には列車が停車してる可能性がありますが、16-17番線ホームは(他ホームへの振り替えも含め)前後の時間帯が発車には使われておらず警備もしやすい事が推測されます。

伊勢神宮へは夕方4時頃に参拝されていますが、諸々のスケジュールを考慮すると(宿泊先の志摩観光ホテルに6時前に着く)、この時間帯が必然だったのだろうなと思いました。

 

三種の神器天叢雲剣八咫鏡八尺瓊勾玉)の内、皇居にある剣(天叢雲剣※形代:実物は熱田神宮)と勾玉(八尺瓊勾玉)が陛下と一緒に持ち出され、伊勢神宮天照大神のご神体として内宮に祭られている八咫鏡と併せて、三種の神器が揃った事になります。ドラゴンボールが全て揃った様な・・・と言ったら怒られそうですが、何か感慨深いものがあります。

 

皇居から持ち出された2つの神器がどう運ばれるのか?物理セキュリティの観点から気になったのですが、侍従の方々が肌身離さず、両手で持って移動していたのが印象的でした。両陛下の護衛の方が侍従の方も警護していると考えると、これが一番セキュアな輸送方法であるのは間違いないかと思います。

www.asahi.com

 

 余談となりますが、陛下の地方移動の際は、新幹線は全車両貸し切りが普通の様です。一般客への影響を考えてというのが主な理由だそうです。

www.sankei.com

 

仮に同じ車両に乗れたとしても、乗降時にはホームが(警備上の理由で)一時的に使えなくなると思いますので、私のよくあるビジネス出張では、両陛下の事のみならずアポ時間(遅れ気味で移動するのが悪いのですが・・)も気になってしまうだろうなぁと思います。

 

 

f:id:foxcafelate:20190419110144p:plain

 

更新履歴

  • 2019年4月19日AM(予約投稿)

 

カード授受の脆弱性

この穴を突いてきましたか。。。偽造運転免許証を使ったクレジットカード不正授受の事件が報じられていました。

www.tokyo-np.co.jp

 

他人名義のクレジットカードで高級腕時計をだまし取ったとして、詐欺などの疑いで警視庁に逮捕された男らが、東京都内の高級マンションの集合ポストから郵便物を盗み、約五百人分の個人情報を集めていたことが捜査関係者への取材で分かった。男らはこの情報を基に運転免許証を偽造し名義人に成り済ましてクレジットカードを入手。二〇一七年末以降、少なくとも約千六百万円分を不正利用したという。

 捜査関係者によると、男らは目黒区などの高級マンションに、オートロックの共用玄関から住人が出入りするタイミングに合わせて侵入。マンション内側のポストから公共料金の請求書などを盗み出していた。ダイヤル式のロックは回転する際の音や感触を頼りに解錠していたという。

 男らは郵便物の氏名、住所などをパソコンに入力し、精巧な運転免許証を偽造。顔写真は詐欺グループのメンバーの画像を張り付けていた。偽造した免許証を使って銀行口座を開き、クレジットカードを契約していた。男らはカードが郵送される頃、マンション前で配達員を待ち伏せしたり、不在票をポストから抜き取り、郵便局で偽造免許証と共に提示してカードを受け取ったりしていた。

東京新聞記事より引用)

 

◆キタきつねの所感

今回の事件で狙われた脆弱点は、「共連れ侵入」「ダイヤルロック」「銀行口座の本人確認」等、いくつか考えられますが、カード授受の部分、すなわち郵便局窓口での(不在通知を使った)本人確認部分が狙われたと言っても良いかと思います。

 

郵便局の本人確認(運転免許証チェック)は、券面確認(写真)と、光源による(ICチップ)透かしチェックが実施されていますが、偽造免許証が使われる事を想定したセキュリティ体制にはなっていません。現場での局員の方の作業負荷を考えると仕方がない事かも知れませんが、今回の様な事件が多数発生する様であれば、抜本的に運用を見直す必要があるかも知れません。

 

因みに、抜本的対策として考えられるのは、運転免許証のICチップ情報を使った本人確認だと思います。

www.excite.co.jp

 

NFCスマホと「IC運転免許証リーダー」スマホアプリでIC免許証は、簡易的にチェックする事が可能です。

※偽造運転免許証ではICチップの中まで偽造に成功したという話は聞きませんので、精工に出来た偽造免許証であっても、窓口で見破る事が可能だと思います。

 

とは言え、IC運転免許証が登場してきたのは2007年ですので、時期から考えると郵便局は意図的にICチップでの本人確認を採用しなかったと推測されます。読み取りシステム構築の費用を考えて、あるいは現場の運用が煩雑になるから・・というのが理由かも知れませんが、こうした事件が多発するのであれば、社会インフラの要たる郵便局の信用にも響いてくるかも知れません。

 

今年に入ってからの「偽造運転免許証」に関わる記事を見ても、毎月の様に記事が出ている事がわかります。こうした状況を考えれば、郵便局の「簡易チェック」に対するリスク(閾値)は上がっていた事を気づけたかも知れません。

 

■2019/4/15 中国新聞記事

www.47news.jp

■2019/3/20 産経記事

www.sankei.com

■2019/2/19 日経記事

www.nikkei.com

 

 

 

余談ですが、システム導入を考えないのであれば、、、下記の記事の様に局員(従業員)を”教育する”事から始めるのも良いのかも知れません。

www.kobe-np.co.jp


同署によると、偽造免許証は兵庫県公安委員会の記名や公印も似せられて精巧だったが、レンタカー店の女性事務員が免許証のコピーを見た際、12桁の番号にある都道府県の管理番号が兵庫県でなかったため気付いたという。男は4月3日に再び同店を訪れ、店員が通報した。

神戸新聞記事より引用)

 

偽造運転免許証(ID証)は世の中に出回っている。その認識の上で、セキュリティ体制を見直す必要がある組織は多いのではないでしょうか。

 

 é転å許証ã®ã¤ã©ã¹ãï¼ç·æ§ã»ã´ã¼ã«ãï¼

 

更新履歴

  • 2019年4月15日AM(予約投稿)

シトリックスへのパスワードスプレー攻撃

米国のCitrix社へのサイバー攻撃が記事に出ていました。

www.sbbit.jp

 

公式発表 Citrix investigating unauthorized access to internal network | Citrix Blogs

 

Citrixがサイバー攻撃を受けたことはFBIから告知を受けたと、Black氏は次のように説明しています。

2019年3月6日、国際的なサイバー犯罪者がCitrixの社内ネットワークへアクセスしたと信ずる十分な理由があると、FBIがCitrixに連絡をとってきた。


 Citrixはまだ調査中ながらもこの攻撃により社内ドキュメントなどへのアクセスがあったとしています。

私たちの調査は進行中だが、現時点で分かっているのはハッカーは社内文書へのアクセスとダウンロードを行ったようだということだ。ただしまだ、どのドキュメントにアクセスされたかは特定されていない。


 FBIによると、「パスワードスプレイ攻撃」と呼ばれる種類の攻撃を受けたとのこと。 

 パスワードスプレイ攻撃とは、攻撃していることが分からないように時間をかけてパスワードの総当たりやパスワードリストを基にした攻撃を仕掛けるというものです。これにより認証が突破され、社内ネットワークにアクセスされてしまったようです。

(ビジネス+IT記事より引用)

 

 

◆キタきつねの所感

セキュリティベンダのResecurityによると、イリジウム(Mabna)というイラン系ハッカー集団による標的型攻撃だった様です。

最近の分析によると、攻撃者はツール、テクニック、およびプロシージャ(TTP)の組み合わせを悪用して、電子メールによる通信を含め、Citrixの企業ネットワークに保存されている6テラバイト以上の機密データにアクセスします。プロジェクト管理および調達に使用されるネットワーク共有およびその他のサービス内のファイル。

イリジウムの兵器庫には、VPN(仮想私設ネットワーク)チャネルおよびSSO(シングルサインオン)へのさらなる不正アクセスのための重要なアプリケーションおよびサービスに対する2FA認証を回避することを可能にする独自の技術が含まれています。

(Resecurityブログ記事より引用)※機械翻訳

 

FBIの3/23のFlashアラートに手口が書かれているとあったので、少し読んでみたのですが、パスワードスプレー攻撃でこのハッカー集団は、まず多要素認証が無く、推測しやすいパスワードを使っており、かつシングルサインオン(SSO)クラウドを使っている組織を狙っている様です。

例えばオフィス365の受信トレイ同期を利用して、不正にファイルを取得したり、電子メールに直接アクセスし、ローカル保存されている電子メールファイル(.PST)を転送する事を狙ってきます。

 

FBIの対策推奨案としては、

 ①多要素認証の導入

 ②NISTガイドラインに沿った、強固なパスワード設定

 ③パスワード管理・運用のレビュー(初期パスワード、パスワードリセット、共有アカウント)

を挙げていました。まぁ常識的な対策ですね。

 

マイクロソフトも、パスワードスプレー攻撃についてアラート記事を出している様です。

www.microsoft.com

 

こちらも対策推奨内容は以下の4点が書かれていました。

 ①Azure Active Directory パススルー認証によるユーザー サインイン

 ②Azure Active Directory スマートロックアウトの利用

 ③IPロックアウト

 ④Attack Simulations 

 

①~③は(オプション)設定を使うという事なので、何となくわかったのですが、そうしたものがあるとまったく知らなかったが、④の攻撃シュミレータです。2月21日からプレビュー版が公開されている様です。

techcommunity.microsoft.com

 

英語版だけな気もしますが、こうしたマイクロソフトクラウドサービスプロバイダー)が提供する追加防御策がもっと出てくると、パスワード認証の根本的な脆弱点を突かれて、やられ放題になりつつあるクラウド基盤のサービスのセキュリティは劇的に向上する気がします。

因みに、このシュミレータの機能を見ると、3つのシナリオスピアフィッシング攻撃」「パスワードスプレー攻撃」「ブルートフォース(総当たり)パスワード攻撃」が組み込まれている様です。

 

気になる方はチェックしてみては如何でしょうか。

 

 

ä¿å®å®ã®ã¤ã©ã¹ãï¼ç·æ§ï¼

 

更新履歴

  • 2019年4月15日AM(予約投稿)