GitHub Actionsの脅威検知ツール tracee-action を触ってみる
はじめに
こんにちは、セキュリティエンジニアのJJ (yuasa)です。今回はGitHub Actionsのワークフローにおける脅威検知ツールであるtracee-actionを触り、検知ルールの書き方について見ていきます。なお、tracee-actionは2024年7月時点で本番環境での利用は想定されていない点にご注意ください。
This project is not production ready. We are experimenting with it to test and demostrate Tracee capabilities.
tracee-action
tracee-actionはTraceeを用いてGitHub Actionsのワークフローにおける脅威を検知します。TraceeはeBPFを用いてLinuxランタイム上でのシステムコールを検出することができるツールです。TraceeをGitHub Actionsで利用することで、例えばワークフローにおいてシークレットの外部送信やランナーの計算リソースの不正利用などが行われた場合にそれらのイベントを検出することができます。
tracee-actionが主に行うのはTraceeをGitHub Actionsのワークフローで利用するためのセットアップです。このようにTraceeの起動処理と終了処理をジョブ内で実行するために利用でき、起動処理と終了処理の間に実行された検知対象のアクティビティを検知し、対象のプルリクエスト内のコメントで通知します。
name: My pipeline
jobs:
my-job:
runs-on: ubuntu-latest
steps:
- name: Start Tracee
uses: aquasecurity/tracee-action@v0.3.0-start
...
- name: Stop Tracee
uses: aquasecurity/tracee-action@v0.3.0-stop
tracee-actionにはGithub Actionsにおける脅威を検知するための検知ルール群は備わっておらず、サンプルの検知ルールがいくつか用意されているのみです(2024年7月時点)。そのため、ユーザー側で検知したい脅威に応じたTraceeの検知ルールを作成する必要があります。
事前準備
tracee-actionの最新版(2024年7月時点でv0.4.0
)はTraceeの最新版(2024年7月時点でv.0.21.0
)に対応していないので、実験用のリポジトリ内でcompositeアクションとして定義します。
以下が本記事を執筆するための実験で用いたリポジトリです。
検知ルールの作成
検知ルールはPolicy、Custom Events+Policyの2パターンの方法で作成することができます。
Policyの作成
参考: https://aquasecurity.github.io/tracee/latest/docs/policies/
Policyではscopeとrulesを指定することで、対象のイベント群がどのスコープで生じたかを検知することができます。scopeにはホスト全体を示すglobal
、実行ユーザーuid
やプロセスのIDpid
などを指定することができます(参考)。rulesにはeventと検知条件を絞るためのfiletersが指定できます。filetersにはscopeを指定するScope Filters(参考)と、各eventが持つ引数であるArgument filter(参考)、返り値を指定するReturn value filter(参考)が利用できます。
以下のPolicyはscopeをglobal
、eventをArgument filterとしてpathname=/tmp/*
を指定したfile_modification
を指定します。ホスト全体で/tmp
以下でのファイル更新を検知します(参考)。
apiVersion: tracee.aquasec.com/v1beta1
kind: Policy
metadata:
name: file-modification
annotations:
description: trace signature events
spec:
scope:
- global
rules:
- event: file_modification
filters:
- args.file_path=/tmp/*
Custom Eventsの作成
参考: https://aquasecurity.github.io/tracee/latest/docs/events/custom/overview/
Custom EventsはTraceeで用意されているBuilt-in Eventsの検知ルールを示すものです。Policyのrulesに指定するfiletersを用いて検知したいイベントを絞り込めない場合に使用できます。例えば、ランナーの計算リソースを暗号通貨のマイニングに不正利用するイベントを検知する際に、ドメインを複数指定し、指定したドメイン中いずれかに一致するDNS問い合わせが行われた場合に検知することができます。
Custom EventsはGoかRegoを使用して記述することができます。以下はRegoを用いて作成された暗号通貨マイニングの検知ルール miner_domain
です。net_packet_dns_request
というBuilt-in Eventを対象とし、DNSの問い合わせでdomains
で指定したドメインのいずれかが指定された場合に検知します(参考)。
package tracee.CUSTOM_MD
import data.tracee.helpers
__rego_metadoc__ := {
"id": "CUSTOM_MD",
"version": "0.1.0",
"name": "miner_domain",
"eventName": "miner_domain",
"description": "Check for commom cryptominers domains access",
}
tracee_selected_events[eventSelector] {
eventSelector := {
"source": "tracee",
"name": "net_packet_dns_request",
}
}
domains := [
"miner1.example.com",
"miner2.example.com",
"miner3.example.com",
]
tracee_match {
input.eventName == "net_packet_dns_request"
dns_questions := helpers.get_tracee_argument("dns_questions")
domains[_] = dns_questions[_].query
}
作成したCustom Event miner_domain
をPolicyで指定すると検知されるようになります。
apiVersion: tracee.aquasec.com/v1beta1
kind: Policy
metadata:
name: miner-domain
annotations:
description: trace miner domain events
spec:
scope:
- global
rules:
- event: miner_domain
検知結果
以下のようなワークフローファイルを作成し、tracee-actionの起動処理と終了処理の間で/tmp
以下へのファイル作成、暗号通貨マイニング(特定ドメインへのDNS
問い合わせ)などの処理を実行します。
name: CI
on:
pull_request:
workflow_dispatch:
jobs:
sample-job:
permissions:
pull-requests: write
contents: write
runs-on: ubuntu-latest
steps:
- name: checkout
uses: actions/checkout@v4
- name: Start Tracee
uses: ./.github/actions/start
- name : Do something
run: |
echo "Doing something"
echo "hoge" > /tmp/hoge
dig miner1.example.com
/bin/bash -c "echo 'hoge'"
- name: Stop Tracee
uses: ./.github/actions/stop
プルリクエストを作成するとワークフローが実行され、対象のイベントが検知されたことがプルリクエストへのコメントで知らされます。
また、ホームディレクト配下の.tracee
ディレクトリに過去の検知結果のログが格納され、プルリクエストのターゲットブランチとの差分が生じた場合にプルリクエストが自動作成されます(元々の実装がTraceeのv0.21.0
を想定した実装になっていなかったので少し修正しました)。
おわりに
本記事では、GitHub Actionsのワークフローにおける脅威検知ツールであるtracee-actionを触ってみました。実際に検知ルールを作成し、ワークフロー内で悪意のあるアクティビティが実行された際にそれらを検知できることを確認しました。今回は実験目的で簡易的なルールのみを実装したため、今後はより実用的な脅威検知のためのルールを作成していきたいです。
Discussion