セキュリティ の記事一覧

こんにちは、GMOインターネットグループ株式会社 システム統括本部 ホスティング・クラウド開発部 アプリケーション共通チーム（技術推進チーム/AWS運用チーム）の井本です。弊社では、AWS環境におけるセキュリティ強化の取り組みを随時実施しております。今回は、直近で実施したセキュリティ統制の取り組みである「AWS Security Hubの導入」について、ご紹介させていただきます。 はじめに みなさんは、Security HubやGuardDuty, Trusted Advisorなどを導入したものの、「各チームにご対応いただけない」、「通知が来すぎてしまう」など、うまく運用を回すことができないという状況に直面したことはないでしょうか？ 今回は、Security Hubの横断導入に際して、得られた知見をご共有させていただき、ぜひみなさんが導入・運用改善される際の参考にしていただければと思います。 AWS Security Hub導入の背景 弊社では、従来オンプレミスで運用を行っていた際はもちろん、Security HubやGuardDuty, Trusted Advisorなどの導入は行っておらず、「GMOサーバーセキュリティ by イエラエ株式会社」の「クラウド プラットフォーム診断」を実施させていただり、社内で策定したセキュリティガバナンスに基づいているかを定期的にチェックする、あるいは、問題が発生した（発生してそうと判明した）ときに、手動で検知して対応するしかありませんでした。 そこで、自動的にセキュリティ上の問題を検知・集約化してくれるSecurity Hub導入への機運が高まり、導入に行った次第でございます。 各開発・運用チームに対応いただくための取り組み コントロールの精査 コントロールとは、Security Hubのセキュリティ基準における各セキュリティ項目を指し、何の優先度も付けず、すべてを片っ端から対応を進めていくのは生産的ではないため、弊社では下記のような分類に基づき、優先度付けや対応方針を策定しました。 なお、弊社で導入しているセキュリティ基準は２つであり、「AWS 基礎セキュリティのベストプラクティス v1.0.0」と「CIS AWS Foundations Benchmark v1.4.0」です。 「AWS 基礎セキュリティのベストプラクティス v1.0.0」では、下記４種類の対応方針を定めています。 ◆是正まで追跡　・期限を設定し、検知項目が是正されるまでAWS運用チームが追跡する◆通知のみ　・ユーザーに通知のみ、是正するかは任せる　・通知したら抑制済みとし、セキュリティスコア対象外◆対応しない　・対応する必要なし、抑制済みにする◆無効化　・コントロールを無効化にする 「CIS AWS Foundations Benchmark v1.4.0」については、弊社の使っていなサービスに関する項目や対応が難しそうな項目は「無効化」し、それ以外のすべてのコントロールを「是正まで追跡」と定めています。 また、「AWS 基礎セキュリティのベストプラクティス v1.0.0」については、下記の分類により対応方針を定めています。 ◆必須サービス　・必須で有効化すべきサービスや必要な設定　・サービスや設定毎の特徴があるため、実際はコントロール個別での判断が多い　・対応方針：是正まで追跡◆可用性確保　・マルチAZやバックアップなど　・セキュリティといえばセキュリティだが、今回のスコープでは特に幅の広い要素　・厳密なセキュリティ要件ではないため管轄外　・対応方針：対応しない◆ロギング　・サービスのログ保存など　・本番環境の大体のログは必須とする　・対応方針：是正まで追跡◆通信中の暗号化　・TLSを利用するもの　・現代のインターネットでは必須　・対応方針：是正まで追跡◆保管時の暗号化　・KMSなどを利用したストレージ上の暗号化　・ポリシーと規制要件のためここでは管轄外　・対応方針：対応しない◆使用なし　・現状、使用していないサービス　・検知ステータス：データなし　・対応方針：無効化◆その他　・セキュリティ要件から外れるログの適用等は対応しない　　‐VPCフローログとか　　‐ログだけ運用されないといった事象につながるので必須にはしない　・WAF適用は本番で通知のみ　　‐WAFが不要な対象もあるため、WAF入れてないけど大丈夫かの確認だけ通知する　・OS以上のレイヤーの脆弱性管理は管轄外　　‐SSMパッチコンプライアンスなど、別で管理する場合も多いため　　‐AWS環境のセキュリティを維持する目的からは外れる なお、重要度が「CRITICAL/HIGH」、かつ上記の分類が「是正まで追跡」となっているコントロールはそのまま「是正まで追跡」とし、重量度が「MEDIUM/LOW」、かつ上記の分類が「是正まで追跡」となっているコントロールは「通知のみ」と定めています。また、それ以外の対応方針（「通知のみ」/「対応しない」）は、重要度に関わらず、上記の分類に基づいた対応を実施します。 これらのコントロール別の対応方針は、DynamoDBの「対応方針テーブル」に保存しておき、セキュリティ上の問題検知後、それぞれの対応方針に応じて、対応が実施されます。 通知周りの実装・設定 通知周りの実装は、うまく運用を回す上で、最も重要な部分です。 まずは、Security Hubの検出結果をAmazon EventBridgeにより取得し、その取得結果をStep Functionsに流します。 私が設定しているEventBridgeのルールにおける、イベントパターンは下記の通りです。 { "source": ["aws.securityhub"], "detail-type": ["Security Hub Findings - Imported"], "detail": { "findings": { "Compliance": { "Status": ["FAILED", "WARNING", "NOT_AVAILABLE"] }, "RecordState": ["ACTIVE"], "Workflow": { "Status": ["NEW"] } } } } ここで特筆すべき事項としては、findingsのComplianceのStatusが「FAILED/WARNING/NOT_AVAILABLE」、WorkflowのStatusを「NEW」に限定している点です。 これにより、新たに検知された問題のあるセキュリティ項目のみを取得することができます。 取得されたセキュリティ項目は、下記のStep Functionsにより、対応方針に応じた処理が実行されることになります。 また、その対応方針が「是正まで追跡」である場合は、DyanamoDBに登録したアカウントテーブルからそのアカウントの担当者情報などを取得し、その結果をもとにSlack通知やチケット記票（後述）を行います。 通知の実装をする際には、EventBridgeから取得したデータを基にして、Amazon SNSとAWS Chatbotを使用することで、Slackチャンネルへの検出結果の送信が非常に簡単にできます。 しかし、デフォルトでは英語で通知、詳細な条件分岐によるメッセージの変更など、カスタマイズ性が悪く、今回の要件とはマッチしなかったため、弊社ではAWSに関する通知周りの実装を行う際はLambdaを利用するケースが多いです。 なお、今回対応方針を「通知のみ」に定めたコントロールに関しては、Security Hubの定期的なチェックのタイミングで通知するのではなく、月次サマリとしてすべての対応状況と併せて通知するようにしています。 当初は、対応方針が「通知のみ」のコントロールについても、Security Hubの定期的なチェックのタイミングで通知するように実装を行っていたのですが、「是正まで追跡」を実施するコントロールがSlack上で流れてしまい、管理がしにくくなってしまう懸念が生じたため、仕様変更を行いました。 （チャンネルを分けて、対応方針が「通知のみ」専用の通知用チャンネルを作るという選択肢もなくないですが、みなさんご存じの通り、そのようなチャンネルはまあ見ることはないですよね、、） 月次サマリを実装する際ですが、Security HubのセキュリティスコアをAPI経由で取得する手段はないため、boto3から各コントロールの「成功/失敗」を取得して算出するようにしています。 月次サマリのメッセージのサンプルは下記の通りであり、これだけでは詳細は分かりかねるものの、Security Hubのコンソールや対応状況管理チケットへの導線として機能するようにしています。 ※数値は仮のものを使用しております 2024年4月1日 現在のSecurity Hub検知状況をお知らせいたします。 ◆CIS AWS Foundations Benchmark v1.4.0　・CRITICAL：0　・HIGH：0　・MEDIUM：3　・LOW：5 ◆ AWS 基礎セキュリティのベストプラクティス v1.0.0　・CRITICAL：0　・HIGH：0　・MEDIUM：8　・LOW：10 なお、上記の検知結果は失敗件数でございます。 CIS AWS Foundations Benchmark v1.4.0およびAWS 基礎セキュリティのベストプラクティス v1.0.0の「CRITICAL/HIGH」については、対応必須ですので、期日までのご対応をお願いいたします。 是正までの管理方法 弊社では、対応方針が「是正まで追跡」のコントロールに関しては、Slack通知とともに、自動的に社内のチケット記票を行い、そのチケットを利用して対応状況を管理できる仕組みを構築しています。 なお、上記チケットは弊社では、GMOチケットと呼んでおり、普段のプロジェクト管理にも利用しているため、様々なツールや機能がもともと用意されておりますが、ない場合はどのように対応状況を管理していくかを検討する必要があります。 なお、検出結果に基づく通知するメッセージのサンプルは下記の通りであり、各開発・運用チームは検出されたメッセージを確認して、参考URLから検出された原因やネクストアクションを確認することができます。 最終行に記載がある通り、商材やセキュリティ診断などの事情により許容すべき場合もあるので、その際はスレッドにその旨を記載いただき、ご相談させていただくような形式にしています。 タイトル：重要度: LOW (S3.13) S3 バケットでは、ライフサイクルポリシーを設定する必要があります対応期限：２週間以内に対応してください対象◆AWSアカウント：<Account Name>（<Account ID>）◆リージョン：ap-northeast-1◆リソース：<Resource>◆参考URL： https://docs.aws.amazon.com/console/securityhub/S3.13/remediation◆許容すべき設定の場合はこのスレッドでメンションをつけて理由を説明してください 委任アカウントでの運用 Security Hubでは、権限を委任することで委任アカウントに、検出結果や通知の実装などを集約することが可能です。 しかし、標準機能では、委任アカウント側からコントロールの有効/無効を変更しても、その変更はメンバーアカウント側に伝搬することができません。 そこで、aws-samplesにて公開されているcontrol-disablerというソリューションを導入することで、この問題を解決することができました。 ただし、Security Hubの機能の１つである検出項目の自動修復については、Terraformによりリソースを管理しており、そのstateファイルと不整合が生じる可能性が高く、弊社では利用しておりません。 目下のセキュリティ施策 私たちが実施している目下のセキュリティ施策の一部について、ご紹介させていただきます。 現在、弊社では「継続的な運用」をテーマに、本記事のようなSecurity Hubの通知周りの整備を行ったように、AWS Trusted AdvisorやAmazon GuardDutyについても同様に集約アカウントで管理し、何か悪意のあるアクティビティや異常な動作をモニタリングして、自動で重要度に応じた通知する仕組みを実現しようとしています。 また、オブザーバビリティ向上のために、ログ最適化やX-Rayの導入、障害予測・検知ためにAmazon DevOps GuruのPoCを実施しております。 まとめ セキュリティ施策を実施する上で、重要なのは目的から逆算して、必要な施策を行うことです。ここでの目的とは、セキュリティ上の問題に対して、完璧に０にすることはできなくとも、限りなく０にするために、コスト見合いを行いながら、対応を継続的に行っていくことです。 AWS環境を利用していれば、往々にして「Security Hubを導入しましょう」「GuardDutyを導入して悪意のある動作を検知しましょう」といったサービスの導入部分にフォーカスされた会話になりがちですが、重要なのは導入することが目的なのではなく、継続的にそのサービスを利用して対応を進めていくことです。 しかし、それでもなお、「発見的統制」「予防的統制」「障害予測・検知」において、対策できていない箇所があれば、新たにAWSのサービスや他のツールの導入を検討しましょう。 今後 今後については、足元のセキュリティ施策を完遂させることに加え、本記事で課題として挙げたセキュリティ上の問題の検知→自動修復をTerraformで管理している場合でも、実現できないかという観点を模索したいと考えています。 それが破壊的な変更となっていないか念のために確認するという作業は結局人が行う必要があるものの、自動修復を実現することができれば、少ない工数で最高にセキュアな環境を維持し続けられることができます。 また、そこで削減できた時間を新規開発に充てることができれば、今まで「守り」に費やしていた時間を「攻め」の時間として活用することができると考えております。 参考URL https://tech.gunosy.io/entry/2022/12/04/120000 https://dev.classmethod.jp/articles/devio-2022-how2make-strongest-aws-secure-accounts/ https://github.com/aws-samples/aws-security-hub-cross-account-controls-disabler https://dev.classmethod.jp/articles/get-control-finding-summary-by-boto3/

10月5日（木）に開催された「技育CAMPアカデミア -Vol.03」においてデベロッパーエキスパートの三村 聡志が登壇し「コンピュータの仕組みを知ろう」というタイトルで勉強会を開催しました。勉強会では、普段あまり気にしないようなコンピュータ内のデータの保存の仕組みからOSの仕組みまでを紹介しました。イベント告知： https://developers.gmo.jp/37769/ 登壇者 GMOインターネットグループ デベロッパーエキスパート三村 聡志（@mimura1133 / 親方） 実際に動いているものを見てコンピュータの見方を広げる 今回の勉強会では「実際に動いているものから仕組みを知る」ということにフォーカスを当てました。いくつか勉強会の資料のスライドを用いて説明します。 たとえば「コンピュータが『0』『1』の2つの値の組み合わせで動いている」という話は、学校の技術の教科書にも掲載されているほど、コンピュータの説明としてよく登場する話です。 では、実際にどういう信号が「0」と「1」になっているのでしょうか。下記の右下の図を見てみましょう。よく見ると波形が表示されていることに気づきます。 この波形は、左の図の装置で記録した実際の通信データであり、実際にUSBキーボードの通信を記録したものになります。 コメントを入れて読みやすくしたものが下図になります。（上図で掲載の波形とは少々異なります） 色々とアルファベットが書き込まれていて複雑になってきました。もちろん、今回の勉強会では、このような波形を読めるようになる事はゴールとはしていません。 今回の勉強会では「実際にはこういうことが起きている」とか「教科書に載っているような理想との差（たとえば波形が矩形波ではないということ）がある」ということを知ること、そしてこのような基礎技術の存在を知り見方を広げることが今回の勉強会の大きなテーマでした。 身近なものから高度な技術まで 今回の勉強会では下記の4テーマに触れて進めました。このうち後半の3テーマについて順を追って説明します。 2進数・「0と1」ファイルの中身（フォーマット）プログラムの動く仕組みOSの仕事 ファイルの中身（フォーマット） ファイルの中身をバイナリエディタを用いて開きその特徴を調べました。 まず Bitmap ファイル (BMP) の場合。（ここでは分かりやすくするために 24bit フルカラーのファイルを用います。）下図に示すように、光の三原色がそれぞれ 1バイト (=8bit) で表現されていること、また書き換えるとその部分がそのとおりに色が変わることを紹介しました。 またファイルによっては特徴的なデータ列 (magic) が含まれる場合や、文字列として中身が見える場合などがあり、そのような特徴がファイルによって存在することを確かめました。 プログラムの動く仕組み ここでは nasm を用いて、実際にアセンブル・および逆アセンブルを実施して、簡単なプログラムの作成と解析を行いました。 高度なプログラムも簡単な操作を複数組み合わせることで成り立っていること、そしてもちろん現在のPCで動作するプログラムも基本的な考え方は同じであることを紹介しました。 OSの仕事 ハードウェアの抽象化・リソース管理・スケジューリングについてこれまで話をしてきたことを組み合わせながら説明を行いました。 OS側でケアをすることにより、機器毎の違いをアプリケーションの開発者が気にしなくてもよくなっていること、複数のプログラムを起動しても動いていることなどを実例を交えて説明を行いました。 さいごに 今回の内容は1時間としてはとても濃い内容になっていたと思います。また演習環境の準備の関係上、勉強会の時間内では手を動かせなかったかたもいると伺っています。 いくつかの準備不足等はありましたが、資料は参加者のみなさんには公開していますので、少しでも興味関心が湧く所やもう少し掘り下げてみたいと思える場所が今回の内容から見つかれば嬉しいと思っています。

こんにちは、暗号のおねえさんことGMOインターネットグループ デベロッパーエキスパートの酒見(@ysakemin)です。2023年7月22日〜28日、アメリカ・サンフランシスコでInternet Engineering Task Force (IETF) 117 に参加しました。今回の参加目的としては、IETF117でHackathonに参加すること、IETFにおける暗号技術の動向を調査することです。Hackathonでは低遅延暗号 Areion に関するプロジェクトを立上げたので、今回の記事ではその話題に触れたいと思います。 イベント概要 The Internet Engineering Task Force (IETF)とはIETFは、インターネット技術の標準化を行う団体です。 これまで、HTTP、IP、TCP/UDP、TLS、QUICなどインターネットで使われる多くのプロトコルが標準化されてきました。オープンな組織であり、会合には誰もが参加可能です。活動の生産物として、RFC(Request for Comments)を発行されています。IETFの詳細については、こちらをご参照ください。 以下は、本記事で取り扱う2023年7月に開催されたIETF117の概要です。 イベント：IETF117開催日時：2023年7月22日（土）～28日（金）開催場所：カリフォルニア州サンフランシスコ ヒルトンユニオンスクエア　　　　　オンラインのハイブリッド主催：NOKIA（ノキア） 活動の背景 今回のHackathonでは、低遅延暗号 Areion に関する活動を行ったのですが新規にテーマ登録して参加を行なったので、この活動を実施する上でのノウハウも書かせていただきたいと思います。 この活動の背景としては、NICT Beyond5G研究開発促進事業 委託研究の「リアルタイム暗号技術とプライバシー保護への拡張」があり、この研究テーマでは低遅延暗号Areionをインターネット上で利用できるような環境を増やすことがミッションの一つとなっております。気になる方はこちらのURLを確認してくださいね。 ＜ノウハウ1＞ Hackathonでの「最初の一歩」 Hackathonに参加する際には、IETF Hackathon Wiki の中から興味のあるテーマを見つけるのですが、今回のわたし達のテーマは立ち上げが必要です。 テーマを立ち上げるためには「Champion」になる必要があります。「Champion」とは、テーマの主催者であり、Championとして登録することはテーマを主導していくことの宣言となります。 Championになる方法は簡単で、Hackathon Wikiに下記のような内容を記入するだけです。 ### Your Project Name - **Champion(s)** - Your Name (email at domain.com) - **Project Info** - Your project description here なお、Hackathon Wikiの記入はIETF Datatracker accountの取得が必要となるため、ご注意ください。 例えば、今回の低遅延暗号 Areion ですと、Wikiへの記載例は以下のとおりです。 ＜ノウハウ2＞ Hackathon当日の場所取り Hackathon当日のChampion のミッションとして、お花見でいうところの「場所取り」があります。会場には大きなテーブルがたくさんあるので、どの席がいいか？などを考えて場所を決めます。場所の取り方は原始的で、ホワイトボードの空きテーブルと実際の空きテーブルを確認しながら、確保できそうな場所にテーマ名を記入します。私たちのテーマだと、以下のような感じで確保することができました。 テーブルが確保できたら、テーブルに立て看板が用意されているので、そこにテーマ名を出して場所取り完了です。 今回、いい感じの場所を獲得することができたのですが、真夏のサンフランシスコだったにも関わらず、エアコンの吹き出し口の真下な席で寒すぎて体調を崩したので…次回からはその辺も気にして場所取りしたいですね！ 陣地も獲得できたら、あとは計画していたHackを進めていきます。 Hackathonの2日目に成果発表会があるため、目標を達成して良い報告ができるように活動に取り組んでおりました。成果発表の時間は、IETF Hackathon Wikiにテーマ登録を行い、専用のGitHubリポジトリに登録することで枠をもらえます。 今回のHackathonでの活動 今回は、Areionのリファレンス実装のOpenSSLへの組み込みを行い、TLS1.3でAreionを使えるように対応を行いました。 Areionを組み込んだOpenSSLの実装と発表資料は以下のとおりです。 実装はこちら。発表資料はこちら。 Hackしている時や発表後にコメントやアドバイスを多くいただけたので、今回は大成功だったと思っています。 今後の取り組み 今後は、2023年11月4日から開催されるIETF118に向けて活動を準備していきます。引き続きよろしくお願いします。 当社では、先端技術を用いたコア実装、調査研究、実証実験などの研究支援から、標準化支援、エンタープライズ向けサービス開発まで積極的に実施しておりますので、お気軽にお問合せください。 お問い合わせはこちら

先日開催された、セキュリティ・キャンプ 全国大会 2023に、GMOインターネットグループはシルバーメンバーで協賛しました。当日は企業紹介イベントへの参加や、GMOインターネットグループの社員が講師として参加してきましたので、その内容をレポートしていきます！ イベント概要 セキュリティ・キャンプ全国大会とは 「セキュリティ・キャンプ」のメインイベントとして主に夏休み期間中に実施する合宿形式の勉強会です。 毎年テーマ別に集められるエキスパートが講師となり、専門的・実践的な講義が受講できるほか、合宿の中で同じ趣味を持った仲間との交流もあります。全国大会のほか、全国大会修了生の次のステップとなるネクストキャンプ、小中学生を対象としたジュニアキャンプも同時開催いたします。また会期中には、これまでにセキュリティ・キャンプに参加した修了生がチューターとして学習の支援等も行います。 開催日：2023年8月7日（月）～8月11日（金）開催場所：クロス・ウェーブ府中参加費：無料（事前登録制）主催：独立行政法人情報処理推進機構（IPA）、一般社団法人セキュリティ・キャンプ協議会公式HP：https://www.security-camp.or.jp/IPA HP：https://www.ipa.go.jp/jinzai/security-camp/2023/zenkoku/index.html 会場となるクロス・ウェーブ府中は、勉強する部屋、食堂、ホテルがすべて建物内に入っており、学生たちは過ごしやすそうで勉強に集中しやすい環境が整ってました。 「このはちゃんポーチ」使ってくれたかな？！ 参加者には、各協賛企業からのノベルティが事前配布という形で各自宅に郵送されました。 GMOインターネットグループからは、合宿期間中に使用できるようにと、小物類など持ち運びに使える『このはちゃんポーチ』をプレゼントさせていただきました！！ 弊社のホスティングサービス「ConoHa by GMO」のキャラクターである”美雲このは”です。是非たくさん使ってくださいね～！！ 企業紹介イベント 今回は現場で活躍するエンジニアと人事が参加させていただきました。 前半は人事より、会社説明や働く環境について詳しく説明させていただきました。後半はセキュリティに携わるエンジニア2名より、実際に行っている業務内容や働いていくうえでのモチベーションなど、なかなか聞けないリアルな現場の話をお話しました。 最後の質問タイムではたくさんの声をいただき、有意義な時間になったのではないかなと思います。 参加してくれた方にはGMOオリジナルノベルティをプレゼントさせていただきました！ GMO講師 GMOインターネットグループより、講師として複数名参加いたしました。実際に参加してみての感想やインタビューをいただきました！ GMOペパボ株式会社 紫関 麗王 開発コース│Z2『Rust製Linux向けアンチウィルス実装ゼミ』 Q：全国大会の講師を終えての感想 紫関セキュリティ・キャンプ全国大会には2020年に受講生としてオンラインで参加したため、オフライン会場での参加は初めてでした。今回は講師という立場での参加でしたが、受講生と共に、自分も多くの事を学びました。 Q：学生へのメッセージ 紫関セキュリティ・キャンプは恐らく来年も開催されるでしょう。密度の高く、熱量もある濃密な5日間を過ごすことができる貴重なイベントなので、今年参加できなかった方もぜひ来年またチャレンジしてください。 GMOサイバーセキュリティ byイエラエ株式会社 三村 聡志 専門コース│A4『ローレイヤーから見るファイルシステムの理解』 開発コース│X1『リバースエンジニアリングゼミ』 Q：全国大会の講師を終えての感想 三村今年も昨年に引き続き、専門コースで1講義と開発コースのひとつを担当しました。「ローレイヤーから見るファイルシステムの理解」は、昨年や他のミニキャンプでも行っている内容で、xxd コマンドと grep と電卓だけで FAT32 を読み進めるという講義になります。慣れるまでがとてもハードな内容とはなりますが、今年は終わったあとに「とても楽しかった」という感想をもらう事も出来、私の方もとても楽しかったです。また「リバースエンジニアリングゼミ」は本業で行っている IoT ペネトレーションテストをそのまま一週間行うような講義になっています。全国大会の講師は昨年に引き続きとなりますが、参加者の知識や感性が異なるため、毎回新しい発見や刺激があってとても楽しいコースと感じています。来年も機会があれば引き続き担当出来たらと思っています。 Q：学生へのメッセージ 三村ものごとの仕組みを知る、基礎を知るというのはとても大事なことだと考えています。「USB端子に機器を接続すれば繋がる」ということは知っていても、機器が使えるようになるまでにどのような通信が行われているのか、機器が繋がったことをどうやって知るのか、などそこには通常知られていない様々な技術が隠れています。仕組みを深く知るためにはそれなりの時間や手間が掛かりますが、知ることができればそこから新たな世界が見え、新たな活用方法・攻撃手法の発見に繋がっていきます。是非学生のうちに、ものごとの仕組みや基礎の学習・調査を進め、ワクワクがあふれ出るエンジニアに皆さんがなられることを願っています。 GMOサイバーセキュリティ byイエラエ株式会社 緑川 志穂 開発コース│L1『暗号化通信ゼミ』 Q：全国大会の講師を終えての感想 緑川講師を拝命するのも6回目になりますけれども、受講生の方々のバイタリティには毎年驚かされるばかりです。そして久々のオフライン開催はオンライン指導との違いを改めて感じさせてくれました。開発コースではしばしば事前学習期間に極めて高い比重を置きますし、私の担当したゼミも事前学習期間が寧ろメインの指導期間となっていました。それでもオフラインで開催された5日間は事前学習よりもひときわ濃い印象を残したと感じます。叶うなら来年も是非オフラインで参加したいところです。 Q：学生へのメッセージ 緑川閉講式で言われたことを覚えておられるかもしれませんが、キャンプ修了後に重要なのはモチベーションの維持です。でも本記事の投稿の頃にはそろそろ一度息切れする頃かとも思います。五線譜に描かれる休符に無駄なものが無いように、休むこともまたモチベーションへと寄与します。キャンプ以降幾星霜が経過しても能力を発揮し続けられるよう、頭に留めてもらえると幸いです。 GMOサイバーセキュリティ byイエラエ株式会社 西谷 完太 / 山崎 啓太郎 専門コース│B6『ソースコード解析によるWebアプリケーションの脆弱性調査』 Q：全国大会の講師を終えての感想 西谷去年講義を行った「マイクロサービス／分散モノリス的アーキテクチャへの攻撃手法」では、近年普及が進んでいるクラウドサービスやマイクロサービスアーキテクチャを題材にした各サービス連携時に発生する脆弱性を使った攻撃手法を取り扱いました。今年の講義は「ソースコード解析によるWebアプリケーションの脆弱性調査」ということで、よりアプリケーション単体のロジックにフォーカスし、ソースコードの静的解析による脆弱性調査の楽しさや開発者自身が原因の特定などに役立ててもらうための内容を盛り込んだ内容となっています。また、CodeQLなどWebセキュリティの中でも比較的新しいトピックを講義内容に盛り込んでいるので学生だけでなくエンジニアが興味を持って取り込める内容だと思いますので、興味があれば今後公開予定の資料を覗いて取り組んでもらえると幸いです。 山崎講義は手動でのソースコード解析とツールによる自動化という内容で行いましたが、比較的実践的な内容になったかと思います。専門Bコースでは本講義の他にもWebプロダクトのセキュリティーやその周辺に関連した講義から構成されており、どれも社会人にとっても面白い講義だったのが印象的でした。 Q：学生へのメッセージ 西谷各プログラミング言語やソースコードリーディングだけでなく、様々な知識を必要とする講義で取り組むのが非常に大変だったと思います。ただ、その中でソースコードの静的解析による脆弱性調査の楽しさや開発者自身が原因の特定など、あなた自身のやりたいこと、やっていることに少しでも役立てていただければ幸いです。 山崎今回の講義の後半ではソースコード解析ツールを利用してクエリを書いてもらいましたが、実際には開発者の意図や状況を想定して人間がソースコードや設計書を読み、動作を検証しなければ見つかりづらい脆弱性がまだまだ多く存在しますし、今後も必要とされるスキルだと思います。ソースコードを読んでバグを探す時には様々な知識や経験が役に立つので、本講義が自身の興味を広げたり新しい知識を得る一助になっていると嬉しいです。 ▼講義資料はこちらhttps://gmo-cybersecurity.com/news/security_camp_presentation_slide_20230912/ さいごに セキュリティ・キャンプ全国大会2023にご参加された学生の皆さま、5日間の勉強合宿、大変お疲れさまでした！！皆さんの今後の頑張り・活躍を応援し期待しております！

こんにちは、GMOインターネットグループ株式会社の小林です。今回はセキュリティ対策の一環で導入しました、Yubileyについてご紹介させていただきます。 導入背景 以前よりMicrosoft365を導入していましたが、元々はID/PASSでの認証でした。それでは脆弱な状態であると判断し、全パートナーにスマートフォンを配布して多要素認証を導入しました。しかし、コールセンターや特定の業務のみに従事している場合は多要素認証のためだけにスマートフォンを配布するため一定のリスクが伴います。そのためID/PASSのみの認証にはならずに多要素認証を実装できるYubikeyの導入を決めました。 Yubikeyとは Yubikoという会社が開発したセキュリティキーで、用途に応じて複数の種類が発売されています。今回導入したのは以下画像にあるUSBのような形状のものになります。 種類についての詳しくは日本の公式代理店であるソフト技研のサイトを参考にしてください。 導入方法 Yubikeyが使用できるサービスは様々ありますが、今回は全パートナーに導入済のMicrosoftアカウントの認証に実装してみました（多要素認証を実装するためには事前にMicrosoftのライセンス及びMicrosoftアカウントの設定が必要になりますのでご注意ください） 簡単にユーザーが使用を開始できるまでの方法をご紹介させていただきます。 ①Yubikeyのソフトウエアを使用するPCにインストールします（Yubico Authenticater）②PCにインストールされたYubico Authenticaterを起動します。 ③Yubikeyデバイスをパソコンに接続します。 ④Yubikeyを接続するとアプリが以下の画面に代わります。　「三本リーダー」をクリックします。 ⑤「Add account」をクリックします。 ⑥以下のリンクをクリックし、Microsoft365のセキュリティページにアクセスします。　Microsoft365マイアカウント-セキュリティ確認　「＋サインイン方法の追加」をクリックします。 ⑦「認証アプリ」を選択し、「追加」をクリックします。 ⑧「別の認証アプリを使用します」をクリックします。 ⑨「次へ」をクリックします。 ⑩認証アプリのQRコードが表示されます。　㋐Yubico Authenticaterの「Scan QR code」をクリックします。　㋑Yubico Authenticaterの「Require touch」をクリックします。　㋒Yubico Authenticaterの「Save」をクリックします。　㋓認証アプリの「次へ」をクリックします。 ⑪Yubico Authenticaterにメールアドレスを登録されます。　㋐Yubico Authenticaterに登録されているアカウントの「指マーク」をクリックします。　㋑Touch requiredというメッセージが表示されますので、Yubikeyデバイスの金属部分をタッチします。　㋒認証の番号が表示されますので、認証アプリの「コード入力」場所に入力します。　㋓認証アプリの「次へ」をクリックします。 ⑫認証アプリの登録が完了するとセキュリティ情報に認証アプリが表示されます。 利用方法 次回以降、再認証がMicrosoftのログインページで求められる際はパスワード認証の後に以下の認証が求めらます。表示されたらYubico Authenticatorからコードを取得して入力してログインできれば認証完了となります。 ※Yubico Authenticatorのコードを確認する方法 ①Yubico Authenticatorのアプリを起動します。 ②Yubicoアプリに登録されているアカウントの「指マーク」をクリックします。 ③以下の画面が表示されますので、「Calculate」アイコンをクリックします。 ④「Touch required」のメッセージが表示されます。 ⑤Yubikeyデバイスの指定した場所を「タッチ」します。 ⑥Yubico Authenticatorの認証コードが表示されます。 まとめ Yubikeyの設定自体は簡単で、仕様を理解していれば短時間で導入可能です。 実際の多要素認証の場面では物理的に触れることで認証されるため、業務で利用するパートナーにとっても理解しやすいものとなります。導入によりスマートフォンを使用する多要素認証よりも問い合わせが少なくなり、IT部門と利用者の双方の負担が軽減され、時間とリソースを節約することもできます。ご参考になれば幸いです。

GMOインターネットグループが、12月6日（火）～7日（水）の2日間にわたり開催した「GMO Developers Day 2022」。東京・渋谷フクラスにおけるリアル登壇とオンライン配信のセッションを組み合わせたハイブリッドで開催された今回のイベントでは、Web3、AI、セキュリティ、クリエイティブといった「技術の拡張（Add on）」を、スペシャリストたちが紹介しました。今回はその中から、「プライバシー保護連合学習技術と活用方法について」と題したオンラインセッションをお届けします。登場するのはGMOサイバーセキュリティ byイエラエ株式会社から、AI開発部スペシャリストの伊藤一明です。 登壇者 伊藤 一明GMOサイバーセキュリティ by イエラエ株式会社AI開発部 スペシャリスト 連合学習に暗号技術を「Add on」したDeepProtect インターネット技術の中でもサイバーセキュリティなどに関する事業を展開するGMOサイバーセキュリティ byイエラエ。「誰もが犠牲にならない社会を創る～デジタルネイティブの時代を生きるすべての人が安全に暮らせる社会作りに貢献します～」をミッション＆バリューとして掲げています。 現代の課題の1つとして、伊藤は「複数の組織がデータを持ち寄って分析しないと解決できない課題に対して、データを共有したり開示したりできないという二律背反がある」と指摘します。 これを解決するための技術としてイエラエ社が社会実証・ビジネス化を進めているのが、連合学習と呼ばれる機械学習の手法に、暗号化したまま計算できる特性を持つ準同型暗号を「アドオン」したプライバシー保護連合学習技術である「DeepProtect」です。複数の組織が持つデータセットを互いに秘匿し、プライバシーや機密性を保ったまま共同で機械学習を行える、独自のプライバシー保護連合学習技術となります。 では、そのDeepProtectとはどんな技術でしょうか。 鍵となる技術である「連合学習」は、2017年にGoogleが提唱した機械学習モデルの手法です。Googleでは、キーボードアプリである「Gboard」の予測変換の精度向上に活用しています。 この技術は、機械学習に必要な学習用データを、1つの拠点やサーバに集約せずに作成できるという点が最大の特徴です。散在した学習用データを使っても、作成されたモデルは集約した場合と同等の性能があるとされています。 例えばGboardでは、各スマートフォン上で入力されたテキストデータと入力サジェストのクリック状況等から学習データを生成するのですが、キーボードで入力された文字列やクリック状況は機密性の高いデータになります。この学習データから機械学習を実行し更新モデルを作成するのですが、ここまではGboardをインストールしたスマートフォン内で行われ、学習データはローカルにとどまっています。 その後、更新モデルの差分情報のみがクラウドに送信され、他のユーザーの更新モデルと平均化されて、すべてのユーザーで共有する共有モデルを作成、改善されたモデルを再び共有します。これが個々のスマートフォンにダウンロードされて、再びローカルでの改善、更新モデルの作成に活用されます。これが繰り返されることで、キーボード入力の予測精度が向上する、というのがGboardの連合学習です。学習データ自体はスマートフォン内にとどまり、サーバに集約する必要がありません。 Gboardにおける連合学習の概念図。ローカル内で学習、改善、更新モデルの作成というサイクルを回しつつ、差分情報だけをクラウドに集約して、共有するためのモデルを作成、改善していきます。google資料「Federated Learning: Collaborative Machine Learning without Centralized Training Data」より抜粋 このように、学習モデルを作成する際には個人情報を含むデータの送信が行われず、学習によって得られた差分パラメータ（勾配情報）のみを送信することで、個人情報などの機密データを開示することなく学習モデルを構築できるのが連合学習です。 送信されるのは、プライバシーに関わるような個人情報などではなく、学習モデルの差分パラメータ（勾配情報）のみになります これに「アドオン」する準同型暗号は、その名の通り代数学で知られる「準同型（homomorphic）」の性質を持った暗号方式です。暗号化されたデータに対して加算や乗算といった演算を行った場合、復号した結果が、暗号化しない場合と同じデータ演算結果になる暗号方式です。 例えばEnc(m_1)とEnc(m_2)という暗号化されたデータがあった場合、復号をしない状態でEnc(m_1+m_2)、Enc(m_1×m_2)といった計算が可能で、復号した結果は、もともとの暗号化されていないデータの演算結果と同じとなっています。こうした特性から、暗号化した状態で中身を隠したままデータ処理ができるわけです。 連合学習技術と準同型暗号を組み合わせると、学習モデルの勾配情報を暗号化したまま計算して、その結果を集約して更新するため、データの漏えいを防ぐことができます。送信されるのが勾配情報に限られる上にそのデータは暗号化されているので、中身を見ることができないからです。 勾配情報を暗号化したまま計算する準同型暗号。計算式は図のようになります 厳格なセキュリティ、プライバシー保護によって、組織を横断したデータの利活用が妨げられるという課題に対して、プライバシー保護連合学習技術の「DeepProtect」であれば、個人情報などの機密性の高いデータを開示しなくても、組織を横断したデータ利活用が可能になります。 金融機関における不正取引検知で利用に期待 実例を見てみましょう。JST CRESTでの実証実験として、金融機関における不正取引検知でDeepProtectが活用されました。複数の銀行のデータを使って不正検知の学習モデルを作成するには、これまでは各銀行のデータを集約する必要がありました。口座情報や取引履歴などが含まれるため、通常は外部に出せない情報です。 DeepProtectでは、各銀行内で学習したモデルの勾配情報のみを暗号化し、中央サーバへアップロードします。中央サーバでは集約された勾配情報を、準同型暗号によって暗号化されたまま統合し、集約された勾配情報として更新をします。 各銀行では、この更新された学習モデルをダウンロードして、それぞれの学習モデルをまた更新します。このサイクルを繰り返すことで、精度の高い学習モデルが共同で構築できます。1つの銀行のデータだけではなく、複数の銀行のデータによる連合学習モデルを構築することで、より精度の高い不正取引検知ができるというわけです。 DeepProtectの実例として、金融機関の不正取引検知での概念図。それぞれの銀行の学習モデルの差分パラメータのみを暗号化、中央サーバにアップロードし、集約した差分パラメータを使って学習モデルを更新 実データ自体は外部に送信されず、あくまで差分パラメータという勾配情報のみが、しかも暗号化されたまま処理されるため、データの機密性やプライバシーが確保されているというのがメリットです。 実証実験の結果は、各銀行での被害取引の検知率で比較されています。1つの銀行のデータだけを用いた個別学習モデルと、DeepProtectの連合学習モデルを使った検知精度の比較では、検知率が個別の84％に対して85.3％と、1.3ポイントの向上が見られました。個別学習モデルでは検知できなかった不正取引が検知された事例も確認されました。 実証実験での結果。連合学習モデルの方が高い結果を得られました 銀行における不正取引の被害額は、把握されているものだけで約300億円程度とみられており、1ポイントの向上で3億円程度の不正が防げるということになります。表に出ている被害額は氷山の一角とも言われていますので、実際はもっと被害額を減らせる効果があると考えられます。 実証実験で示されたDeepProtectの高いポテンシャル 不正取得された口座が振り込め詐欺などの金融犯罪に使われる、といった加害取引検知の実証実験では、個別学習モデル単独と、個別学習モデルと連合学習モデルを組み合わせたハイブリッドモデルで検証。加害取引が検知されるとその口座を凍結するのですが、その口座凍結が個別学習モデルと比べて20～50週程度、早く検知できていたそうです。検知率も個別学習モデルで78.9％が、ハイブリッドモデルだと94.7％で15.8ポイントの向上。実証実験によって、DeepProtectの高いポテンシャルが証明されました。 加害取引検知の実験では、ハイブリッドモデルで大幅な性能向上が確認されました 金融機関に対する攻撃は複雑化、巧妙化しています。マネーロンダリングや不正送金、振り込め詐欺などが相次ぐ中、単独のデータだけでは不正対策が間に合わなくなっています。複数の金融機関にまたがってデータの解析を行うことで、不正の検知率が向上すれば、犯罪を未然に防ぐ可能性が高まります。 そのほかにも様々な分野での応用が期待されます。例えば医療・ライフサイエンスの分野では、ウェアラブルデバイスの普及で計測できるバイタルデータが急拡大。電子カルテシステムなどの環境整備も進み、大量のデータが収集されています。こうした極めて機密性の高いデータでも、セキュアに複数の機関やデバイスをまたいだ統合分析が可能になり、医療やライフサイエンスの進歩に貢献できる、と伊藤は話します。 マーケティング分野では、単独企業だけでなくグループ企業や業界内を横断した豊富なデータをベースにした学習モデルを構築。詳細なインサイトやターゲットの発見といった精度の高い分析の実現が期待できる、としています。 製造現場でも貢献できそうです。IoTの導入が進んだ製造現場では、AIを使ったデータ分析も始まっています。これによって、設備などの故障予知、部品の品質管理、製品の異常検知などの分野で活用が期待されています。こうした分析には、1社、1工場のデータだけでは不十分なので、複数企業の工場データを活用できるDeepProtectが「課題解決を支援します」と伊藤は言います。 サービスの分野にも応用できます。電力やガスなどの公益サービスでの需給バランスの最適化、自動翻訳、スパムメールの検出、カスタマーサービスのチャットボット、バーチャルアシスタントサービス、自律走行を制御する車両運行システムなど、伊藤は様々なサービスでの利用を例に挙げ、広く活用が期待できるとアピールします。 さいごに もともと今回の技術「DeepProtect」は、発明した情報通信研究機構（NICT）から技術移転された（ニュースリリース：https://www.nict.go.jp/press/2022/03/17-1.html）もので、サイバーセキュリティや暗号技術、機械学習に関して高い技術力を持つことからイエラエ社が移転先として選ばれました。社会実証やビジネス化を進めていますが、伊藤は、幅広い分野の多くの課題を解決できる可能性がある技術として、「今後に是非とも期待して欲しい」と締めくくりました。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://www.youtube.com/watch?v=kx7V6_jNU7U

こんにちは。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形式などでデータを受け渡しする方が良いとされています。昨今のサイトではほとんど使用していない気がしますが、昔に作成したサイトをそのまま運用しているというような場合はシリアライズ機能がないかチェックしてみると良いかと思います。