2019年06月27日に初出の投稿

Last modified: 2019-07-11

ZAP

出勤して暫くすると、証明書をインストールするかどうかという画面が何度も出てくる。調べると "*.biowareonline.net" というワイルドカードの証明書で、Star Wars のゲームで使っているサーバのようだ。実体は AWS の EC2 インスタンスで構成されたサーバ群だと思われる。もちろん、こんなゲームを業務マシンにインストールした覚えはない。 そして、問題は CA が DigiCert だということだ。ご承知のとおり、ここはシマンテックの子会社だった CA で、昨年の10月以降はとっくに証明書が多くのブラウザから失効あるいは不正と見做されて、インストールも更新もできなくなっている筈である。いまデスクトップに表示されている確認画面も、 DNS Name=*.test.biowareonline.net DNS Name=*.dev.biowareonline.net DNS Name=*.int.biowareonline.net DNS Name=*.lt.biowareonline.net DNS Name=*.demo.biowareonline.net DNS Name=*.cert.biowareonline.net DNS Name=*.biowareonline.net という、サイト名と一致しない FQDN があてがわれていてエラーとなっている。 もちろん、すぐにマシンのネットワークを無効にしてから、イベント・ビューワなどで確認してみた。もちろん、情報セキュリティの実務家であってもウイルスに感染する可能性はあるし、Windows のどういう脆弱性を使われて LAN で繋がっている他のマシンからウイルスに接続されているかもわかったものではない。重要なのは、疑わしい事実を認めたらすぐに対処することだ。 とりあえず DigiCert のルート証明書などが残っていたので、これは MMC の証明書ペインから全て削除した。DigiCert の証明書をいまだに使って通信しているソフトウェアやデバイスが、そもそも僕の使っているマシンで動作する資格などありはしないからである。また、ESET の設定を見直すと、SSL/TLS の通信を保護する設定で「証明書の有効性」について「証明書の信頼を確立できない場合」に、「証明書の有効性を確認する」となっていたので、これは「証明書を使用する通信をブロック」に変更した。これはそもそも確認するような設定になっている方がおかしい。ブロックしたと告知すればいいだけのことだ。なぜなら、証明書の信頼性が確認できないにもかかわらず、エンド・ユーザが証明書の有効性を別の独立した基準で自分で保証できるわけがないからだ(そんなことができるなら CA は何のためにあるのか)。逆にそんなことをしてまで怪しい証明書を使わなくてはいけない通信先や機器を使うこと自体が重大なリスクだと考えるのが正しい。そういうわけで、以上の対処をすると証明書の確認画面は出なくなった。ひとまず現象面の対処は終わったと考えていい。 しかし、これはあくまでも表面的な現象の措置が済んだというだけの話でしかない。まだこれだけではインシデントとして何か具体的な被害が起きているのかどうかも分からないし、そもそも、なんでこんな画面が出るようになったのかという原因を突き止めなければ、コンピュータ・フォレンジックスの基本対応にすらならないだろう。第一に、こんな使い物にならず殆どのサーバで破棄されているような証明書を使った通信を ESET が遮断しなかったのはなぜか(確認画面は ESET のものではない)。そして第二に、なんの通信で Star Wars のゲームのサーバへアクセスしようとしていたのかということだ。第一の点については、ESET が遮断しなかったのは通信そのものに問題はなかったからだろう。IE で起きやすいようだが、Chrome などしか対応していない HTTPS 通信の特殊な仕様を使うと、こういう警告が出るらしく、2年ほど前から頻発しているという。しかし、通信の仕様や手順に問題がなくても、なぜそこへ通信しようとしたのかという点は重大な疑問として残り、いまのところよく分からない。"biowareonline.net" について、殆ど情報がないからだ。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook