Vấn đề tóm gọn trong một câu
Lần tới một Trợ lý AI đề xuất gói phần mềm cần cài đặt.Bạn có thực sự kiểm tra xem gói đó có tồn tại hay không? Hầu hết các nhà phát triển đều không làm vậy. Khoảng cách giữa đề xuất và xác minh chính là nơi các cuộc tấn công chiếm đoạt mã nguồn bất hợp pháp bắt đầu, và đó là lý do tại sao việc hiểu cả sự phát triển của tấn công chiếm đoạt mã nguồn bất hợp pháp và các biện pháp phòng ngừa thực tế đã trở thành ưu tiên hàng đầu đối với các nhóm bảo mật ứng dụng và bảo mật hệ thống phát triển.
Cuộc tấn công ngồi xổm là gì?
Tấn công ngồi xổm là một biến thể của đánh máy (thực tiễn đăng ký tên miền hoặc tên gói phần mềm bắt chước tên miền hoặc tên gói hợp pháp bằng cách sử dụng lỗi chính tả phổ biến, chẳng hạn như...) yêu cầu thay vì yêu cầu(với hy vọng lỗi chính tả của người dùng sẽ dẫn họ thẳng đến đó), nhưng có một sự khác biệt quan trọng về nguồn gốc của lỗi. Tấn công typosquatting khai thác lỗi đánh máy của con người. Tấn công slopsquatting khai thác những lỗi mà các mô hình ngôn ngữ lớn mắc phải: một LLM "tạo ra" một tên gói nghe có vẻ hoàn toàn hợp lệ nhưng không tồn tại trong bất kỳ kho lưu trữ công khai nào, và kẻ tấn công sẽ có được quyền truy cập trước bằng cách đăng ký chính xác tên đó trước bất kỳ ai có thiện chí.
Cơ chế đằng sau một cuộc tấn công kiểu "slopsquatting" điển hình rất đơn giản, và chính sự đơn giản đó lại làm cho nó hiệu quả:
- Một lập trình viên nhờ trợ lý AI giúp giải quyết một vấn đề lập trình.
- Mô hình này tạo ra một giải pháp nhập khẩu hoặc đề xuất cài đặt một gói phần mềm chưa từng tồn tại.
- Kẻ tấn công nhận thấy một số mô hình liên tục lặp lại cùng một tên ảo tưởng và đăng ký gói đó trên npm, PyPI hoặc một kho lưu trữ công khai khác, với mã độc bên trong. Đây là lúc ảo tưởng biến thành một cuộc tấn công chiếm đoạt tên miền thực sự.
- Nhà phát triển tiếp theo nhận được đề xuất tương tự và không kiểm tra kỹ, sẽ cài đặt gói phần mềm hiện đã có sẵn, vốn là một cửa hậu xâm nhập vào môi trường của họ.
Thuật ngữ “slopsquatting” được Seth Larson, nhà phát triển bảo mật thường trú tại Python Software Foundation, đặt ra và được Andrew Nesbitt phổ biến, để mô tả chính xác kiểu mẫu này: một “ảo giác về gói phần mềm” được biến thành một phương thức tấn công.
Sự tiến hóa của tư thế ngồi xổm: làm thế nào một sự tò mò trong nghiên cứu đã biến thành một mối đe dọa thực sự
Điều đáng chú ý về sự phát triển của kiểu tấn công ngồi xổm không chỉ là khái niệm; mà còn là tốc độ nó chuyển từ một quan sát nghiên cứu thành một loại hình tấn công được ghi nhận và đo lường được.
2023: Dấu hiệu cảnh báo đầu tiên. Nhà nghiên cứu bảo mật Bar Lanyado Tôi nhận thấy rằng một số chuyên gia quản lý học tập (LLM) liên tục đề xuất một gói phần mềm có tên là... ôm mặt-cli, thứ không tồn tại (gói phần mềm thực sự được cài đặt với) pip install -U “huggingface_hub[cli]”Để chứng minh rủi ro, anh ta đã tải lên một phiên bản trống của gói phần mềm đó lên một kho lưu trữ công khai. Trong vòng ba tháng, nó đã nhận được hơn 30,000 lượt tải xuống, mà không cần bất kỳ hoạt động quảng bá nào. Cái tên giả mạo thậm chí còn xuất hiện trong tệp README của một kho lưu trữ liên quan đến nghiên cứu từ Alibaba, cho thấy ngay từ đầu cách những cái tên "giả" này có thể rò rỉ vào tài liệu thực và tạo tiền đề cho các cuộc tấn công chiếm đoạt tên miền sau này.
2024: Rủi ro này không chỉ còn là bài đăng trên blog của một nhà nghiên cứu mà đã trở thành chủ đề được các phương tiện truyền thông công nghệ đưa tin rộng rãi. Vào tháng 3, 2024, Đăng ký Bài báo đã đưa tin về việc các mô hình AI tự tin tạo ra tên gói phần mềm mà các nhà phát triển sau đó tải xuống, một số trong đó có khả năng bị nhiễm phần mềm độc hại. Bài báo đó không chỉ quan trọng ở những gì nó tiết lộ về mặt kỹ thuật mà còn ở những gì nó báo hiệu: trường hợp huggingface-cli không còn là một sự việc hiếm gặp; đó là dấu hiệu đầu tiên của một mô hình nghiêm trọng đến mức báo chí công nghệ chính thống đã chú ý, trước cả nghiên cứu học thuật quy mô lớn xác nhận phạm vi của vấn đề một năm sau đó.
2025: Lần đo lường quy mô lớn và chính xác đầu tiên về vấn đề này. Giấy “Chúng tôi có một gói hàng dành cho bạn! Phân tích toàn diện về ảo giác gói hàng bằng cách tạo mã LLM” (Spracklen và cộng sự, trình bày tại Bảo mật USENIX (Hội thảo) đã thử nghiệm 16 mô hình tạo mã, cả thương mại (GPT-4, GPT-3.5) và mã nguồn mở (CodeLlama, DeepSeek, WizardCoder, Mistral), trên 576,000 mẫu mã Python và JavaScript. Kết quả đánh dấu một bước ngoặt rõ ràng trong sự phát triển của việc sử dụng mã nguồn rời rạc, chuyển từ giai thoại sang dữ liệu:
- 19.7% Các gói phần mềm được mô hình đề xuất không tồn tại.
- Các mô hình mã nguồn mở thường xuyên gặp lỗi hơn nhiều (21.7% trung bình) hơn các mẫu thương mại (5.2%).
- Hai trường hợp tệ nhất, CodeLlama 7B và CodeLlama 34B, đã bị ảo giác trong hơn một phần ba số lần hoạt động của chúng.
- Trên tất cả các mô hình được thử nghiệm, các nhà nghiên cứu đã ghi nhận hơn 205,000 tên gói hàng ảo giác độc đáo, một nguồn nước đủ lớn để duy trì các cuộc tấn công chiếm đất trái phép trên nhiều hệ sinh thái khác nhau.
- Một chi tiết đặc biệt quan trọng đối với công tác phòng ngừa: khoảng 38% Những cái tên ảo tưởng đó trông rất giống với các gói hàng thật, điều này làm giảm khả năng ai đó nhận ra chúng ngay từ cái nhìn đầu tiên.
Một chi tiết quan trọng từ nghiên cứu, và có lẽ là lý do khiến sự phát triển của tấn công slopsquatting tăng tốc thay vì giảm dần, là các tên ảo không phải ngẫu nhiên và chúng không thay đổi trong mỗi lần thử. Các mô hình tương tự có xu hướng lặp lại các tên được tạo ra khi được cung cấp các gợi ý tương tự, điều đó có nghĩa là kẻ tấn công không cần phải đoán. Họ chỉ cần quan sát hành vi của mô hình, xác định các tên liên tục xuất hiện và đăng ký chúng trước khi một nhà phát triển thực sự làm được. Phân tích tiếp theo về khả năng lặp lại này cho thấy rằng khi các nhà nghiên cứu chạy lại các gợi ý giống hệt nhau mười lần, 43% tên gói ảo xuất hiện trong mỗi lần chạy và 58% lặp lại nhiều hơn một lần, bằng chứng cho thấy hầu hết các ảo giác là các hiện tượng lặp lại chứ không phải là nhiễu đơn lẻ. Chính khả năng lặp lại đó biến một ảo giác đơn lẻ thành một cuộc tấn công slopsquatting có thể mở rộng.
2026: Từ các gói hàng riêng lẻ đến các tác nhân tự động. Năm nay đã mang đến bằng chứng rõ ràng nhất cho thấy việc sao chép trái phép không còn chỉ giới hạn ở việc nhà phát triển sao chép y nguyên một đề xuất nữa. cài đặt pip or NPM cài đặt lệnh. Vào tháng 1 năm 2026, nhà nghiên cứu Charlie Eriksen Tại Aikido Security, người ta phát hiện ra rằng các tác nhân lập trình AI đã lan truyền các chỉ thị tham chiếu đến một gói npm ảo. react-codeshift (một cái tên có vẻ như kết hợp hai công cụ có thật, jscodeshift và react-codemod), trên 237 kho lưu trữ, và các tác nhân vẫn đang cố gắng cài đặt nó hàng ngày. Eriksen đã tự đăng ký tên này để phòng thủ, trước khi kẻ tấn công có thể sử dụng nó làm vũ khí. Riêng biệt, một gói phần mềm độc hại thực sự có tên nhập khẩu không sử dụng, ảo giác thay thế cho thực tế chính đáng. eslint-plugin-unused-importsMặc dù npm đã tạm giữ phần mềm này vì lý do an ninh, nhưng đến đầu năm 2026, nó vẫn ghi nhận khoảng 233 lượt tải xuống mỗi tuần, cho thấy một cuộc tấn công chiếm đoạt tài nguyên trái phép có thể tiếp tục thu hút nạn nhân trong thời gian dài ngay cả sau khi đã bị gắn cờ cảnh báo. Gần đây hơn, vào tháng 7 năm 2026, các nhà nghiên cứu đã mô tả một kỹ thuật liên quan, được gọi là “HalluSquatting”, kết hợp ảo giác AI với việc chèn mã nhắc nhở để một tác nhân lập trình AI tìm nạp tài nguyên ảo giác thay mặt người dùng có thể bị chiếm quyền điều khiển và chạy mã do kẻ tấn công cung cấp, mở rộng sự phát triển của tấn công chiếm đoạt tài nguyên trái phép từ rủi ro cài đặt thụ động thành một vectơ thực thi mã từ xa chủ động bên trong quy trình phát triển tác nhân.
Vì sao "mã hóa cảm xúc" lại mở rộng phạm vi cho các cuộc tấn công chiếm dụng không cần thiết
Các cuộc tấn công chiếm dụng mã nguồn một cách cẩu thả sẽ không gây nhiều vấn đề nếu mã do AI tạo ra chỉ là một lĩnh vực nhỏ. Nhưng thực tế không phải vậy. Sự trỗi dậy của các trợ lý lập trình, các tác nhân tự động và quy trình làm việc "lập trình theo cảm nhận", nơi các nhà phát triển xem xét mã ngày càng ít hơn trước khi chạy, đã làm thay đổi bề mặt tấn công phần mềm theo hai cách cụ thể, và cả hai đều đang thúc đẩy sự phát triển của các cuộc tấn công chiếm dụng mã nguồn một cách cẩu thả:
- Điểm khởi đầu không còn chỉ dành cho nhà phát triển nữa. Trước đây, tấn công typosquatting chỉ phụ thuộc vào việc một người mắc lỗi đánh máy. Giờ đây, lỗi đó có thể bắt nguồn từ chính mô hình và lan truyền đến hàng trăm nhà phát triển khác nhau, những người đặt câu hỏi tương tự và nhận được cùng một khuyến nghị ảo, làm tăng phạm vi ảnh hưởng của một cuộc tấn công slopsquatting duy nhất.
- Phạm vi tấn công đã dịch chuyển lên cao hơn trong chuỗi bảo mật. Ngày nay, việc chỉ giám sát mã do con người viết là không đủ. Các nhóm cũng cần giám sát các phụ thuộc mà trợ lý AI đề xuất, các máy chủ MCP mà nó kết nối đến và các tác nhân cài đặt gói tự động mà không cần sự xem xét trực tiếp của con người. Bảo mật ứng dụng truyền thống, được xây dựng để xem xét các kho lưu trữ và con người, không đáp ứng được yêu cầu này. commits, chưa bao giờ được thiết kế để quan sát sự tương tác mới này giữa nhà phát triển, AI và kho lưu trữ gói, và đó chính là nơi các cuộc tấn công chiếm đoạt gói phần mềm hiện đang ẩn náu.
Điều này không có nghĩa là trí tuệ nhân tạo tạo sinh (generative AI) vốn dĩ không an toàn. Điều đó có nghĩa là nó tạo ra một loại rủi ro chuỗi cung ứng mới mà các công cụ bảo mật truyền thống không được thiết kế để phát hiện, và loại rủi ro này đòi hỏi các nguyên tắc xác minh tương tự mà chúng ta đã áp dụng cho bất kỳ sự phụ thuộc bên ngoài nào: không tin tưởng một cách mặc định, xác minh nguồn gốc và tự động hóa quá trình xác minh đó thay vì dựa vào trí nhớ hoặc sự cảnh giác của từng nhà phát triển. Việc tự động hóa đó là nền tảng của bất kỳ chiến lược ngăn chặn chiếm đoạt mã nguồn bừa bãi nào thực sự hiệu quả.
Phòng chống tình trạng ngồi xổm không đúng tư thế: các đội có thể làm gì ngay hôm nay?
Tin tốt là việc ngăn ngừa lỗi chiếm dụng mã nguồn không đòi hỏi các công cụ phức tạp. Nó đòi hỏi việc áp dụng một cách có hệ thống các thực tiễn vệ sinh phụ thuộc đã tồn tại, nhưng nhiều nhóm lại lơ là ngay khi một AI mà họ tin tưởng "đề xuất" mã nguồn. Một phương pháp ngăn ngừa lỗi chiếm dụng mã nguồn hiệu quả thường kết hợp các yếu tố sau:
- Kiểm tra thủ công bất kỳ gói phần mềm mới nào trước khi cài đặt.Đặc biệt là khi nó đến từ gợi ý của trợ lý AI. Hãy xác nhận xem nó có tồn tại trong sổ đăng ký chính thức hay không, ai là người quản lý, khi nào nó được xuất bản và liệu số lượt tải xuống có vẻ thực tế hay không. Thói quen đơn giản này là hình thức phòng ngừa lười biếng rẻ nhất mà bất kỳ đội nào cũng có thể áp dụng.
- Đừng bao giờ cho rằng mã do AI tạo ra là an toàn theo mặc định. Một đoạn mã "hoạt động" không có nghĩa là các phần phụ thuộc của nó là hợp lệ. Việc xem xét các phần phụ thuộc nên là một phần của việc xem xét mã, chứ không phải là một ngoại lệ.
- Sử dụng tệp khóa và xác minh băm. Để xác định chính xác phiên bản và ngăn chặn quá trình cập nhật ngầm thay thế gói phần mềm khác với gói đã được kiểm tra ban đầu.
- Triển khai tính năng quét phụ thuộc để phát hiện các mẫu rủi ro vượt ra ngoài các lỗ hổng CVE đã biết.Các gói phần mềm bất thường, tên gọi đáng ngờ giống với các gói hiện có, người bảo trì mới không có kinh nghiệm, hoặc các tập lệnh cài đặt có hành vi bất thường. Một gói phần mềm mới được phát hành gần như không có lịch sử, có tên gọi gần giống với một thứ gì đó "gần như" quen thuộc, chính là mô hình đằng sau hầu hết các cuộc tấn công chiếm đoạt phần mềm trái phép đã được ghi nhận cho đến nay.
- Hãy đối xử với các cơ quan đăng ký công khai với thái độ hoài nghi tương tự.ciscũng giống như bất kỳ nguồn thông tin bên ngoài chưa được xác minh nào khác. Thực tế là cài đặt pip or NPM cài đặt Việc không báo lỗi không phải là bằng chứng về tính hợp lệ.
- Đào tạo các nhóm phát triển Thực tế là việc lập trình có sự hỗ trợ của AI không loại bỏ trách nhiệm xác minh những gì được cài đặt; nó chỉ bổ sung thêm một bước cần được tích hợp vào quy trình làm việc như một phần của bất kỳ kế hoạch ngăn chặn chiếm dụng trái phép nào một cách nghiêm túc.
Không có biện pháp nào trong số này là mới hoàn toàn. Điều đã thay đổi là quy mô: khi một đề xuất về phụ thuộc không còn đến từ Stack Overflow hay đồng nghiệp, mà từ một mô hình có thể lặp lại cùng một lỗi ảo tưởng cho hàng nghìn nhà phát triển khác nhau, việc xác minh thủ công, dù vẫn cần thiết, không còn đủ nữa. Đó là lý do tại sao ngày càng nhiều nhóm đang tự động hóa lớp ngăn ngừa việc chiếm dụng mã nguồn không chính xác này trong quy trình của họ. Phân tích thành phần phần mềm (SCAcông cụ )thay vì để mặc cho kỷ luật của từng nhà phát triển.
Đây là trướccisely tại sao ASPM nền tảng Lượt thích Xygeni Tích hợp khả năng phát hiện các phụ thuộc đáng ngờ, bao gồm cả việc chiếm đoạt mã nguồn do lỗi chính tả, nhầm lẫn phụ thuộc và các gói độc hại đã biết, vào cùng một hệ thống phân tích phụ thuộc mã nguồn mở và trí tuệ nhân tạo. pipelineVì vậy, việc ngăn ngừa tình trạng chiếm dụng thư viện không phụ thuộc vào việc mỗi nhà phát triển có nhớ kiểm tra điều này mỗi khi trợ lý AI đề xuất một thư viện phụ thuộc mới hay không.
FAQ
Liệu tấn công chiếm đoạt tài nguyên một cách cẩu thả có giống với tấn công chiếm đoạt tài nguyên một cách sai sót chính tả không?
Không hẳn. Cả hai đều liên quan đến việc đăng ký một tên gói giả để đánh lừa người cài đặt, nhưng nguồn gốc của lỗi lại khác nhau. Tấn công typosquatting khai thác lỗi đánh máy của con người. Tấn công slopsquatting khai thác các tên gói được tạo ra (ảo tưởng) bởi các mô hình AI, mà kẻ tấn công sau đó đăng ký trước khi nó tồn tại hợp pháp.
Liệu trình quản lý gói có thể tự động ngăn chặn loại tấn công này không?
Không hoàn toàn, đó chính là lý do tại sao việc ngăn chặn tấn công chiếm đoạt gói phần mềm không thể chỉ dừng lại ở cấp độ trình quản lý gói. Nếu kẻ tấn công đăng ký gói phần mềm giả mạo trước khi nhà phát triển cố gắng cài đặt nó, quá trình cài đặt sẽ hoàn tất mà không có lỗi nào vì gói phần mềm đó thực sự tồn tại, mặc dù nó độc hại. Việc ngăn chặn hiệu quả cần thêm bước xác minh nguồn gốc và hành vi của gói phần mềm.
Điều này chỉ ảnh hưởng đến các mô hình mã nguồn mở thôi sao?
Không. Nghiên cứu của Spracklen và cộng sự đã phát hiện ảo giác ở mọi mô hình được thử nghiệm, bao gồm cả các mô hình thương mại, mặc dù với tỷ lệ thấp hơn đáng kể (5.2% so với 21.7% đối với các mô hình mã nguồn mở được đánh giá). Không có mô hình nào hoàn toàn không gặp phải vấn đề này, đó là một phần lý do tại sao sự phát triển của việc lập trình cẩu thả lại song hành với sự phát triển của lập trình hỗ trợ bởi trí tuệ nhân tạo nói chung.
Đây là rủi ro lý thuyết hay đã từng bị khai thác rồi?
ôm mặt-cli Trường hợp này, một gói phần mềm rỗng được một nhà nghiên cứu tải lên đã được tải xuống hơn 30,000 lần trong ba tháng mà không cần bất kỳ hoạt động quảng bá nào, cho thấy rủi ro không chỉ là lý thuyết: một cái tên ảo tưởng chỉ cần đủ nhất quán giữa các lời nhắc khác nhau là ai đó có thể biến nó thành một cuộc tấn công chiếm đoạt tài sản bất hợp pháp thực sự.
