Nhà nghiên cứu bảo mật của Snyk phát tán gói NPM độc hại nhắm vào Cursor.com

 (sourcecodered.com)
1 điểm bởi GN⁺ 2025-01-14 | 1 bình luận | Chia sẻ qua WhatsApp
  • Nhiều gói được đưa lên npm chứa script cài đặt có vẻ nhắm vào Cursor.com, và khi cài đặt sẽ gửi thông tin hệ thống đến một dịch vụ web bên ngoài
  • Người phát tán là người dùng npm sn4k-s3c, sử dụng các tên gợi nhớ đến gói nội bộ của Cursor như cursor-retreival, cursor-always-local, cursor-shadow-workspace
  • Đầu ra env mà các gói lấy đi có thể chứa biến môi trường nhạy cảm như khóa AWS, token npm, thông tin xác thực GitHub, nên phạm vi ảnh hưởng có thể lớn
  • OpenSSF package analysis scanner đã xác định các gói này là độc hại, và OSV đã tạo 3 cảnh báo MAL-2025-27, MAL-2025-28, MAL-2025-29
  • Trong metadata npm, email snyk.io của Snyk Security Labs xuất hiện là nhà phát hành, sau đó nhà nghiên cứu của Snyk đã gỡ các gói xuống và Snyk phản hồi bằng một bài blog

Các gói npm có vẻ nhắm vào Cursor

  • Trong quá trình phát hiện gói độc hại của SourceCodeRed, nhiều gói được tải lên npm đã được phát hiện
  • Tên gói có dạng gợi nhớ đến các gói nội bộ liên quan đến Cursor
    • cursor-retreival
    • cursor-always-local
    • cursor-shadow-workspace
  • Người phát tán được hiển thị là người dùng npm sn4k-s3c
  • Danh sách gói được cho là có thể xem tại https://www.npmjs.com/~sn4k-s3c

Hành vi được thực hiện khi cài đặt

  • Khi cài gói, dữ liệu hệ thống sẽ bị thu thập và gửi đến dịch vụ web do kẻ tấn công kiểm soát
  • Theo ảnh chụp màn hình, gói lấy đầu ra của lệnh env
  • Đầu ra env có thể bao gồm các biến môi trường nhạy cảm cùng với cấu hình hệ thống
    • khóa AWS
    • token npm
    • thông tin xác thực GitHub
    • các biến môi trường nhạy cảm khác
  • Kết quả là chỉ cần cài đặt cũng có thể khiến thông tin môi trường cục bộ bị rò rỉ ra bên ngoài

Khả năng dependency confusion và kết quả phát hiện

  • Những gói kiểu này thường xuất hiện trong các cuộc tấn công dependency confusion nhắm vào một công ty cụ thể
  • Chưa xác nhận được liệu Cursor.com có chương trình bug bounty hay bối cảnh cụ thể nào khác hay không
  • SourceCodeRed nghi ngờ Cursor có thể đang dùng các gói npm riêng tư như cursor-always-local, cursor-retrieval, cursor-shadow-workspace
  • Kẻ tấn công có thể đã kỳ vọng nhân viên Cursor vô tình cài gói công khai và gửi dữ liệu đi
  • OpenSSF package analysis scanner đã xác định các gói này là độc hại, và OSV đã tạo 3 cảnh báo mã độc

Metadata của nhà phát hành

  • Trong metadata gói npm, nhà phát hành dùng địa chỉ email snyk.io của đội Snyk Security Labs
  • Metadata email nhà phát hành này được mô tả là phần không thể bị giả mạo
  • Trường author nêu đích danh một nhân viên Snyk
  • Trường author có thể bị giả mạo, nhưng vì nhà phát hành dùng email Snyk đã được xác minh nên có suy đoán rằng gói thực sự xuất phát từ Snyk

Phản ứng của người dùng và cập nhật sau đó

  • SourceCodeRed cho biết đã báo cho npm, nhưng vào thời điểm đó các gói vẫn chưa bị đánh dấu là độc hại
  • Nhiều công cụ bảo mật chuỗi cung ứng phần mềm chỉ có thể chặn khi chúng biết gói đó là độc hại
  • Khuyến nghị là không cài các gói npm một cách vô điều kiện
  • Các gói này chỉ chứa hai tệp là package.json và index.js hoặc main.js, đây có thể được xem là một dấu hiệu đáng ngờ
  • Theo cập nhật ngày 15/01/2025, nhà nghiên cứu của Snyk đã gỡ các gói liên quan đến Cursor xuống vào ngày sau khi bài blog được công bố
  • Ngày 14/01/2025, The Register đã đăng bài liên quan: https://www.theregister.com/2025/01/14/snyk_npm_deployment_removed/
  • Cùng ngày, Snyk đã đăng phản hồi trên blog và khẳng định theo hướng rằng họ không làm gì sai: https://snyk.io/blog/snyk-security-labs-testing-update-cursor-com-ai-code-editor/

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-01-14
Ý kiến trên Hacker News

  • [Chỉnh sửa: Xem phản hồi của nhà phát triển Cursor bên dưới thì có vẻ không phải Cursor phê duyệt việc này] Nghe như bên trong Cursor có một NPM registry riêng tư chứa các gói đó, và do cách NPM hoạt động nên kẻ tấn công dễ lừa để lấy gói cùng tên từ registry công khai
    Có lẽ một nhân viên Snyk đã phát hiện hoặc nghi ngờ rằng một phần bản build của Cursor bị cấu hình sai theo kiểu này, nên đã đăng gói lên như một bằng chứng khái niệm. Nhìn mô tả gói là “for Cursor” nên tôi tưởng họ được thuê cho mục đích này
    Nếu vậy thì cũng không có gì quá lớn; nếu trọng tâm là cho thấy cấu hình sai khiến bỏ qua registry riêng tư, thì nhà nghiên cứu bảo mật hẳn không thể dùng NPM registry riêng tư cho bằng chứng khái niệm được
    Đặc biệt, nhiều proxy sẽ chọn registry công khai thay vì registry riêng tư nếu phiên bản gói mới nhất ở đó cao hơn: https://snyk.io/blog/detect-prevent-dependency-confusion-att...

    • Tôi là nhà phát triển Cursor. Suy đoán này hợp lý, nhưng thực tế hơi khác. Các gói Snyk chỉ là tên các extension mà chúng tôi bundle kèm, và chúng tôi không đóng gói chúng hay đưa chúng lên bất kỳ registry nào
      Chúng tôi xử lý theo cùng cách với VS Code: https://github.com/microsoft/vscode/tree/main/extensions
      Chúng tôi không thuê Snyk; sau khi thấy việc này và liên hệ với họ, chúng tôi đã nhận được lời xin lỗi. Chúng tôi chưa được xác nhận chính xác họ định làm gì, nhưng lời giải thích rằng ai đó nghi ngờ có lỗ hổng dependency confusion nghe có vẻ hợp lý. Tuy vậy, việc thực sự gửi biến môi trường từ NPM công khai là khá vô trách nhiệm theo tôi
    • Bằng chứng khái niệm hoàn toàn có thể thực hiện mà không gửi thông tin host đã cài đặt và toàn bộ biến môi trường ra bên ngoài. Việc đó có vẻ đã vượt quá giới hạn
    • Việc cho ai đó toàn quyền truy cập toàn bộ môi trường của tôi, tức là toàn bộ đầu ra của lệnh env, sẽ là vấn đề lớn với hầu hết mọi người
    • Tôi phụ trách DevRel & SecRel tại Snyk. Tôi vừa công bố một bài viết để làm rõ các tin đồn, trong đó có khá nhiều thông tin sâu về tình hình: https://snyk.io/blog/snyk-security-labs-testing-update-curso...
    • Chẳng phải chuyện này lẽ ra nên được NPM sửa rồi sao? Tôi nhớ một nhà nghiên cứu bên PortSwigger từng thuyết trình về vấn đề này, và hồi đó gần như mọi công ty FAANG như Apple, Microsoft, Meta đều bị ảnh hưởng

  • Thú vị là đồng sáng lập Snyk đã khởi nghiệp một công ty cạnh tranh với Cursor
    https://www.tessl.io/ https://techcrunch.com/2024/11/14/tessl-raises-125m-at-at-50...
    Hy vọng là không có hành vi gian lận nào

    • Vì mọi lần tương tác của tôi với họ đều rất tiêu cực, nên tôi cho rằng khả năng đã có hành vi gian lận là khá cao

  • Có vẻ từ giờ mọi hoạt động phát triển phần mềm cần được làm nghiêm túc bên trong máy ảo. Mỗi dự án một VM. Có quá nhiều cách tinh vi để tôi có thể vô tình mắc lỗi mà làm hỏng bảo mật lúc nào không hay. Điều an ủi duy nhất là tôi chỉ là kẻ vô danh, không có bí mật hay tài sản gì để bị đánh cắp
    Chúng ta đang đặt niềm tin mù quáng vào quá nhiều mã: IDE, plugin, tiện ích phát triển, thư viện ngôn ngữ, gói hệ điều hành, v.v.

    • Có vẻ Docker container đã làm Vagrant bớt được ưa chuộng, nhưng với tư cách là cách dựng môi trường phát triển thì tôi vẫn thích Vagrant nhất
      Ở một nơi tôi từng làm vài năm trước, họ cấm dùng trình duyệt web và công cụ phát triển trên laptop. Nếu cần trình duyệt thì phải dùng qua Citrix, nếu cần viết code thì phải dùng VDI hoặc chạy công cụ bên trong VM
      Lúc đó cách làm ấy trông gần như điên rồ, nhưng tôi ngày càng hiểu ra
    • Vấn đề thật sự là hiệu năng đồ họa của VM. Đến giờ vẫn đơn giản là khá tệ. Chạy Cinnamon trong VM thì gần như không thể làm GL acceleration hoạt động tử tế
      NVIDIA khóa tính năng GPU ảo hóa sau các card enterprise, nên rốt cuộc phải dựa vào việc chuyển đổi lệnh không mấy hiệu quả
      Hầu hết overhead khác của VM thì còn chịu được, nhưng GUI giật và không phản hồi có tác động xấu đến công thái học hơn ta tưởng, và kỳ lạ là còn kéo tụt cả các hiệu năng khác
      Nếu vấn đề này được giải quyết, dù chỉ trong trường hợp ảo hóa Linux trên Linux, thì lựa chọn ảo hóa mọi thứ sẽ thực tế hơn nhiều
    • Thật đáng sợ khi niềm tin sụp đổ đến mức này, và việc hệ điều hành nhận các bản cập nhật hàng GB mỗi tháng cũng không khiến tôi yên tâm. Ý tưởng có một VM cô lập ổn định cho từng dự án nghe rất hợp lý. Có công cụ mã nguồn mở chuẩn nào cho việc này không?
      Cụ thể là tôi đang chuyển môi trường phát triển Go và Zig từ một máy Mac cũ sang Asahi Linux trên M1, và đã loay hoay ngay từ việc tìm thứ thay thế TrueCrypt và Little Snitch. Các công cụ VM kiểu này có hỗ trợ VM được mã hóa và quy tắc tường lửa không? Ở đây có nhắc đến Vagrant và có vẻ nó giải quyết phần nào việc cô lập mạng, nhưng ngoài ra còn có thể khuyến nghị gì?
    • Tôi hiểu cảm giác đó, và bản thân tôi cũng đã nghĩ chuyện này nhiều lần. Hiện giờ tôi không muốn làm vậy, mà lý do chính không phải vì tốn công
      VM có thể bảo vệ tôi, nhưng không bảo vệ người dùng phần mềm mà tôi tạo ra. Làm sao tôi có thể gửi cho khách hàng một sản phẩm mà chính tôi phải mặc đồ bảo hộ mới dám chạm vào, rồi kỳ vọng họ dùng nó an toàn mà không có bảo vệ?
      Môi trường tôi mong muốn không phải như vậy
      Giải pháp hiện tại là cực kỳ khắt khe khi chọn phụ thuộc. Cụ thể hơn, tôi nghĩ không nên tin dự án hay công ty, mà chỉ nên tin con người. Không dễ, nhưng hiện tại tôi chưa thấy lựa chọn nào tốt hơn
    • Tôi phát triển nhiều dự án trên Linux. Chủ yếu vì lo các công cụ, script build và test có thể đọc dữ liệu nhạy cảm hoặc vô tình phá hủy dữ liệu, nên tôi dùng Linux namespace và bubblewrap để hạn chế quyền truy cập file khi làm việc trong dự án
      Tôi ghi các bind filesystem vào một file dot đơn giản theo từng dự án, và khi mở terminal mới trong lúc làm việc thì nó tự động được cô lập theo file dot đó. Gánh nặng nhận thức rất thấp và tích hợp gần như liền mạch. Tôi đoán nhiều lập trình viên cũng có script tương tự. Trước đây tôi từng tìm một dự án như vậy nhưng không thấy; không rõ là vì nó quá đơn giản nên chẳng có gì để biến thành dự án, hay vì tôi không biết người khác gọi nó là gì. Nếu có thứ gì đáng tham khảo thì tốt quá
      Tôi không hạn chế truy cập mạng. Tôi từng thử ghi lại toàn bộ lưu lượng và tự động thiết lập proxy man-in-the-middle, nhưng nó chưa đủ tiện để dùng như người dùng bình thường. Tất nhiên bề mặt tấn công kernel vẫn còn. Tuy vậy mối lo chính của tôi là file bị đọc hoặc bị phá hủy

  • Phần tôi không đồng ý trong bài là đoạn: “Không nên cài đặt mù quáng các gói NPM, và có những tín hiệu để xem gói có đáng ngờ không. Các gói này chỉ có hai file là package.json và index.js hoặc main.js, nên đó là một trong các cờ để đánh giá có bình thường hay không”
    Điều này có thể phần nào đúng với gói cấp cao nhất, nhưng gần như không thể kiểm tra toàn bộ phụ thuộc bắc cầu
    Nếu kéo về một gói có 400 phụ thuộc, làm sao kiểm tra tử tế được dù chỉ 10% bề mặt đó? https://gist.github.com/anvaka/8e8fa57c7ee1350e3491#top-1000...

    • Lời khuyên bảo mật áp dụng khi đó sẽ khác: đừng kéo về một gói có 400 phụ thuộc
    • Ở điểm này, hướng đi lớn của SELinux là đúng. Nếu phân loại trước file theo mức độ nhạy cảm dữ liệu và từ chối truy cập dựa trên đó, vấn đề này — chẳng hạn ngăn việc cài NPM truy cập id_rsa — có thể được giải quyết khá tốt
    • Một component carousel cho React rốt cuộc làm sao lại có hơn 400 phụ thuộc được…
    • Công ty chúng tôi dùng một công cụ bảo mật tuyệt vời tên là Snyk. Nhất định nên thử xem /s

  • Snyk cũng là công ty không xoay vòng khóa công khai mà cứ đổi cái rụp không báo trước: https://github.com/snyk/cli/pull/5649
    Nếu một dự án chuyển sang dịch vụ lưu trữ repository khác không phải GitHub, họ gắn nhãn “abandoned”, và dù có bản phát hành mới trên npm/PyPI thì nó vẫn tiếp tục bị coi là dự án bị bỏ rơi
    Tôi không nghĩ năng lực của họ lớn như danh tiếng
    Ngoài ra một nhân viên sales của Snyk đã xúc phạm tôi qua email. Có vẻ việc tôi không quan tâm đến mua sản phẩm đồng nghĩa với chuyện tôi là một developer kém cỏi chỉ biết dùng phần mềm đầy lỗ hổng

    • Họ cũng phạt điểm cả những thư viện đã phát triển xong và chỉ cần bảo trì tối thiểu
      Trông giống kiểu phần mềm hoàn toàn ngược đời mà doanh nghiệp mua chỉ vì công ty bảo hiểm bắt điền các mục trong checklist bảo mật
    • Cái nhãn “abandoned” đó đặc biệt đáng tiếc. Gần đây tôi cũng đang cố rời khỏi GitHub, và có cảm giác GitHub đang nắm quá nhiều quyền kiểm soát
      Codeberg trông khá thú vị, và nếu cáng đáng được việc bảo trì thì các lựa chọn tự host như Forejo cũng có vẻ tốt
    • Chuyển sang repository khác không phải GitHub là bị coi là “abandoned”, rồi dù có bản phát hành mới trên npm/PyPI vẫn bị giữ nguyên như vậy, đúng là dấu hiệu của một đội ngũ tốt /s
      Tôi chưa nghe nhiều về Snyk ngoài chuyện họ khá kiêu, nhưng đây là một góc nhìn khá thú vị
    • Chắc bạn có thể cung cấp nội dung email đó ở dạng đã che các phần phù hợp chứ?

  • Nếu không có thêm bối cảnh thì phía Snyk trông cũng không ổn. Điều đó có nghĩa là nhân viên đã dùng NPM để thử nghiệm dịch vụ của chính công ty trong môi trường thực, hoặc khi thực hiện một cuộc kiểm toán hợp pháp đối với Cursor thì thiếu kiểm soát và quy trình để tránh dùng tài nguyên công khai

    • Vì sao không được? NPM hành xử kỳ lạ nếu có một gói công khai trùng tên với gói trong kho riêng tư, và trong một số trường hợp nó sẽ lấy gói công khai. Theo tôi biết, chuyện này được gọi là chiếm trước tên gói. Có thể trong quá trình đánh giá họ chỉ đang cho thấy điều này là khả thi. Theo tôi thì không có thiệt hại và cũng không có vấn đề gì

  • Trông giống một cuộc kiểm toán white-hat của Snyk. Có vẻ bị phát hiện vì oastify.com là máy chủ mặc định của Burp Collaborator
    Lẽ ra bài kiểm thử phải dùng kho npm riêng tư, và ghi đè cục bộ cũng không khó. Họ cũng nên dùng máy chủ Collaborator riêng

    • Đây không phải white-hat vì họ đã chủ động rút dữ liệu ra ngoài. Nếu chỉ để chứng minh nó hoạt động, chỉ cần in console.log, làm npm install thất bại, hoặc dùng cách không trích xuất payload là đủ

  • Có vẻ NPM đang tạo ra việc làm cho ngành bảo mật. Đó là một mớ hỗn độn không thể sửa, và tôi hy vọng các đối thủ như JSR sẽ tạo đủ áp lực lên tổ chức này

    • Đây không chỉ là vấn đề của riêng NPM mà là vấn đề niềm tin vào thư viện bên thứ ba nói chung. Dù hiếm hơn nhiều, các nền tảng như NuGet cũng có exploit. JSR rồi cũng sẽ có. Nhờ tính bất biến nên bảo mật tốt hơn, nhưng nó không ngăn được việc tải về gói độc hại trước khi gói đó bị phát hiện
      Ngược lại, các quy định như DORA và NSIS nhiều khả năng sẽ ngày càng yêu cầu kiểm toán gói bên thứ ba. Điều này sẽ buộc các ngành quan trọng phải thay đổi cách phát triển. Ngoài ra, trong kỷ nguyên LLM, tôi cho rằng việc dùng gói bên ngoài sẽ giảm đi rất nhiều. Vì sao phải kéo một gói bên ngoài về chỉ để làm những việc như tạo đặc tả OpenAPI? Chỉ cần một hai giờ cấu hình, LLM có thể viết cho bạn script CLI cần thiết. Tương tự, ngay cả khi không dùng LLM để tự động sinh trực tiếp các phần mã nhàm chán, bạn có thể nhờ nó tạo công cụ CLI làm việc đó. Khi đó bạn không phải phụ thuộc vào yếu tố bên ngoài; gần như chắc chắn các công cụ CLI đó sẽ là thứ code kiểu cao bồi lộn xộn, nhưng đầu ra có thể được tinh chỉnh bằng cách cải thiện công cụ để ra đúng dạng mong muốn
      Nhìn vào những ngôn ngữ như Go, vốn nhồi những thứ cần thiết vào các gói chuẩn, có thể thấy một thế giới nơi chỉ với thư viện chuẩn cũng làm được rất nhiều việc một cách rất dễ dàng

  • Hơi lạc đề, nhưng có ai từng nhận được SBOM đúng nghĩa cho chính các công cụ và dịch vụ của Snyk chưa? Tôi hỏi vì họ đang cố bán cho công ty tôi một giải pháp tạo SBOM

    • Snyk là công ty do những người từng thuộc Unit 8200 của quân đội Israel sáng lập
      Có trả tiền tôi cũng không nghĩ mình sẽ cài. Unit 8200 liên tục sản sinh nhà sáng lập và rót vốn cho họ, khiến tôi có cảm giác như NSA đã đặt được một chân vào trong cửa
    • Tôi có kết quả tốt hơn với Syft
    • Theo kinh nghiệm của tôi thì có nhiều cảnh báo sai

  • Snyk Research Labs thường xuyên đóng góp cho cộng đồng thông qua việc thử nghiệm và nghiên cứu các gói phần mềm phổ biến. Nghiên cứu Cursor lần này không có ý đồ ác ý, và các gói có kèm thông tin liên hệ của Snyk Research Labs cũng như nhà nghiên cứu. Chúng tôi đang xem xét rất cụ thể hiện tượng dependency confusion trong một số extension VS Code, và các gói đó không phải thứ mà nhà phát triển sẽ tự cài đặt
    Snyk tuân theo chính sách công bố có trách nhiệm. Không ai lấy các gói này, nhưng nếu có ai đó lấy, chúng tôi đã lập tức có hành động tiếp theo

    • Rải một cuộc tấn công ra không gian công cộng rồi hy vọng nó trúng mục tiêu là điều hoàn toàn trái ngược với hành vi có trách nhiệm. Phần duy nhất “tốt” là họ bị bắt quả tang trước khi ai khác dính đạn lạc
      Cách phản ứng nghe như gửi thư xin lỗi đến đám tang của người bị trúng. Dù là “ý định tốt”, nếu bạn xâm phạm thông tin xác thực thì người đó đã bị xâm phạm rồi, và phải phản ứng y như khi bị một kẻ tấn công ác ý tấn công
      Chuyện này gần đến mức khó cảm nhận được khác biệt với hành vi ác ý
      Thêm nữa, mọi người cũng nên nhớ rằng một bên liên quan của Snyk hiện đang chuẩn bị ra mắt sản phẩm cạnh tranh với Cursor. Điều này khiến việc giả định thiện chí khó hơn rất nhiều
    • Tốt thôi. Nhưng tại sao lại gửi biến môi trường của người dùng về nhà? Để xác nhận lỗ hổng, chỉ cần gửi giá trị giả thay vì giá trị môi trường thật là đủ
    • Nhìn theo hướng tốt nhất thì đây cũng là gray-hat. Ý định có thể tốt, nhưng nhóm này đã tạo và phân phối phần mềm truy cập rồi rò rỉ dữ liệu khi chưa được phép, và điều đó cực kỳ bất hợp pháp. Trước khi đăng những bài như thế này lên diễn đàn công khai, tốt hơn là nên trao đổi với đội pháp lý
    • Nghe thì có vẻ hợp lý, nhưng tại sao lại gửi ngược các biến môi trường bằng POST? Dù hoàn toàn thiện chí, tôi cũng không muốn một gói tùy ý có đầu ra env của mình
    • Có khả năng đây thật sự là CTO của Snyk và câu trả lời chính thức thì mọi người nên thấy nên tôi vẫn upvote, nhưng chuyện này thật sự có vẻ vô trách nhiệm. Họ hoàn toàn có thể làm bằng chứng khái niệm mà không thực sự đánh cắp thông tin xác thực của các nhà phát triển vô tội
      Hơn nữa, vì có xung đột lợi ích với một sản phẩm cạnh tranh Cursor, họ càng phải cẩn trọng hơn. Cả việc ra quyết định lẫn cách phản hồi đều tệ