Chiến dịch tấn công chuỗi cung ứng mã nguồn mở của Triều Tiên và bài học cho cộng đồng phát triển phần mềm

07 tháng 4, 2026·5 phút đọc

Gần đây, các cuộc tấn công chuỗi cung ứng trong mã nguồn mở xuất hiện với kịch bản tinh vi do nhóm hacker Triều Tiên thực hiện. Bài viết phân tích chi tiết cách kẻ tấn công lợi dụng pull request hợp lệ để chèn mã độc, sử dụng blockchain làm nơi lưu trữ payload mã hóa, và nguy cơ ảnh hưởng rộng trong môi trường CI/CD.

Chiến dịch tấn công chuỗi cung ứng mã nguồn mở của Triều Tiên và bài học cho cộng đồng phát triển phần mềm

Chiến dịch tấn công chuỗi cung ứng mã nguồn mở của Triều Tiên và bài học cho cộng đồng phát triển phần mềm

Gần đây, các cuộc tấn công chuỗi cung ứng nhắm tới các thư viện mã nguồn mở như LiteLLM và axios liên tục được phát hiện. Một trường hợp nghiêm trọng là nỗ lực tấn công nhắm vào thư viện xác thực JavaScript phổ biến Better-Auth, được thực hiện bởi nhóm hacker Triều Tiên (DPRK).

Bài viết này tổng hợp từ những phân tích kỹ thuật cho thấy kẻ tấn công đã dùng một pull request (PR) hợp lệ để chèn đoạn mã độc khó phát hiện, tận dụng cơ chế CI/CD và thậm chí sử dụng blockchain làm kho lưu trữ payload. Đây là cảnh báo lớn cho cộng đồng phát triển phần mềm về nguy cơ tấn công chuỗi cung ứng ngày càng tinh vi.

Mở đầu cuộc tấn công: chèn mã độc qua pull request hợp lệ

Điểm đặc biệt nguy hiểm trong cuộc tấn công này là kẻ xấu đã ngụy trang mã độc bên trong một PR hợp lệ do một contributor có quyền trên kho mã nguồn gửi lên. Những PR này mang lại các tính năng thật, nên dễ được duyệt mà không bị nghi ngờ.

Phát hiện cho thấy hơn 30 repository trên GitHub có chứa chuỗi ký hiệu đặc trưng của mã độc này, và số lượng thực tế có thể lên tới hàng trăm hoặc hàng nghìn. Mã độc thường nằm trong các file cấu hình build như next.config.mjs hoặc vue.config.js – nơi các developer ít khi kiểm tra kỹ khi code đã được merge.

Việc để mã độc trong file cấu hình build mang lại hai lợi thế cho hacker:

  • Khó bị phát hiện do thay đổi ít khi xảy ra ở các file cấp root.
  • Nếu PR được phép chạy trong môi trường CI/CD, toàn bộ môi trường này sẽ bị nhiễm và lây lan mã độc.

Phân tích cấu trúc và cơ chế hoạt động của mã độc

Mã độc được viết một cách cực kỳ khó hiểu, minify và mã hóa nhiều lớp để tránh bị phát hiện qua phân tích tĩnh. Mã gồm ba giai đoạn chính:

  • Giai đoạn 1: Mã tải payload tiếp theo từ các node blockchain công khai như TronGrid và AptosLabs thông qua các API được mã hóa động. Đây là bước để "thu thập" payload đang được lưu trữ trên blockchain.

  • Giai đoạn 2: Mã khởi tạo một tiến trình "zombie" chạy ngầm ngay cả sau khi bước build chính kết thúc. Tiến trình này đứng ra tải và chạy mã độc giai đoạn 3 mà không để lại dấu vết.

  • Giai đoạn 3: Một payload JavaScript được mã hóa RC4 dung lượng 91KB, chứa logic điều khiển từ xa (command and control - C2). Payload này thực hiện:

    • Lấy dấu vân tay hệ thống (thu thập thông tin máy chủ như OS, RAM, hostname, biến môi trường).
    • Kết nối với server điều khiển qua Socket.IO để nhận và thực thi các lệnh.
    • Thực thi các lệnh nguy hiểm như chạy shell code, đánh cắp biến môi trường quan trọng (AWS keys, GitHub token, OpenAI API key...), tải payload bổ sung, cài đặt persistence.

Cấu trúc tấn công và tải payloadCấu trúc tấn công và tải payload

Nguy cơ lan rộng trong chuỗi cung ứng và môi trường CI/CD

Một khi máy chủ bị nhiễm, tính nguy hiểm của cuộc tấn công này là tác động dây chuyền:

  • Trong môi trường CI/CD, các pipeline thường chạy với quyền truy cập cao, có thể thao tác nhiều dịch vụ nội bộ và cloud. Việc để tấn công chạy được trong một bước build có thể làm lộ thông tin nhạy cảm như database credentials, AWS admin roles.

  • Mã độc có thể tự lan truyền sang các package khác phụ thuộc do bị chèn vào chuỗi dependency, như vụ việc lịch sử của gói npm event-stream từng xảy ra năm 2018.

Tác giả đã phát triển một công cụ tính toán tác động giả lập dựa trên dữ liệu thị trường để mô phỏng số lượng máy bị nhiễm và nạn nhân thứ phát, cho thấy quy mô có thể lên đến hàng chục ngàn hệ thống.

Blockchain: Kênh lưu trữ mã độc bất khả xóa

Điểm đặc biệt khác biệt của chiến thuật tấn công này là việc payload được lưu trữ mã hóa trên blockchain - một hệ thống phân phối phi tập trung, bất biến và không ai có thể xóa dữ liệu sau khi đã ghi.

Điều này làm cho việc gỡ bỏ hoặc chặn payload trở nên gần như không thể, trái ngược với các tấn công truyền thống dựa vào hạ tầng có thể bị đóng.

Ví dụ, vụ tấn công vào thư viện axios gần đây thất bại do payload được đặt trong GitHub repo nên có thể bị xóa. Nhưng đối với Better-Auth, kẻ tấn công chọn blockchain làm hosting payload, từ đó nâng cao tính bền vững và khó ngăn chặn của chiến dịch.

Lời kết và khuyến nghị

Cuộc tấn công chuỗi cung ứng của nhóm hacker Triều Tiên là lời cảnh báo nghiêm trọng với toàn bộ cộng đồng developer và tổ chức sử dụng mã nguồn mở. Các bước khuyến cáo gồm:

  • Kiểm soát chặt chẽ contributor, rà soát kỹ các PR đặc biệt là những thay đổi ở file cấu hình hệ thống build.

  • Áp dụng các công cụ scan an ninh tự động có khả năng phát hiện mã độc ngụy trang và cảnh báo bảo mật.

  • Giám sát nghiêm ngặt quá trình CI/CD, giới hạn quyền truy cập và phân quyền hợp lý ở pipeline.

  • Tăng cường awareness với tập thể dev, staff về nguy cơ chuỗi cung ứng và mã độc giấu mặt.

Bởi tấn công qua chuỗi cung ứng có khả năng gây thiệt hại lan rộng, việc "đánh trước để được bảo vệ trước" như dịch vụ kiểm thử an ninh tự động của Casco là cần thiết để bảo vệ hệ thống và ứng dụng một cách chủ động.

“Hãy để chúng tôi giúp bạn bị hack trước khi những kẻ xấu làm điều đó.” - Casco


Nguồn tham khảo:

Bài viết được tổng hợp và biên soạn bằng AI từ các nguồn tin tức công nghệ. Nội dung mang tính tham khảo. Xem bài gốc ↗