Bên trong chiến dịch Atomic Arch: Cách 1.900 gói AUR bị biến thành vũ khí

Trang chiến dịch của SafeDep và các danh sách do cộng đồng tổng hợp cuối cùng đã liệt kê 1.937 tên gói AUR bị ảnh hưởng, nhấn mạnh phạm vi tiếp cận khổng lồ của cuộc tấn công . Điều quan trọng cần lưu ý là các kho lưu trữ chính thức của Arch Linux (core, extra, community) không bị ảnh hưởng — đây hoàn toàn là một sự cố của riêng AUR .

Phương thức tấn công: Khai thác quy trình dựa trên lòng tin

Atomic Arch không phải là một vụ xâm phạm vào hạ tầng của Arch. Thay vào đó, nó là một sự khai thác có tính toán vào quy trình nhận nuôi gói mồ côi của AUR, một quy trình cho phép bất kỳ thành viên nào trong cộng đồng yêu cầu quyền sở hữu các gói bị bỏ rơi .

Cuộc tấn công diễn ra trong hai đợt riêng biệt, với thủ phạm liên tục tinh chỉnh cách tiếp cận để tránh bị phát hiện.

Đợt 1: Móc câu npm (Ngày 11 tháng 6)

Những kẻ tấn công đã nhận nuôi một cách có hệ thống các gói mồ côi. Khi đã có được đặc quyền của người bảo trì, chúng không thay đổi mã nguồn phần mềm gốc — một động thái sẽ làm hỏng checksum và kích hoạt cảnh báo. Thay vào đó, chúng sửa đổi các tập lệnh xây dựng PKGBUILD để tiêm vào các gói phụ thuộc npm độc hại: atomic-lockfile (v1.4.2) và js-digest (v4.2.2) . Các gói này được cấu hình để tự động thực thi trong quá trình makepkg. Để che giấu hoạt động độc hại hơn nữa, mã nguồn được nhúng vào các tập lệnh .install và ngụy trang bằng cách sử dụng kỹ thuật tách chuỗi shell, trích dẫn hỗn hợp và mã hóa thập lục phân .

Đợt 2: Chuyển sang Bun (Ngày 12 tháng 6)

Chỉ một ngày sau, một đợt tấn công thứ hai xuất hiện. Lần này, kẻ tấn công thay thế đường dẫn cài đặt npm bằng quy trình cài đặt dựa trên Bun, sử dụng một gói độc hại khác có tên là lockfile-js (v1.4.2) . Sự thay đổi này làm phức tạp thêm việc phát hiện, vì nhiều IoC (Chỉ báo thỏa hiệp) ban đầu tập trung vào kho npm và các công cụ bảo mật phải được cập nhật để giám sát môi trời gian chạy và gói phụ thuộc mới này .

Bằng cách chỉ đầu độc các hướng dẫn xây dựng thay vì chính phần mềm, kẻ tấn công đã vượt qua các kiểm tra tính toàn vẹn truyền thống. Mã nguồn gốc có vẻ sạch sẽ, và phần mềm độc hại chỉ được tải về và thực thi tại thời điểm xây dựng, khiến nó trở nên vô hình đối với những người dùng không kiểm tra thủ công các tập lệnh PKGBUILD .

Tải trọng độc hại: Mã đánh cắp và Rootkit

Các máy đã xây dựng các gói bị thỏa hiệp sẽ nhận được một tải trọng hai giai đoạn được thiết kế cho mục đích gián điệp và duy trì sự tồn tại.

• Mã đánh cắp thông tin viết bằng Rust: Một tệp nhị phân tập trung vào việc thu thập các bí mật của nhà phát triển, bao gồm phiên trình duyệt, khóa SSH, mã thông báo GitHub, mã thông báo npm, phiên Slack/Teams, mã thông báo Vault, thông tin xác thực Docker/Podman và khóa truy cập đám mây .
• Rootkit eBPF (Chỉ chạy với quyền Root): Nếu gói được xây dựng với đặc quyền root, phần mềm độc hại sẽ triển khai một rootkit eBPF có khả năng ẩn các tệp, tiến trình và hoạt động mạng của chính nó khỏi các công cụ phát hiện tiêu chuẩn như ps và htop. Rootkit này sử dụng /sys/fs/bpf/ để duy trì sự tồn tại, khiến việc loại bỏ nó trở nên cực kỳ khó khăn .

Sự kết hợp giữa mã đánh cắp thông tin và rootkit cấp nhân khiến đây trở thành một mối đe dọa nghiêm trọng, đặc biệt đối với các nhà phát triển — những người mà máy trạm của họ thường chứa các khóa truy cập đặc quyền và dữ liệu nhạy cảm.

Phản ứng của Cộng đồng và Nhà phát triển

Cộng đồng Arch Linux và ngành bảo mật đã phản ứng nhanh chóng, nhưng nỗ lực khắc phục trở nên phức tạp do quy mô của cuộc tấn công.

• Hành động từ Nhóm Arch: Các cộng tác viên của Arch đã mở một chủ đề báo cáo tổng hợp trên AUR vào ngày 11 tháng 6 và bắt đầu quá trình hoàn nguyên các commit độc hại, cấm các tài khoản của kẻ tấn công, và dọn dẹp nhóm các gói mồ côi. Arch Linux cũng đã tạm ngưng đăng ký tài khoản mới trên AUR vào thứ Hai tuần kế tiếp để ngăn chặn các hành vi lạm dụng tiếp theo . Người đóng gói của Arch, Jonathan Grotelüschen, xác nhận nhóm đang làm việc để "khôi phục hoặc xóa tất cả các commit độc hại và cấm các tài khoản chịu trách nhiệm" .
• Tranh cãi trong Cộng đồng: Cuộc tấn công đã gây ra tranh luận gay gắt. Các cuộc thảo luận sôi nổi trên các nền tảng như diễn đàn PrivacyGuides ghi nhận một số thành viên kêu gọi đóng cửa AUR hoàn toàn, lập luận rằng mô hình dựa trên lòng tin của nó đã bị phá vỡ về cơ bản ở quy mô thỏa hiệp này .
• Phản ứng từ Bên thứ Ba: Các công ty bảo mật bao gồm Sonatype, Corgea, Cloud Security Alliance (CSA), và TrueSec đã công bố các phân tích chi tiết, Chỉ báo thỏa hiệp (IoCs), và các tập lệnh phát hiện của cộng đồng (chẳng hạn như aur-malware-check) để giúp người dùng tự kiểm tra hệ thống của họ .

Một nguồn gốc của sự bất đồng là việc nhóm Arch chính thức đã không ngay lập tức công bố một danh sách duy nhất, chuẩn tắc về tất cả các gói bị ảnh hưởng, khiến người dùng phải dựa vào các bản kê từ bên thứ ba như của SafeDep và Corgea .

Bài học cho Hệ sinh thái Linux

Vụ tấn công Atomic Arch phơi bày những điểm yếu mang tính cấu trúc trong các kho lưu trữ cộng đồng dựa trên lòng tin vốn dựa vào sự bảo trì tình nguyện.

• Cạm bẫy gói mồ côi là một rủi ro hệ thống: Khả năng bất kỳ người dùng nào cũng có thể ngay lập tức nhận nuôi và sửa đổi một gói bị bỏ rơi mà không cần xác minh danh tính hay rà soát mã bắt buộc đã biến một tính năng tiện lợi thành một vectơ tấn công có tác động cao .
• Tiêm nhiễm tại thời điểm xây dựng vượt qua kiểm tra tính toàn vẹn: Các cơ chế phòng vệ truyền thống dựa vào việc xác minh tính toàn vẹn của các tarball mã nguồn. Vì Atomic Arch đã đầu độc các tập lệnh xây dựng thay vì mã nguồn, các checksum tiêu chuẩn không cung cấp sự bảo vệ nào .
• Chuỗi cung ứng xuyên hệ sinh thái là biên giới mới: Cuộc tấn công đã vũ khí hóa các kho lưu trữ npm và Bun để phát tán phần mềm độc hại vào hệ sinh thái Linux, chứng minh rằng một gói bị thỏa hiệp duy nhất trong một kho lưu trữ có thể gây ra hiệu ứng dây chuyền xuyên suốt các nền tảng .

Người dùng bị ảnh hưởng phải làm gì ngay bây giờ

Hướng dẫn từ các nhà nghiên cứu bảo mật và cộng đồng Arch là thống nhất: đây không phải là trường hợp chỉ cần gỡ bỏ một gói đơn lẻ là đủ.

1. Mặc định là đã bị xâm nhập hoàn toàn: Hãy coi bất kỳ máy chủ nào đã xây dựng hoặc cập nhật một gói AUR trong khoảng thời gian từ ngày 9 đến ngày 12 tháng 6 năm 2026 là đã bị thỏa hiệp hoàn toàn .
2. Cài đặt lại từ phương tiện sạch: Một cuộc quét phần mềm độc hại đơn giản là không đáng tin cậy vì rootkit eBPF được thiết kế để ẩn mình khỏi các công cụ phát hiện. Biện pháp khắc phục duy nhất được đảm bảo là xây dựng lại hệ thống bị ảnh hưởng từ phương tiện cài đặt đáng tin cậy .
3. Xoay vòng tất cả thông tin xác thực ngay lập tức: Mặc định rằng mã đánh cắp thông tin đã lấy cắp mọi bí mật có thể truy cập được trên máy: khóa SSH, mã thông báo GitHub và npm, mã thông báo Vault, khóa truy cập đám mây, phiên trình duyệt và thông tin xác thực Docker/Podman .
4. Rà soát lịch sử AUR: Chạy lệnh

   pacman -Qm

   để liệt kê tất cả các gói ngoại lai được cài đặt trên hệ thống và đối chiếu chúng với các bản kê gói độc hại do cộng đồng công bố .
5. Kiểm tra các chỉ báo thỏa hiệp: Tìm kiếm dấu vết của atomic-lockfile, lockfile-js, hoặc js-digest trong bộ nhớ đệm xây dựng, cũng như các mục đáng ngờ trong /sys/fs/bpf/ .
6. Coi đây là một sự kiện ứng phó sự cố: Các tổ chức không nên xem đây là một bài tập quét đơn giản. Bất kỳ máy trạm của nhà phát triển Arch hoặc máy chủ CI/build nào đã lấy dữ liệu từ AUR trong khoảng thời gian bị tấn công đều nên được coi là một sự cố bảo mật yêu cầu phản ứng đầy đủ .