出典：T.N. Sursock（Shutterstock）
ユーザーが独自のサンドボックス化されたコードを作成・実行できるローコードのクラウドサービスは、SaaS（サービスとしてのソフトウェア）プロバイダーが環境を適切にサンドボックス化せず、非人間IDのロールと権限を管理せず、コードアーティファクト内に誤ってシークレットを露出させた場合、複数ステップのエクスプロイトチェーンによって侵害され、プラットフォーム全体の乗っ取りにつながる可能性がある。
このような侵害は、ローコード自動化サービスのZapierでほぼ現実のものとなるところだった。エージェンティック・アイデンティティセキュリティ企業Token Securityの研究者たちは、同社のプラットフォームを悪用したいくつかの手順を用いることで、Zapierのサンドボックス環境を偵察し、認証情報を発見し、水平移動して同社のプライベートリポジトリを取得できること、さらには悪意のあるコードを公開できた可能性があることを、5月28日に公開された分析レポートで明らかにした。
Token Securityの研究者は、Zapierのリポジトリおよびシステムに認証済みのすべてのユーザーに対して悪意のあるコードをプッシュできた可能性があると、Token Securityの研究チームリードであるYair Balilti氏は述べている。
「Zapierにアカウントを持つユーザーがいれば、そのCookieを取得して攻撃者のウェブサイトに送信できます」と同氏は言う。「同じCookieを使って、そのユーザーがZapierで利用しているすべてのツールを使用できます。たとえば、メールを送信して別のサービスに接続する自動化が設定されていれば、同じ仕組みを利用することができます。」
認証情報、開発用シークレット、非人間IDを使用してクラウドコンポーネント間を横断する能力は、エンタープライズクラウド利用における主要な脆弱性の源泉となっている。ソフトウェアの様々なクラウドサービスへの分散化と、エージェンティックAIスウォームへの急速な移行が進む中、SaaSインフラはより複雑化し、セキュリティの確保が難しくなっている。サイバーセキュリティ研究者はすでに、大多数の企業——実に56%——がSaaS間の接続や統合を追跡するプロセスを持っていないことを指摘している。たとえば昨年、脅威アクターUNC6395は、サードパーティの営業自動化アプリ「Salesloft Drift」に関連するOAuthトークンを悪用して、企業のSalesforceインスタンスからデータを窃取した。
“note — this isn’t a security thing”
自動化サービスをほぼ侵害するところだったToken Securityの5ステップの攻撃チェーンは、コードブロックにコードを書く能力から始まった。Zapierや他の自動化サービスプロバイダーは、ユーザーがカスタムタスクを実行するための独自コードを記述したり、AIエージェントにコードを書かせたりすることを許可している。Code by Zapierは例えば、PythonおよびJavaScriptで顧客のスクリプトやデータ操作コードを記述できるようにしている。
「それはユーザーが独自のロジックを実行できる場所として宣伝されています」とToken SecurityのBalilti氏はオンライン分析の中で述べている。「だから私たちは自分たちのロジックを実行しました。」
研究者たちは独自のコードを使ってサンドボックスのOSに問い合わせを行い、それがAWS Lambda上で動作していることを発見した。明らかに漏洩した認証情報はなかったものの、タスクファイルを読み取る能力により、「allow_nothing_role（何も許可しないロール）」という誤った名称が付けられた過剰な権限を持つロールと、認証情報の安全な削除の失敗が判明した。
そのファイルのコメントには、開発者がこう記述していた：
# note - this isn't a security thing since we pass a allow\_nothing role - just avoids
# responding to dozens of annoying false positive security reports
第2ステップとして、研究者たちはメモリからシークレットを抽出するPythonスクリプトを作成した。これは、AWS Lambdaがコンテナのリサイクルまでトークンやその他のシークレットを積極的に削除しないという事実によって助けられた。そのロールを使用して、研究者たちは攻撃の第3段階でZapierのプライベートリポジトリから1,111個のファイルをリスト化してリクエストできることを発見した。それらのファイルの中に、すべてのパッケージに使用できる公開用NPMトークンが露出しているものを発見した。
クラウド侵害の5段階には、サンドボックスからの脱出、認証情報と過剰権限ロールの発見、そして水平移動が含まれる。出典：Token Security
研究者たちは残り2つのステップを説明したが、実際には実行しなかった。インストール後スクリプトを使えば、正規のZapierパッケージに任意のコードを追加して実行できたはずであり、第5段階では認証済みのすべてのZapierユーザーのブラウザにそのコードを配布できたはずだった。
「攻撃者はZapier内でユーザーとして行動できたでしょう。Zapを作成し、テーブルを作成し、MCPサーバーを作成し、既存の自動化を変更し、Zapierのプラットフォームを通じてサードパーティサービスへのユーザーの既存接続を利用することができたはずです」とBaliltiは分析の中で記述している。「それらの接続はサーバーサイドで実行されます。攻撃者はユーザーのセッションに乗り、Zapierに操作を指示することで、それらを制御できます。」
権限過多、セキュリティ不足
Token Securityは2月に責任ある開示ガイドラインに従ってZapierに通知し、Zapierは1週間以内に問題を修正した。Token Securityはその後、修正が機能していることを確認し、6月1日にfwd:cloudsec North Americaでこの研究を発表する予定である。
企業は自社の自動化プラットフォームとそれがアクセスできるデータにより注意を払い、ロールをできる限り制限することに注力する必要があると、Balilti氏は述べている。
「何らかの自動化プラットフォームを使用する場合、Salesforce、Gmail、Google Driveなどすべての統合に接続されています。そうする際には、可能な限り最小権限のスコープで行うようにしてください」と同氏は言う。「そうすれば、仮にユーザーが侵害されたとしても、読み取り専用または特定のリソースに限定されるだけです。」
権限の問題は深刻だ。たとえば3月には、Salesforceが顧客に対して、ゲストアカウントの権限が緩くなりがちであることを警告し、サイバー犯罪者がソーシャルエンジニアリング攻撃を実施してデータを窃取できるリスクがあると指摘した。
攻撃者はすでに企業のSaaSデプロイメントに対してペネトレーションテストを実施している可能性が高いと、Balilti氏は述べている。
「世界には多くの自動化ワークフロープラットフォームが存在し、そのほとんどにコードブロックに類似した機能があります」と同氏は言う。「おそらく一部の攻撃者が同じアプローチを試みるでしょう。」
