1. セキュリティのアレ
  2. 第178回 痛快なりゆきポッドキ..
2023-05-08 1:00:57

第178回 痛快なりゆきポッドキャスト!スペシャル

Tweet【関連記事】 ・FortiMailを侵入経路としたインシデントについての事例紹介 ・公文書管理システ[...]

The post 第178回 痛快なりゆきポッドキャスト!スペシャル first appeared on podcast - #セキュリティのアレ.

00:00
ゴールデンウィークももう終わりですからね。 そうね、長かったね。長いかどうかは人によるか。
そうね。大体、世の中の空気感を見ていると、旧連休みたいな感じなのかな。 そうね、長い人は旧連休だね。
1日、2日、 今宵通りに働いた人は
5連休? 5連休かな。 5連休でも結構お休みになりますよね。
確かにそうですね。なんか僕、ゴールデンウィークって聞くと、5連休っていうイメージあるんですよ。 なんでや。なんでですか。
なんか1日間くらい休みが…いや、違う違う、そろじゃないよ。 3日間ね、祝日が続きますからね。
そうそうそう。土日と合わせて5日みたいな。 飛び石埋める埋めへんみたいなことって、子供の頃って飛び石関係ないじゃないですか。
まあそうだね。それは社会人になったからかもね。 そうそうそう。だから多分僕また心が社会人じゃないのかもしれないね。
何人なんですか。 もうまだ学生気分なの。
学生気分が20年ほど抜けてないっていう。 何年経っとんねんって。
抜けるんですかね、ちゃんとそれは。 長すぎやろ。
抜けるとか抜けへんじゃないんでしょうね。 もうそもそも何もなかった人のことなんですよね。
いやいや、ゴールデンウィーク間でもほんとなかったですね、僕は。 なかったか。いつも毎年そんなこと言ってない? そうそうそう、言ってる言ってる、ついさんは。
なんか同じ日々と同じ生活をしているというか、普通に仕事もしているんですけど、でもあれですね、横やりっていう言い方は良くないかもしれないですけど、
割り込み処理みたいなものが発生しないっていうのではやっぱりちょっと違うところかな。 あーそうね、世間が安売りだからね。 そうそうそう。だからものすごい、これはこれで寂しい気持ちになるんですよ。
だってものすごい勢いでメール返してるのに、もう3日も4日も返事こないわけでしょ? 普通そうだよね。
寂しくなってきてね。 寂しいと、はい。
なんかその急連休始まるよーみたいなタイミングで結構返してたメールがあったんですけど、まぁだいたい1日2日に返してくる人っていうのと、そうじゃない人っていうのになってて。
なんかね、結構返してんけど返事返ってけーへんから寂しいなーっていう。 深夜に起きてたらこの世界に自分しかおれへんのちゃうかなみたいな、勘違いするような気持ちあるじゃないですか。
あんまないけど、わからなくはない。 言わんとしたいことは。 だから別に休みにもメール見ろなんてことを言ってるわけではないんですけど、
まぁなんかあんまりそれぐらいかな、なんか普段と違うことといえば。 なるほど。
だからゴールデンウィークはGWというよりはゴーワークだったなっていうことですね。 よくわかんない。
無理やりこじつけて言うのもあんまり良くなかったですよね。 あんまりピンとこなかった。 ゴーワークって言葉もあんまり言わへんしね。
03:05
それはそうとですね、このBODCASTも一応ゴールデンウィークにカコつけて1回休ませていただきまして。 そうね、久しぶりにお休みを。
であれですね、スペースやりましてまた。 また。君ら休んでないやん。
あんまり休んだ感ないんですよね、なんか。 でもね、ゴールデンウィークっていうのもあって、やっぱ人によったら落ち着いて聞けるみたいな意見いただきましたよ。
休みの日の方がそういう感じあんのかな。 そうそうそう。事前に言ってあって、なおかつ多くの方が休みの4日にしたんですよね。
そうですね。 だからこう、1、2、仕事をしてた人の次の日の3日ではなくて、1回あてて4日ぐらいがええかなみたいな思って4日にしたんですけど。
でそれでしたら、同時視聴者数みたいなやつが多分今までで一番多かったんですよね。 あれ何人ぐらい?
えっとね、一番多かった時で191やったかな。 190か191かそんなでしょ。僕がずっと見てたわけじゃないけど。
結構な数の方が聞いてらっしゃるんですか。 あんなっていうとあれですけど、かなり雑談的なゆるふわトークでしたけど。
そうですよね。なんかあんまりこうセキュリティの話っていうか、なんか注意喚起の話が多かったですね。
ね、なんかずっと注意喚起の話してましたね。 みんな大好き設定確認、定期的な設定確認みたいな話とか。
あールーターのやつか。 そうですね。ルーターの話とか、あとなんか最近のこう僕とカンゴさんの関心事みたいなやつとかですね。
いう話をして、まあ僕があんまり関心のがないみたいな話をしてて。 ゲームでゲームっていうね。
ゲームね、ゲームもやってる。あ、でもなんか紹介したのは、そのなんかドキュメントのレビューフローとかすごく最近僕なんか考えてるみたいな話をしてる。
なんからしくないね。 らしくないですか。僕でも意外と意外とそういうとこしっかりしてるのよ。
まあね、まあね。 そうそうそうそう。そういうのをなんか作ってた、作っててんけど、なんか公開したろうかなとかね、そういう話をしたりもして。
いろいろそういう多岐にわたるようなお話をしてましたね。 いいですね。唯一したゴールドウィークで。そうそうそうそう。
そんな感じでね、やってたんですけど、まあちょっと今日もお便りから入っていこうかなと思います。 お願いします。休みというのもあって、そんなに今日はお便り多くないんですけれども、
2つほどちょっと紹介したいんですが、1つはつい先日ヤフオクで2.5インチのハードディスクを買ったら
パーティションが切られていて、もしかしてと、 フォトレックで覗いたらリカバリー領域、Cドライブ、Dドライブらしいパーティションの中に大量のファイルが復元できそうだったので、ランダムで上書きしてから利用しましたっていう。
なるほど。タイムリーナ。 これすごいですよね。これ紳士的な対応ですよね。
06:04
まあ紳士的っていうか、その人は立派だと思うけど、自分でもさ、もし見つかっちゃったら、見えちゃったらさ、
物によったらどっかに届けてあげなきゃいけないとか、 面倒くさいってのもあるよね。
紳士的にやるかって言われたら、ちょっと自分的には微妙だけど、面倒くさいから消しちゃおうと思うかもしれないな。
確かに確かに。見たがゆえにっていう面倒くささも中にはね。 余計なものは見たくないっていうか。
確かに確かに。確かにね。これだって破棄というか、捨てた、 平たく言えば捨てたものなわけじゃないですか。
自分の手元からね、無くしたものなわけやから、 それは無くなったものとして処理するのが一番正しいのかもしれないですね。
なんかね、スマートではあるよね。 無いしは、見ちゃったらそれを叱るべきところにちゃんと責任を持って最後までやらないと、
なんかちょっとね、気持ち悪いというか。 確かにね。見てしまった内容によってはね、どこどこ本人なのか、違うとこなのかは別にして、
無かったことにできるようなレベルじゃないものが入ってるかもしれないですね。 そうそう、場合によったらね。
確かに確かに、見なきゃよかったものってあるかもしれんもんなぁ。 倫理的な話とかそういうところで考えるとね。
そういうのもありましたということでございます。 あとは、これは脅威アクターの命名の話なんですけど、
ご意見というか、自分はこう考えてますみたいなものを しっかり書いてくださっている方がいらっしゃったんですけれども、
私個人としてはスレッドアクターそのものを意識しすぎず、それぞれのインシデントの イニシャルアクセス及び侵害の流れ、各組織が採用した対策などに注目をしてますというような意見でして、
結局スレッドアクター全般の侵害リスクに対処する必要があるので、 アクターの特徴というよりは実際に使われたイニシャルアクセスとかラテラルムーブメントの手法が自分にとっては大事かなと。
ただ、脅威インテリジェンスを専門にする場合は、脅威アクターの個々の特徴は大事なので立場次第だと思いますという、
普段思っていることをきれいにまとめてくださったコメントをくださってたので、紹介してみましたということですね。
そうだよね。大半の人にとっては、今のお便りのスタンスが正しいのかなというか、
アクターが誰かとかどういう名前がついているかというのを気にするよりも、何すべきかというふうに注力したほうが生産的よね。
そうですね。この2つの立場みたいなものを挙げてくださってますけど、自分たちにとってはどうなのか。
メディアがどう報道しているとか他人がどう言っているとかっていうよりも、自分たちが対策を行う上で何が大事なんだっけっていう観点は忘れないようにしたいなというふうなのをこれを右手でまた改めて思いました。
ちょっとそういう意味で考えてやっているというのは素晴らしいですね。
09:02
そうですよね。というお便りを2ついただいておりましたということでございます。
ありがとうございます。
今日は休みも挟んだということでリハビリ会という感じで行くんですかね。
そんなの今までやったことあったっけ?
やったことない。やったことなくてすぐに通常運転し始めるという。
鳴らし運転というものを知らない3人ということでやってますけども。
今日はそうですね。誰から行きますかね。僕から行きますかね。
はい、お願いします。
今回はですね、紹介するのは40メールを侵入経路としたインシデントについての実例紹介というのをですね、
NTTセキュリティがブログという形なのかなというので出してくれていたので、
非常に内容もそうですし、これを聞いて結構僕も考えたことがあったので、
ちょっと興味深いなということで紹介したいんですけれども。
まず内容から紹介していきますが、これは2022年の3月から4月にかけて対応した、
このNTTセキュリティが対応したインシデントの中に40メールがイニシャルアクセスであると考えられるようなものがあったので、
それを紹介しますというふうなものでした。
このインシデント、そもそも何でこれが発覚したのかという発覚の部分から説明してくださっているんですけれども、
一番初めにこれが異常が起きたというのが分かったのは、内部のネットワークの中で、
ドメインコントローラー、ADですね、のプロックダンプというツールを使って、
LSSSのプロセス、認証の情報のダンプですよね。
ダンプをしているぞというふうなものをEDRが検知したというアラートからこの事件の発覚というふうになっていました。
だから一番内部まで、最重要のところまで入り込まれたところで検知したわけね。
もうあかんというタイミングってことですよね。
最後の最後だね。
普通に考えれば多くの場合、ドメインコントローラーというのはインターネットから直接アクセスできるなんてことはほぼないので、
横展開でここまで来たんだろうというふうに想定されたと。
これがきっかけで調査をどんどん開始していく中で、
40MailはDMZに存在していたんですけども、そこのDMZにある40MailのIPアドレスから
ドメインコントローラーに対してリモートデスクトップの接続が確認できたと。
でも40Mail自体にはリモートデスクトップのクライアント機能というのはないので、
悪用可能とされている、いわゆるKEVとかに乗っているような脆弱性が放置されている状態でもなかったと。
こうもやもやしますよね、この辺もね。
40Mailのログとかを調査していくわけなんですけれども、
設定ファイルとかログファイルを入手して、そこからファイルとかディレクトリに対する40Mailの中のタイムラインの分析、
12:00
ログイン、ログオフゾーナーされているのとか、あとファイル消されているものはないのとか、そういうふうなものを調査していったそうですと。
そしたらKログっていうところがあって、そこは重要なログイン、ログオフとかの内容が書かれてあるログのディレクトリがあるんですけども、
そこに一部の日付のログが欠けてしまっていると。
イベントログを復元していたところ、ある期間だけすっぽり抜けてて、前と後ろがあるのにそこだけないみたいなですね。
あとはログの書き出しの日付に乱れがあると。
例えば10日ごとに区切られる規則性みたいなものがあるのに、それが成立していなくてブチッと開いているみたいなものがあって、
その規則性が成立していないというおかしなポイントが見つかったというようなところですね。
インシデントに関連するようなログインというようなものは特になかったんですけども、
アップロードしたんじゃないかというふうに思われるようなログが2件ほど見つかったそうなんですよ。
どんな方法でアップロードしたのかというのはここからは分からなかったんですけれども、
ログのフィールドを見るとですね、UIフィールドというのがあって、
そのUIフィールドというのはどのインターフェースから、例えばWebなのかGUIなのか、
REST APIを使っているのかという何経由で上げられたのかというのを表すフィールドがあるらしいんですけど、
そこでWebとかGUIとか書かれるはずがヌルってなってたんですって。
だから通常起こり得ないっていうやつですよね。というふうなものが不審なものが見つかったということと、
あとはWebのインターフェースがインターネットに公開されている状態だったということが分かったそうです。
そのインターフェースに対してなんですけども、先ほど言ったみたいに悪用が認められているというような脆弱性自体は解消されているような状態なんですけれども、
ただ気になったのが認証なしでこのWebのGUIにアクセスすることができれば、
悪用可能とされている利用可能な脆弱性、脆弱性の利用条件ですね。
というふうにされているCVEでいうところの2021-24-007という認証なしでSQLインジェクションが可能な脆弱性というふうなものがあるので、
もしかしたらこれなんじゃないかなというふうに疑うというふうなことがログから判明したというふうなことが書かれてありました。
そこからアップロードログ、ここではこれは悪用されたかどうかわからないんですけども、
実際のこのアップロードログの中から調査を進めていったらですね、
Webシェルが2つアップロードされていたということも分かった。
1つはBusyBoxという知っている方は知っているようなものだと思いますけども、これを使うようなWebシェルで、
UNIX系のコマンド、攻撃者が扱いたいコマンドを実行環境を整えるようなものがあったりとか、
あとPythonで書かれたWebシェルがあって、アップロード、ダウンロードとかOSのコマンドを実行できるような、
Pythonで書かれているけども実行形式に変えられているものが保存されているというのが分かったそうです。
実際の侵害の流れというのはここから推測するしかないんですけども、
15:03
Webシェルとかを使って新たな攻撃ツールとかを設置したり実行したりすることによって、
侵害をした40メールを経由して攻撃者が外からリモートデスクトップを使って、
DCに攻撃をするという流れに至ったんじゃないか、みたいなことが書かれてあったんですけども、
ただDCの侵入方法というのはどうやってその認証情報を取ってやっていったのかというところまでは分からなかったですし、
40メールを経由するためのいわゆるトンネルリングツールみたいな風に言われるツールがありますけども、
そういったものも消されていたのかどうなのか復元できなかったのかは分かりませんけども、
実物自体は発見することができなかったということで、最終的にはどの脆弱性を使って40メールを侵害したのかというところは分からないんですけれども、
先ほど言った認証なしでSQLインジェクションが使える、SQLインジェクションを実行できるという
2021-24007が悪用されたのかもしれないなと推測の域を出ない結論で終わってはいるんですけども、
そういったことが書かれてありました。これを読んで思ったのは2つ思ったことがあって、
1つは外部からのアクセス制御をちゃんとしようよということと、内部から内部のアクセス制御というのもありますよね。
DMZに置いてある40メールからですね、そのままDCにリモートデスクトップを貼れるような状態というようなことも
よくない状態なので、そういったことの見直しというのは基本的なこととして必要かなというふうに思ったんですが、
我々いつもKEVの話をよくするじゃないですか。僕たちは第一歩としてああいったものを参考にして、
足りないもの、例えばCVEが発行されないものとか、あと日本独自なものとかもあるので、
合わないものは自分たちである程度埋めていくという、あれが全てではないという考え方で接していきつつも、
参考にするには結構踏み台という言い方がよくないかもしれないですけど、そういうふうに使えるんじゃないかという話をしてるんですが、
ただこれは推測の域は出ないとは言うものの、何を使ったかわからない状態で、この脆弱性かもというふうなことを考えると、
エクスプロイトコードとかPOCですね、そういったものが公開されていなくても、インターネットに公開されているサービスに関しては、
ああいったところに載っていなくても、ちょっと1段階上げないといけないような判断をする必要のある脆弱性というふうなものも考慮しないと、
ちょっと怖いというのがあるのかなというのがあったので、今回これを見ていて考えさせられたなというふうに思うのは、
KEVを押しすぎというふうに、まず人にどう見られるかわかりませんけど、それだけやってればいいんだという伝え方をしてしまわないようにしないとなというようなものを思いましたということでございます。
いろいろ、まず公益に関してはEDRで最後検知するまで、奥底にまで入り込まれるまでは気づかなかったということだから、
おそらく事後にNTTセキュリティさんがECAの対応して調べても、
18:05
手法の特定とかに至るようなログだったりなんだり、そういうものが多分足りてなかったんだろうね、もともとね。
そうですね。
そういうのがあれば、もしかしたらその公益の経路の途中で検知できたかもしれないけど、
そういう検知したり、あるいは後から公益情報を詳しく分析するのに十分なログとかがなかったり、
あるいは40メールのログも消されてたっていうのがあったけど、そういうのをちゃんとどっかで中継して取っておくとか、
なんかそういうような部分が少し足りてなかったのかなという感じがあるので、
そこはちょっとその事前の準備として不足してた部分があるかなと思うんだけど、
後半に言ってたさ、KEVとかに載ってない、POCも公開されていないし、
悪用が公には確認されていないけど、そこそこ危ない脆弱性。
特にこれ、CVSSにあまり依存するのは良くないけど、
でもこれ9.8でクリティカルだから非常に危険なやつじゃない?
というのをどう判断するかっていうのは、これはちょっと難しいよな。
ここの組織がどういう優先順位でこの脆弱性を管理したのかわかんないんで、
たまたま攻撃されるタイミングに間に合わなかったのか、
ないしは対応不要と判断しちゃったのかどうかちょっとよくわかんないけど、
そのあたりの取り味ってちょっと難しいよね。
結果論で後付けでやっておけばよかったねっていうのは誰でも言えるんだけど、
事前にそれができてたかと言われると、どうだろう。
わかんないよね。わかんないし、このブログの記事を見て、
うちも大丈夫かなって心配になったところ他にもあると思うんだけど、
ちょっとこの攻撃された組織がどういう種類のところかわからないんだけど、
ここだけが狙われたのか、ないしはこの脆弱性があるところを狙ったのかによってだいぶ変わってくるなというかさ、
同じ機器を使ってたところが他にも同じようなタイミングでやられてたらおかしくはないよね。
そうですね。手法自体は同じような使い回せるわけですからね。機器が同じなら。
幸いというか、公開は今の時点でもたぶんされてないと思うんで、
もし仮にこの脆弱性が悪用されたという推測が正しいんだとすると、
今回の攻撃者、ないしはその関連する攻撃者に限定される可能性は高いので、
そうですね。議事じゃないから。
そんなにすごく広く攻撃されるとは思えないんだけど、危ないといえば危ないよね。
21:05
そうですね。この脆弱性を気をつけようというよりも、こういうものがあるっていうことを知っておいた上で、
どこまでやるか問題だと思うんですよ、結局は。
そうだよね。
例えばアプローチとしては、ネギさんが言ったみたいに、
例えばドメインコントローラーに至るまで、所定の後のアクションですよね。
そういったものを経路上とかホスト上とかでどうやって検知していくのかっていう、
ダメージコントロールというか、そういったところにするのか、
例えば脆弱性管理の方法を攻撃方法がわかっている、いわゆるKEVに乗っているようなものとかっていうようなものはすぐに対処して、
クリティカルとか緊急とかに当てはまるようなものは、何週間、1週間とか何週間以内に対処してっていうふうに決めた上で、
それでもやられたら他のもので検知するかっていう風な受け皿を用意しとくっていうのは現実的なのかなっていう気はするんですけどね。
そうだね。あとこの事例、別に特殊な事例でもなんでもなくてさ、
一旦中に入られちゃうと、わりとズブズブで中はRDPし放題とかっていうのはよくある。
よくある話ですよね、そこはね。
あと今回の事例だけでなくて、ランサムウェア標的型の、いわゆる侵入型って言えばいいのか、
侵入型ランサムウェアとかでも内部展開でRDP使うだとかさ。
めちゃめちゃありますよね。
多いよね、多く使われるけども、結局そういうのって中ではやっぱり制限されてないっていうところが、
よくはないけど一般的な状態だと思うので。
一般的な運用かもしれないですね、その内部から内部ってやつはね。
そういうのを見ると国内だけでなく、広く境界防御の考え方が根強く残ってて、
外部からの入り口のところはなんとか目が行くんだけど、
入られた後の中の横展開についてはどうしても後手に回ってるというか、
あんまり考慮されてないっていうところがまだまだ多いのかなっていう感じはあるよね。
あとはあれですね、あんまりこう普段から考えてなかった、
できることは分かっているけどあんまり考えてなかったのは、
こういったネットワーク機器とはいえ中身はLinux、Unix、KOSで動いてるやつ多いじゃないですか。
そこでやられてることってあんまり検知に及ばないなっていうね。
例えば40メールの中にアンチウイルスとかそういうものを入れるってあんまり効かないじゃないですか。
ここを結構この中で見つけるっていうこともできればいいのになと思いましたけどね。
変更管理とかでできるんじゃないかなと思うんですけど。
もともとのセキュリティのアプライアンスだったり、
もともとそういう機器が持っている機能として、
そういうさまざまな攻撃の検知とかね、
そういうのあるものはたくさんあると思うんだけど、
一旦そういうのがバイパスされちゃうと、
だいたいデータクセがある場合ってそういう機能バイパスされちゃうことがあるから、
そうなっちゃうと、そのOSになっちゃうと、
あんまり手がないっていうことはあるかもしれないよね。
24:04
足元はやっぱり弱いみたいなというか、
自分自身に起きていることを検知するっていうのはちょっと弱いなっていう印象が強まりました。
そういう場合にはそこで見つからなかったら、
次どこでっていう手を考えておかないといけないんだろうね。
そうなんですよね。
今やっているこの管理の仕方が本当にこれでいいのかっていうのは、
やっぱりこれを見直すきっかけになる事例だなって思ったので、
紹介させていただいたという感じでございます。
こういう実際に対応した実例というものを紹介してもらうと、
説得力があるというか、いいよね、気づきになるというかね、
自分たちも調べてちゃんと対応しようというきっかけになるよね、こういうのはね。
なんか結構読んでて、何て言うんですかね、面白いというかすごく、
それでどうなった?どうなった?みたいな感じで読める記事でした、本当に。
読みやすいし、自分の知らんことが出てくるんじゃないかみたいな感じで、
学びが多かったんで、直接読んでみたらいいと思います、本当皆さんも。
はい。
はい、ということでございます。ありがとうございます。
ありがとうございます。
はい、じゃあ次はですね、半野さんいきましょうか。
はい、今回私はですね、新潟県で発生した公文書管理システムのファイル消失の事故について取り上げたいなと思っておりまして、
これもゴールデンウィーク前に公表されていたもので、4月21日付けで新潟県であったり、
あるいは開発や保証になっていた事業者である富士電機ITソリューションなどから、
転末というか、経緯などが公表されていたものでありますけども、
内容としては、これ事故というか、このインシデント自体は非常に目を引くというか、
いろんな人に興味・関心を引く事例だったので、すでにご存じの方も多いのではないかと思うんですけども、
改めて説明させていただくと、4月9日に、今ご紹介した公文書管理システム、
これ2022年の4月から運用が始められていたそうなんですけども、
約1年後の4月9日に、システム上で公文書に添付する形でファイルをくっつける事がシステムにできているということであったんですけども、
その添付されたファイル、約10万件が消失してしまったと。
期間で言いますと、3月の24日から、2023年の3月24日からその月末前ですね、31日までに登録されたファイル10万件が消失してしまったと。
非常に大量のファイルが公文書というものから消えてしまったということではあったんですけども、
これなんで消えてしまったのかというところが、なかなか注意をしておかないと、自分たちのところでも起こりかねないなというものではありまして、
27:09
直接的な原因としては、事業者が3月24日に行ったシステム回収が原因であったんですけども、
内容的にはですね、公文書の管理システム上に添付されたファイル、ファイルの名前ですね、拡張子を付けられますけども、
その拡張子、大文字で元々は記録されていたものだったそうなんですが、それを小文字に変更すると。
そういった機能をその24日に機能追加をしたと。
ただその機能追加した影響によってですね、元々そのシステム上でおそらくファイルのクリーニングみたいなのを目的としたものだったと思うんですけども、
不要なファイルを削除する処理っていうのが元々動いておりまして、今回ファイルの名前を結果的に拡張子を小文字に変更するということで、
ファイルの名前を変更する処理が追加されたんですが、不要判定をする削除の処理において何をもって不要としていたかというと、
ホワイトリスト的にですね、ファイルリストをそのシステム上で持っていてですね、そのリストと凸合させることで登録されたファイルがどうかっていうのを確認して、
登録されていないものであれば不要だという判断で削除を行うというものであったんですが、小文字に変更したことによって、
いずれにおいてもリストと凸合せずにですね、全て結果的に不要判定されて、先ほど申し上げた10万件相当のファイルが消えてしまったと、
そういった事故が発生してしまったんですが、話はこれだけで進めばよかったんですけども、ちょっとその後の対応、前後も含めてなんですが、
なかなかこれはよくあると言うとあれですけども、実際の人材的な部分もありまして、まずバックアップ取ってなかったのかという話も当然あると思うんですが、
消えたと言われたらバックアップに目が行きますよね。
ランサメアでもバックアップに注目されている対策ではありますけども、フルバックアップ取ってたんですね、システムで取ってたんですけど、
残念ながらそのフルバックアップを取っていた期間が3日間というちょっと短めな期間であったと。
ただファイルの消失が4月9日の夜に発生していたんですが、新潟県側はその翌日の4月10日にファイルが開けないということでその事業者に問い合わせを行っていてですね、
この時点でおかしいぞと、消されてるぞということにすぐに気づかれて対応すればそのフルバックアップから復旧がおそらくできたんだと思うんですけども、
残念ながらその事業者側でもその消失が起こったという事実に気づくまでに時間をちょっと要してですね、気づかれたのがちょうどそのバックアップの期間が過ぎた4月12日の時点であったということで、
30:13
現状そのフルバックアップが使ってそのまま復旧できるかっていうのが何とも言えないというところもあり、あとですね、この手の話、なんか似たような事例が過去にもありましたけども、ファイル消えたと思ったら実は別のところに置いてたみたいな。
そういった事例もまあ、それが結果的に復旧できたにしては、それがいいかどうかはさておいてですね、そういったものがあるかなっていうのも確認するということも含めて、現状その復旧可否を事業者側で確認を進めているというものであったんですが、
ちょっとその3日間っていうのが結構短いねっていうのは、SNSでも結構反応というか反響があったところではありまして、ITメディアもこの3日間って何でっていうのをツッコミを県側に取材されてるんですけども、3日っていうのは事業者と新潟県側で合意をしたことについては間違いがないと。
しっかり握られてる仕様通りってことですね。
そうですね、仕様通りであったと。ただ、何で3日にしたのかっていうのはわからんというところだったので、まあもともと3日間っていうのが規定値みたいなもので、特段運用的な部分とかも含めて議論とかはなかったのか、ちょっとその辺は天末わからないんですけども。
もともとそういう習慣というか3日っていうのが当たり前だったみたいなかもしれないなと。あと担当者が変わってるとかもあるかもしれないですね。
そうですね。で、あとそのポイントとなるのは、何でその事業者側でそのバックアップを取られていたにもかかわらず、結果的にファイル消失に気づくのが遅れて対応が遅れてしまったのかというところなんですが、これもまだ事業者側でも調査中だと思うんですけども、どうも事業者内での手続きっていうのも正規の手続きが踏まれていなかったということで発表されており、
正規の手続きというとどんなものかというと、しっかり運用テストをして、社内でレビューをして、バージョン管理などもしっかりするということが記載されているんですが、そういったものにはのっとらずにリリースまで、先ほどの小文字に変更するといった機能追加というのがリリースされてしまっており、
本当かなと思うんですけども、そのリリースされたことに関しても、実際にリリースを行った開発担当の方と、実際に新潟県のシステムを運用されている事業者の運用担当の方の間で、その情報が共有をされていなかったと、機能追加で結果的にファイルが消失してしまったんですけども、運用担当、実際にその新潟県から問い合わせを受けた人ですね。
33:02
その運用担当の方から見れば、そのファイルが消えるなんてことは起こり得ないというふうに思ってしまったということで、最終的にそういった対応が遅れてしまったというところでありました。
あと最後にちょっと余談的な話として、なんで小文字変更の仕様というか機能追加がされたのかっていうのをやっぱり気になるポイントではありますけども、こちらについても細かいところはまだ確認中だと思うんですが、どうも新潟県側が町内の業務でマクロイレクセルを使っておられてですね、
そのマクロを動作させるにはどうも大文字の拡張子のファイルだと正常に動作がしなかったということで、小文字にできないかみたいなそういった趣旨の問い合わせを事業者側にされたというところがあったらしく、
でちょっとそこからその実際の機能追加に至る判断までのその経緯っていうのはちょっと細かいところ書かれていないんですけども、そういった経緯があって最終的に小文字変更の機能追加が行われたと。
いろいろなポイントというか気づきというかですね、防げたんではないかなというところがいくつも重なって、なのでちょっと重なって重なっては最終的にこういった大きなインシデントというかですね、大量のファイルの消失につながってしまったといったところでありまして、
で先ほどの最終的に復旧できるかっていうところについては、おそらくこの連休中もきっと調査等やられてるんだと思うんですが、連休明けのですね7日頃にはその可否がわかるというところでありますので、ちょっとまた続報的なものがもしかしたらこの後出てくるかもしれないんですが、いろんなちょっと気づきのあるインシデントだったなというところでございます。
何か拡張したら発生してるわけじゃないですか、これって。そもそも大文字でなぜ登録したのか、なんで小文字にしたかったのかでも、なぜそもそも大文字やったのか気になったんですけど、システムの方の回収するのとマクロの回収するのと、マクロの回収する方が安全で楽な気がしたんですけど、こっちを大文字対応にするとならなかったのかなっていうのはこれ見て思いましたけど。
そうですね。なんで機能追加に至ったのかっていうところが、ちょっと経緯が公表はちょっとされてないので。
県側の言葉しか公表されてないわけっていうのもありますしね。
そうですね。問い合わせがイコールでリクエストになってしまったのかとか、ちょっとその辺は何ともわからないところではあるんですが、この今お話しした事故の天末については、実は私もうすでにブログにまとめてまして、
36:11
なんでリリースをもしかしたら結果的に急ぐような形になってしまったのかについては、もしかしたらその3月という年度末っていうのが影響あるんじゃないかみたいな、そういったことを推察されている方もコメントでおられてですね。
ちょっとこの辺、もう少しですね、こういう結果につながった経緯などが事後的に明らかになるといいなと思いつつ、ただちょっと今回の事案自体は、新潟県側は県民の方であるとか、県内の事業者に対して直接的に大きな影響が及ぶ事案ではないという、そういった見解は示しておられて、
県内の業務に当然影響は出ていると思うんですけども、それそのものが直接県民の方とかに影響が出ているっていう話ではないという話ではあるので、他の事案であるような第三者委員会を立ててであるとか、もう少し詳しい調査をして調査報告を出しますとかっていうところまではちょっといかないのかなっていう感じはちょっと今の私の個人的な見立てではあるんですけども。
ちょいちょい忘れた頃にこういうの来ますよね、データ消えました事件っていうか消しちゃった事件みたいなやつで。
だいたいどれも原因がしょうもないよね。
まあ一番初めはね、なんかそうそうわかるわかる、なんかこういうの見るたびに僕いつも思うんですよね、世界が終わる時ってこういう感じで終わるのかなみたいな。
まあちょっとしょうもないは言い過ぎだけどさ、なんていうかこの手の事故ってほんとたびたび起きるけど、まあなんていうかそのちょっと言葉悪いけどほんとしょうもないというか単純な何かミスが二重三重になぜか重なって起きるっていうか。
そうですよね。
一個一個は別に複雑でもないことだと、そんな難しいことをみんなやっているわけではないのに、なぜかそういうのが重なっちゃって重大事故になるみたいな。
なんかそういうパターンってやっぱ多いよね。
確かにですね。
わかんないけどそれってその一個一個の作業を多分軽視しちゃってるというか、大したことない作業だからっていうその拡張子を変えるだとかさ、なんかそういうのって一見それ自体は大したことないじゃない。
だけどそういう一個一個のやつが何かこう重なっちゃうと全体としては重大なことに繋がるなんていうのはまあなんか典型的なパターンだなあっていうのを聞いてて、なんかね思ったね。
そうした通りですね。
拡張子を変えたら消しに来るハンターみたいなやつがおって。
まさかねっていうのは多分あると思うんですけど。
でもでもバックアップ取ってるからみたいな感じになったらそれも時間が過ぎ去って、で3日しかなくて手遅れみたいなものになって結局何にも引っかかるざるに一番下まで落ちたみたいな。
本当に。
だから正規の手順には則ってはいないにせよ、一個一個の作業は一応その目的とすることをちゃんと達成する代表になってるわけじゃん。
39:04
そうですね。
そうなんですよね。
全部がさ。
全く。
まあまあちょっと連絡吹雪取る日とかあるかもしれないけど、一応その仕様通りに則ってとか要望通りに則ってやってその通りに動いてるはずなのになぜかね大問題になっちゃうみたいなさ。
なんかね。
なんか一個一個ね、ねぎさんが今おっしゃったみたいに本当に一個一個やったことは別に何も悪いわけじゃないんですよね、アクション自体はね。
まあみんな悪いことやろうと思ってやってないからね。
そうそうそうそう。
全部が重なって何か合わせ技一本になったみたいな。
まあでもそういうもんだよね。重大事故ってだいたいそういうもんじゃない。
だからこそこういうね、こういうセキュリティ事故に限らないけど、いわゆるそういう重大事故とかを防ぐためには二重三重ってさ、なんかチェック機構があったりとか。
まあいろいろそういう過去の歴史があるわけだけど、まあこういうの起きるときって言ったらだいたいこういうパターンだよなっていう。
そうですよね。本当にそうだと思いますね。
なんか変に納得しちゃったよね。
なんかこう一個一個見ていけば、ここをこうしとけばみたいなっていうのを後からでも何とでも言える部分があるとは思うし、
なんかこういうのをやゆするというかね、これおかしいんじゃないのみたいなこと言うのってめちゃくちゃ簡単じゃないですか。
そうですね。
でもなんかこういう本当ちょっとしたことで崩壊するみたいなものは我が身にも起きるんだってことの方が大事なことですよね。
そうそうそう。
そうだね。
どうしとけばよかったよりもそちらが大事かななんて思って聞いてました。
ありがとうございます。
はい。
はい、じゃあ最後ですね、ねぎすさんにお願いしようかと思うんですけど。
お願いします。
今日は何でしょうか。
今週の木曜日、今日今土曜日収録してるけども。
はいはい。
木曜日5月4日何の日か知ってる?
僕らがツイッタースペースやった日。
知らんからそんなの。
そうだったんだけど。
毎年これ言ってるんだけど、5月の第1木曜日は実はワールドパスワードデイっていう日なんで。
出た。
出ましたね、いいですね。
速攻ブレないの大好きなんですよ本当に。
毎年俺しか言ってないんじゃないかっていう。
このポッドキャストでも多分リモート収録になってから毎回取り上げてくれてますね。
多分ね、雑談とかで毎年言ってる気がするんだけど。
そうですね。
今年もそういう感じで国内では誰も取り上げてなかったんだけど、海外ではちょいちょいパスワード管理ソフトとかのベンダーが記事書いたりね。
セキュリティ会社が記事書いたりしてるんだけど。
今までそういう話をしてきたんだが、そろそろパスワードのことを言うのはもうぼちぼちやめたいなということで。
今週はですね、前日の5月3日にGoogleがGoogleアカウントでパスキー使えるようになりましたよっていうアナウンスを出していたので。
ちょっとその紹介をしようかなと。
なんでパスワードの話はしないんですけど。
42:01
パスワードデーなのにね。
もうそろそろいいよねっていう。
確かにパスワードデーがなくなることが目的やもんねこれってね。
Googleアカウントのパスキーっていう話なんだけど、パスキー自体はこのポートキャンセラーも何回か取り上げてるんで。
もうちょっと今更繰り返しになるんで詳しく話はしないですけど。
使えるようになったのはもうだいぶ前から使えるんだけど、Googleアカウントではまだ使えてなかったんだよね。
そうなんですよ。
やっぱりこういうのって大手のサービスが使い始めるとなかなか普及しないっていうのがあるので。
今回Googleがアカウントで使えるようになったっていうのは結構大きなマイルストーンかなと思うんだけど。
実際使えるようになったので使ってみたんだけど、非常に簡単で。
Googleのアカウント使ってる人だったら、だいたい使ってる人結構多いと思うんだけど。
スマホから、iPhoneとかAndroidとかスマホからGoogleアカウントにログインして、
セキュリティのメニューってのがあって、二段階認証とかそういうのを設定するメニューがあるじゃないですか。
あそこに新しくパスキーっていうボタンが表示されてるんで、それを選択して登録するだけなんで、
1分くらいあれば本当にできちゃうかなっていう感じで、めちゃくちゃ簡単なのね。
僕は個人的にいつもiPhone使ってるんで、Androidはちょっと使ってないから試してないんだけど、
説明読んだらAndroidであらかじめGoogleのアカウントで使ってる人は自動的にパスキーが生成されてるんだって、勝手に。
メニューに行くと、もう作ってありますよって出てきて、使いますかっていうのが。
使うかどうかの選択ってことですよね。
そう、使えますって言うだけで使えると。
iPhoneの場合にはそういうのはないんで、自分でパスキーを作成するってやると、
iOSの機能に遷移してパスキーが作られて、それがiPhoneの場合にはiCloudキーチェーンに登録されて、複数のデバイスで自動的に同期がされると。
こういう感じで、非常に使いやすいというか簡単に登録できるので便利ですよということなんだけど、
ちょっと使ってみてね、2つ注意点があるなと思って。
一つは、これパスキーを登録すると、まず自動的にパスワードレスの設定が有効になるような仕掛けになってるんで、
パスキーを登録したGoogleのアカウントでは、パスキーが使える環境だともうパスワードは使わなくなる。
自動的にね。一応この設定は後で自分で無効率することもできるんだけど、
でも多くの人で、いわゆる物理的なセキュリティキー、指キーとかああいうタイプの鍵を元々使ってた人以外は、
パスキーの方が基本的には安全なので、これはそのままの設定にして使うのがいいんじゃないかなというふうに思いますし、
仮にパスキーが使えない環境、ブラウザとかでサポートしてないとかも今でもあるんで、
45:02
そういうところで使おうと思ったら自動的にパスキー以外の元々の従来の認証方法が使えるので、
特に特段問題がなければ、この設定はそのままデフォルトの有効なままにするのがいいんじゃないかなと。
ただ一応勝手に有効になるので、一応注意点としては気をつけてねというのが一つと、
あともう一つ、これもあんまり使ってる人はいないと思うんだけど、
もともとGoogleって何年も前から、ファイドの今回のパスキーに対応する何年も前から、
独自のビルトインセキュリティキーっていう機能をもともと持ってて、
AndroidフォンとかiPhoneとかを物理的なセキュリティキーの代わりに使えますよっていうGoogle独自の機能がもともとあったのね。
AndroidだとOSにもともとビルトインでそういう機能があって、
iPhoneではこれもポートキャストで紹介した記憶があるんだけど、
Smart Lockっていうアプリをインストールすると、それが鍵代わりになって使えるっていう仕組みが昔からあったんだよね。
だけどこれは機能的には今回のパスキーと重複するんで、
どうなるかっていうと、パスキーを登録すると自動的にもともとビルトインセキュリティキーを使ってた人は、
これが無効になって置き換わる形になるのね。
今まで使えたやつが使えないって思っちゃわないように注意が必要というか、
よいよい手段に置き換わるっていう感じで、パスキーを使うと自動的にそっちが無効になるっていう仕掛けになっているので、
もともとビルトインセキュリティキーを使ってた人には、今回のタイミングでメールで通知が来てるはず。
あー、使えなくなりますよみたいな案内が来てるね。
そうそう、パスキー使うと置き換わりますよっていう案内が僕のところでも届いたんで、
一応そこは注意点としてはおって思う可能性があるので。
ただそれ以外はあまり気にせず、もともと今までパスワードと、
あと例えばよくあるGoogleオセンティケーターみたいな認証アプリを使って2段階認証してましたみたいな人は、
基本的にパスキーを使った方がフィッシング体制とかははるかに安全なので、
なのでできるだけパスキーを使う方がいいかなと思うので、
大半のGoogleアカウントを使っている人にはおすすめというか、
本当に簡単に使えるので、iPhoneとかAndroidとかのスマホを持っている人はすぐさまログイン画面に行ってパスキー登録ってやった方がいいんじゃないかなと。
そんな感じで非常に簡単だし使い勝手もいいし、よくできているかなと思ったので、
そんな感じで紹介をしておこうかなと思いました。
もう使ってみた?
僕まだ使ってないです。
本当?ちょっと使ってみて。
使ってないです。
これあれなんですよね、自動で作成されたパスキーと手動で作成されたパスキーが分かれて表示されるんですね。
Windowsでやったよとか、例えばGoogleのPixelでやったよとか。
一応端末ごとにパスキーってひも付くので、
48:04
Appleみたいに同期すれば、あとGoogleもGoogleのパスワードマネージャーを使って同期すれば一緒になるけど、
そうでない場合は基本的に端末ごとに生成するという形になっちゃうとバラバラになっちゃうので、
そこはちょっと管理があらかじめちゃんと考えておいた方がいいかもしれないね。
そうですよね。わけわからなくなっちゃうかもしれないですよね。
使ってみようかな。そろそろやっとGoogleも対応したし。
これでGoogleでそれなりにユーザー数多いから、
これだけ使ってる人が多いサービスが対応したら、一気に使うようになってもおかしくはないので、
ようやく一つの普及期に入るかなっていう感じで。
これで使い方に慣れていけば、いいなってなるんじゃないかなっていうか。
もうこれより便利なものでえへんかな。
そうね。出ないんじゃないか。安全性が高くて使い勝手もいいものっていう意味だよね。
もうパスワードや認証に関しては、これやっとけばもういいっす。これだけやってくださいみたいな。
一応これがファイナルアンサーなんじゃない?
と思うけど、しばらくはこれが普及するまではパスワードがなくなっていくっていう未来じゃないかな。
他には何かないと思うんだけどな。
パッと浮かばないですよね。すごい自分に身近なデバイスで追加で何か買う必要なくてみたいなものを考えると、そこも便利というかコスト面もね。
あとさっき言ったGoogleがもともと使ってた独自の仕組みとかっていうのは、結局スマートフォンにひも付いちゃうんで。
僕も例えば毎年買い替えてるじゃないスマートフォンを。
スマートフォンというかiPhone。
iPhone。そうすると毎回毎回買い替えるたびに鍵を再生成しなきゃいけないんだよ。
そうですね。端末に縛られるとね。
それがめちゃくちゃ面倒くさいんだけど、このパスキーが何がいいかっていうと、同期ができるっていう点が最大の利点なので、
同じね、僕だったらiPhoneだったら同じAppleアカウントを使ってるデバイスだったら簡単に同期できるし、
スマホ買い替えても同じアカウントで乗り換えればさ、勝手に同期されるから、再生成とかする必要が全くないから。
そうですよね。
そういう意味ではこれこそがファイナルアンサーとして。
そっか、確かに。
復旧してほしいな。
買い替えの面も全然フォローされてる。
そこが大きいよね、やっぱね。
なので、ぜひ騙されたと思ってとりあえず使ってみてください。
いや、騙されたらダメですからね。
そうね。
こんなクリティカルなところで騙されたらそれはもう終わりやからね。
どうだろう、これもまだ当面はオプトインというか、ユーザーが自ら使いますってやらないと使われないので、
まだまだちょっと一般の人が…
強制的に使わせるぐらいの動きがないと。
51:01
もうパスワードは無効にして強制的にこっちっていう風にやらないと、なかなかね、また復旧まではいかないかなとは。
そうですね、確かに。
この辺はやっぱり、なりすまし事案ってまだまだいっぱいあるじゃないですか。
特に個人アカウントのやつってよくニュースでも取り上げられたり。
そうだね。
今だったら組織だったらクラウドとか個人のクラウドから乗っ取られて、個人端末やられてみたいなのもあったりしますけど、
これをですね、そういった事件事項があった時に、じゃあどうすればいいんだっていう風なものを説明するときに、これを進めた方がいいのかなやっぱり。
2要素2段階ではなく。
今だったら使い勝手もそんなに悪くないし、個人の利用者にはパスキーとりあえず登録して使えるなら使いましょうじゃないかな。
選択肢って3つあるかなと思ってるんですよね。
今よりもより良いセキュリティレベルに上げるこのパスワードの管理使い方みたいなことで言うと、
今あるパスワードを本当に力技でバラバラにして、難しいが推測できないようなものにするという、今までのパスワードを強固にするというだけ。
2要素2段階の導入、パスキーの導入っていうのがあるんですけど、これをうまく、使える使えないがあるじゃないですかサービスの中には。
この選択肢が増えるっていうことになると、僕が聞いてと思ったのはせっかくGoogleがやっと対応してくれたってことがあるんで、
GoogleのGmailをリセットに使っている人って多いと思うんですよ。
GoogleとAppleやったらAppleの方をパスキーで強固に何としてでもこれだけはっていう風に進めるのがいいのかな。
今の3つで言ったら優先順位的な3,2,1だよ。
パスキーが使えないならとにかくパスキーを使う、パスキー使えないならしょうがないから2要素認証を導入しましょう。
それもダメならパスワードを強固にしましょうでしょ。
でもどれか1個しか嫌やねんって言われたら、パスキー使える、そういう主要なサービスっていう風なものだけでも。
どれか1個しか嫌やねんっていうのは?
全部バラバラやるの嫌なんですみたいな面倒くさいですっていう。
せめてこれだけやってって言うんやったらどこからかなっていう程度の話ね。
それを言い出したらさパスキーはまだ全然普及してないから、それだけで全て解決しないよ。
でもそれ普及するのを待ってたらいつまでも使われないんで。
そうなんですよね、そうなんですよね。程度が難しいなと思ってね。
使えるところはもうとりあえず使ってくれっていう。
これまで面倒くさかったら管理手法が1個増えるとそれだけ手間が増えちゃうっていうことだったと思うんだけど、
パスキーはそういう意味ではそんな手間が増えないんで、勝手に同期もされるし、
54:00
端末のスマホの普段使ってるロックを解除すれば勝手に裏で認証してくれるわけだから、
そういう意味ではユーザーの負担はそんなに増えないから、最初の登録の時だけだからさ。
そういう意味ではとりあえず使えるところでは使ってくれでいいと思うけど普通の人にも。
その辺りが難しいよね。
そうですね、その差し加減をちょっと自分なりのアンサーを作らなあかんなあなんていうのを思いました。
確かに、僕たちにとっては当たり前のことでも大多数の人にとっては当たり前じゃないからね。
そこのバランスですね。どこができそうなのかポイントみたいなところをバランス取らなあかんなっていうのをちょっとね。
確かに。
はい、ありがとうございます。ということで今日も3つのセキュリティのお話をしてきたので、最後にオススメのあれなんですが、
今日はちょっと番組というかコンテンツというか紹介しようかなと思うんですけど、
何も考えずにアッパーなものをぼーっと見るのもいいんじゃないかということで、
今日紹介するのはですねAmazonプライムで見られるものなんですけれども、
34年ぶりに復活しました風雲竹市場ですね。
なんかそれ話題になってたよね。ニュースで見たよそういえば。
そうそう少し前にね、復活風雲竹市場かっこ狩りみたいなタイトルでテレビ局から出てたんですよ。
募集を参加者の。
そうなんだ。
多分その辺から話題になってるんじゃないかな。
メディア向けに記者会見があった?わからないけど。
多分やってると思いますね。
なんかネットニュースで見たよそれ。
知らなかった。
それがちゃんと実施されて放映されてるんですけれども。
34年ぶり?
34年ぶりですね。
そんな前だったのあれ。
そうそう。
でも当時はすごい人気番組っていうか。
いやそうですよそうですよ。
みんな見てたよな。
意外となんかで僕の記憶ではね結構長年やってた長寿番組のイメージあったんですけど、そんなやってないですよね。
そうなの?
3年ぐらいしかやってない。
マジで?そうなのか。
短いんですね意外と。
インパクトが結構あったからもっと長かったような。
毎週毎週テレビつけてはいつでもやってたみたいなイメージなかったですか?
俺もそんなぐらいのイメージだったわ。
そうなんですよ。でもちゃんとこれ改めて調べてみたら86年の5月から89年の4月なんですよ。
短いな意外と。
3年?4年?そんなぐらいしかやってないっていうのは意外だったんですけど。
それが復活したのがすげー。
そうそうそう。復活しましてそうなんですよ。
それをね、シーズン1って書いて2、3があんのかそれは視聴率とかそういうのにもよるんだと思うんですけど、
昔よく見てたこれこれみたいなやつもあったり、新しい難関と言われるようなね、
57:00
をクリアしていかないといけないものが追加されてたりとかみたいなのがあって、
結構面白いというかテレビの良かった時代みたいな感じが出てますね。
こんなめっちゃ枯れかけてるなみたいな感じがするんですよ。
あれすごい豪華なセット使ってやってたよね。
そうそう。緑山スタジオっていうよく仮面ライダーとかああいうの爆破シーンとか撮るようなところのスタジオでやってるんですよね。
屋外のスタジオで。でっかい大掛かりなセット作って、
例えばジブラルタル海峡とか、
取って手すりのない吊り橋みたいなの渡って下からドッジボールが飛ばされて落ちたらあかんみたいなやつとかね。
あと龍神池っていうやつとかね。
今回のAmazonプライムのやつはまだ見てないんだけどさ、
昔あったフォーマットをそのままリバイバルっていうか同じような感じでやってるわけ?
基本的にはそうですけど、昔よりかはちょっと緩めかな。
そうなんだ。
例えばなんかその難関にチャレンジして思いっきりダメでしたと、捕まりましたとか落ちましたとかってなったけど、
落ち方がおもろかったから突破みたいなのもあるんですよ。
普通に0-1でやったらすぐいなくなっちゃうと思うんですよ、挑戦者が。
全滅してしまうというのもあるんで、とんでもない落ち方したとか、めちゃめちゃ頑張ったとか、
そういうのがあると次に進めるみたいな、
敗者復活の救済措置みたいなのがあるんですよね。
そういうの見せずにやっちゃうとやらせみたいになるから見せてるんだと思うんですけど。
そういうのをやってるんで、あの頃知らない人もいるかと思うんですけど。
そうだね、もう結構その30何年前って言ったらもう全然知らないって人も多いはずだよな。
僕らの世代ぐらいがギリかな。
そうだろうね。
ちょうどよく見てた頃みたいなね。
そうね。
だしその頃って割とテレビ、今と比べたら何でも自由にまだまだやれてた時代っていうか。
テレビ前世紀みたいなとこもありましたしね。
そういう時だから、なんか懐かしいし、今見たら逆に新鮮かもね、わかんないけど。
そうなんですよ、こんなのないと思うんで、ここ20年30年ぐらいテレビ見てきても、
どんどんあの頃から景気も悪くなっていきましたしね、これぐらいの時期から。
だから今見ると逆に斬新なんて思いますね、皆さんが見ると。
だからこそそういうのがやられるんだろうね、今の時代にね。
そうそうそう。なんでちょっとAmazon入ってる方は、ちょろっとバカバカしくて何も考えずに見れるというか、
そういうのもいいかなと思うんで、見てみてもいいんじゃないかなというふうに思いますし、
結構難関なんですよ、みんなね。
ちなみに昔竹市場をやってた頃っていうのは、127戦中攻撃側のチームが勝ったのは8勝しかないので、
1:00:02
あ、そうなんだ。
なので通算勝率で言うと6.3%らしいですね。
低い。
しかもしかもですよ、しかも127戦やってこの8勝しかしてない、
なんていうの、記念すべき第1勝目っていうか落上させたっていう時には、
ボスが竹市さんではなくて竹市くん人形だったんですね。
そうだったんだ。
これは僕はリアルタイムに見てて今でも記憶にあるんですけど、
竹市さんがちょっと禁止中だったということなんですね。
竹市くん人形がレギュラーになったタイミングで負けてるんで、
実質これは負けてないと言っても問題ないかもしれないですね。
竹市さんは負けてないってことで。
そういうのもあるんで、見ていただければいいんじゃないかなと思って紹介させていただきました。
はい、ということで今週は以上ですね。また来週のお楽しみです。バイバイ。
バイバイ。
01:00:57

コメント

スクロール