Нууц түлхүүр хулгайлах "Gheist" дайралт: Хулгайлагдсан GitHub Token-оор Actions лог руу Secret-үүдийг юүлж эхэлжээ

Үүлэн технологийн аюулгүй байдлын Wiz Research баг сүүлийн 24 цагийн дотор өргөн цар хүрээтэй, автоматжсан шинэ кибер халдлагын тайланг дэлгэлээ. "Gheist" хэмээн нэрлэсэн энэхүү дайралт нь хөгжүүлэгчдийн хулгайлагдсан GitHub токенуудыг (Personal Access Token буюу PAT) зэвсэг болгон ашиглаж, байгууллагуудын хувийн репозиториудад нэвтрэн CI/CD дэд бүтцээр нь дамжуулан үүлэн нууцуудыг (cloud secrets) хулгайлж байна.

Одоогоор 850 гаруй хэрэглэгчийн эрх халдлагад өртөж, 13,500 гаруй сэжигтэй branch үүссэн нь бүртгэгджээ. Хамгийн ноцтой нь энэ тактик гадагшаа холболт (outbound network traffic) огт үүсгэдэггүй тул сүлжээний хамгаалалтын системүүдийг төөрөгдүүлж байна.

Халдлага хэрхэн явагддаг вэ? C2 сервергүй нууц хулгайлалт

Уламжлалт халдлагууд ихэвчлэн хортой скрипт ажиллуулан олж авсан мэдээллээ өөрсдийн Command-and-Control (C2) сервер рүү сүлжээгээр илгээдэг. Гэвч ихэнх байгууллагууд CI/CD орчны сүлжээний урсгалыг сайтар хянадаг тул ийм сэжигтэй хандалт даруй баригддаг билээ. Харин "Gheist"-ийн арын бүлэглэл энэ саадыг тун нарийн аргаар тойрч гарчээ:

1. Token ашиглан нэвтрэх: Халдагчид интернетээс эсвэл бусад халдлагаар олзлогдсон хөгжүүлэгчийн бичих (write) эрхтэй токенийг ашиглан тухайн хэрэглэгчийн хандах боломжтой бүх репозитори руу ханддаг.
2. Хортой салбар үүсгэх: Репозитори бүрд ci-sync- угтвартай, араасаа 6 санамсаргүй үсэг бүхий нэртэй шинэ branch (жишээ нь ci-sync-ab12cd) автоматаар үүсгэдэг.
3. Хортой Workflow Push хийх: Тухайн салбарт .github/workflows/ хавтас үүсгэн sync-check.yml нэртэй GitHub Actions workflow файл нэмнэ.
4. Secret-үүдийг лог руу асгах: Энэ workflow нь GitHub Actions runner дээр ажиллахдаа тухайн репозиторид хадгалагдаж буй Environment Secret, AWS access key, API token зэрэг эмзэг хувьсагчдыг консолын лог руу (stdout/stderr) шууд хэвлэдэг.
5. API-аар татах ба мөрөө баллах: Runner-ийн лог бэлэн болмогц халдагчдын автомат хэрэгсэл GitHub REST API-аар дамжуулан уг лог файлыг татаж авдаг. Энэ хүсэлт нь User-Agent: gheist нэртэй байсан нь кампанит ажлын нэр болох үндэс болжээ. Татаж дуусмагцаа хэдхэн секундийн дотор GitHub Actions workflow run-ийг API ашиглан бүрмөсөн устгаж, ажлын түүхийг цэвэрлэдэг.

Гадагшаа ямар ч сэжигтэй IP хаяг руу хандаагүй, бүх процесс зөвхөн албан ёсны api.github.com дотор өрнөсөн тул энэхүү exfiltration-ийг гаднын сүлжээний хамгаалалтууд анзааралгүй өнгөрчээ.

Яагаад Private репозиториуд онцгой эрсдэлд оров?

GitHub энэ оны долоодугаар сард нээлттэй (public) репозиториудыг хамгаалах үүднээс сэжигтэй workflow-уудыг автоматаар зогсоох (pause) механизмыг нэвтрүүлсэн билээ. Wiz-ийн судлаачдын баталснаар Gheist халдлага Public репозиториуд дээр туршигдах үед GitHub-ийн хамгаалалт амжилттай хааж байжээ.

Гэвч энд том асуудал байна: Энэхүү хамгаалалтын механизм нь хувийн (private) репозиториуд болон GitHub Enterprise Server (GHES) дээр үйлчилдэггүй.

Иймээс байгууллагуудын дотооддоо ашигладаг, код болон үүлэн дэд бүтцийн түлхүүрүүдээ хадгалдаг Private репозиториуд руу халдагчид чөлөөтэй нэвтэрч, workflow-г саадгүй ажиллуулж амжжээ. Wiz-ийн тэмдэглэснээр нэгэн байгууллагын хувьд Actions логноос олдсон AWS түр үнэмлэхийг (credentials) ашиглан халдагчид хэдхэн цагийн дараа AWS Secrets Manager-ийг нэгжиж, мэдээлэл цуглуулж эхэлсэн байна.

Хортой салбарыг (branch) устгах нь хангалтгүй

Хэрэв танай төслийн гишүүний аккаунт дээр ci-sync-****** хэлбэрийн салбар үүссэн байвал зүгээр л тухайн branch-ийг устгаад тайвширч болохгүй.

Нэгэнт workflow ажиллаж дууссан бол танай Secret-үүд аль хэдийн халдагчдын гарт орсон гэсэн үг. Устгасан ч гэсэн түүхийг сэргээх боломжгүй бөгөөд татаж авсан мэдээллийг буцаах аргагүй юм.

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

Энэ төрлийн халдлагаас сэргийлэх, өртсөн эсэхээ шалгахын тулд дараах арга хэмжээнүүдийг нэн даруй авахыг зөвлөж байна:

1. GitHub Audit Log-оо шалгах: Байгууллагынхаа audit log-оос ci-sync- нэртэй branch үүссэн эсэх, мөн gheist User-Agent ашиглан workflow run устгасан API хүсэлт байгаа эсэхийг шүүж үзэх.
2. Токенуудаа цэгцлэх ба Rotate хийх: Хэрэв сэжигтэй үйлдэл олдвол тухайн салбарыг түлхсэн токенийг яаралтай revoke хийж, уг репозитори болон байгууллагын хэмжээнд ашиглагдаж буй бүх AWS key, DB нууц үг, API токенуудыг бүрэн сольж шинэчлэх.
3. Fine-grained PAT ашиглах: Хуучин "Classic" Personal Access Token нь хэрэглэгчийн хандах бүх репозиторид өргөн эрх олгодог аюултай. Зөвхөн шаардлагатай репозитори, тодорхой үйлдэлд зөвшөөрөл өгдөг хугацаатай Fine-grained PAT-ийг хэвшүүлэх.
4. Workflow Permissions-ийг хязгаарлах: Байгууллагын тохиргоо (Organization Settings -> Actions) хэсгээс default workflow permissions-ийг Read repository contents and packages permissions болгож хумих.
5. Environment Secrets & Protected Branches: Чухал Production болон Staging Secret-үүдийг репозиторийн глобал secret болголгүй, заавал "Environment" дотор байршуулж, зөвхөн main эсвэл хамгаалагдсан салбараас review авч байж ажиллахаар тохируулах нь үл таних шинэ салбаруудаас secret уншигдахаас найдвартай сэргийлнэ.

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

---

Эх сурвалж:

• Wiz Research: Gheist: Attempted Scaled Abuse of Stolen GitHub Tokens Stumbles
• The Hacker News: Gheist Uses Stolen GitHub Tokens to Steal Private Repository Secrets via Actions Logs
• Dark Reading: 'Gheist' Weaponizes GitHub Tokens to Steal Cloud Secrets