Tổng quan

Bảo mật chuỗi cung ứng phần mềm đề cập đến việc bảo vệ toàn bộ quy trình phát triển, phân phối và triển khai phần mềm khỏi các hành vi xâm nhập hoặc sửa đổi trái phép. Thay vì tấn công trực tiếp vào sản phẩm cuối, kẻ tấn công có thể nhắm vào các thành phần trung gian – như thư viện mã nguồn mở, công cụ build, hoặc tài khoản của nhà phát triển – để chèn mã độc. Những cuộc tấn công kiểu này ngày càng gia tăng về quy mô và mức độ nghiêm trọng; theo dự báo của Gartner, 45% tổ chức toàn cầu có thể sẽ trải qua một cuộc tấn công chuỗi cung ứng phần mềm trước năm 2025, gấp ba lần so với năm 2021 [1]. Một ví dụ điển hình là vụ SolarWinds 2020, khi mã độc được cài vào bản cập nhật phần mềm quản trị mạng, lây nhiễm hàng chục nghìn khách hàng trên toàn cầu [2]. Mặc dù phần mềm nguồn mở thường được xem là an toàn hơn (do có nhiều người cùng xem xét mã), thực tế nhiều dự án nguồn mở thiếu nguồn lực để rà soát bảo mật một cách đầy đủ [2]. Điều này tạo kẽ hở cho kẻ xấu lợi dụng, biến các thành phần đáng tin cậy trong chuỗi cung ứng phần mềm thành “mắt xích yếu” để tấn công vào hệ thống của người dùng cuối.

Những vấn đề phổ biến trong bảo mật chuỗi cung ứng phần mềm

• Thao túng quyền truy cập của maintainer (người bảo trì dự án): Kẻ tấn công có thể chiếm quyền tài khoản của maintainer hoặc tìm cách giành vai trò maintainer để phát tán mã độc. Chẳng hạn, năm 2025 đã xảy ra một cuộc tấn công khi một lập trình viên nổi tiếng trên npm bị lừa đảo qua email, dẫn đến việc kẻ xấu chiếm được tài khoản npm của anh ta. Từ đó, đối tượng tấn công đã xuất bản phiên bản mới chứa mã độc của nhiều gói thư viện phổ biến, tạo ra một cuộc tấn công chuỗi cung ứng nghiêm trọng [3]. Phương thức này thường bắt đầu bằng kỹ nghệ xã hội (social engineering) như phishing nhằm đánh cắp thông tin đăng nhập, sau đó lợi dụng quyền của maintainer để cập nhật mã độc vào dự án [3].
• Tiêm mã độc trong các gói phần mềm nguồn mở: Ngay cả khi không chiếm được tài khoản maintainer, kẻ tấn công vẫn có nhiều cách để “đầu độc” các gói phần mềm. Các chiến thuật bao gồm typosquatting (tạo gói có tên gần giống để đánh lừa người dùng), dependency confusion (đăng tải gói trùng tên với gói nội bộ để lừa hệ thống tự động tải về) hoặc chiếm quyền dự án bị bỏ hoang rồi chèn mã độc [1]. Vì các thư viện nguồn mở thường được tin cậy và sử dụng rộng rãi, một khi mã độc lọt vào, nó có thể lây lan rất nhanh qua các bản build hoặc bản phân phối phần mềm.
• Khó khăn trong việc kiểm soát và kiểm tra mã nguồn: Các dự án hiện đại thường phụ thuộc vào hàng trăm thư viện bên thứ ba, khiến việc kiểm toán từng dòng mã trở nên bất khả thi. Nhiều dự án nguồn mở được duy trì bởi nhóm nhỏ tình nguyện viên vốn đã quá tải, nên ít có thời gian rà soát bảo mật kỹ lưỡng cho mọi đóng góp [2]. Hơn nữa, mã độc có thể được che giấu kỹ lưỡng (ví dụ: obfuscation, nhiều lớp mã) khiến ngay cả các đợt kiểm tra thông thường cũng khó phát hiện. Sự phức tạp này đòi hỏi những cách tiếp cận mới trong việc kiểm soát chuỗi cung ứng – chẳng hạn như sử dụng danh sách vật liệu phần mềm (SBOM), quy trình đánh giá độ tin cậy của nhà cung cấp, và các công cụ tự động quét mã độc.

Phân tích sự cố XZ Utils Backdoor (CVE-2024-3094)

XZ Utils là bộ công cụ nén/giải nén định dạng .xz (dựa trên thuật toán LZMA) và thư viện liblzma của nó được tích hợp sẵn trong hầu hết các bản phân phối Linux [4]. Tháng 2/2024, một đoạn mã backdoor độc hại đã bị cài cắm vào mã nguồn XZ Utils (cụ thể là trong thư viện liblzma phiên bản 5.6.0 và 5.6.1) bởi một tài khoản maintainer có tên “Jia Tan” [5]. Lỗ hổng này nhanh chóng được gán mã CVE-2024-3094 với điểm CVSS 10.0 tối đa, cho thấy mức độ nghiêm trọng tuyệt đối. Backdoor cho phép kẻ tấn công sở hữu một khóa Ed448 chuyên biệt có thể thực thi mã từ xa (RCE) thông qua dịch vụ OpenSSH trên hệ thống Linux bị ảnh hưởng [5]. Nói cách khác, nếu backdoor hoạt động, kẻ tấn công sẽ có “cửa hậu” đăng nhập SSH vào máy nạn nhân mà không cần mật khẩu.

Nguồn gốc & cơ chế tấn công: Cuộc điều tra sau đó hé lộ rằng vụ cài cắm backdoor này là đỉnh điểm của chiến dịch kéo dài gần 3 năm (11/2021 – 2/2024) của một đối tượng mang danh Jia Tan/JiaT75 [5]. Đối tượng này đã tham gia đóng góp mã cho dự án XZ từ cuối 2021, cần mẫn gửi các pull request sửa lỗi và cải tiến nhỏ để xây dựng uy tín. Bằng cách đó, y dần được trao quyền commit và cuối cùng là quyền tạo bản phát hành (release) cho XZ Utils [4]. Thậm chí, có dấu hiệu cho thấy JiaT75 đã sử dụng nhiều tài khoản giả (sockpuppet) để tạo áp lực công việc lên maintainer chính, buộc người này phải thêm mình làm đồng maintainer để chia sẻ gánh nặng [5]. Sau khi nắm quyền, Jia Tan đã ký phát hành phiên bản 5.6.0 (và sau đó 5.6.1) – đây chính là các phiên bản chứa backdoor được cài cắm một cách tinh vi [5].

Hình 1: Infographic tóm tắt cách kẻ tấn công “JiaT75” thâm nhập dự án XZ Utils và cơ chế nhiều tầng của backdoor CVE-2024-3094. Mã độc được chia nhỏ và ẩn bên trong các tệp kiểm thử nén cùng một tập lệnh M4 độc hại, nhằm vượt qua khâu rà soát mã nguồn. Khi build trên hệ thống Linux x86-64 (với GCC và glibc), tập lệnh này tự động giải nén payload ẩn và chèn một đoạn mã độc vào thư viện liblzma trong quá trình biên dịch [5]. Toàn bộ chuỗi cài cắm được thiết kế nhiều giai đoạn, kích hoạt có điều kiện để giảm thiểu khả năng bị phát hiện sớm.

Backdoor trong XZ Utils có cơ chế hoạt động phức tạp và đa tầng. Thoạt tiên, mã độc “ngủ đông” và không làm gì bất thường cho đến khi hội đủ điều kiện cần thiết. Cụ thể, payload lợi dụng một cơ chế của glibc gọi là IFUNC (Indirect Functions) để chiếm quyền điều khiển việc resolve hàm trong quá trình nạp thư viện [5]. Khi máy nạn nhân chạy bản OpenSSH có tích hợp thư viện systemd (một bản vá phổ biến trong các distro khiến sshd nạp libsystemd và kéo theo liblzma) [5], backdoor sẽ thay thế hàm RSA_public_decrypt của OpenSSH bằng phiên bản độc hại của mình [5]. Kết quả là quá trình xác thực khóa SSH bị chèn thêm “cửa sau”: nếu kẻ tấn công kết nối tới dịch vụ SSH bằng một chứng chỉ SSH đặc biệt (được ký bởi khóa Ed448 bí mật mà chỉ kẻ tấn công có), backdoor sẽ nhận diện và cho phép thực thi payload do kẻ tấn công gửi lên, ngay trước bước xác thực [6]. Ngược lại, nếu kết nối SSH bình thường (không mang dấu hiệu của kẻ tấn công), liblzma vẫn hoạt động như bình thường và không để lộ dấu vết gì. Chính cơ chế “kích hoạt có điều kiện” này khiến việc phát hiện backdoor trở nên khó khăn – mã độc chỉ kích hoạt cho đúng kẻ tấn công và lặng lẽ ẩn mình với mọi người khác [2].

Quá trình khai thác và phát hiện: Để lợi dụng backdoor này, kẻ tấn công cần có cặp khóa Ed448 phù hợp. Kẻ tấn công sẽ tạo một chứng chỉ SSH độc hại sử dụng khóa Ed448 của mình làm Certificate Authority (CA) và nhúng payload (lệnh tùy ý) vào một trường của chứng chỉ đó [2]. Khi kẻ tấn công cố gắng đăng nhập SSH vào máy nạn nhân (máy có cài liblzma 5.6.0/5.6.1) bằng chứng chỉ đặc biệt nói trên, backdoor trong liblzma sẽ kiểm tra khóa CA của chứng chỉ. Nếu khóa CA khớp với khóa của kẻ tấn công, backdoor sẽ giải mã payload ẩn trong chứng chỉ và gọi thực thi lệnh đó với quyền root trên máy nạn nhân [2]. Toàn bộ quá trình xảy ra trước khi bước xác thực SSH thông thường diễn ra, nghĩa là kẻ tấn công chiếm quyền điều khiển máy mà không cần thông tin đăng nhập hợp lệ. Ngược lại, nếu chứng chỉ không mang dấu hiệu “hợp lệ” của kẻ tấn công, backdoor sẽ trả quyền điều khiển lại cho quy trình SSH bình thường, khiến kết nối tuân theo cơ chế xác thực thông thường [2].

Rất may mắn, backdoor nguy hiểm này đã bị phát hiện trước khi kịp gây hậu quả trên diện rộng. Tháng 3/2024, kỹ sư Andres Freund (một nhân viên Microsoft và cũng là nhà phát triển PostgreSQL) khi điều tra lỗi hiệu năng trên Debian Sid đã nhận thấy hiện tượng bất thường: quá trình đăng nhập SSH tiêu tốn CPU bất thường và gây lỗi bộ nhớ trong công cụ Valgrind [5]. Điều này khiến anh nghi ngờ có vấn đề trong thư viện liblzma. Freund đã đào sâu và phát hiện mã độc ẩn trong XZ Utils, sau đó anh công bố phát hiện này trên danh sách thư điện tử bảo mật của Openwall (oss-security) vào ngày 29/3/2024 [5]. Ngay khi thông tin được công bố, cộng đồng mã nguồn mở cùng các nhà cung cấp Linux đã nhanh chóng vào cuộc.

Bảng 1. Dòng thời gian chính của sự cố XZ Utils CVE-2024-3094:

Tác động của sự cố và bài học rút ra

Mức độ nguy hiểm: Giới chuyên gia nhận định sự cố XZ Utils có tiềm năng trở thành một trong những backdoor nghiêm trọng nhất lịch sử phần mềm nếu không được phát hiện kịp thời. Alex Stamos (cựu CSO Facebook) bình luận rằng, giả sử backdoor này lọt vào các bản phát hành ổn định, nó sẽ trao cho kẻ tấn công “chìa khóa vạn năng” để mở cửa hàng trăm triệu máy tính chạy SSH trên khắp thế giới [5]. Thật vậy, XZ Utils hiện diện mặc định trên hầu hết các hệ điều hành Linux; một khi bản XZ có backdoor được đưa vào distro và cập nhật cho người dùng, kẻ tấn công có thể truy cập từ xa gần như bất kỳ máy chủ Linux nào (bao gồm các máy chạy Fedora, Ubuntu, Debian…) chỉ trong nháy mắt [4]. So sánh với vụ SolarWinds (ảnh hưởng ~18.000 tổ chức), backdoor XZ còn có khả năng phủ rộng và âm thầm hơn nhiều, vì SSH là dịch vụ cốt lõi hiện diện ở mọi nơi.

May mắn, tác động thực tế của CVE-2024-3094 đã được kiểm soát ở mức tối thiểu nhờ phát hiện sớm. Vào thời điểm lộ diện, các phiên bản XZ 5.6.0/5.6.1 mới chỉ có trong các bản distro phát triển (dev/testing) chứ chưa kịp vào bản ổn định [5]. Nhờ quy trình phát hành thận trọng (đưa gói mới vào nhánh experimental trước khi vào stable), cộng đồng Linux đã “cách ly” được backdoor này trong phạm vi hẹp [7]. Thống kê cho thấy chỉ các nhánh Fedora Rawhide, Debian unstable/testing, Alpine Edge… bị ảnh hưởng; các phiên bản phát hành ổn định của đa số distro không tích hợp XZ độc hại [6]. Ngay sau khi nhận thông tin, các nhà cung cấp đã hành động quyết liệt: Red Hat, SUSE, Debian đồng loạt rút lại hoặc thay thế gói XZ bị lỗi bằng phiên bản cũ an toàn [5]; GitHub tạm khóa kho mã XZ để ngăn tải xuống bản có backdoor [5]. Canonical thậm chí trì hoãn lịch phát hành Ubuntu mới để biên dịch lại toàn bộ nhằm loại trừ rủi ro mã độc lan sang thành phần khác trong quá trình build [5]. Những động thái nhanh chóng này cho thấy sức mạnh của mô hình nguồn mở khi đối mặt sự cố: cộng đồng đã phát hiện, cảnh báo, và khắc phục lỗ hổng chỉ trong vài ngày, trước khi nó trở thành thảm họa an ninh diện rộng [7].

Tuy nhiên, vụ XZ Utils cũng dấy lên nhiều lo ngại và bài học quý giá. Thứ nhất, nó nhắc nhở rằng ngay cả các dự án lõi, được tin tưởng nhất cũng có thể bị tổn thương. Kẻ tấn công đã lợi dụng điểm yếu quy trình (quản lý quyền maintainer, phát hành tarball không khớp với nguồn git) để qua mặt hệ thống kiểm soát. Thứ hai, sự cố này đặt ra câu hỏi về mô hình duy trì phần mềm nguồn mở: liệu có bền vững không khi hạ tầng quan trọng của Internet lại phụ thuộc vào nỗ lực tình nguyện của vài cá nhân? [5]. Áp lực lên maintainer đơn lẻ có thể dẫn tới việc họ dễ mắc sai lầm hoặc bị thao túng, như trường hợp maintainer XZ bị sockpuppet gây sức ép. Cuối cùng, XZ backdoor cho thấy tầm quan trọng của việc giám sát hệ thống: chính các dấu hiệu bất thường ở thời gian chạy (runtime) đã phơi bày malware, gợi ý rằng tổ chức nên theo dõi những dị thường trong hành vi tiến trình (ví dụ: tiến trình sshd khởi chạy lệnh lạ) để phát hiện sớm các backdoor tương tự [4].

Giải pháp và khuyến nghị

Sự cố XZ Utils là một hồi chuông cảnh tỉnh về rủi ro trong chuỗi cung ứng phần mềm. Để tăng cường bảo mật và phòng chống các cuộc tấn công tương tự, các tổ chức và cộng đồng phát triển có thể tham khảo một số giải pháp sau:

• Nâng cao an ninh cho tài khoản và quy trình dự án nguồn mở: Các dự án nên áp dụng chính sách đa kiểm soát đối với thay đổi mã nguồn quan trọng – ví dụ, yêu cầu code review độc lập và phê duyệt từ nhiều maintainer trước khi hợp nhất mã. Bên cạnh đó, bảo vệ tài khoản maintainer bằng các biện pháp mạnh như xác thực hai yếu tố (2FA) là bắt buộc [3]. Nhà phát triển cần cảnh giác với phishing và thường xuyên kiểm tra tính toàn vẹn của môi trường phát hành (như đảm bảo gói phát hành không khác biệt so với mã nguồn trong repo).
• Cải thiện quy trình phát hành và kiểm thử: Bài học từ XZ cho thấy giá trị của việc phát hành gói mới qua kênh thử nghiệm trước khi đưa vào bản stable [7]. Các nhà phân phối phần mềm nên tiếp tục duy trì chiến lược staged rollout (triển khai theo giai đoạn), kết hợp với mở rộng phạm vi kiểm thử bảo mật tự động (fuzzing, phân tích mã tĩnh) trên các phiên bản phát triển. Việc này giúp phát hiện hành vi bất thường của thành phần mới (như XZ 5.6.x) trong môi trường cô lập trước khi chúng ảnh hưởng diện rộng. Ngoài ra, cần có quy trình đối soát giữa mã nguồn và binary phát hành – đảm bảo rằng gói phân phối (tarball, binaries) không chứa thêm thành phần ngoài những gì có trên repository nguồn (như trường hợp script độc hại chỉ có trong tarball XZ).
• Áp dụng công cụ giám sát và săn tìm mối đe dọa (threat hunting): Do backdoor thường ẩn mình rất kỹ trong mã nguồn, giám sát ở cấp hệ thống có thể là lớp phòng thủ phát hiện cuối cùng. Tổ chức nên cấu hình hệ thống ghi log và cảnh báo khi có hiện tượng lạ, ví dụ: tiến trình hệ thống (như sshd) thực thi lệnh ngoài dự kiến hoặc tăng đột biến sử dụng CPU/bộ nhớ bất thường. Các dịch vụ săn tìm mối đe dọa hiện nay có thể thiết lập baseline và phát hiện khi tiến trình con, hoạt động của hệ thống lệch khỏi bình thường [4]. Việc đầu tư vào những công cụ này giúp phát hiện sớm dấu hiệu của backdoor đang hoạt động, giảm thiểu thiệt hại.
• Hỗ trợ cộng đồng nguồn mở và củng cố chuỗi cung ứng: Cuối cùng, bài học dài hạn là cần đầu tư nhiều hơn cho an ninh của các dự án nguồn mở trọng yếu. Như OpenSSF nhấn mạnh, chúng ta phải luôn cảnh giác và sẵn sàng hỗ trợ những “người gác cổng” thầm lặng của phần mềm nguồn mở [7]. Điều này bao gồm tài trợ cho công tác kiểm toán mã nguồn độc lập, xây dựng các công cụ tự động phát hiện backdoor (ví dụ: dự án phát triển trình quét backdoor XZ của Binarly [8]), và tạo môi trường để các chuyên gia bảo mật, maintainer, lập trình viên cùng hợp tác trao đổi thông tin về mối đe dọa [7]. Về phía doanh nghiệp, nên duy trì danh sách SBOM cho sản phẩm của mình để theo dõi phiên bản các thành phần phụ thuộc và nhanh chóng hành động khi có cảnh báo về lỗ hổng. Việc cập nhật thường xuyên các bản vá bảo mật và loại bỏ kịp thời những thành phần độc hại trong chuỗi cung ứng sẽ quyết định khả năng chống chịu trước các cuộc tấn công tương tự trong tương lai.

Tài liệu tham khảo: Các thông tin và phân tích trên được tổng hợp từ nhiều nguồn uy tín, bao gồm thông báo của các hãng bảo mật và các bài viết phân tích chuyên sâu về CVE-2024-3094 [4], [5], [7]. Sự cố XZ Utils backdoor tuy gây chấn động, nhưng phản ứng kịp thời của cộng đồng đã biến đây thành một case study quý giá. Nó nhắc nhở chúng ta rằng bảo mật chuỗi cung ứng phần mềm không chỉ là câu chuyện về công nghệ, mà còn về con người, quy trình và sự phối hợp trách nhiệm trong toàn bộ hệ sinh thái phát triển phần mềm. [7]

Tài liệu tham khảo

[1] https://blog.rad.security/blog/software-supply-chain-attacks-13-examples-of-cyber-security-threats

[2] https://www.cybereason.com/blog/threat-alert-the-xz-backdoor

[3] https://snyk.io/blog/npm-supply-chain-attack-via-open-source-maintainer-compromise/

[4] https://www.akamai.com/blog/security-research/critical-linux-backdoor-xz-utils-discovered-what-to-know

[5] https://en.wikipedia.org/wiki/XZ_Utils_backdoor

[6] https://jfrog.com/blog/xz-backdoor-attack-cve-2024-3094-all-you-need-to-know/

[7] https://openssf.org/blog/2024/03/30/xz-backdoor-cve-2024-3094/

[8] https://harsim.ca/Unraveling-the-XZ-Backdoor-A-Close-Call-for-Open-Source-Security/