新しいOctocatコイン：攻撃者はCI/CDコンピューティングの制限をどのように回避するか #aqua #セキュリティ #argon #パイプライン #cicd
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは「Aqua Security」社の技術ブログで2022年3月23日に公開された「 The New Octocat Coin: How Attackers Bypass CI/CD Compute Limits 」の日本語翻訳です。
新しいOctocatコイン：攻撃者はCI/CDコンピューティングの制限をどのように回避するか
ここ数年、攻撃者は計算能力をデジタルコインに簡単に変換できるクリプトマイニングを、すぐ手に入れられる収入源として利用しています。他のサイバー犯罪とは異なり、クリプトマイニングは、比較的無害、可逆的、被害が少ない、すぐに報酬が得られる、と攻撃者に認識されています。昨年、悪質な攻撃者は、パッチの適用されていないサーバへの攻撃から、無料で利用可能なクラウド CI/CD プラットフォームを悪用する方法に切り替わりました。このブログでは、攻撃者がプラットフォーム上で、痕跡を残さずに最大限の利益を得るために使用する技術や戦略をいくつか紹介します。
無料のCI/CDプラットフォームの悪用はどのように行われるか
CI/CD パイプラインのステージが短時間で実行されることを前提としているのとは対照的に、マイニングプロセスは長時間実行されてこそ効果を発揮するものです。そのため、CI/CD プラットフォームでは、最大実行時間や並列処理の制限など、フェイルセーフのための機能が導入されています。これらの機能は、システムを悪用から保護し、技術的なバグによって無限に実行されることがないようにするためのものです。
しかし、悪質な攻撃者は、1つのプラン内で並行して実行する複数のビルドステップを作成することで、これらの制限を引き伸ばします。下のスクリーンショットにあるように、各ジョブは6時間実行されます。これは GitHub が許容する最大の実行時間です。
これらの実行は、以下のワークフローマニフェストによって記述されています。
CI/CDの制限と検出を回避するために使用されるテクニック
さらに調べていくと、いくつかのユニークなパターンが見えてきました。
- 攻撃者は max-parallel を 20 に設定し、この GitHub ドキュメントにあるように、同時実行ジョブを上限まで最適化します。
- Fail-fast は、1つのステップが失敗しても残りが実行されるように false に設定されています。
- 攻撃者は、bash スクリプトと ELF バイナリを実行できるように、Windows subsystem for Linux(WSL)付きの Windows イメージ上で実行することを選びました。これは、プラットフォームを監査し、これらの活動を検出することを困難にするため、別のサンドボックスレイヤーを作成することを意図していたようです。
- この攻撃者は、実際のマイニングのアドレスを隠すために、ショートリンクソリューションとして git.io を使用しました(Ubuntu では ccminer を使用)。このアドレスも GitHub リポジトリに格納されます。繰り返しになりますが、この方法は、ネットワーク遠隔測定監査が行われた場合に、活動を目立たないようにするための方法です。
この攻撃者が達成できる利益を調べるために、ワーカーマシンが現在のハッシュパワーと保留中の報酬を確認できるマイニングプールの組み込み機能を使用して、攻撃者のウォレットの活動を追跡しました(暗号ネットワークによって公開はされてはいませんが)。
以下に見られるように、この攻撃者はまだアクティブなクリプトマイナーを持っています。
合計で287枚のヴェルスコイン(今の相場で約2万円)がしっかりと報酬として提供されるのです。
GitHub Actionsに対するさらなる回避策
別のキャンペーンでは、gradient.run と GitHub Actions をターゲットとして、攻撃者は、既知のダイナミックリンカハイジャック技術によってマイニングプロセスを隠すことを目的とした node-process-hider という NPM パッケージをインストールしています。
ビルドジョブの準備の一環として、ノードモジュールをインストールすることは一般的でよくあることです。しかし、攻撃者は、プラットフォームプロバイダーによって制限または監査される可能性のある疑わしいドメインからのバイナリのドロップを避けるために、これを使用しました。また、クリプトマイナー自体は別の GitHub リポジトリに格納されており、これも検知される可能性を低くしています。
この攻撃者は、同じリポジトリをフォークし複製することで、複数の GitHub アカウントを同時に操作しているようです。アカウントやリポジトリごとのノイズを減らし、一部が BAN された場合のバックアップを取ることが目的だと考えられます。
CI/CDの乱用がもたらすリスク
攻撃者は、安全でない CI/CD プラットフォームを悪用する方法を常に探し求めています。これは、複数のリスクにつながる可能性があります。
- 経済的損失：攻撃者がコンピュートリソースを消費することで、計算トークンを使い果たし、その結果、大きな収益損失をもたらす可能性があります。
- サービス妨害(DoS)：すべてのビルドリソースがクリプトマイニングに占拠されると、正規の CI/CD 実行のために利用できなくなります。これは、ある種の DoS であり、開発チームの速度を低下させる可能性があります。
- ビジネスクリティカルな資産の侵害：CI/CD 環境を足がかりに、攻撃者はよりリスクの高い資産、例えばメルセデスの事案のようにソースコードに狙いを定める可能性があります。また、Travis CI と spell-check.js の事件のように、CI/CD 環境に保存されているシークレット情報を利用して、アーティファクトリポジトリ、データベース、Kubernetes クラスター、 API への侵入が可能です 。
CI/CD プラットフォームをクリプトマイニングから保護する方法
良いニュースは、主要な CI プロバイダーのほとんどが、すでに無料サービスの乱用を認識しており、そのような行為を防止しブロックしようとしていることです。例えば、GitHub はフォークされたプルリクエストの実行方法を厳しくし、GitLab はより強力な認証を要求し、Azure DevOps は無償の計算リソース提供を停止し、CircleCI は違反したアカウントを禁止しています。しかし、これまで見てきたように、攻撃者は依然としてこれらの制限を乗り越えてくるでしょう。
そのため、安全なソフトウェアサプライチェーンスタックを一貫して実行し、異常がないかどうかを監査することが非常に重要です。これにより、攻撃対象が劇的に減少し、問題を早期に発見できます。
ここでは、セキュリティを向上させるためのベストプラクティスをいくつか紹介します。
CI/CD プラットフォームにおける許可された権限と誤った設定の修正
- 全ユーザに2要素認証を強制する
- 許可制のアクセスでユーザを制限する
- ブランチ保護の制限
- フォークされたプルリクエストの CI 上での実行を制限する
- CI ランナートークンを許可制にする
既知の脆弱性の修正
- オープンソースの依存関係やアーティファクトに含まれる既知の CVE を発見し、修正できます。脆弱性をスキャンするには、オープンソースのスキャナである Trivy を使用できます。
- オンプレミスのソースコード管理ソリューションを使用している場合は、GitLab が最近発表したものなど、最新のセキュリティバージョンを実行するようにしてください。
また、Argon Security のソリューションもご覧ください。Argon は、CI/CD パイプラインの各ステージにクラス最高のセキュリティを提供し、安全のためにスピードを妥協することなく、最大のアウトプットを確保します。
