クラウド環境
GitHub Codespacesの機能がマルウェアの配布に不正使用されるリスク
この記事では、実証実験（POC）として、GitHub Codespacesのリアルタイムコード開発およびコラボレーション機能を調査し、クラウドベースのマルウェア配信の悪用が可能であることを確認しました。これにより、攻撃者は、GitHubの正規アカウントを悪用してマルウェアのファイルサーバを作成することができます。
クラウド型の統合開発環境（IDE：Integrated Development Environment）を提供する「GitHub Codespaces」は、当初一部のユーザのみにプレビュー目的で限定公開されていましたが、2022年11月からは無料で一般公開されています。開発者や企業は本プラットフォームのファイル「dev container」を編集することで、従来の開発作業における難点であったプロジェクトの設定変更を容易に行うことが可能になりました。
トレンドマイクロでは、このクラウド型IDEが提供する各種サービスや機能について調査を行いました。その結果、コードの開発や共同作成を支援する機能「転送ポートのパブリック共有」が攻撃者に不正使用され、正規なGitHubアカウントからマルウェア用ファイルサーバを作成されるという可能性が、懸念事項として挙がりました。不正使用されるサーバは、攻撃用コンテンツ（特にスクリプト、マルウェア、ランサムウェアなど）を配布する場合でも、不正または不審なものとして検知されません。結果として、企業や組織では、これらの事象を無害なものとして見過ごしてしまう可能性があります。
GitHubのWebサイトによると、GitHubを利用する開発者数は9千4百万に及び、その中にはDuoLingoやVantaといった会社の他、GitHub自身も含まれます。今日、各開発者は少なくとも2個のCodespaceインスタンスを無料で作成できます。こうしたCodespacesの知名度や、簡便なビルド手段に基づく広範な用途を踏まえると、開発チームでは脅威をモデル化してテストを実施し、各プロジェクトを適切に保護することが求められます。
GitHub Codespacesの概要
開発者はGitHub Codespacesを用いることで、Webブラウザ上でコードを直接作成、編集、実行することが可能です。その際には、事前に設定済みの仮想マシン（VM：Virtual Machine）上にコンテナベースの開発環境が用意され、そこではJavaScriptやPython、Rubyなどのプロジェクトに必要なツールや依存関係の全てが整備されています。これにより、従来から開発者の時間を奪い、生産性に影響を及ぼしていたローカルIDEの設定作業が大幅に削減され、新規プロジェクトを手早く作成できるようになりました。Codespacesのもう1つの強みは、統一された開発環境を提供しながらも、オンラインのペアプログラミングのように、複数の開発者による共同でのコード作成をリアルタイムで支援できることです。従って、開発者はどの端末からでも同じプロジェクトにアクセスでき、ローカル設定の差異を心配する必要はありません。
GitHub Codespacesには、「VMから転送したポートを共有」する機能があります。開発者はポートの共有法として、「企業または組織内のプライベート共有」および「パブリック共有」を選択できます。プライベート共有の場合、企業や組織のメンバーのみが当該ポートのURLにアクセスできますが、パブリック共有の場合、URLを知っている全ユーザが認証なしで当該ポートのURLにアクセスできます。この機能は、アプリケーションがエンドユーザ側でどのように見えるのかを開発チーム側で検証する際に有用です。一方、GitHub Codespacesが全GitHubユーザ向けに公開されている状況を踏まえると、当該機能がサイバー犯罪者や攻撃者によって不正使用される可能性も懸念されます。
アプリケーションのポートをプライベート共有した場合、ブラウザのクッキー情報に基づく認証が要求されます。しかし、パブリック共有の場合は認証が不要となるため、攻撃者はこの設定を使用して不正なスクリプトやマルウェアをホストする可能性が考えられます。さらに、AzureやAmazon Web Services（AWS）、Google Cloud Platform（GCP)のように、アカウント登録にクレジットカードが必要となる数多くのクラウドサービスプロバイダ（CSP）と比べ、Codespacesの環境はより安価に作成することが可能です。
上述した脅威モデルや不正使用シナリオの仮説を検証するため、今回はPythonベースのHTTPサーバを起動しました。ポート番号を8080として、パブリック共有するように設定しました。この過程で、まずURLが容易に特定され、さらに認証用クッキー情報が使用されていないことが確認されました。
上図の通り、公開されたアプリケーションのドメインURLは下記のような形式を持ちます。
<GitHubのユーザ名>-<codespaceの名前>-<ランダムな識別子>-<共有するポート番号>.preview.app.github.dev
例：https://satoshiav0cad0-urban-space-guide-5pxrp5x5q792v5qg-8080.preview.app.github.dev
GitHub Codespacesのポート転送は多くの場合、HTTPプロトコルによって行われます。一方、開発者は必要に応じて任意のポートにHTTPSプロトコルを指定することも可能です。パブリック共有したポートにHTTPSを指定した場合、そのポートの可視性は自動的にプライベートに変更されます。HTTPS設定されたドメインをVirusTotalなどの脅威インテリジェンスプラットフォーム上で解析しても、不正な処理の報告は見られません。結果として、このドメイン上に置かれた不正なファイルのダウンロードは阻止できない可能性が高まります。
オープンディレクトリの自動作成
以降、GitHub Codespaces上にオープンディレクトリ（ファイルサーバ）を自動構築するスクリプトについて解説します。今回の想定として、攻撃者はこのスクリプトを用いることで、パブリック共有ポートを持つCodespaceを幾度にも渡って繰り返し作成し、それを不正なファイルの配布サーバとして利用することが可能です。
Dev Containerの使用
開発者はdev containersを用いることで、開発環境としての全機能をコンテナ内に格納できます。開発に必要なアプリケーションやツール、ライブラリ、ランタイムはコンテナ内で稼働します。さらに、コンテナの設定情報は、共有と再利用が可能です。こうした特性は、継続的インテグレーションやテストの自動化、機能を完備したコーディング環境の実現に役立ちます。
Visual Studio Codeの拡張機能「Dev Containers」では、Dockerのコンテナを包括的な開発環境として扱うことが可能です。開発者はコンテナ内のフォルダを開く（またはフォルダにマウントする）ことで、その全てにアクセスすることが可能です。今回のシナリオにおいて、攻撃者は下記のようにdev containerを設定します。
上記設定では、プロパティ「forwardPorts」によってポート8000を転送します。また、プロパティ「postStartCommand」によって、コンテナの起動が成功する度にPythonベースのHTTPサーバを稼働させます。コンテナイメージとしては、Microsoft社による「devcontainer」を使用しました。
攻撃者は、「GitHub CLI」によってアクセストークン経由で対象ポートを認証した後、リポジトリ「adititli/adititli」の内容に基づくcodespaceインスタンスを作成します。なお、当該リポジトリ内の「devcontainer.json」には、図5に相当する設定情報が格納されています。codespaceのデプロイ完了後、下記コマンドがGitHub CLIを経由してコンテナ内で実行されます。
上記コマンドによって、先に作成したcodespace内に、不正なファイルがダウンロードされます。次に、再びCLIを使用して共有ポートの可視性を「パブリック」に設定します。以上の手順により、不正なファイルを配備したオープンディレクトリ型Webサーバが自動構築されます。また、当該サーバは100秒後に自動消滅するようにプログラムされています。
今回の分析および概念実証（PoC：Proof of Concept）で用いた「100秒」という持続時間は、変更することも可能です。この遅延処理は通常、スクリプトによって返却されたURLへのアクセス完了後に、当該codespaceを自動削除するために用いられます。
上述のスクリプトにより、攻撃者は自身で管理するGitHub Codespaces上に、パブリック共有ポートを持つWebサーバを簡単かつ迅速に構築し、不正なコンテンツの配布に用いることが可能です。作成される個々のcodespaceには一意の識別子が付与されるため、紐づくサブドメインも一意なものとなり、重複することはありません。こうした性質は、オープンディレクトリのインスタンスを多数構築したい攻撃者にとって、都合の良いものと言えるでしょう。さらに、codespaceは最長で30日間保持することが可能です。従って、同じURLが、不正な目的のために30日間に渡って使われ続けるケースも考えられます。
結論
今回述べたセキュリティ課題は、GitHub Codespacesについて攻撃者側の視点から分析した際に導出されたものです。実際に当該の手口による攻撃が確認されたわけではありません。しかし、これまでにもサイバー犯罪者はCSP提供の無償サービス（free tier）や、サービスとしてのプラットフォーム（PaaS：Platform as a Service）、サービスとしてのソフトウェア（SaaS）を含む数多くのクラウド型サービスを、利益目的またはいたずら目的で不正利用してきました。そうしたサービスの例として、HerokuやGoogle Drive、GitHub Actionsなどが挙げられます。そこで使われた技術自体は新しいものではありません。しかし、攻撃者は暗号資産マイニングを始めとする個々の活動に適した環境を常に模索し続けていることもあり、これまでにも増して数多くのプラットフォームやサービスが狙われる傾向にあります。
今回報告した攻撃シナリオは、特に正規のアカウントとドメインを不正使用する点で異なります。前回報告した「GitHubとNetlify」の事例では、攻撃者がGitHubのディレクトリ内に不正な検体を配備しましたが、そのGitHubのコンテンツデリバリーネットワーク（CDN：Contents Delivery Network）に紐づくIPアドレスは、すでに不正なものと検知されていました。今回述べたPoC（概念実証）に基づくシナリオでは、パブリック共有されたポートに紐づくドメインは一意で重複することもなく、セキュリティツールで事前に不正なものと検知されていない場合が大半を占めるでしょう。攻撃者は、こうしたポートの不正利用を通して、最終的には標的環境への侵入または不正なコンテンツのデプロイといった活動に繋げる可能性が懸念されます。
クラウドサービスは、正規なユーザと攻撃者の双方に利益をもたらします。攻撃者にとっては、攻撃の準備や規模の調整を手早く容易に行える他、GitHub Codespacesのような正規サービスを中継することで、活動を隠蔽して検知を回避できるといった利点が得られます。攻撃者は正規ユーザ同様、CSPが提供する機能やリソースを活用することが可能です。こうした点を踏まえ、開発チームでは、GitHub Codespacesのリスクについて把握し、適切な手段を用いてアカウントやシステムを保護することを推奨します。本プラットフォームによって既知または未知のマルウェアがホストされ、感染や攻撃に不正利用されるような事態を回避するため、ITおよびセキュリティチームでは、下記ベストプラクティスの実施を推奨します。
- 可能であれば、VSCodeの拡張機能やGitHubリポジトリなど、信頼できるコードのみを使用してください。それが難しい場合、使用しているリポジトリの性質を把握した上で、信頼性を確認できないコードを用いる際には十分に注意してください。攻撃者による不正なdevcontainerの設定は、開発環境やシステムに対して被害のリスクをもたらします。
- devcontainerで指定したコンテナイメージの確認と管理を徹底してください。攻撃者はタイポスクワッティングの手段によって有名なコンテナイメージやコンテナレジストリを偽称することが、これまでの手口として確認されています。
- GitHubのパスワードとしては強力で一意なものを使用し、トークンのスコープにも注意してください。攻撃者は既存のGitHubアカウントを侵害し、Codespacesを作成または使用する可能性があります。
- アカウントの安全性を高めるため、二要素認証（2FA：Two Factor Authentication）を有効化してください。シークレットデータや認証情報を公開環境にコミットすることは流出に繋がるため、避けてください。
- GitHub Codespacesの実装法や利用法については、公式ドキュメントに記載のベストプラクティスに従ってください。
参考記事：
Abusing a GitHub Codespaces Feature For Malware Delivery
By: Nitesh Surana, Magno Logan
翻訳：清水 浩平（Core Technology Marketing, Trend Micro™ Research）