Nhà phát triển Python thoát thảm họa nhờ trực giác... và AI

Nhà phát triển Python Roman Imankulov gần như đã cắn câu. Việc ông không trở thành nạn nhân của một cuộc tấn công mạng có thể được quy cho trực giác của con người và sự hỗ trợ đắc lực từ AI trong việc thẩm định mã nguồn.

Mọi chuyện bắt đầu khi một người tự xưng là tuyển dụng viên từ một startup về tiền mã hóa nhỏ đã liên hệ qua LinkedIn. Người này nhờ Imankulov xem xét và sửa chữa một đoạn mã khái niệm (proof-of-concept) không hoạt động, với lý do công ty đang rất cần một kỹ sư dẫn dắt.

Theo như Imankulov mô tả trong một bài đăng trên blog, tuyển dụng viên đã yêu cầu anh xem xét một vấn đề liên quan đến mô-đun Node đã bị ngưng hỗ trợ. Dù yêu cầu có vẻ bình thường, nhưng có gì đó trong cuộc giao tiếp này khiến anh cảm thấy không ổn.

"Tôi đã từng nghe nói, và chắc hẳn chúng ta đều đã nghe nói về những kiểu tấn công này," Imankulov chia sẻ trong một cuộc phỏng vấn. "Và tôi tự nghĩ, 'nh nếu mình là mục tiêu thì sao?'. Đó chỉ dựa trên kinh nghiệm trong quá khứ mà tôi đã tích lũy được."

Do đó, ông đã thực hiện một bước bất thường: thuê một máy chủ ảo (VPS) trên Hetzner để sao chép (clone) kho chứa mã nguồn (repo) về đó. Sau đó, ông sử dụng tác nhân mã hóa Pi (chạy Codex) để thực hiện phân tích mã ở chế độ chỉ đọc.

"Tôi chạy tác nhân để xem nó hoạt động thế nào, và tôi gần như chắc chắn rằng nó sẽ trả lời 'mọi thứ ổn ổn, mã xấu xí nhìn chung là an toàn, cứ tiến hành kiểm tra đi'," ông giải thích. "Đến ngỡ ngàng, gần như ngay lập tức tác nhân trả lời rằng: 'Đừng chạy mã này, hãy bỏ đi ngay vì có cái bẫy ở đây'."

Mô hình AI đã đánh dấu cờ đỏ cho một trong các tệp tin, app/test/index.js. Tệp tin này chứa một cửa sau (backdoor). Nó ngụy trang dưới dạng một URL máy chủ bị chia nhỏ để trông giống như cấu hình bộ kiểm thử, cùng với một yêu cầu mạng sẽ thực thi bất kỳ thứ gì máy chủ gửi lại trong phản hồi.

Imankulov ghi nhận công lao cho tác nhân AI của mình vì đã phát hiện ra những chi tiết mà ông đã bỏ sót.

"Tôi tự mở mã này ra và lướt qua, nó trông giống như một tệp tin tồi tệ viết bởi một lập trình viên cẩu thả," ông nói. "Vì vậy tôi vừa cuộn xuống vừa nghĩ 'Ừ thì, mã tệ thật, nhưng nếu họ trả tiền để tôi sửa thì tôi không phiền'. Nhưng tác nhân đã tìm ra chính xác lỗ hổng mà tôi đã bỏ qua trong cùng một tệp tin đó."

Chỉ cần cài đặt repo đó bằng lệnh npm install là đủ để kích hoạt cửa sau. Tệp package.json trong repo chứa một hook "prepare" sau cài đặt, được thiết kế để chạy đoạn script độc hại ngay sau khi quá trình cài đặt hoàn tất.

Kho chứa mã độc nói trên hiện đã không còn thể truy cập được – có lẽ là GitHub đã xóa nó sau khi nhận được khiếu nại từ Imankulov – nhưng một bản sao chép vẫn có thể được tìm thấy.

Devashri Datta, kiến trúc sư bảo mật và mã nguồn mở độc lập, đã giải thích sự nguy hiểm của cuộc tấn công này qua email cho The Register: "Điều khiến cuộc tấn công này xảo quyệt là cách nó chiếm đoạt quy trình làm việc tiêu chuẩn của nhà phát triển. Kẻ tấn công không dựa vào việc mục tiêu thực thi một tệp nhị phân đáng ngờ; chúng dựa vào việc mục tiêu chạy một lệnh thường nhật: npm install."

"Bằng cách chôn chặt logic thực thi bên trong hook vòng đời prepare trong package.json, tải lệ độc hại sẽ tự động kích hoạt trong quá trình phân giải phụ thuộc. Đây không phải là một kỹ thuật mới, nhưng nó vẫn cực kỳ hiệu quả chính vì các nhà phát triển thường chạy npm install theo bản năng. Việc chia nhỏ chuỗi để lắp ráp URL độc hại, ghép một tên miền từ các hằng số nhỏ, là sự làm mờ có chủ ý nhằm đánh bại các công cụ phân tích tĩnh quét các chỉ số bị xâm phạm được mã hóa cứng."

Imankulov cho biết các lần commit trong repo độc hại dường như là công việc của một nhà phát triển có hồ sơ web và danh sách các dự án đã được thiết lập. Tuy nhiên, khi ông liên hệ với tác giả giả định, người này nói rằng tài khoản GitHub của họ đã bị mạo danh nhiều lần và họ không viết mã đó.

Hồ sơ LinkedIn của "tuyển dụng viên" đề cập đến một nhà báo nghệ thuật thực sự, dù Imankulov tin rằng hồ sơ liên quan đã bị giả mạo. Các tương tác trực tuyến của ông với người này cho thấy mức độ kiến thức kỹ thuật không thể hiện rõ trong lịch sử làm việc của họ.

LinkedIn thường tuyên bố về hàng chục triệu tài khoản giả mà họ bắt và xóa trước khi chúng tương tác với bất kỳ ai. Nhưng hàng trăm nghìn tài khoản vẫn được tạo ra và tương tác với mọi người trước khi bị phát hiện và đánh dấu. Con số này tiếp tục tăng. Trong giai đoạn từ tháng 1 đến tháng 6 năm 2025, LinkedIn đã hạn chế 386.000 tài khoản sau báo cáo của người dùng. Con số này là 266.000 trong sáu tháng trước đó. Và chỉ là 86.000 trong giai đoạn từ tháng 1 đến tháng 6 năm 2021.

Các cuộc tấn công kỹ thuật xã hội vào chuỗi cung ứng phần mềm kiểu này đã trở nên phổ biến. Đầu tháng này, chúng tôi đã lưu ý cách những kẻ lừa đảo liên kết Triều Tiên đang chạy các chiến dịch khác nhau để xâm nhập tài khoản nhà phát triển bằng các cuộc phỏng vấn giả và lời mời làm việc.

Các nhà phát triển khác cũng đã báo cáo việc suýt bị lừa bởi các chiêu trò này (và cũng được cứu bởi tác nhân AI của họ) và đã đăng tải các phân tích mã.

Datta cho biết phản ứng của Imankulov làm nổi bật sự thay đổi trong cách các nhà phát triển có ý thức bảo mật tiếp cận quy trình kiểm duyệt mã.

"Lịch sử, hướng dẫn là sandbox mã không đáng tin cậy hoặc xem xét thủ công," bà nói. "Ở đây, Roman đã triển khai một tác nhân AI cục bộ trong môi trường bị hạn chế, chỉ đọc để phân tích cơ sở mã trước khi thực thi bất cứ thứ gì. Đây là một phản bổ ích cho câu chuyện chủ đạo xem AI là vector đe dọa tấn công. Khi sử dụng phòng thủ tại điểm cuối của nhà phát triển, tác nhân AI không bị mệt mỏi hay áp lực xã hội; nó đơn giản chỉ làm nổi bật hành vi bất thường, chẳng hạn như bộ kiểm thử khởi tạo kết nối mạng向外 để truy xuất mã chưa được xác minh, trong vài giây."

npm 12 có thể thay đổi cục diện

Nếu là một sự an ủi, vector tấn công liên quan dự kiến sẽ được giải quyết vào tháng tới.

GitHub, đơn vị duy trì npm, đang chuẩn bị phát hành npm 12 thay đổi hành vi của lệnh npm install. Cài đặt allowScripts sẽ mặc định bị tắt.

"npm install sẽ không còn thực thi các script preinstall, install hoặc postinstall từ các phụ thuộc trừ khi chúng được cho phép rõ ràng trong dự án của bạn," GitHub giải thích.

"Script vòng đời lúc cài đặt là bề mặt thực thi mã lớn nhất trong hệ sinh thái npm," Leo Balter, quản lý sản phẩm của GitHub, giải thích trong một bài đăng thảo luận cộng đồng tuần trước. "Mỗi lệnh npm install đều chạy script từ mọi phụ thuộc bắc cầu, vì vậy một gói đơn bị xâm nhập bất kỳ đâu trong cây của bạn có thể thực thi mã tùy ý trên máy của nhà phát triển hoặc trình chạy CI. Việc thực thi script trở thành lựa chọn tham gia (opt-in) sẽ đóng đường dẫn đó trong khi vẫn giữ nó cách một lệnh đối với các gói bạn tin tưởng."

Imankulov nói rằng ông không có ý kiến mạnh mẽ về vấn đề đó. "Theo quan điểm của tôi, chỉ vì sự an toàn cá nhân, tôi đã chuyển sang pnpm để đảm bảo rằng mình không thực thi các script đó theo mặc định," ông nói.

Datta nhận định sự cố nhấn mạnh lý do tại sao bảo mật chuỗi cung ứng phần mềm doanh nghiệp phải mở rộng ra ngoài biên mạng của công ty.

"Kẻ tấn công hiện đang dịch chuyển sang bên trái (shifting left) tất cả cách đến các điểm cuối kỹ thuật cá nhân trước khi một dòng mã nào nhập vào chuỗi cung ứng doanh nghiệp," bà nói. "Khi máy trạm cục bộ của nhà phát triển bị xâm nhập trong những gì dường như là một cuộc phỏng vấn việc làm thường nhật, máy đó thường giữ các khóa SSH hoạt động, token nhà cung cấp đám mây và quyền truy cập trực tiếp vào các kho lưu trữ nội bộ."

Sự phòng thủ thích hợp, theo lập luận của Datta, yêu cầu thực thi các hàng rào kỹ thuật như các vùng chứa nhà phát triển cô lập hoặc máy trạm đám mây an toàn để đánh giá mã của bên thứ ba hoặc không đáng tin cậy.

"Các khung framework mới đang bắt đầu mở rộng ngữ cảnh khai thác xuống tận lớp trạm làm việc, nhận ra rằng tín hiệu kiểu VEX cần di chuyển xa hơn bên trái so với danh mục tồn kho SBOM doanh nghiệp nếu nó muốn chặn các mối đe dọa tại điểm giới thiệu," bà kết luận.