タグ: Security

  • 読了:情報セキュリティの敗北史: 脆弱性はどこから来たのか

    読了した。いつごろの時代から情報セキュリティという考えかたができて、どう変遷してきたのか。それが書かれてあり、面白かった。敗北史と題名についているだけあり、セキュリティの対策と、それをぬけてくる様々なことが書かれていた。今の状況の背景を知るというのは、本当に重要。

    情報セキュリティの歴史と、その敗北をしると、ゼロトラストセキュリティという思想が出てきた理由も腑に落ちる。いまの状況打破という側面もゼロトラストセキュリティにはあるけれど、結局、行き着くところだった、ということなんだろう。防げないのであれば、レジリエンスを高めるというのは当然といえば当然と。セキュリティが考慮されて設計されたアーキテクチャでないのだから、そうなるわけだ。国家がハッキングによる情報収集を行って、そのハッキングを防ぐことができないというのであれば、同じ原理で攻撃者であるハッカー集団からも攻撃もあり防げない(ゼロデイアタック)可能性が高い。だから行き着く先はゼロトラストセキュリティの考え方になる、と。

    それから、今のインターネットが完全に崩壊するようなワームやウィルスが出回らないのは、P.279の「最悪のワームを防ぐのは、現在のセキュリティ対策ではない。いまだにそうしたワームが発生していないのは、それが誰の利益にもならないからだというジョブズの答えは、恐らく正解だろう。このケースでは、他の多くの場合と同様に、情報セキュリティの経済学と心理学の観点から問題を検討することで重要な洞察が得られる。」ということ。分断したり、崩壊させるよりも、ほどよく脆弱性を使い、利用するほうが利益になるわけで、完全にインターネットをシャットダウンしたほうがよいという状況が作られない限りは、ギリギリで大丈夫なのだろう。

    敗北の歴史から学ぶ、学びが多くてよい。初期の情報セキュリティ研究の幕開けのころの話はぜんぜん知らなかったし、考え方の変遷も面白かった。読んでよかった。

  • ”Needs triage” って、何?

    Ubuntuのセキュリティ対応状況を確認していて、状況が「Needs triage」になっているものが多数あり。「Needs triage」はどういう状況なのか忘れるので、メモ。

    Needs triage → 脆弱性があるパッケージ(やモジュールなど)が存在しているが、対応が必要かどうかは確認・選別が必要な状況

    Ubuntuの場合、ステータスが、Needs triageとなっているものは、脆弱性の影響があるのかどうかわからない状態ということ。

    「Released (5.15.0-53.59)」となっているものは、カッコ内のバージョンで対応されているので、それと比べればよい。

    「Not vulnerable (code not present)」は、影響なし。

  • Text4ShellというApache Cmmons Textの脆弱性

    「Text4Shell」というApache Commons Textのバージョン1.5~1.9にある脆弱性。この脆弱性を利用されると、意図しないリモートコード実行やリモートサーバ接続の危険性があるとのこと。「CVSS v3」では、「9.8」のクリティカル判定。MAXが10なので、数値としては、かなりの深刻度だ。

    「Apache Commons Text」は、Javaのプログラムなどに組み込まれて使われるライブラリで、テキスト処理に特化した機能が集められたパッケージ。これ、地味に使っているかどうかの判定が難しい気がする。ソースコードで、importしているかの検索をすればよいが、ビルド時に使っているApache Cmmons Textのバージョンがいくつかによるので、管理されていないといちいち確認する必要がある。Githubなどにあるチェックツールを使っていれば簡単に検知できるみたいだが。

    Log4Shellのような大事にはならないようだが、使っているかどうかが外形でわかりにくいこと、提供されてるプログラムの一部で使われている可能性もあることから、発見されないものが多く残りそうな気がする。

    参考

    https://forest.watch.impress.co.jp/docs/news/1449820.html

    https://sysdig.jp/blog/cve-2022-42889-text4shell/

  • 「CVE-2022-3075」の脆弱性対応版のChromeとEdge

    「CVE-2022-3075」の脆弱性対応版、ChromeとEdgeがリリースされている。バージョンのつけ方がChromeとEdgeで異なるので、対応バージョンをメモする。

    CVE-2022-3075の対応版のChromeバージョン

    105.0.5195.102

    CVE-2022-3075の対応版のEdgeバージョン

    105.0.1343.27

    ゼロデイの脆弱性がふえているのは気になる。新しいバージョンがリリースされていれば、自動更新なので楽ではあるけれど。ただし、ChromeやEdgeの再起動は必要。

    参考

    Chrome https://chromereleases.googleblog.com/2022/09/stable-channel-update-for-desktop.html

    Edge https://docs.microsoft.com/ja-jp/deployedge/microsoft-edge-relnotes-security

  • 「Dirty Cred」の対応をUbuntuでやったログ

    「Dirty Cred(CVE-2022-2588)」についてのUbuntuのページ。修正されたカーネルのバージョンを調べて、アップデート後にそれよりも新しくなっていればよい。

    https://ubuntu.com/security/CVE-2022-2588

    修正パッチは出ているので、”apt update” “apt upgrade” でできるはずなので、試した。カーネルのバージョンが変わっていることが確認できたので、apt upgradeで問題なし。

    Ubuntu 18.04 LTS のとき

    作業前

    zen@LABO:~$ lsb_release -a
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description:    Ubuntu 18.04.6 LTS
    Release:        18.04
    Codename:       bionic
    zen@LABO:~$ uname -a
    Linux LABO 4.15.0-166-generic #174-Ubuntu SMP Wed Dec 8 19:07:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
    zen@LABO:~$

    作業後

    zen@LABO:~$ lsb_release -a
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description:    Ubuntu 18.04.6 LTS
    Release:        18.04
    Codename:       bionic
    zen@LABO:~$ uname -a
    Linux LABO 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
    zen@LABO:~$

    Ubuntu 20.04 LTS のとき

    作業前

    zen@TEST:~$ lsb_release -a
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description:    Ubuntu 20.04.4 LTS
    Release:        20.04
    Codename:       focal
    zen@TEST:~$ uname -a
    Linux TEST 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
    zen@TEST:~$

    作業後

    zen@TEST:~$ lsb_release -a
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description:    Ubuntu 20.04.4 LTS
    Release:        20.04
    Codename:       focal
    zen@TEST:~$ uname -a
    Linux TEST 5.4.0-125-generic #141-Ubuntu SMP Wed Aug 10 13:42:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
    zen@TEST:~$
  • メモ:2021年日常的に悪用された脆弱性(CISA発表)

    メモとして。アメリカのCISAが発表した2021年に日常的に悪用された脆弱性の記事。

    米国CISA:2021年日常的に悪用された脆弱性
    https://www.cisa.gov/uscert/ncas/alerts/aa22-117a

    Log4jと、Exchange Serverまわりが多い。それに、VMwareのvCenter Serverに、フォーティネットか。悪用が多いということは、それだけ対策されていないということ。

    2020年の脆弱性も悪用されているものがあることから考えると、Log4jの脆弱性は2022年も引き続き主要な攻撃対象になるのだろう。

  • 新しいタイプのEmotetが流行

    3月のEmotetは、WordやExcelのファイルのマクロを使った攻撃が主体で、メールの文面が工夫されて、より間違いやすく誘導するタイプのものだった。このときは、添付ファイルを開いても、マクロを実行しないなどの対策が有効だった。

    現在、新しく流行を始めたタイプは、WordやExcelのファイル形式ではなく、Windowsのショートカットの形式で配布されている。このショートカットファイル(リンク形式)のファイルは、拡張子が「.lnk」ですがWindowsのデフォルト設定として、拡張子が表示されない。そのため、見た目上のアイコンは、「xxx.pdf」のように見えてしまう。※フォルダ設定で表示にしていても、表示されない。レジストリでの変更が必要。

    このリンクタイプのEmotetは、ファイルを開くと、インターネット上にあるVBスクリプトやPowershellスクリプトを実行して、Emotetの本体をPCに感染させるとのこと。リンク形式のため、アンチウィルスでの検疫を通過する(Emotet本体が実行されたときは、検知してくれる可能性はあり)。

    対応策は、

    • 怪しげなファイルを開かない
    • 添付ファイルをむやみに開かない
    • アイコンをよく見る。
    • ファイルのプロパティも確認して、拡張子が「.lnk」じゃないことを確認する。

    くらいだろうか。アンチウィルスソフトなどで対応してくれるとよいのだが、このタイプだと限界がありそうだ。

    参考:

    「Emotet」に「Microsoft Office」がなくても感染するショートカットファイルの亜種
    https://forest.watch.impress.co.jp/docs/news/1406053.html

    「Emotet」の新たな攻撃手法を観測、メールに添付されたショートカットファイルやパスワード付きZIPファイルに注意
    https://internet.watch.impress.co.jp/docs/news/1405843.html

  • 数年ぶりにEmotetが流行中

    数年ぶりに、Emotet(エモテット)の攻撃が活発になっているとのこと。大手企業で、Emotetの被害が広がっている。IPAでも注意喚起を行っている。

    クラシエ、マルウェア「Emotet」に感染 ライオンや積水ハウスに続きhttps://www.itmedia.co.jp/news/articles/2202/10/news113.html

    「Emotet(エモテット)」と呼ばれるウイルスへの感染を狙うメールについてhttps://www.ipa.go.jp/security/announce/20191202.html

    インフルエンザのように数年に1回 Emotetが流行する。迷惑なので、この手の攻撃の流行はいらないのだが。わかりにくく、巧妙化しているので、Emotetに気をつけなくては。

  • 「情報セキュリティ10大脅威 2022」が発表された

    今年(2022年)の情報セキュリティの10大脅威がIPAから発表された。

    https://www.ipa.go.jp/security/vuln/10threats2022.html

    個人の情報セキュリティの脅威は、あまり昨年とかわらない。COVID‐19の影響でネットショッピングやキャッシュレス決裁が増えている状況が継続されているので、順位の変動はあるが、昨年と同じ脅威が継続している。

    個人ではなく、企業などの組織を対象にしたところをみると、昨年と同じく、リモートワーク(テレワーク)環境を狙った脅威が上位にいる。今年は、これらに加えて、「修正プログラムの公開前を狙う攻撃(ゼロデイ攻撃)」が増え、「脆弱性対策情報の公開に伴う悪用増加」の順位が上がっている。昨年後半のLog4Jの脆弱性が与えたインパクトが大きかったのだろう。

    いろいろと考えなければならないのは、「脆弱性対策情報の公開に伴う悪用増加」と「修正プログラムの公開前を狙う攻撃(ゼロデイ攻撃)」が注目されることによって、対策を求められるケースだ。何ができるかというと、常日頃からセキュリティパッチを継続的に当て続けること、緊急でセキュリティパッチが出たときにパッチを当てられる体制(テストも含めて)を整えていることだ。対策としては、当たり前とはいえ、日本の組織は、これが一番難しいかもしれない。メンテナンス時間を定期的に設定して、パッチを当て、最新に保つというのは、コストがかかるから理解されないから。パッチを当てるときのトラブルも考えると、作業者のスキルレベルが高くないといけないわけで、そういう人を抱え続ける必要もある(そうすると部門コストが上がる)。

    それから、ゼロデイ攻撃の対策としては、ログ監視や振る舞い検知が対策としては考えられる。ログの蓄積・分析は大容量の保存スペースが必要になり、分析ツールはログの量でコストが変わってくるので、コストが高い。クラウドサービスならば、というと、結局保存するログの量が増えるとその分コストがかかる。ログがあったとしても、分析できるだけのツールとツールを使うためのスキルが必要であり、難しい。アウトソースを行うという考え方もあるけれど、これまたコストがかかる。そもそもアウトソース先が機能してくれるかも業者によっては怪しい。それに最後は、普段の行動なのかどうかの見極めが必要になってくるので、業務パターン(の通信パターン?)に精通している必要がある。

    対策を迫られると、「修正プログラムの公開前を狙う攻撃(ゼロデイ攻撃)」と「脆弱性対策情報の公開に伴う悪用増加」への対応の解はあるが、実際に行うのは難しい。公開された脆弱性への対応は、対応できる人がいるかどうかと、常日頃からセキュリティに対する対策をしているかが一番のまっとうな対応だろう。ゼロデイは対応にコストをかけるかどうかだろう。

  • 北京冬季オリンピックではスマホやPCを使い捨て推奨なくらいセキュリティが危ないと思われるようだ。

    北京冬季オリンピックの開会式でスマートフォンで撮影しながら、入場してくる選手が多数いた。中国のネットワークを使っていてセキュリティは大丈夫なんだろうか。そういう疑問への回答の記事がWiredにある。

    “使い捨てスマートフォン”が欠かせない北京冬季五輪、そのセキュリティリスクの深刻度
    https://wired.jp/article/winter-olympics-2022-phones-security/

    なるほど。たぶん、国によって違うだろうけれど、アメリカは選手にプライベートのスマホではなく、オリンピックのときだけ使うスマホをすすめている。体調管理アプリをスマホにいれれば、行動が筒抜けだろう。中国のネットワーク網を使えば、そのエリアを保護する目的でファイアウォールが入れられていれば通信も筒抜けなわけだ。今回のオリンピックはバブル方式で、選手も関係者も報道陣も行動制限が厳しいので、監視の手間は少ないから、なおさらなのだろう。

    スマホもPCも、オリンピックのときだけの使い捨てを推奨とは、それほど危険視されているということ。日本の報道だと、COVID-19対策のことばかり報道されている。このようなセキュリティの話は聞かないので、偏りがあるなと思う。日本の報道各社や関係者は、どのような対策をしているのだろうか。していないような気がしなくもないけど。

    中国内から中国のネットワークを介さずに通信しようと思うと、衛星通信くらいだろうか。低軌道通信衛星を使いつつ通信を暗号化すればいけるか。無線通信だから、傍受する方法が編み出されるだけなのだろうけど。諜報系の対策はいたちごっこだから。