Phát hiện các gói npm độc hại trên toàn bộ Red Hat Cloud Services

 (github.com/RedHatInsights)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Vấn đề này hiện vẫn đang mở, và tại thời điểm bài viết được ghi lại chưa có người phụ trách, mốc phát hành, nhánh liên kết hay PR liên quan
  • Đây được ghi nhận là một sự cố bảo mật khi phát hiện các phiên bản độc hại trong nhiều bản phát hành npm thuộc phạm vi @redhat-cloud-services/
  • Tài liệu tham khảo được đưa ra gồm bài phân tích của StepSecurity và kết quả tìm kiếm OSS Security Feed
  • Danh sách ảnh hưởng đã được cập nhật bao gồm 32 gói, như @redhat-cloud-services/chrome, frontend-components, rbac-client, types, vulnerabilities-client và các gói khác
  • Các phiên bản bị xâm phạm trong bảng hầu hết là 3 phiên bản cho mỗi gói, riêng @redhat-cloud-services/vulnerabilities-client chỉ gồm hai phiên bản 2.1.9 và 2.1.11
  • Tính theo toàn bộ bảng, có thể thống kê được 95 phiên bản bị xâm phạm; tiêu đề của một PR bên ngoài được nhắc riêng cũng chỉ ra 95 versions
  • Dòng @redhat-cloud-services/frontend-components-* cùng nhiều gói *-client cũng nằm trong danh sách, cho thấy đây không phải vấn đề của một gói đơn lẻ mà là sự cố phát hành trên toàn bộ cùng một scope
  • Trong phần bình luận, trước câu hỏi “What are these?”, có câu trả lời “all that module is pwned”, cho thấy mọi mục trong danh sách đều được hiểu là đã bị xâm phạm
  • DanielRuf cho biết đã thêm sự việc này vào supply-chain-incidents
  • Hoạt động trên GitHub cho thấy có nội dung tóm tắt tham chiếu đến issue này và một PR liên quan đến phát hiện, nhưng trong nội dung chính vẫn chưa có chẩn đoán, biện pháp giảm thiểu, việc gỡ bỏ hay phiên bản đã được sửa từ phía Red Hat

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến Hacker News

  • Hy vọng vẫn ổn nếu mượn lại luồng này để nói về thiết lập cooldown. axios, tanstack, @redhat-cloud-services và nhiều cuộc tấn công chuỗi cung ứng npm gần đây có lẽ đã bị chặn nếu có cooldown
    Nếu dùng Artifactory/Nexus thì rất có thể đã có sẵn, còn nếu chưa có thì cũng dễ cấu hình. Phần lớn các vụ xâm phạm npm hay PyPI đều bị gỡ xuống trong vòng vài giờ, nên chỉ cần bỏ qua các gói được phát hành chưa quá N ngày là đủ. 1 ngày cũng có tác dụng, 3 ngày là ổn, còn 7 ngày thì hơi quá nhưng vẫn hiệu quả
    pnpm mới nhất đã bật cooldown 1 ngày theo mặc định: https://pnpm.io/supply-chain-security
    Nếu muốn làm xong chỉ với một cú nhấp, có thể dùng https://depsguard.com. Đây là CLI thêm cooldown và các cấu hình được khuyến nghị cho npm, pnpm, yarn, bun, uv, dependabot, và tôi là người duy trì nó
    Cũng có https://cooldowns.dev tập trung nhiều hơn vào cooldown, cùng các script hỗ trợ thiết lập cục bộ. Tất cả đều là mã nguồn mở/miễn phí
    Nếu bạn biết tự chỉnh ~/.npmrc v.v. thì không thật sự cần, nhưng nếu quanh bạn có người chỉ cần bản sửa một cú nhấp thì nó có thể giúp tránh được đợt tấn công tiếp theo
    Tuy vậy, khi cần vá một CVE nghiêm trọng mới xuất hiện thì phải có cách vượt qua cooldown, và mỗi công cụ đều có cách làm việc đó. Tôi không có số liệu chính xác cho vài tháng gần đây, nhưng ngay cả trong thời đại phát hiện lỗ hổng kiểu Mythos, rủi ro từ các cuộc tấn công chuỗi cung ứng phần mềm như phát hành phiên bản độc hại có vẻ vẫn lớn hơn so với CVE zero-day mới

    • Là một lập trình viên embedded, tôi đã quen với việc cố định toolchain và dependencies suốt nhiều năm, nên văn hóa phát triển web ở nhiều mặt thật sự gây sốc
    • Có kho GitHub của một người bạn tổng hợp các cách cấu hình hợp lý và an toàn hơn một chút: https://github.com/jordanconway/package-manager-hardening
    • Có cách hợp lý nào để thêm cooldown cho việc pull image Docker/Podman không?
    • Ngay cả với người có thể mở file ~/.npmrc và thêm một dòng, tôi vẫn cảm thấy nhóm thực sự cần bản sửa một cú nhấp là rất nhỏ
    • Ngoài cooldown, sẽ tốt hơn nếu nhiều trình quản lý gói có thể xử lý riêng bản sửa bảo mật và các bản phát hành thông thường (sửa lỗi/cải thiện hiệu năng/tính năng mới)
      Hoàn toàn có thể nói rằng “bản sửa bảo mật chỉ nên chứa sửa bảo mật và không được kèm tính năng khác”. Khi đó cả nhà nghiên cứu bảo mật lẫn công cụ đều sẽ dễ kiểm toán hơn
      Có thể áp dụng cooldown cho các bản phát hành thông thường, còn với bản sửa bảo mật thì bỏ cooldown hoặc rút ngắn rất nhiều
      Mô hình như Debian, với các máy chủ cực kỳ ổn định và có thể cấu hình unattended upgrades chỉ áp dụng cho bản sửa bảo mật, là điều đáng để tham khảo. Những bản phát hành gói mới kiểu này cũng dễ để các nhà nghiên cứu bảo mật kiểm toán hơn

  • Mỗi khi có những thảo luận kiểu này, thường có rất nhiều bình luận hành xử như thể kiểu tấn công này chỉ tồn tại ở npm, hoặc mỉa mai như thể chẳng hề có biện pháp nào được đưa ra, nhưng tôi thấy như vậy là không công bằng
    Cũng có nhiều bình luận nhắc đến các tính năng hữu ích như delay line và pnpm đã được đưa vào để bảo vệ người dùng tiêu thụ gói
    Phần ít được nhắc tới hơn là các công cụ phía người bảo trì gói. MFA cho phát hành: https://docs.npmjs.com/requiring-2fa-for-package-publishing-..., và trusted publishers đã được cung cấp từ khoảng 1 năm trước: https://docs.npmjs.com/trusted-publishers
    Gần đây còn có staged publishing, kết hợp ưu điểm của cả hai tính năng: https://docs.npmjs.com/staged-publishing
    Giờ đây có thể phát hành từ CI mà không cần thông tin xác thực tĩnh, đồng thời yêu cầu người bảo trì phê duyệt bằng MFA trước khi thực sự được công khai lên registry. Nếu muốn, còn có thể dùng GitHub Actions Environments protection để yêu cầu nhiều lượt phê duyệt hoặc độ trễ thời gian ở phía CI
    Cộng đồng nên được khuyến khích áp dụng những cơ chế bảo vệ phát hành như vậy, nếu không thì vấn đề này sẽ còn tiếp diễn

    • Theo [1], “tất cả các gói bị ảnh hưởng đều được phát hành qua GitHub Actions OIDC từ kho RedHatInsights/javascript-clients, điều này cho thấy chính pipeline CI/CD thượng nguồn đã bị xâm phạm”
      Khi đó, các gói độc hại cũng sẽ nhận được ngôi sao xanh và khiến người dùng yên tâm rằng chúng “được build và ký kèm chứng thực nguồn gốc”
      [1] https://lwn.net/Articles/1075742/
    • Vì chuyện này cứ tiếp diễn nên cũng buồn cười thật. Các vụ tấn công npm nhiều đến mức có thể đánh dấu lên lịch, và thậm chí có người còn làm một bản nhại theo bài kinh điển của The Onion “không có cách nào để tránh” phiên bản npm
      Việc đang có nỗ lực để ngăn chặn là rất đáng hoan nghênh, nhưng dù vậy nó vẫn tiếp tục xảy ra. Cái buồn cười là theo kiểu “lại nữa rồi”
    • Chỉ khi bắt buộc với tất cả mọi người thì lúc đó mới thật sự coi là đã làm gì đó
    • Có vẻ có một nhóm người không mấy ấn tượng với các thay đổi mang tính cơ học và xem đây là vấn đề văn hóa
      Nhìn từ bên ngoài, phát triển web có một kiểu năng lượng như miền viễn Tây hỗn loạn. Có tính khả biến, kiểu động, các tiêu chuẩn và framework thay đổi liên tục, triển khai liên tục, CDN, chiến dịch A/B thời gian thực, rất nhiều phụ thuộc, và dữ liệu người dùng nhạy cảm rải khắp nhiều hạ tầng
      Tôi không nói góc nhìn đó là chính xác, cũng không nghĩ thái độ “thấy chưa” là đúng, nhưng tôi hiểu nó xuất phát từ đâu
    • Theo tôi, cả hai đều là giải pháp kiểu tô son cho lợn. Cuối cùng thì tất cả chỉ là biến thể của “hãy làm cho việc phát hành release khó hơn”, và chỉ dạy mọi người cách lách qua chúng thôi
      Đặc biệt, chẳng cái nào trong hai thứ đó có thể ngăn backdoor xz-utils lọt vào một bản phát hành gói. xz-utils vẫn là cột mốc chuẩn cho một vụ xâm phạm thượng nguồn tinh vi
      Lỗi ở đây không phải là ta cần xác thực tốt hơn cái thượng nguồn mà ta đã tin, mà là ta không thể tin thượng nguồn như nguồn duy nhất của bảo mật. Thượng nguồn là một tập hợp hacker ít quan tâm đến kỹ nghệ phát hành vững chắc và cũng không làm tốt việc đó
      Nhưng cũng có những người làm tốt. Giải pháp của thế giới Linux, và cũng là cách đã cứu chúng ta khỏi xz-utils, là tồn tại một tầng con người thứ hai để rà soát, kiểm toán, đóng gói và tùy biến phần mềm thượng nguồn do hacker tạo ra cho người dùng
      Những người này có một góc nhìn khác, nhu cầu người dùng khác và tiêu chuẩn chất lượng khác, nên họ phát hiện được lỗi và ác ý mà thượng nguồn chưa sẵn sàng bắt ra
      NPM, cargo, PyPI và các hệ sinh thái tương tự cứ nghĩ rằng họ có thể lách qua nhu cầu về lao động thủ công này, nhưng họ không thể. Hệ sinh thái NPM đặc biệt dễ gặp chuyện này hơn Python hay Rust trong các gói node vì ở đó có rất nhiều lập trình viên web đã quen với nhịp phát hành cực nhanh, yêu cầu tương thích lỏng lẻo và mức tái sử dụng cực đoan

  • Công ty tôi dùng yarn 4, và có một tùy chọn chặn cài đặt trong vài ngày đầu sau khi gói npm được phát hành. Có vẻ phần lớn các cuộc tấn công kiểu này đều bị phát hiện trong khoảng thời gian đó (1~3 ngày)
    https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...

  • Có vài đề xuất. Cooldown phụ thuộc 1~2 ngày có vẻ rất hiệu quả mà không làm giảm khả năng vá CVE
    Mọi nơi có chạy mã, như npm install, npm test, đều nên chạy trong môi trường không có đặc quyền. Trên GitHub Actions, việc tách job build·test artifact khỏi job triển khai·ký tên v.v. là tương đối đơn giản. Nếu dùng AI, chỉ cần thêm skill/hướng dẫn để ép buộc mẫu này
    Nếu dùng GitHub Actions thì cài zizmor bản mới nhất sẽ cải thiện đáng kể tư thế bảo mật
    Biện pháp thứ hai giúp nó không còn có thể “lan truyền như sâu” nữa, và giảm bớt một phần lớn vấn đề hiện nay. Biện pháp thứ nhất giúp các công ty có thêm thời gian để phản ứng với cuộc tấn công. Một số vendor trong lĩnh vực này cũng đáng để đánh giá

    • Nếu zizmor bị xâm phạm thì sao?
      Nghe khá buồn cười như một câu đùa, ngay sau khi vừa nói rằng nên trì hoãn các gói mới
    • Thay vì cooldown như vậy, chẳng phải chỉ cần chạy build trong ngữ cảnh cô lập là được sao?
      Chạy một Maven proxy cục bộ, và mọi bản build đều thực hiện trong container. Python, npm, Go chỉ dùng kho công khai nên các build này cũng chạy trong container, nhưng không cần proxy cho kho
    • Với mọi nơi có chạy mã, có vẻ các agent orchestrator như codex, claude-code mặc định đều làm như vậy

  • Đúng vào cùng ngày Red Hat và IBM công bố Project Lightwell để hỗ trợ phát hiện và khắc phục lỗ hổng chuỗi cung ứng
    https://www.redhat.com/en/lightwell

  • Vài ngày trước tôi thấy bài rant thú vị này: https://github.com/uNetworking/uWebSockets.js/blob/master/mi...
    Cũng có lý khi nói rằng cách đúng đắn là fork mọi dependency mình dùng, rồi khi cần thì rà soát và merge từ upstream trong lúc cài đặt từ kho của chính mình. Chỉ là có vẻ sẽ cực kỳ phiền phức

    • Đây không phải việc không thể tự động hóa. Bên Go có thể gọi cách này là vendoring: https://go.dev/ref/mod#vendoring
      Cách này tốt để giảm hoặc loại bỏ sự phụ thuộc vào các nhà cung cấp dịch vụ lưu trữ dependency bên thứ ba, đưa dependency vào trong công cụ review code của mình, và về lâu dài bảo đảm build có thể tái lập
    • Vấn đề là dependency của dependency, rồi lại tiếp tục xuống nhiều tầng bên dưới nữa
    • Tôi đã tạo Packj để dễ kiểm toán dependency từ CLI
      Packj(https://github.com/ossillate-inc/packj) phát hiện các dependency độc hại trên PyPI/NPM/Ruby/PHP... bằng phân tích hành vi. Nó quét các chỉ dấu xâm nhập như thực thi shell, dùng khóa SSH, giao tiếp mạng, sử dụng decode+eval bằng phân tích mã tĩnh + động. Nó cũng kiểm tra nhiều thuộc tính metadata để tìm các tác nhân độc hại như typosquatting
    • Dù có thể thay đổi xác suất, nhưng nếu không chăm chỉ fork và monkeypatch cho mọi lỗ hổng về sau thì bạn có thể sẽ phát hành fork đã bị xâm phạm mãi mãi
    • Chẳng phải ngoài việc giữ package luôn mới thì cũng nên ràng buộc cả số phiên bản sao?

  • Khoảng một tuần trước tôi đã gỡ Node khỏi laptop và thấy rất dễ chịu
    Ngay cả khi xui xẻo dính exploit, tôi cũng đang cố làm mọi thứ trong dev container hoặc sandbox khác để giảm bán kính ảnh hưởng. Kẻ tấn công có thể lấy token Claude, nhưng sẽ không dễ thoát khỏi container để lục lọi thư mục home của tôi
    Cooldown và allowlist script cài đặt là lớp bổ sung rất tốt cho phòng thủ nhiều tầng, đặc biệt trong CI. Nhưng thứ cần thay đổi tận gốc, theo tôi, là mô hình quyền của hệ điều hành. Mặc định tin cậy phần mềm bên thứ ba với toàn bộ quyền người dùng giờ không còn hiệu quả nữa

    • Tôi muốn biết mọi người có dùng những thứ như Bubblewrap/Firejail/Flatpak không, hoặc cấu hình kiểu đó trông như thế nào. Tôi đã nghĩ đến ý tưởng tương tự một thời gian nhưng vẫn chưa bắt tay làm

  • Có lẽ nên gắn link bài công bố gốc
    https://www.stepsecurity.io/blog/multiple-redhat-cloud-servi...

    • Đúng vậy. Với cả trong tiêu đề còn viết sai cả tên Red Hat nữa

  • Giờ tôi có thói quen dùng cờ --before=2026-05-30 khi cài package. Nó buộc chọn các phiên bản được phát hành trước ngày chỉ định, và tôi thường chọn mốc khoảng 5 ngày trước

  • NPM bị hỏng ngay từ thiết kế, và hội chứng NIH lan tràn trong cộng đồng khiến ngay cả các biện pháp đơn giản cũng không làm nổi

    • Tôi không hiểu lắm câu thứ hai. Chẳng phải npm là vấn đề ngược lại với kiểu “không phải tự làm ở đây thì không dùng” sao?
      Vì tiếp nhận quá nhiều package bên ngoài thay vì tự phát triển, các dự án npm có xu hướng có cây dependency lớn và phức tạp. Từ lâu đã có lời phàn nàn rằng các package như https://www.npmjs.com/package/is-windows tạo ra lỗ hổng tiềm ẩn và gánh nặng bảo trì, dù đoạn code tương đương quá dễ để tự viết
    • Một ngộ nhận phổ biến ở phía NIH là nghĩ rằng sẽ tốn rất nhiều thời gian để làm lại package X
      Nhưng rõ ràng đâu cần phải làm lại toàn bộ tính năng, chỉ cần làm phần mình cần là được
      Hơn nữa, khi chỉ code một chức năng thì cũng không cần tạo abstraction hay interface hàm bổ sung. Vì thế sẽ rẻ hơn và có lẽ tích hợp cũng tốt hơn
      Một ngộ nhận khác là nghĩ rằng như vậy sẽ tạo ra bug và lỗ hổng. Với lập trình viên kém thì có thể đúng, nhưng bạn sẽ tránh được cả một lớp lỗ hổng xuất hiện ở ranh giới tích hợp giữa hai thư viện vốn không được thiết kế để khớp chính xác với nhau. Trường hợp đó xảy ra khá thường xuyên