はじめに
Flatt Security セキュリティエンジニアの Tsubasa、lambdasawa、Osaki です。本ブログでは、2024年8月に開催された Bsides Las Vegas、Black Hat USA 2024、DEF CON 32 に弊社メンバーが参加した際の記録、および、特に興味深かったセッションの詳細についてお伝えします！
なお、本稿の作成にあたっては各セッションの発表内容について可能な限り誤りがないように注意を払って記述しましたが、誤りを含む可能性があります。また、各セッションの内容については、筆者独自の考えや解釈を含む場合があります。本稿を通して気になったセッションがあった方は、ぜひオリジナルの文献や発表のアーカイブにアクセスしていただければ幸いです。
Flatt Security の研修制度
Flatt Security には、業務に関係するカンファレンスやセミナーへの登壇や受講を業務時間に行うことができ、参加に必要な費用を会社に負担してもらえる「カンファレンス・セミナー参加支援制度」という研修制度があります。今回のアメリカ渡航も業務時間内の扱いとなり、渡航やイベント参加にかかる費用も会社から全額補助してもらいました。
なお、弊社 Flatt Security では新卒・中途を問わずセキュリティエンジニアを積極採用中です！エンジニアであれば全員がこの研修制度に応募するチャンスがあります。ご興味のある方は、ぜひ以下のフォームからカジュアル面談をお申し込みください。
その他、Flatt Securityでの働き方やメンバー、待遇や福利厚生については以下よりご覧ください。
Bsides Las Vegas
Black Hat USA / DEF CONへの派遣、及び海外登壇の支援制度により、今年Flatt Securityからは5名のメンバーが会社の費用補助のもと米国ラスベガスに滞在しています。
— 株式会社Flatt Security (@flatt_security) 2024年8月7日
現地で弊社メンバーを見かけたらぜひお声がけください！ pic.twitter.com/Uaz3iEUXRI
Bsides Las Vegas について
Bsides Las Vegas は、その名の通り Las Vegas で例年2日間開催されているコミュニティベースのセキュリティカンファレンスで、セキュリティに関する技術的な知識の普及やコミュニティの活性化を目指して開催されています。今年も例年通り Tuscany Suites & Casino で開催され、会場ではサイバーセキュリティに関連する様々なプレゼンテーションや CTF、ネットワーキングイベントが実施されていました。
本年度は 8/6 と 8/7 の2日間の開催でしたが、筆者3名は Black Hat への参加を優先するため1日目のみ参加しました。 以下では、私達が聴講した中で特に興味深いと感じたセッションについて紹介します！
Don’t Make This Mistake: Painful Learnings of Applying AI in Security
Kirill Efimov 氏および Eitan Worcel 氏による本発表では、ここ数年で大きな盛り上がりを見せている AI (とりわけ LLM) をプロダクト開発における脆弱性修正の自動化に向けて活用する際の落とし穴や有効なアプローチが紹介されました。
本発表でははじめに、脆弱性が存在する実装を自動的に修正する際の目標について以下の通り定義されていました。
- Minimize MTTR: 修正までの時間を最小化すること
- Fix at Scale: プロダクトやコードベースの規模が大きくなってもスケールする仕組みであること
また、発表の導入において、今日の LLM は「a タグの href 属性にユーザーから入力された javascript: スキームの値がそのまま出力されないようにする」といった比較的単純な修正タスクであっても想定通り実施できないことがあるというケースについて言及されていました。同発表者が公開している記事 においても、正しく修正されるケースは全体の約30%、本来の機能は維持されているものの脆弱性の修正にはつながっていないものが約20%、そして残りの約50%についてはそもそも実行できなかったり、本来のロジックを破壊していたりするものであることが示唆されています。*1
発表者らは、LLM が実装されたコードの全体的なコンテキストを正しく理解するのが困難であることがこの問題の原因であると考えたうえで、以下のような対策を提案していました。
- 脆弱性ごとにカスタマイズされたプロンプトを用意しておくこと
- 脆弱性を修正するために必要なコンテキストをプロンプト内で過不足なく伝えること
- どのように修正すると良さそうかをプロンプトで伝えること
ただし、このようにプロンプトをチューニングしたとしても、正しく修正されたかどうかを判断するためには (特にセキュリティに詳しい) 人間がレビューをする必要があるため、本来の目標である Fix at Scale が達成できないおそれがあります。そのような状況に対処するため、発表者らは LLM による修正を静的解析ツールや SAST と併用するハイブリッドなアプローチが現時点での最適解であること、そして、何より生成 AI を利用する場合は結果のレビューを必ず行い、その結果を盲目的に使用しないことが重要であると結論付けていました。
Redis or Not: Argo CD & GitOps from an Attacker’s Perspective
Elad Pticha 氏および Oreen Livni 氏による発表で、彼らが発見した Argo CD の脆弱性 (CVE-2024-31989) に関する解説が行われました。
まず、脆弱性調査の対象としてなぜ Argo CD を選択したのかについて、以下のように紹介されていました。
- CNCF Annual Survey などの資料から定量的に Argo CD が広く使われていることが分かったため
- Shodan などでパブリックな Argo CD のインスタンスを探した結果、広く使われていることが分かったため
- Argo CD のようなシステムにはインフラ環境を変更するような強い権限が割り当てられており、攻撃者にとって格好のターゲットであるため
- 攻撃者の視点で重要なのはクラウド環境にあるデータであり、その手前にある GitOps のシステムがターゲットになりやすい、といったような表現もされていました
この脆弱性の概要としては、Argo CD がキャッシュサーバーとして利用している Redis のインスタンスに対して攻撃者が通信ができる場合に、Argo CD が管理する Kubernetes クラスタに任意のマニフェストをデプロイすることができるというものでした。 Argo CD が Kubernetes のマニフェストを Redis に対して読み書きするため、このような挙動が発生するようでした。 Argo CD のコード中にはマニフェストのチェックサムを計算しているような処理が存在していたものの、特に秘密鍵による署名などは行われておらず攻撃者もその値を計算できるものとなっていました。
このような状況下では、攻撃者が制御可能な Pod にノード(ホストマシン)のファイルシステムをマウントするようなマニフェストをデプロイすることが可能です。 この Pod からマウントされたディレクトリにファイル書き込みを行うことにより、ホストマシンに攻撃者の SSH キーを書き込むことが可能となります。 すると攻撃者はこの Kubernetes クラスタのノードに SSH で接続することが可能となり、そこで任意コマンドが実行可能な状態となります。
なお、この発表内容とほぼ同等の内容が以下のブログで解説されています。興味がある方はぜひこちらもご覧ください。
Black Hat USA 2024
Black Hat USA について
Black Hat USA は世界最大級のセキュリティカンファレンスの1つです。カンファレンスでは、以下に示すような様々なコンテンツが提供されています。
- Briefing
- 最新の攻撃手法や脅威アクターの動向等に関する技術的なトピック、及び、サイバーセキュリティに関する法整備や政策、標準化等の動向に関するポリシー系のトピックに関連したプレゼンテーションが提供される。
- Business Hall
- いわゆる企業出展ブースで、世界的に有名なセキュリティベンダーからセキュリティ関連のソリューションを提供するスタートアップ等、様々な企業がブースを出展している。
- Arsenal
- Arsenal は自身が開発した (とりわけオープンソースの) ツールを紹介する場で、開発者はツールのデモを行いながら参加者からの質問に回答したり、議論したりできる。
- Training
- その名の通りセキュリティに関する様々なトピック (マルウェア、ハードウェアセキュリティ、Webアプリケーションセキュリティ、DFIR 等々) に関するトレーニングや講義が提供される。
- Merchandise
- Black Hat 関連のグッズが購入できるブースで、ロゴ入りのアパレルやステッカーが販売される。
以下では、私達が聴講した中で特に興味深いと感じたセッションについて紹介します！
Gotta Cache Em All: Bending the Rules of Web Cache Exploitation
PortSwigger 社の Martin Doyhenard 氏による本発表では、近年主要な攻撃ベクターとなっている Web cache を利用した攻撃について、各種 CDN や Web アプリケーションサーバー、アプリケーションフレームワークにおける URL パーサーの解釈の不一致を利用した新たな攻撃手法が紹介されていました。
まず、Web cache は、大雑把に言えばある Cache key をあるコンテンツに対応付けて一時的に保存するものです。近年では、多くの Web アプリケーションがオリジンサーバにおけるトラフィックや負荷の低減のために CDN を利用しており、CDN ではリクエストされたリソースのパスや Host ヘッダー等の値に基づいてコンテンツをキャッシュすることが一般的です。
この Web cache を用いた攻撃テクニックとして代表的なものに Web Cache Poisoning と Web Cache Deception があります。 このうち、前者の Web Cache Poisoning は「不正な値 (例: XSS のペイロード) を含むコンテンツをキャッシュさせ、ユーザーに配信させること」を指し、後者の Web Cache Deception は「機密情報を含むレスポンス (例: 個人情報、トークン等) を何らかの方法でキャッシュさせることで、攻撃者がそれを読み取れるようにすること」を指していますが、根本的にはどちらの手法も「キャッシュサーバとオリジンサーバにおいてリクエストに関する解釈が異なること」に基づいています。
本発表では、このような解釈差分のパターンを体系化したうえで、それを用いて Web cache に関する脆弱性を検証する際のテクニックについて詳細に説明していました。
たとえば、URL パーサーにおいて発生するパスに関する解釈差分について、以下の2つの観点について検討していました。
- delimiter の解釈差分
$や#などの特殊文字をパスの delimiter (区切り文字) として解釈するかどうか
- パスの正規化に伴う解釈差分
- URL エンコードされたパスを解釈する際にデコードするかどうか
- ドットセグメント (
..) が含まれたパスを解釈する際に正規化するかどうか
たとえば、以下のような構成に基づくアプリケーションがあったとします。
- キャッシュサーバ
$を delimiter として解釈しない- リクエストのパスが
.cssで終端する場合、対応するレスポンスを無条件にキャッシュする
- オリジンサーバ
$を delimiter として解釈する- ログイン済みの状態で
/myAccountにアクセスすると、個人情報を含んだ自身に関する情報がレスポンスされる
このような構成のアプリケーションに対して /myAccount$static.css というパスを対象としたリクエストを送信すると、オリジンサーバはこれを /myAccount というパスに対するリクエストと解釈する一方、キャッシュサーバはパスが .css で終端する当該リクエストに対するレスポンスをキャッシュ可能なものとして解釈するため、あるユーザーがこのようなパスに誘導されると Web Cache Deception につながります。
本発表ではこのような Cache Key Confusion を検出するための手法に加え、static (と解釈される) なコンテンツの拡張子やディレクトリを活用した Deception の手法や、Cache Key Confusion, Cache Poisoning, Open Redirect 等のテクニックを組み合わせた XSS など、興味深い様々な手法、洞察が提供されていました。
本セッションの paper は以下のページにて公開されているので、興味がある方はぜひこちらを一読されることをオススメします！
Self-Hosted GitHub CI/CD Runners: Continuous Integration, Continuous Destruction
Adnan Khan 氏と John Stawinski 氏により、 GitHub Actions の self-hosted runner に対する攻撃手法についての発表がありました。
本発表は、まず self-hosted runner のセキュリティにおける体系的な認識が無く攻撃がコミュニティに知られていないこと、これらに対する攻撃が容易であるということの主張から始まりました。 その後、managed runner と self-hosted runner には以下のような違いがあることが説明されました。
- 管理者の違い
- managed runner は GitHub が責任を持ち管理、アップデートを行う
- self-hosted runner はユーザーが責任を持ってアップデートを行う必要がある
- エフェメラルか否か
- managed runner は常にエフェメラル
- self-hosted runner はデフォルトでエフェメラルではない
- つまり、一度攻撃が成功したらそれを永続化することが容易
- パブリックリポジトリにおける self-hosted runner では約半数がエフェメラルでないという調査結果も報告された
self-hosted runner はこのような特徴を持つことから managed runner と比較して潜在的にリスクが大きいものと考えられます。
こうした前提が説明された上で、この発表ではパブリックリポジトリの self-hosted runner を悪用するケーススタディが3つほど紹介されました。 ここでは、そのうちの1つである actions/runner-images の事例について概要を解説します。
この事例では、攻撃者*2はまず適当なtypoを修正するプルリクを作成してそれをメンテナーにマージしてもらいました。 GitHub リポジトリのデフォルト設定では、初めてプルリクを作成したアカウントは許可がないと GitHub Actions のワークフローが実行できません。 しかし、何かしらのプルリクをマージされたことのあるアカウントは、次回移行のプルリクでは許可を求めずにワークフローの実行が可能です。
その後、攻撃者はこのリポジトリをフォークして、あるワークフローファイルを書き換えました。 このフォークからプルリクを作ると、書き換えられたワークフローが被害者側の self-hosted runner で動作するため、この時点で self-hosted runner 上で任意のコマンドが実行できることになります。 ここで使うペイロードは攻撃者が所有する C2 サーバーならぬ C2 リポジトリに紐づいた self-hosted runner をインストールするものとなります。
つまり、被害者の self-hosted runner 上に攻撃者の self-hosted runner をインストールします。これはややこしい話ですが攻撃側の目線では次 のようなメリットがあります。
まず、直接的にワークフローを利用して任意コマンドを実行する代わりに C2 サーバーに相当する仕組みを利用することにより、被害者のリポジトリに GitHub Actions のログとして攻撃の履歴が残る機会を減らせると考えられます。
そして、被害者の self-hosted runner が動作しているネットワーク環境で攻撃者の C2 サーバーと通信できるとは限りませんが、 self-hosted runner が行う通信が許可されていることは分かっているため、 C2 のシステムを安定して動かせることになります。
これ以降、攻撃者は C2 リポジトリ(プライベートリポジトリ)に git push をしたり workflow_dispatch trigger を使ったりすることにより、self-hosted runner 経由で任意コマンド実行が可能となります。 攻撃者はこうして獲得した環境を用いて self-hosted runner が動作するマシンの調査を行い、 所有者がGitHubの従業員であると思われるPATを盗み出すことなどができたとしています。
なお、この事例に関しては発表者の一人である Adnan Khan 氏のブログでも解説されているため、興味がある方はぜひご覧ください。
また、この発表で用いられたスライドは以下で公開されているため、興味がある方はこちらもぜひご覧ください。
Slides for John Stawinski and I’s #BlackHat2024 talk are up! Learn about how an external pull-request could have disclosed Intel Corporation’s intellectual property including upcoming CPU designs.https://t.co/AyUBMspgy3
— Adnan Khan (@adnanthekhan) 2024年8月8日
DEF CON 32
DEF CON について
DEF CON も Black Hat と同じく世界最大級のセキュリティカンファレンスの1つで、例年 Black Hat USA の直後に開催されます。 DEF CON では “Village” と呼ばれる特定のトピックに着目した多数のグループが各々独自のプレゼンテーションや CTF、ワークショップなどを開催しており、参加者は興味のある Village を自由に訪れてイベントに参加することができます。本年度の全ての Village は https://forum.defcon.org/node/248125 にて公開されています。
以下では、私達が DEF CON で参加した Village やセッションについて紹介します！
Tsubasa: Bug Bounty Village と AppSec Village
Tsubasa です。私は DEF CON 期間中、主に Bug Bounty Village と AppSec Village を行ったり来たりしつつ、セッションを聴講したり CTF に参加したりしていました。どちらの Village も非常に人気で、特に興味深そうなセッションやワークショップの時間帯には部屋の外まで行列が伸びており、中には時間内に参加できないこともありました......。
中でも特に注力していたのは AppSec Village で3日間に渡って開催されていた Fix the Flag Wargame という CTF です。本 CTF は一般的なアプリケーションやサーバを攻撃してフラグを取得するといった形式ではなく、与えられた脆弱なアプリケーションに対して脆弱性を修正するようなパッチを適切に実装することができればクリアという形式のものでした (弊社が提供している KENRO の堅牢化演習と同じような形式です)。また、他のプレイヤーが提出した修正済みの実装が稼働しているサーバを攻撃するという Attack & Defense 形式の問題もありました。
出題範囲は幅広く、反射型 XSS の脆弱性が存在する Web アプリケーションにエスケープ処理を追加するといった単純なものから、脆弱なパスワードが設定できないようにするためにパスワード要件のバリデーション処理を実装する問題、GraphQL API に存在する DoS 脆弱性を修正する問題など、複雑なものも出題されていました (実装言語も幅広く、覚えているだけでも C, C++, Go, Rego, Python, Solidity などがありました)。
最後はかなりギリギリの勝負にはなりましたが、結果的にはなんとか1位を取ることができました。
ちなみに、本 CTF を開催するにあたって利用されていたプラットフォーム SecDim ではこのような問題をいつでも解くことができるようです。興味がある方はぜひアクセスしてみてください！
lambdasawa: SQL Injection Isn't Dead: Smuggling Queries at the Protocol Level
こんにちは。lambdasawaです。私は主に Bug Bounty Village に参加していたのですが、 Bug Bounty Village のスキマ時間にフラッと立ち寄った「SQL Injection Isn't Dead: Smuggling Queries at the Protocol Level」というトークが思いのほか興味深いものであると感じたため、こちらの概要について共有します。
SonarSource 社の Paul Gerste 氏による本発表では、データベースドライバを悪用した SQL インジェクション手法が紹介されました。
従来の SQL インジェクションといえば、ユーザー入力として「' OR 1=1 --」といった文字列を入れると、クエリが文法的に意図しない構造になり問題が発生するようなものでした。 しかし、本発表はクエリの文法に関する攻撃ではなく、データベースが持つプロトコルの仕様とデータベースドライバの実装に着目したものとなっています。
例えば PostgreSQL で扱われるバイナリプロトコルでは以下のようなフィールドを持ったメッセージが用いられます。
- type: 1バイト。メッセージのタイプを表す。
- length: 4バイト。後続の値の長さを表す。
- value: 可変長。クエリ本文などを表す。
このような構造を持ったメッセージで length が表しうるサイズ(約4GB)より大きい value を扱う際、ドライバの実装によっては length の overflow や truncate が発生することがあります。 するとドライバは length より大きいサイズの value を送信することになります。 しかし、データベースはそのような事情は知らないので素直に truncate された length に従って value を読み取りますが、こうなると value の後半は読み取られずに余った状態になります。 この余った value がまた別の type、length、value と解釈できる時に、本来送られるべきメッセージとは別のメッセージが密輸 (smuggling) されたことになります。
この攻撃は従来の SQL インジェクションにおける stacked query のように攻撃者が1つの statement を丸ごと制御できるという強力さがあります。 そのため、データベースに対して任意の書き込み、更新、削除などの操作が可能です。 一方、攻撃者がデータの窃取をしようとしてもアプリケーションは先頭のクエリの結果しか読み取らないため、そのような観点では特筆して強力になるわけではありません。
この発表では実際に脆弱だったライブラリとアプリケーションの紹介も行われており、理論的なものではなく実践的なものであることも示されていました。
更に MongoDB のドライバでも類似の smuggling が可能であったとも発表されており、PostgreSQL に限定した問題ではなくいわゆる NoSQL やその他のDBMSでも同様の問題が発生しうると考えられます。
しかし、この攻撃にはいくつかの制限があり万能ではないことも説明されていました。
- 4GB の巨大なデータを送る必要があるため、DoS になってしまう可能性がありブラックボックスで安全に検出することが難しい
- 4GB の巨大なデータを送る際、アプリケーションやリバースプロキシの各種サイズ制限に達してリクエストが拒否される可能性がある
- なお、一部のエンドポイントだけ例外的に制限がされていないケース、サーバーサイドで文字列を生成するケースなどではこれをバイパスできる可能性がある
- 言語処理系によっては文字列、バッファが 4GB を超えるサイズのデータを扱えないことがある
- Java では文字列、バッファのどちらも 4GB を超えられない
- C## と JavaScript ではバッファは 4GB を超えられるが文字列 は 4GB を超えられない
なお、本発表に用いられたスライドは以下で公開されています。カラフルな図を参照すると smuggling の仕組みが分かりやすいため、ぜひこちらもご覧ください！
Osaki: Practical Exploitation of DoS in Bug Bounty
Don't miss "Practical Exploitation of DoS in Bug Bounty" by Roni Carta (@0xlupin)! 📅 Friday, Aug 9 ⏰ 10 AM 📍 Creator Stage 4 #BugBounty #DEFCON pic.twitter.com/OMSWTtpIyL
— Bug Bounty Village (@BugBountyDEFCON) 2024年7月23日
Osakiです。自分が聴講した、Bug Bounty Villageの上記セッションではBug BountyにおけるDoS脆弱性の特定と悪用のテクニックを取り上げていました。
DoS攻撃とは？
DoS攻撃は、サーバーやネットワークに過剰な負荷をかけ、正規のユーザーがサービスを利用できないようにする攻撃です。複数のマシンから同時に攻撃を行い、リソースを枯渇させます。これにより、ウェブサイトのダウンやサービスの著しい遅延が引き起こされ、企業にとっては大きなリスクとなります。
発表では、以下のようなテクニックが紹介されていました
1. n+1問題の悪用
n+1問題とは、バックエンドシステムで1つのリクエストに対して、複数のサブリクエストが連鎖的に発生する問題です。例えば、あるリクエストがユーザーのリストを取得し、その各ユーザーごとに別のデータ（例えば投稿やプロフィール情報）を取得する場合、それぞれのユーザーごとに追加のクエリが実行されます。このクエリがリクエストのたびに発生するため、データ数が多いと、結果的に数千、数万ものデータベースクエリが発行されることになります。
悪用の手法: まず発表者は、このn+1問題が発生するAPIやエンドポイントを特定します。 次に、そのエンドポイントに大量のリクエストを送信し、特にリソースを多く消費するクエリを利用します。 すると各リクエストが大量のデータベースクエリを引き起こすため、サーバーのリソースを一気に消耗させます。 結果的に、サーバーが処理能力を超え、システム全体をダウンさせることができました。
この攻撃の報告によって、数万ドルの報奨金を得ることができたそうです。n+1問題は一般的な問題ですが、これが攻撃の対象となるとシステム全体に重大な影響を与える可能性があるため、設計段階から注意を払う必要があります。
2. GraphQLのディレクティブの悪用
GraphQLディレクティブは、GraphQLスキーマの一部にメタデータや追加の動作を付与するための機能です。ディレクティブを使用することで、クエリやフィールドに対してフィルタリングや認証などの特定の処理を柔軟に適用でき、システムの拡張性を高めることができます。
紹介された脆弱性事例では、リクエスト内に含まれるディレクティブに署名が付与されており、署名とクエリ内容が一致しない場合にエラーが発生する実装でした。しかし、署名付きのディレクティブを複数送信すると、サーバーはそれぞれの署名を検証する実装だったため、大量に署名つきのディレクティブを送信することで検証処理に過度な負荷がかかり、最終的にはDoS攻撃が可能になりました。この脆弱性により、発表者は数千ドルの報奨金を得たそうです。
3. キャッシュポイズニング
Black Hatのセッション紹介でも触れましたが、Webキャッシュポイズニングとは、攻撃者がウェブサーバーとキャッシュの動作を悪用し、他のユーザーに有害なHTTPレスポンスを返すように仕向ける攻撃手法です。
この脆弱性が存在していたサービスでは、キャッシュキーはURLや一部のヘッダーに基づいて生成されていましたが、あるヘッダーがキャッシュキーに含まれていませんでした。
発表者がこのヘッダーを追加してリクエストを送信すると、404エラーページが返されました。本来、このエラーページは、キャッシュされるべきではありません。しかし、キャッシュキーがURLや一部のヘッダーに基づいて生成されていており、追加されたヘッダーが考慮されていなかったため、サーバーはこの404エラーページを正規のリソースとしてキャッシュに保存してしまいました。
その結果、他のユーザーが同じURLにアクセスすると、正しいページの代わりにキャッシュされた404エラーページが返され続ける事態が発生しました。攻撃者はこれにより、サービスを一時的に利用不能にする「キャッシュポイズニング」を行い、結果的に他のユーザーにも影響を与えるDoS攻撃を成功させました。
まとめ
今回の発表を通じて、DoS攻撃の影響度と、それに対する防御の重要性を改めて感じました。特に、GraphQLのような新しい技術が普及する中で、これらの攻撃手法が進化し続けていることを実感しました。
おわりに
本記事では、筆者達が BSides Las Vegas、Black Hat、DEF CON に参加した様子を書きました。本記事をもとに、カンファレンス参加の楽しさや筆者達が実際に聴講した興味深かったセッションの内容、そして Flatt Security の福利厚生である支援制度についてお伝えできたのであれば幸いです。 なお、この場を借りてイベント参加を後押ししてくれた弊社メンバーにも感謝申し上げます。ありがとうございました。
株式会社 Flatt Security では、カンファレンス・セミナー参加支援や、そこで得た知見の検証などを積極的に行っています。もし自分もこのような活動を行いたい、興味がある、という方がいらっしゃったら、ぜひ弊社採用情報ページをご覧ください。
