wakatonoの戯れメモ このページをアンテナに追加 RSSフィード

たわいもないこと(日々の妄想とも言う)をつらつらと書いてます。断じて壊れメモではありません。ましてや「穢れメモ」でも爛れメモでもありません(涙)。
が、時により一つのことを掘り下げる傾向が見られるので、article数は少ないカモ。
ちなみにSlashdot Japanの日記もあります。個人的な連絡がある方はwakatono@todo.gr.jpまで("@"は2バイト文字になってるんで、てけとうに書き直してください)。GnuPG公開鍵はこちら

他のあたり:PFSEC - Systems Platform and Securityアマゾンのレビュー

強いWindowsの基本 WebDAVシステム構築ガイド(萌えバナーその1)
WebDAVシステム構築ガイドの方のバナーの絵柄は、内容とは何の関係もありません(汗)
アクセス探偵IHARA

おとなり日記はこちら

2016-07-14 世の中CSIRTという文字列が…

いろんなところで見られるように。

でも、どこまでやればいいの?とか何やればいいの?という話はあちこちで…。

[] 前提:CSIRTのコンスティチュエンシーとかサービス範囲とかはすでに決まっている  前提:CSIRTのコンスティチュエンシーとかサービス範囲とかはすでに決まっているを含むブックマーク  前提:CSIRTのコンスティチュエンシーとかサービス範囲とかはすでに決まっているのブックマークコメント

CSIRT設置するにあたって、「コンスティチュエンシー」や「サービス範囲」をはじめとすることは、すでに決まっているものとして以下の話を書いてたりします。

[]CSIRTとは、外部との情報交換のための信頼の枠組み CSIRTとは、外部との情報交換のための信頼の枠組みを含むブックマーク CSIRTとは、外部との情報交換のための信頼の枠組みのブックマークコメント

CSIRTに関して一番本質的なところをついてるものの1つが、こちらの山賀さんの講演で触れられているところと考える。

作ったから云々でもなく、外部から情報を得るのみでもなく、適切な情報も出していくという営みは必要だ。

[]外部との情報交換を行うインタフェース=CSIRTならば… 外部との情報交換を行うインタフェース=CSIRTならば…を含むブックマーク 外部との情報交換を行うインタフェース=CSIRTならば…のブックマークコメント

「情報交換を行うインタフェースがあればCSIRTを設置したといえる」のか?と言われると、これはYesともNoともいえる。

とある人wは、「最低限外向けの窓口(PoC)を設置してくれればCSIRT作ったといえるのでは」と述べているが、これは窓口対応を正しく理解していて、本当に必要な機能は何なのか?というのをわかっている人向けの説明といえる。

そこすら理解していない人が、「あ、それでいいんだ。んじゃとりあえず外部に対して窓口のメールアドレス公開するか」と安易に動くと、たいてい痛い目を見る。

[]窓口すらない場合 窓口すらない場合を含むブックマーク 窓口すらない場合のブックマークコメント

f:id:wakatono:20160714004933p:image

窓口すらない場合は、そもそも何か起こったかを外から送ってもらう統一的な枠組みを用意していないといえる(図では「Webサーバおかしい」ということを言おうとしている報告者が「どこに送るのさ?」と不安になってる様を描いている)。

昨今の状況でこれは考えづらいともいえるが、後で述べる例との対比のために、あえて出している。

[]窓口「だけ」ある場合 窓口「だけ」ある場合を含むブックマーク 窓口「だけ」ある場合のブックマークコメント

f:id:wakatono:20160714004931p:image

窓口「だけ」あるという場合は、窓口がない場合よりもひどいことになりうる。

報告者から報告を受け取った後、窓口から先どこに持って行っていいのかわからず、苦労することになる。

窓口を設置した企業なり団体なりの所帯が小さければ、まだなんとかなるかもしれない。しかし、企業規模なり団体規模なりが大きくなってくると、「整理されたエスカレーション先」なり「場合によって送る聞き先」なりを事前に把握しておかないと、確実に死ねる。

[]窓口+エスカレーション先がある場合 窓口+エスカレーション先がある場合を含むブックマーク 窓口+エスカレーション先がある場合のブックマークコメント

f:id:wakatono:20160714004929p:image

窓口を設定する意義の1つは、コミュニケーションや情報交換/コーディネーションを円滑にするところにある。

中と外のコーディネーションもそうだし、中のコーディネーションもそう。中→外の情報伝達も、外→中の情報伝達も、最終的にはPoCチームもしくはPoCチームから近いところでハンドリングされることになる。

窓口を設置するからには、「窓口がエスカレーションなりする体制を整える」ことが必須と言っているわけだ。

[]結論:CSIRTを作るならば窓口(PoC)の設置を&窓口を設置するならば、窓口からエスカレーションできるしくみもあわせて実現を! 結論:CSIRTを作るならば窓口(PoC)の設置を&窓口を設置するならば、窓口からエスカレーションできるしくみもあわせて実現を!を含むブックマーク 結論:CSIRTを作るならば窓口(PoC)の設置を&窓口を設置するならば、窓口からエスカレーションできるしくみもあわせて実現を!のブックマークコメント

窓口(PoC)が何をやるのか?というのを、自分なりの整理も兼ねて書いてみた。

兼任/専任というスタイルもさることながら、「窓口」という機能に着目して考えると、こういう見方もあるとご理解いただければ幸いである。

2016-04-18

ちょっとハマった ちょっとハマったを含むブックマーク ちょっとハマったのブックマークコメント

カスペルスキー マルチプラットフォームセキュリティ 2016を新規インストールしたところ、Firefoxでおかしなことにw

[]カスペルスキー マルチプラットフォームセキュリティ 2016 Windows版をインストールした直後 カスペルスキー マルチプラットフォームセキュリティ 2016 Windows版をインストールした直後を含むブックマーク カスペルスキー マルチプラットフォームセキュリティ 2016 Windows版をインストールした直後のブックマークコメント

カスペルスキー マルチプラットフォームセキュリティ 2016(以下KMS2016)のWindows版を入れた後、FirefoxGoogleにつなごうとすると以下のような画面が。

f:id:wakatono:20160418024750p:image

要は「変な証明書使ってるからつながせないよ」という意味。

KAV2015とかは探すと対処法出てくるんだけど、KMS2016(のWindows版)はなぜか出てこない。

[]なんでこうなるのか?〜MITMやってる結果で解決方法もあるんだけど、どうも中途半端 なんでこうなるのか?〜MITMやってる結果で解決方法もあるんだけど、どうも中途半端を含むブックマーク なんでこうなるのか?〜MITMやってる結果で解決方法もあるんだけど、どうも中途半端のブックマークコメント

KMS2016は最初からそうなんだけど、最近のカスペルスキー社のセキュリティソフトウェアは、SSL接続の中を確認するために、MITMをかけている。

そのために必要な証明書なんかは用意されているんだけど(KMS2016の機能を使ってインストール可能)、後付けで入れたブラウザだからなのか、それとも別の理由からか、Firefoxが使う証明書には、カスペルスキー社による証明書は入らない。

f:id:wakatono:20160418025513p:image

[]解決法?〜証明書をエクスポートして(手順1)、証明書をインポートする(手順2) 解決法?〜証明書をエクスポートして(手順1)、証明書をインポートする(手順2)を含むブックマーク 解決法?〜証明書をエクスポートして(手順1)、証明書をインポートする(手順2)のブックマークコメント

エクスポートしてインポートする、ただそれだけで解決するんだけど、インポート先に少しだけ注意しなきゃいけない。

f:id:wakatono:20160418025723p:image

証明書管理ツールを使って、信頼されたルート証明書の一覧を見ると、KMS2016の機能でインストールされた証明書が見えるので、選択して右クリックして、「すべてのタスク」→「エクスポート」を選び、証明書をファイルに書き出せばよい。

順序はFirefoxを起動後、設定パネルみたいなのを開いて「オプション」→「詳細」→「証明書を表示」と行けば、証明書一覧を別ウィンドウで表示するようになる。

その画面を見ると、「インポート」は可能なので、さきほどエクスポートした証明書(なんとか.cerというファイルに保存されていると思う)を選択して証明書をインポートする。インポート時に何を信頼するか?というのも聞かれるので、Webのみ信頼とする。インポート後は、Firefoxをいっぺん終了させて再起動することをお忘れなく。

f:id:wakatono:20160418030214p:image

f:id:wakatono:20160418030225p:image

f:id:wakatono:20160418030238p:image

[]なんでこんな問題が?〜証明書の管理が分かれてるし〜 なんでこんな問題が?〜証明書の管理が分かれてるし〜を含むブックマーク なんでこんな問題が?〜証明書の管理が分かれてるし〜のブックマークコメント

この問題は、Chromeでは起きず、Internet ExplorerやMicrosoft Edgeでも(当然だが)起きない。これは、問題が起きないブラウザは、Windowsの証明書ストアを使うようにしているためと考えられる*2。しかし、(理由はよくわからないけど)Firefoxは自前で証明書マネージャを持っており、そちらを使用しているためだ。

理由はともかくこうなっていることを把握しておけば、とりあえず次からは対処可能だろう…と思いつつ。

*1:使い方はこちら

*2:ほかの理由があったら教えてほしい…

2016-04-07 ちょっと間が空いてしまった このエントリーを含むブックマーク このエントリーのブックマークコメント

…近いうちに「作ってみた」でも書いてみるか…。

2016-04-02 新年度あけましておめでとうございます

4月1日は、全く余裕がなかった…

[]新手のランサムウェア…ですか 新手のランサムウェア…ですかを含むブックマーク 新手のランサムウェア…ですかのブックマークコメント

トレンドマイクロさんのblogや、MicrosoftさんのThreat Research & Response Blogに、またも頭を抱える事例が…。

その名もSamas。

[]何が新しいのか?〜内容はほとんど自爆テロだけど、何かがおかしい 何が新しいのか?〜内容はほとんど自爆テロだけど、何かがおかしいを含むブックマーク 何が新しいのか?〜内容はほとんど自爆テロだけど、何かがおかしいのブックマークコメント

記事をざっと読んで「うわこれヒドイ」と思った点は大きく2つ。

  • 標的型攻撃の手法に類似した方法で感染拡大を試みる
  • 通常のデータファイルだけではなく、バックアップファイルの破壊も試みる

で…記事をもとに、ざっと図を書き起こしてみた。

f:id:wakatono:20160402115017p:image

  • 図中(1)で感染したPCは、(2)のスキャンを行う
  • (2)のスキャンの結果、スキャン先に使える脆弱性がある場合には、(3)でマルウエアをリモート実行
  • 最終的に(4)のフェーズになると、vssadminなどでボリュームシャドウコピーにある「バックアップ」を削除し放題

という感じか。

標的型攻撃との相違をいろいろと考えてみたけど、「標的型攻撃」というのはあくまで攻撃の仕方や対象の絞り方で攻撃を分類した時の呼称であり、ランサムウェアは明らかに「データの身代金を取る」という目的思考の呼称なので、あまり筋はよろしくない。むしろこのような説明の仕方は、「ランサムウェアの手法を取り入れた標的型攻撃」が登場した際に、変な先入観(ランサムウェア is not used in 標的型攻撃)を植え付けかねないので、正直嫌。

でも、「バックアップファイルの破壊も試みる」は実は、最初の「標的型攻撃の手法に類似した方法で感染拡大を試みる」という特徴を備えた時点でほぼ自動的に実現されるのではないか、と考えている。

また、よく読むと「ボリュームシャドウコピーを削除」なので、(確かにバックアップファイルではあるけど)あまねくバックアップファイルをターゲットとしているわけではない。もちろん、リモートバックアップを行ったところでも、ランサムウェアがターゲットとしているファイル名がそのまま残存してると、そのバックアップ先にランサムウェアが感染した時に「アウチ」となるわけだが。

[]「脆弱性」を狭く捉えるな〜どちらかというと「脆弱性や脆弱な設定を突かれる」のほうが正しそう 「脆弱性」を狭く捉えるな〜どちらかというと「脆弱性や脆弱な設定を突かれる」のほうが正しそうを含むブックマーク 「脆弱性」を狭く捉えるな〜どちらかというと「脆弱性や脆弱な設定を突かれる」のほうが正しそうのブックマークコメント

Windows脆弱性というと、よく「MS16-0xx」とか「CVE2016-xxxx」という感じで管理されているものを想定する人もいる「かもしれない」。

でも、記事を読むと「psexec」という文字列が出て来たり、「ログイン情報窃取」とあるので、地産地消*1が可能な設定(例:パスワードが脆弱で、パスワードリスト攻撃が成立するとか、Pass-the-Hashが可能な状態とか)を悪用されるということも想定できる。

このため、図中では「脆弱性や脆弱な設定」と書いている。

[]対策の考え方はいいんだけど、例がまずい 対策の考え方はいいんだけど、例がまずいを含むブックマーク 対策の考え方はいいんだけど、例がまずいのブックマークコメント

トレンドマイクロさんのblogでは、対策も書かれている。考え方は悪くないけど、例がまずい。

以下、対策の引用。強調と着色部分は筆者による。

  • 定期的なバックアップと「3-2-1のルール」の実践
    ファイルを定期的に取ることで重要な情報を保護することができます。バックアップする際、「3-2-1のルール」をぜひ実践してください。自身のファイルのコピーを 3つ取り、それぞれ異なる端末に保存します。次に、それぞれ端末に保存する際、 2つの異なる種類の端末に保存します(例:ハードドライブおよびUSB)。最後に、3つのコピーの内 1つのコピーは他の 2つとは異なる場所に保存します(例:自宅とオフィス)。
  • 頻繁に訪問する Webサイトブックマークを活用
    頻繁に訪れる Webサイトは、ブックマークしておくことを推奨します。ブックマークを活用することで、アドレスバーに直接入力する際、誤ってタイプミスをして不正なURLに誘導される事態を避ける事ができます。
  • メールの添付ファイルを開封する際は細心の注意を
    身元が不明もしくは証明されていない送信者からの添付ファイルは決して開封しないでください。一方、知人友人からのメールの添付ファイルであっても開封する際には、送信者のメールアドレスを必ず確認して、細心の注意を払ってください
  • PC にインストールされているソフトウェアの更新を怠らない
    Cryptoランサムウェアの感染経路の1つは、上述のとおりソフトウェア脆弱性を突くエクスプロイトキットです。ユーザは、セキュリティ情報の更新を怠らず、自身の PCにインストールされているソフトウェアを常に最新の状態にしてください。
  • セキュリティ対策製品の導入は必須
    最新の脅威から PC や情報を守るためには、セキュリティ対策製品の導入は必須です。定期的なスキャンを実施してください。

この中で一番まずいのは、「定期的なバックアップと3-2-1ルール」の中にある「異なる場所の例」と「細心の注意」のやり方。

  • 「異なる場所」として「自宅とオフィス」を挙げているが、「自宅」は(多くのビジネスシーンを考えると)全く推奨できない。昨今多くの企業では、オフィスからの情報持ち出しを禁止しており、「自宅に保存」を実践された場合には他のリスクを招きかねない
  • 「細心の注意」の例に、「送信者のメールアドレスを必ず確認して」とあるが、送信者のメールアドレス自体は簡単に偽装されうる上に、何をどう確認して細心の注意を払えばいいのかわからない

代案を挙げるとしたら、以下のような感じか。少しわかりにくくなるけど、自席とかメールアドレスを確認するという文言を用いて誤解を招いたりするよりは遥かにマシ(と考えてたり)。

  • 「異なる場所」は、「勤務先の机」と「机以外に自分が管理する場所(ロッカー)」くらいか
  • 送信者のメールアドレスを必ず確認して」は、「表示されている送信者に(可能であればメール以外の手段で)必ず確認をして」くらいか

*1:自動で探して攻撃試行が可能なという意味

2016-03-23 ランサムウェア考察

最近猛威を振るっているランサムウェアだけど、トレンドマイクロさんの記事で「身代金を支払う」ことはおすすめできないというのが書かれていたりして、ちょっと気になった…。

[]はじめに〜オレの記事は、犯罪者に利することを目的とするものでは「ありません」 はじめに〜オレの記事は、犯罪者に利することを目的とするものでは「ありません」を含むブックマーク はじめに〜オレの記事は、犯罪者に利することを目的とするものでは「ありません」のブックマークコメント

いろいろと書いてるうちに、「こいつは犯罪者/攻撃者の片棒を担ぐのか?」と言われそうなことも出てくるかもしれませんが、そんなつもりは1ビットもありません。

あくまで「客観的」「中立」にものごとを考察した結果であって、そんなたいそうな意図は全くありません。

[]「身代金を支払っても元に戻る保障はない」というのは本当か? 「身代金を支払っても元に戻る保障はない」というのは本当か?を含むブックマーク 「身代金を支払っても元に戻る保障はない」というのは本当か?のブックマークコメント

まあ、本当だと思う。ただこれは、ソフトウエアのバグなどに起因して、(攻撃者側が)戻す意図があってもできないケースなどもありうるため、どの程度「元に戻らない」のかはよくわからない。

[]ケーススタディランサムウェアに感染してカネを払っても元に戻らないと何が起こる? ケーススタディ:ランサムウェアに感染してカネを払っても元に戻らないと何が起こる?を含むブックマーク ケーススタディ:ランサムウェアに感染してカネを払っても元に戻らないと何が起こる?のブックマークコメント

こんだけ流行ってる状況を見ると、ランサムウェアは、すでに犯罪者ネットワークでは認知されたビジネスモデルになっていると考えるのが自然だ。

そして、ランサムウェアの生成から配布までをサービスとして提供するRansomware as a Service(RaaS)も出始めている。

RaaSは、通常のSaaSなどと同じように、おおまかに3種類のステークホルダからなるビジネスモデルと理解している。

  • RaaSプロバイダ - 信頼性の高い暗号化機能を持ったRansomware提供および復号サービス提供を行う
  • RaaSユーザ - RaaSプロバイダからサービスを購入し、Ransomware被害者からカネを取る
  • Ransomware被害者 - RaaSユーザに対してカネを支払う

上記のうち、金銭のやりとりは「RaaSプロバイダ - RaaSユーザ間」と「RaaSユーザ - Ransomware被害者間」で成立するが、仮に「カネを払っても元に戻らない」ということがあると、何が起こるかを以降で検討する。

[]「カネを払っても元に戻らない」のがRaaSユーザに起因する場合 「カネを払っても元に戻らない」のがRaaSユーザに起因する場合を含むブックマーク 「カネを払っても元に戻らない」のがRaaSユーザに起因する場合のブックマークコメント

RaaSユーザの意図的な行動により、Ransomware被害者が「カネを払ってもデータが元に戻らない」となった場合、最たる被害者は Ransomware被害者よりもRaaS提供者になる可能性が高い。

これは、復号できないがため、カネを払わずバックアップから戻すという(攻撃者にとって一銭のカネにもならない)アクションをRansomware被害者に取られる可能性が高いからであり*1Ransomwareの出来不出来にかかわらず「ナントカというRansomwareに感染すると、カネ払っても復元できない」という風評被害Ransomware被害者を起点に広がり、「そんなRansomwareを生成するRaaSなんぞカネにもならんから使わねえ!」という(意図的に復元できないようにしたRaaSユーザ以外の)まともな(?)RaaSユーザはそのRaaSプロバイダを敬遠する理由になるからだ。

信頼性の高いSaaSであっても、プラスアルファをつくり込んだり実際にエンドユーザにサービス提供する会社がへたなことをやって、SaaSプロバイダまでまとめて疑われる構図に似ている(エンドユーザに(誤解とはいえ)疑われるサービス基盤を提供するSaaSプロバイダを誰が使いたいと思うだろうか?)。

もっとも、そのようなことを防ぐために、RaaSプロバイダ側もRaaSユーザを選ぶのではないか?(もしくは、RaaSで生成されるRansomwareは、暗号化や復号のためのコア機能はRaaSユーザには触らせないのではないか?)。

[]「カネを払っても元に戻らない」のがRaaSプロバイダに起因する場合 「カネを払っても元に戻らない」のがRaaSプロバイダに起因する場合を含むブックマーク 「カネを払っても元に戻らない」のがRaaSプロバイダに起因する場合のブックマークコメント

このような場合はもはや論外でw、RaaSユーザはまずそのプロバイダは使わない。

自分に非がないのに自分が儲けられないってのは普通に嫌だろうから。

[]流行(普及?)しているランサムウェアは、実はカネさえ払えば確実に復元できるのではないか?という仮説 流行(普及?)しているランサムウェアは、実はカネさえ払えば確実に復元できるのではないか?という仮説を含むブックマーク 流行(普及?)しているランサムウェアは、実はカネさえ払えば確実に復元できるのではないか?という仮説のブックマークコメント

上記のことより、広域に流通している/よく発見されるランサムウェアは、実はカネさえ払えば(自身のサービスの信用を維持するために)確実に復号できるのではないか?という仮説が成り立つ。

致命的なバグ(本来意図した復号機能を提供できない/暗号化や復号機能にバグがあり、暗号化しても復号できない)を作ってしまったSaaSプロバイダは、SaaSユーザから死ぬほど叩かれるし、そんなサービス誰が大々的に使いたがるだろうか?

また、何らかのトラブルがあった場合、きちんとした商売を心がけているRaaSプロバイダやRaaSユーザは、(やってることがそもそも違法ということもあり)誠実に対応するとかんがえられる。これは、山崎はるかさんが書かれたコラム「ピーコの追い込み」の中の一節も、一つの根拠になっている。具体的には以下のように書かれている。

残りの60%の主催者や管理者の氏名・住所はつかめていない。が、プライマリメールアドレスは掴んでおり、なかなかしっぽを出さない場合は、わざとトラブルを演出して 吐き出させた。

(違法販売をしている人はタレコミを恐れるがばかりに、トラブルに対しては カタギの企業よりも誠実に対応する)

[]額にもよるが、「身代金支払い」も視野に入れることで、対処の選択肢は広がるのではないか 額にもよるが、「身代金支払い」も視野に入れることで、対処の選択肢は広がるのではないかを含むブックマーク 額にもよるが、「身代金支払い」も視野に入れることで、対処の選択肢は広がるのではないかのブックマークコメント

トレンドマイクロさんの記事では、身代金を支払うべきでは「ない」理由として以下の3つを挙げている。

  • 「身代金」を払ってもサイバー犯罪者が約束を守る保証はどこにもない
  • 身代金の支払いはサイバー犯罪者に資金を与えることになる
  • 身代金を支払ったことが理由で、別の犯罪や脅迫に巻き込まれる危険性もある

被害者にとっては3つめの理由がリスクとなるが、このリスクを受容する、もしくは低減させられるのであれば、暗号化されてしまったデータの種類や量によっては、身代金の支払いというのも取りうる選択肢になる。

[]基本は「普通のセキュリティ対策」+「こまめなバックアップ」と「バックアップされたデータのオフライン保存」 基本は「普通のセキュリティ対策」+「こまめなバックアップ」と「バックアップされたデータのオフライン保存」を含むブックマーク 基本は「普通のセキュリティ対策」+「こまめなバックアップ」と「バックアップされたデータのオフライン保存」のブックマークコメント

「カネさえ払えば復元できるならば」と思う人はいいけど、何度も何度も引っかかるようなケースも想定できるので、その度にカネ払うのはちょっとどうかと…

なので、そんな(Ransomware被害から復旧するために攻撃者に支払う)カネがあるならば、そのカネを使って普通にセキュリティ対策を充実させるなり、バックアップ装置を購入するなりしたほうが、よっぽど建設的だろう。

*1:そうでなくともバックアップから戻すだろうけどw

0000 | 00 | 01 |
2003 | 09 | 10 | 11 | 12 |
2004 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 04 | 05 | 06 | 07 | 08 |
2011 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 12 |
2012 | 01 |
2013 | 05 | 06 | 07 | 08 | 09 | 12 |
2014 | 03 | 06 | 08 |
2015 | 02 | 04 | 08 | 10 |
2016 | 02 | 03 | 04 | 07 |
hacker emblem
ページビュー
1666937