12月 24

パスワードの有効期間設定及び、パスワードの定期変更についてボクなりに再考してみましたよ。

総務省から「リスト型アカウントハッキングによる 不正ログインへの対応方策について(サイト管理者などインターネットサービス提供事業者向け対策集) 」がリリースされました。思うところがったので以前メモしたのですが、先日、その文書に関わった方と「パスワードの定期変更」についてTwitterでやり取りさせていただきました(やり取り内容はこちら)ので再度「パスワードの定期変更」について総務省からリリースされた文書(以下、文書)を参考に自分なりに考えてみようと思います。

ちなみにボクは、この策に対しては懐疑的、否定的で、リスト型攻撃を含む攻撃(辞書攻撃などを含む)に対抗する場合は、「パスワードの使い回しをやめる」ことと「容易に推測可能なパスワードは設定しない」という対策を行うべきだと考えており、定期変更は必要がないというスタンスです。(もちろん、自ら定期変更を行いたいという方は行っていただいても文句はありません。そこは自由だと思いますので。)

考えるポイントとしては
パスワードの有効期間設定及び、パスワードの定期変更の効果はあるか。
というものです。
また、関連する対策として
「パスワード履歴の保存」というものがあります。
こちらには以下のような記述があります。

パスワードの変更時期が来た際に、利用者が前回まで使用していたパスワードに戻してしまうなど、更新時期が来るたびに2つのパスワードが使い回しされては、攻撃者が保有するリストが再度有効なものになってしまい、意味がありません。そのため、上記(2)のパスワードの定期的な変更と合わせて、パスワードの更新履歴を保存し、変更時に過去のパスワードと照合して、数世代前に使用したパスワードへの変更を認めないようにすることも考えられます。

こちらも整理する際の考慮にいれます。

まずは、文書から読み取れる前提条件などの自分なりの整理。

【前提条件】
 ・ リスト型攻撃への対応。
 ・ 対象はオンライン上のサービスである。
 ・ サービスのユーザID、パスワードは利用者が設定できるサービスである。
 ・ サービス提供側が行える対策である。
 ・ ローカルネットワーク上のサービスやスタンドアロンコンピュータは対象外。

【リスト型攻撃の特徴】
 ・ ある程度の期間に渡り、検知に時間を要する。
 ・ 数万単位の不正ログインが行われる。
 ・ 利用者の通報、大量のエラーの発生、特定IPアドレスからの不正ログインの検知、社内の調査によって検知されている。
 ・ 指名、性別、生年月日、住所などの個人情報が閲覧されている可能性がある。

【定期変更関連以外に文書内で言及されている策】

 [予防策]
  ・ ID・パスワードの使い回しに関する注意喚起の実施
  ・ 二要素認証の導入
  ・ ID・パスワードの適切な保存
  ・ 休眠アカウントの廃止
  ・ 推測が容易なパスワードの利用拒否

 [被害の拡大を防ぐ対策]
  ・ アカウントロックアウト
  ・ 特定IのIPアドレスからの通信の遮断
  ・ 普段とは異なるIPアドレスからの通信の遮断
  ・ ログイン履歴の表示

整理は以上です。

さて、上記の整理を踏まえて

パスワードの有効期間設定及び、パスワードの定期変更の効果はあるか。

ということですが、効果があるとする主張される方の理由としては以下のものが挙げられるかと思います。

① どこかから漏えいしたリストの無効化を行うことができる。
② 万が一、ログインに成功されたとしても被害の拡大を防止できる。

それぞれ効果があるのかどうかということを考えてみます。

① どこかから漏えいしたリストの無効化を行うことができる。

こちらは、そもそもになるかと思いますが文書のP4で言及されている「ID・パスワードの使い回しなどの関する注意喚起」内にある

サービスごとに異なるパスワードを設定することが本質的な対策となります。

の部分ができていればパスワードの定期変更タイミングまで待つということを行う必要はないと思います。

また、Twitterでのやりとりで出てきたもので
「複数のサービスで定期変更のタイミングが異なるため、その異なるタイミングで各サービスで異なるパスワードを設定することを促すこととなるのではないか?」という意見がありました。
これに関してはあるかもしれませんし、ないかもしれません。
数字的な根拠はありませんが個人的な感覚としては、同じものを設定する、もしくは可能性が高いのではないかと思っています。仮に別のパスワードを設定されることがあったとしても許可されている世代数でパスワードを変更していく(3世代なら3つのパスワードをループさせる)という運用をユーザが行った場合、定期変更のタイミングのズレで一旦異なるパスワードとなったものが同じものになるタイミングを生んでしまう可能性もあるではないかと思います。ですので、必ずしも定期変更が使い回し減らすことには繋がらないのではないかと思います。

リスト型攻撃の特徴とは少し逸れますが、定期変更を繰り返すことで生まれるものはパスワードが容易に推測されるような文字列になり、それが複数のサービスで使い回されることの発生を誘発すると考えています。トレンドマイクロの調べによるとパスワードでログインが必要なWebの利用状況として、1ユーザあたり13.95サイト(標準偏差)を利用しているとのことです。使い回しをしない前提ですと、1人当たり約14のパスワードを覚えることになります。これに対し定期変更を行うとそれぞれのパスワードをその都度、覚えなおしになります。(パスワード管理ソフトやメモしている方は除く。)そうなれば、やはり、覚えやすいパスワード(つまりは攻撃者にも推測されやすい)を設定し、複数サービスで共通のものを設定してしまいがちとなるのではないでしょうか。

また、「どこからか漏れたリスト」と考えた場合、他から漏れたリストだけではなく、漏れた元とリスト型攻撃が行われる対象が同じという場合もあると思います。
漏れたリスト(攻撃者からすると盗んだリスト)のパスワードが平文ではなかった場合(多くの場合そうであってほしいのですが)攻撃者は平文に戻す処理を行う必要があります。いわゆるオフラインクラックですね。この平文に戻す処理を行っている間に定期変更のタイミングがやってくれば、攻撃者のオフラインパスワードクラッキングを振り出しに戻すことが可能と言えるでしょう。
しかし、ここではリスト型攻撃の特徴として文書にも挙げられている

・ 数万単位の不正ログインが行われる。
・ 利用者の通報、大量のエラーの発生、特定IPアドレスからの不正ログインの検知、社内の調査によって検知されている。

といった特徴を利用してサービス提供側が早期発見し、リセットなどの対策を取ってほしいとボクは思います。

また、定期変更が招くと考えらえれる「容易に推測可能な文字列」を設定した場合は、パスワードの保存の方法にもよりますが、オフラインクラックに耐性のないものとなってしまう可能性があると考えられます。

② 万が一、ログインに成功されたとしても被害の拡大を防止できる。

こちらは、不正ログインされたタイミングからほど近く、うまい具合に定期変更のタイミングが来た時には効果はあると思います。ただ、文書中P3で言及されている「これまでのリスト型攻撃による被害の特徴」にある

氏名、性別、生年月日、住所などの個人情報が閲覧されている可能性があ
ること

これが仮に目的であった場合は不正ログインを行われてすぐにでもアクセス可能な情報であると考えられるためうまい具合に定期変更のタイミングで守られるとは考えにくく、守れることはかなりのレアケースなのではないかと考えられます。

それ以外の目的であった場合を考えてみます。

不正ログインを行った後、オンラインバンキングで送金処理を行う、ポイントサービスを用いてポイントを不正利用するなどが考えられると思います。前者の場合は、殆どの場合において新規の送金先に送金する場合は何かしらの追加認証が用意されていますので、実際に送金することはパスワードのみでは行うことができません。(住所変更などを行う場合も別の認証が設けられている場合もありますね。)後者の場合は残念ながら追加の認証がない場合が殆どです。では、これが定期変更のタイミングで守りきれるのか?と考えるとやはり疑問が残ります。

先日こんな事件がありました。

楽天ポイント盗み、電子マネーに=不正アクセス容疑で中国人逮捕-岐阜県警

IDとパスワードが流出! キミの楽天ポイントも知らずに盗まれる?

記事を読む限り、どこからか漏れたリスト(楽天でのログインができるできないの確認はしているかどうかは不明)を買い取ったとされる容疑者が犯行に及んだと考えられます。このケースの場合は、どこかからリストが漏れてから実際の被害が発生するまで、前に例で挙げた目的である個人情報を閲覧されるよりもタイムラグがあると考えられます。これであれば定期変更のタイミングでユーザがパスワードを変更すれば不正ログインすることを防ぐのに間に合うタイミングは多少あると思います。しかし、これもタイミングという曖昧なものに頼るのではなく、どこかから漏れたリストを使われたとしてログインできないよう使い回しをやめるというところに力を注ぐべきではないでしょうか。

また、サービス提供側でできる対策としては賛否が分かれるところではあると思いますが

Adobeの個人情報流出のお知らせ、なぜかEvernoteから

一部のYahoo! JAPAN IDに対するパスワードリセット措置について

といったことを実施しているところもあります。

【まとめ的なもの】

ボクの中では、やはり、どうしても「定期変更」によって得られる恩恵はかける労力に見合わなさすぎるという結論です。
ボクは前述した通り、、「パスワードの使い回しをやめる」ことと「容易に推測可能なパスワードは設定しない」に注力することが先決であるという考えは変わりません。
これら2つの対策は単体でも相当の効果が得られる(前者はリスト型攻撃に対して、後者は辞書攻撃などの推測でのログイン試行に対して)のに対して、定期変更は単体での効果も薄く曖昧で、かつ、この2つの阻害要因ともなりえると思っています。

ユーザにはユーザに委ねられる部分である

・パスワードの使い回しをやめる
・容易に推測可能なパスワードは設定しない

を行ってもらうようにし、サービス提供側が行えることについては定期変更に関するもの以外を運用との兼ね合いを考慮した上で行ってもらうというのが現状の現実解なのではないでしょうか。

もちろん、定期変更をやめることで、この2つの対策が必ず行われ、すべてがクリアになるのかというとそういうわけではありませんが、ユーザに対しては必要最低限の労力をかけてもらうようにし、何を行うべきかを示し、それに注力してもらうべきなのではないかとボクは思います。
対策としては、パスワード管理ソフトの使い方を覚えるか(場合によっては有料のソフトもあるのでお金が必要なケースもあります。)、メモというアナログな方法での運用でカバーかというところですね。どちらでもよいと思いますし工夫次第かと思います。ボクとしてはボクが便利と感じるパスワード管理ソフトをおすすめしたいところですが、すべての人が使いこなせるわけではないのでパスワード管理ソフト1択とはできないと思っています。
また、パスワード管理ソフトって言っても全てが有料というわけではありません。複雑なパスワードを設定して、使い回さず、定期変更が必要なのでパスワード管理ソフトを買わないといけませんよ!なんて言ってくる人がいたらそれは「セキュリティ詐欺」だと思っていいと思います。

「パスワードが長期間変更されていません。」
「パスワードは定期的に変更してください。」

といったようなことが書かれているところが消え
パスワードを設定する際に

「容易に推測可能なパスワードを設定していませんか?」
「他のサイトでのパスワードの使い回しをしていませんか?」

に対するチェックボックスなんかが表示されたり、そこを「はい」にしないと
それらの脅威を説明するページに飛ばされたりする日がくればいいなって思いました。
ちょっと鬱陶しいですかね?

Category: memo | パスワードの有効期間設定及び、パスワードの定期変更についてボクなりに再考してみましたよ。 はコメントを受け付けていません
12月 20

Windowsのndproxy.sysの脆弱性により、権限昇格が行える脆弱性(CVE-2013-5065)に関する検証レポート

【概要】
Microsoft WindowsXPまたは2003のndproxy.sysに、ローカルより権限昇格を行える脆弱性(CVE-2013-5065)が発見されました。この脆弱性は、ndproxy.sysドライバへの入力値に対する検証において、不備があることにより発生します。これにより、権限の低いユーザから権限昇格を行うことができ、その権限で任意のコードの実行が可能となります。

攻撃者がこの脆弱性を利用するためには、システムへの有効なログオン情報が必要になります。
攻撃者が何らかの方法でシステムの一般ユーザでのアクセス権を獲得した場合、この脆弱性を利用することで管理者権限も同時に掌握されます。その結果、管理者権限でシステムを操作し、重要情報の改ざん、窃取されてしまうといった危険性があります

本レポート作成(2013年12月20日)時点において、Microsoft社から脆弱性への対策、回避策などのアナウンスが公開されております。しかし、本脆弱性に対応した修正プログラムはリリースされておりません。この脆弱性はローカル環境で発現するものですが、攻撃を成立させるためのコードが容易に入手可能であり、かつ、すでに攻撃に利用されているとの報告もあるため、今回、この脆弱性の再現性について検証を行いました。

【影響を受ける可能性があるシステム】
– Windows XP Service Pack 3
– Windows XP Professional x64 Edition Service Pack 2
– Windows Server 2003 Service Pack 2
– Windows Server 2003 x64 Edition Service Pack 2
– Windows Server 2003 with SP2 for Itanium-based Systems

【対策案】
本レポート作成(2013年12月20日)時点において、Microsoft社から本脆弱性を修正するプログラムはリリースされておりません。
Microsoft社からndproxy.sysを無効化するという回避策が案内されております。

【参考サイト】
CVE-2013-5065

マイクロソフト セキュリティ アドバイザリ (2914486)
Microsoft Windows カーネルの脆弱性により、特権が昇格される

【検証イメージ】
P05_post

【検証ターゲットシステム】
WindowsXP Professional SP3
Windows Server 2003 R2 SP2

【検証概要】
MS13-080を利用して、一般ユーザ権限(Users権限)を奪取した後、本脆弱性(CVE-2013-5065)を利用し、SYSTEM権限へと昇格を行うというものです。

【検証結果】
下図は、攻撃後の誘導先のコンピュータ(Linux)のターミナルの画面です。赤線で囲まれている部分は、ターゲットPC(WindowsXP Professional SP3)にMS13-080を利用し、Users権限を奪取しています。ここでは、User1(Users権限)で接続が行われています。一方、黄線で囲まれている部分は、本脆弱性を利用後の状態です。ここでは、SYSTEM権限で接続が行われています。これにより、権限昇格を行うことに成功したと言えます。

P04_cve-2013-5065_cut3

WindowsXPは2014年4月9日に、Windows Server 2003は2015年7月14日にMicrosoft社のサポートが終了します。

サポート終了後はこのような脆弱性が発見されたとしてもマイクロソフト社による修正は行なわれないため非常に危険な状態となる場合があります。特別な理由がない限り、新しいOSへの移行を行なっていただく事を推奨いたします。

reported by y.izumita, ntsuji

Category: exploit | Windowsのndproxy.sysの脆弱性により、権限昇格が行える脆弱性(CVE-2013-5065)に関する検証レポート はコメントを受け付けていません
12月 19

リスト型アカウントハッキングによる不正ログインへの対応方策について メモ

総務省から「リスト型アカウントハッキングによる 不正ログインへの対応方策について(サイト管理者などインターネットサービス提供事業者向け対策集) 」がリリースされました。そちらについての思うところメモ。

【P2】

このようなリスト型攻撃から個人情報や信用情報などを守るためには、利用者において、自身のID・パスワードの管理に際して対策を実施していただく必要があることは言うまでもありません。しかし、リスト型攻撃による不正アクセスの発生やそれに伴う個人情報の漏洩は、企業のコンプライアンス上問題となり、企業の信用を損ねる恐れがある他、内部調査及び復旧のためにサービスを停止する事態になれば、多くの機会損失が発生することになるなど、サービスを提供する事業者自身の問題とも言えます。

ユーザが設定するパスワードが推測可能なものか、使い回しているかということは最終的にユーザの責任において行われるべきものだと思います。
そこでユーザにきちんと注意喚起や保護する仕組みを提供することはサービス提供側が行ってほしいことではあると思います。しかし、おんぶに抱っこをしないからといって、それが企業コンプライアンスに関わるのかというとそれは違うと思います。
この類の話をするときにボクは自動車メーカーとドライバー(運転手)の話をします。自動車メーカーはサービス提供側、ドライバーはユーザです。
調べてみると分かるのですが(たとえばこのあたりとか)自動車メーカーは安全に対して様々な技術を取り入れています。エアバッグ、歩行者障害低減ボディ、アクティブセーフティ技術などなど。
こういった安全技術が取り入れられていたとしても、ドライバーが飲酒、スピード超過など危険運転を行ってしまっては元も子もありません。

これと同じでサービス提供側とユーザで各々が担う部分があり、双方の努力と歩み寄りを行うような空気や理解を広めていかなければならないのだと思います。サービス提供側が一方的に攻められ負担を強いられるようなセキュリティではあってはならないと思うのです。

【P4】

② パスワードを定期的に更新し、リストを陳腐化する

とありますが、複数のサイトで同一のパスワードを使い回していなければ「定期的」に変更し続ける必要はないと思います。サービスから漏えいが発生してしまったのであれば、ユーザへは漏洩が発覚したときに利用されていたパスワードを使って不正ログインできないようにするために一度変更してもらえばよいはずです。もしくは、サービス提供者の側でリセットを行い、以前使っていたパスワードとは別のものを再設定してもらうよう注意を促すほうがよいのではないでしょうか。もう少し踏み込んだサービス提供側のアクションとしては、他のサービス提供者で漏えいが発覚した際には、そちらの情報を元に注意を促したり、自サービスでパスワードのリセットなどを行うといったことも最近はちらほら行われてきているようです。

【P5】

(2)パスワードの有効期間設定

これに関しては同意できません。
パスワードの定期変更の理由として、定期変更のタイミングで被害を食い止めて、被害の拡大を防止するというものが挙げられますが、これは「情報は盗まれる。不正利用はされる。でも、され続けない。」という些細な効果しかないと思っています。ここの項目では有効期間を設定する理由として、どこからか漏えいしたID、パスワードのリストを陳腐化させるというものが挙げられているのですが、文末には

また、有効期間も一年、半年にするなど、事業者で管理している情報の価値に応じて設定することも一案です。

とあります。
仮に半年とした場合、最長で半年間は不正ログインされ続けることになりますのでリストを陳腐化することができる有効な対策とは言えないと思います。
数時間から数日で攻撃者は欲しい情報を手に入れていくことでしょう。
だからといって変更の感覚を短くすることはユーザへの負荷を高めるだけで利便性を大きく損ない、まさに本文に書いてある通り

ただし、パスワードの有効期限を短くして利用者に頻繁に変更を求めすぎると、利用者が、他人に推測されやすい簡単なパスワードを設定する傾向に陥りやすく、窃取される危険性を高めることもあるので注意を要します。

を招いてしまうことになると思います。

リストを陳腐化させることに対して敢えて、定期変更が有効であるという理由を挙げるとするならば、リスト型攻撃を行った攻撃者がリスト内の有効なアカウント(不正利用可能なアカウント)を確認した上で自分ではそれ以上のことを行わず、他者に売り渡すというパターンでしょうか。それでもやはり半年というのは悪用することにおいて十分な期間とも考えられますし、そもそも、リスト型攻撃のような分かりやすい攻撃が発生していることをサービス提供側がいち早く検知し、対処を行う仕組みを用意することのほうが必要で有効であると言えると思います。
(これについてはP11で触れられていますね。)

【P11】

② 攻撃が行われているIPアドレスからの通信を遮断する

これは有効だとは思います。
しかし、11月に起きた「GitHub」への攻撃では4万あまりにIPアドレスを使った攻撃(リスト型攻撃ではなくブルートフォース攻撃と言われている。)であるとのことですので、そういった場合は、有効性が低くなるということは理解しておく必要があると思います。巷には、リスト型攻撃対策として閾値を超えるログイン試行があった場合はその攻撃元のIPアドレスをブロックするという製品がありますが、リスト型攻撃を行われた場合、そのリストの質によっては、はその閾値以下のログイン試行は成功/失敗確認が取れるということになります。5回を閾値として6回目以降をブロックというものであればIP数 x 5回の確認は行えるということになります。また、閾値が外部から挙動をチェックすることで分かればその閾値以下ギリギリの試行を行って、別のIPに切り替えるということをすればブロックされたことを通知するようなアラートがあった場合、そのアラートは上げさせないということもできそうですね。
IPアドレスを頻繁に変えつつ試行を行っても短時間に行われれば通常よりも集中したアクセスであると検知しやすい側面があるのかもしれませんが、今後はもしかすると時間をかけたものも現れるのかもしれませんね。この辺りは攻撃者のトレードオフに対する考え方にもよるのだとは思いますが。

【さいごに】
リスト型攻撃って本当に厄介なものだなと思うわけですが、冒頭にも書いたようにサービス提供側とユーザ双方の努力と理解による歩み寄りが必要性が顕著に表れているものだなと思います。
過去にセキュリティって誰のためのものなのか?ということを考えたことがあるのですが、セキュリティって一部の専門家のためのものではなくて、脆弱性から保護することよろしく、弱い者(あるいは物、箇所)を守るためにあると思いました。とすれば、守る者と守られる者がいるわけで、つまるところ、みんなのものだと思います。みんなのものであればみんなで役割分担、当事者意識を持っていけるようなものにしていかないといけないなって心底思います。

地道でも頑張っていかないといけないなって改めて思います。

Category: memo | リスト型アカウントハッキングによる不正ログインへの対応方策について メモ はコメントを受け付けていません