Đã phát tán các phiên bản độc hại của Nx và một số plugin hỗ trợ

• Các phiên bản độc hại của gói Nx và plugin đã được phát tán lên npm, quét hệ thống tệp, thu thập thông tin xác thực, rồi gửi chúng đến kho lưu trữ trên tài khoản Github của người dùng
• Để kiểm tra có bị ảnh hưởng hay không, cần xác nhận xem kho lưu trữ s1ngularity-repository có được tạo trong tài khoản Github hay không
• Nếu đã bị nhiễm, bắt buộc phải thay token và mật khẩu, xóa kho lưu trữ độc hại, kiểm tra các tệp cấu hình shell
• Các phiên bản độc hại tác động đến hệ thống bằng script postinstall; đặc biệt khi dùng plugin VSCode Nx Console, rủi ro bị thực thi ngoài ý muốn tăng cao
• Phía Nx đã triển khai biện pháp ngăn tái diễn và các biện pháp bảo mật bổ sung, đồng thời các phiên bản liên quan đã bị gỡ khỏi npm

---

Tổng quan và tóm tắt

• Cảnh báo bảo mật lần này là một cuộc tấn công chuỗi cung ứng nghiêm trọng nhắm vào gói Nx và một số plugin liên quan, với mã độc được phát tán qua npm
• Các phiên bản độc hại này quét hệ thống tệp của người dùng để thu thập thông tin xác thực, đường dẫn, v.v., rồi tải chúng lên kho Github s1ngularity-repository
• Script postinstall độc hại cũng sửa các tệp cấu hình shell của người dùng (.zshrc, .bashrc) để thêm lệnh tắt hệ thống
• Bài viết trình bày chi tiết vector tấn công, diễn tiến của cuộc tấn công, các phiên bản bị ảnh hưởng, hành động khẩn cấp người dùng cần thực hiện và các biện pháp ngăn tái diễn

Cách xử lý khẩn cấp

Những điều mọi người đều phải kiểm tra

1. Kiểm tra trong danh sách kho lưu trữ của tài khoản Github xem có s1ngularity-repository được tạo hay không
2. Tải xuống các tệp trong kho đó để lưu giữ hồ sơ
3. Xóa kho lưu trữ đó khỏi Github
4. Gửi email đến [e-mail] để được hướng dẫn cách giải mã thông tin bị lộ
5. Ngay lập tức thay toàn bộ thông tin xác thực và token của tất cả tài khoản

Cách thay Github token

• Truy cập https://github.com/settings/connections/…
• Thu hồi quyền truy cập của ứng dụng đã kết nối để vô hiệu hóa token cũ
• Nếu dùng gh CLI, hãy xác thực lại để tạo token mới
• Nếu không xử lý, token cũ có nguy cơ bị lạm dụng

Ngừng dùng và dọn dẹp các phiên bản Nx độc hại

• Kiểm tra phiên bản Nx đang dùng có phải phiên bản độc hại hay không bằng lệnh npm ls nx
• Nếu là phiên bản bị nhiễm, cập nhật bằng npm uninstall nx && npm install nx@latest
• Dọn cache bằng npm cache clean --force

Người dùng đã bị nhiễm

• Thay token npm và Github
• Đặt lại toàn bộ mật khẩu và thông tin xác thực của Github cùng các dịch vụ liên quan
• Kiểm tra trong các tệp .zshrc, .bashrc xem có lệnh lạ bị chèn vào hay không, rồi xóa chúng

Đối với quản trị viên kho lưu trữ gói nội bộ

• Cần xóa ngay các phiên bản độc hại khỏi proxy trong registry nội bộ để chặn lây lan thêm

Thông tin các phiên bản bị ảnh hưởng

Gói Nx

• 21.5.0, 20.9.0, 20.10.0, 21.6.0, 20.11.0, 21.7.0, 21.8.0, 20.12.0
• Đã được gỡ khỏi npm tính đến 10:44 PM EDT

@nx/devkit, @nx/js, @nx/workspace, @nx/node, @nx/eslint, @nx/key, @nx/enterprise-cloud

• Đã được gỡ khỏi npm tính đến 10:44 PM, 6:20 AM EDT

Chi tiết vector tấn công

Nguyên nhân workflow dễ bị khai thác

• Một lỗ hổng cho phép thực thi mã tùy ý đã được đưa vào workflow Github Actions
• Nếu chèn mã bash cụ thể vào tiêu đề PR, workflow sẽ thực thi lệnh hệ thống, tức lỗ hổng Bash Injection
• Do dùng trigger pull_request_target, workflow có quyền nâng cao (GITHUB_TOKEN v.v.) nên bị lợi dụng
• Trước khi bị xóa, workflow dễ bị tấn công vẫn tồn tại trên các nhánh cũ không phải main, cho phép kẻ tấn công chạy workflow bằng PR độc hại và đánh cắp secret

Quá trình đánh cắp npm token

• Kẻ tấn công khiến publish.yml được thực thi thông qua workflow dễ bị tấn công
• publish.yml lưu npm token trong Github Secrets, và trong quá trình đó token bị gửi tới webhook bên ngoài
• Cuối cùng, kẻ tấn công dùng token này để tải lên npm các phiên bản độc hại của Nx và các gói hỗ trợ

Hành vi của gói độc hại

Thu thập thông tin, bao gồm thông tin xác thực, và đăng lên kho Github

• Khi script postinstall của gói Nx bị nhiễm chạy, nó thu thập vị trí của nhiều tệp văn bản và thông tin xác thực
• Dữ liệu được mã hóa base64 và tải lên kho Github có tên s1ngularity-repository
• Ngay cả khi kho thực tế đã bị xóa, vẫn cần tính đến khả năng rò rỉ thông tin vì trước đó nó từng ở trạng thái công khai

Can thiệp vào hồ sơ shell (.zshrc, .bashrc)

• postinstall chèn lệnh sudo shutdown -h 0, có thể khiến hệ thống tắt khi mở terminal và làm lộ mật khẩu

Nhiều kịch bản khác nhau có thể kích hoạt postinstall

• Không chỉ khi chạy trực tiếp npm install/yarn/pnpm install, mà còn có thể chạy trong nhiều tình huống như phụ thuộc bắc cầu, tiện ích mở rộng editor, thực thi script

• Đặc biệt, tiện ích Nx Console cho VSCode (phiên bản 18.6.30 ~ 18.65.1) có thể tự động cài nx@latest khi khởi động editor, từ đó kích hoạt postinstall

• Cần lưu ý rằng việc cài mô-đun NPM có thể diễn ra ở nhiều nơi ngay cả khi không chủ ý

• Từ Nx Console (18.66.0), quy trình cài latest nx đã bị loại bỏ

Dòng thời gian tấn công và ứng phó

Ngày 21 tháng 8

• 4:31 PM: PR chứa lỗ hổng Bash Injection được merge
• 10:48 PM: Bài đăng chỉ ra lỗ hổng được đăng trên X (trước đây là Twitter)

Ngày 22 tháng 8

• Buổi chiều: điều tra nội bộ, rollback workflow dễ bị tấn công (chưa hoàn chỉnh)
• Áp dụng CodeQL để phát hiện các lỗ hổng tương tự trong PR về sau

Ngày 24 tháng 8

• Có commit trong fork của kẻ tấn công cho thấy dấu hiệu làm lộ npm token
• PR độc hại được tạo rồi xóa, và publish.yml đã được thực thi bởi PR này

Ngày 26 ~ 27 tháng 8 (phát tán phiên bản độc hại, ứng phó)

• Nhiều phiên bản độc hại của Nx và plugin lần lượt được phát tán lên npm
• Cộng đồng Github/NPM đã báo cáo sự cố
• 10:44 PM: phía NPM đã xử lý, bao gồm gỡ toàn bộ các phiên bản liên quan
• 11:57 PM: vô hiệu hóa toàn bộ token dùng để phát hành các gói liên quan đến Nx
• Ngày 27 tháng 8: vá Nx Console, bật 2FA, chuyển sang cơ chế Trusted Publisher và các biện pháp bổ sung khác

Biện pháp phòng ngừa trước và ứng phó sau đó

• Bắt buộc 2FA với mọi maintainer trong tổ chức nrwl
• Áp dụng cơ chế Trusted Publisher. Cấm phát hành dựa trên npm token
• Các gói sau này sẽ chỉ được phát hành sau khi vượt qua xác minh dựa trên 2FA và độ tin cậy
• Tiếp tục áp dụng theo từng bước các biện pháp như phát hiện rủi ro bổ sung, phê duyệt PR, bảo vệ nhánh

Bài học và kế hoạch sắp tới

• Một lần nữa nhấn mạnh tầm quan trọng trong và ngoài nước của bảo mật chuỗi cung ứng, pipeline CI/CD và nguyên tắc tối thiểu hóa quyền trong workflow
• Sau khi rà soát lại nội bộ, nhóm dự định chia sẻ các bài học rút ra với cộng đồng

Liên hệ

• Có thể liên hệ qua [e-mail]

Tham khảo và phụ lục

• Các issue chính trên Github, timeline và bài viết liên quan
• Cung cấp ví dụ về script telemetry.js trong gói bị nhiễm
• Script này thu thập đường dẫn các tệp văn bản quan trọng trong hệ thống tệp nhằm tạo inventory

Tóm tắt kết luận

• Việc cập nhật lên bản mới nhất và áp dụng bản vá cho Nx cùng các plugin liên quan là rất quan trọng
• Khuyến nghị thay ngay các thông tin xác thực chính như npm, Github
• Đây là sự cố cho thấy những thiếu sót trong bảo mật chuỗi cung ứng và quản lý quyền workflow có thể dẫn đến tai nạn quy mô lớn

[GN⁺]

Ý kiến trên Hacker News

• Muốn nhắc mọi người định kỳ tắt các script của npm install

  • Ví dụ dùng lệnh sau:

      npm config set ignore-scripts true [--global]
    

  • Có thể dễ dàng áp dụng thiết lập này theo từng dự án hoặc toàn cục

  • Dạo này hiếm có package hợp lệ nào không thể chạy nếu thiếu script, nên đa phần sẽ không thành vấn đề

  • Với những package thực sự cần để hoạt động, có thể xử lý bằng cách tạo script cài đặt riêng và chạy thủ công trong thư mục đó

  • Đây không phải lời giải vạn năng cho tấn công chuỗi cung ứng, nhưng thực tế đã chặn hiệu quả rất nhiều cuộc tấn công qua npm

  • Xem thêm trong tài liệu chính thức của npm config

  • Tôi cũng dùng bubblewrap để cô lập npm, pnpm, yarn và mọi phiên do chúng khởi chạy khỏi hệ thống

    • Mã nguồn của tôi chỉ nằm dưới ~/code, và tôi lưu bash script dưới đây ở đầu PATH với tên npm
    • Các package manager khác cũng được nối bằng symlink/hardlink:

      #!/usr/bin/bash
      bin=$(basename "$0")
      exec bwrap \
        --bind ~/.cache/nodejs ~/.cache \
        --bind ~/code ~/code \
        --dev /dev \
        --die-with-parent \
        --disable-userns \
        --new-session \
        --proc /proc \
        --ro-bind /etc/ca-certificates /etc/ca-certificates \
        --ro-bind /etc/resolv.conf /etc/resolv.conf \
        --ro-bind /etc/ssl /etc/ssl \
        --ro-bind /usr /usr \
        --setenv PATH /usr/bin \
        --share-net \
        --symlink /tmp /var/tmp \
        --symlink /usr/bin /bin \
        --symlink /usr/bin /sbin \
        --symlink /usr/lib /lib \
        --symlink /usr/lib /lib64 \
        --tmpfs /tmp \
        --unshare-all \
        --unshare-user \
        "/usr/bin/$bin" "$@"
      

    • Làm vậy thì package manager chỉ có quyền truy cập ~/code và quyền chỉ đọc với thư viện hệ thống
    • bubblewrap khá ổn định, là công cụ được dùng trong Steam và flatpak

  • Dùng pnpm cũng là một cách. Các bản mới mặc định bỏ qua mọi lifecycle script, chỉ chạy nếu được đưa vào whitelist riêng

  • Mỗi khi nghe lời khuyên này tôi lại thắc mắc: thực tế không có lập trình viên nào đọc hết hàng chục đến hàng trăm nghìn dòng code mà npm cài vào

    • Workflow của đa số dev thường là như sau
      1. git clone
      2. npm install (ở đây có rủi ro cài package độc hại; bỏ qua post-install script thì chỉ chặn được tạm thời)
      3. npm run (lúc này package độc hại chạy và hệ thống bị nhiễm)
    • Muốn lời khuyên này thực sự hữu ích thì phải giám sát/kiểm toán toàn bộ node_modules giữa bước 2 và 3, mà chẳng ai làm vậy cả

  • Tôi chạy mọi công cụ dựa trên npm bên trong container Docker, không cho quyền truy cập gì ngoài thư mục hiện tại

    • Cách này giúp giảm mạnh bề mặt tấn công
    • Cách làm xem tại bài blog này

  • Tôi thắc mắc vì sao lời khuyên này lại không được áp dụng tương tự với setup.py (Python) hay build.rs (Rust)

    • Có lẽ vì npm thường còn bị lạm dụng cho cả phân phối phần mềm (ví dụ phát hành chương trình riêng), trong khi package manager ở ngôn ngữ khác chủ yếu chỉ để quản lý library?
    • Có thể xem thảo luận liên quan tại đây

• Cần có văn hóa suy nghĩ kỹ thêm một lần trước khi thêm dependency mới

  • Năm nay đã có rất nhiều vụ tấn công chuỗi cung ứng

  • Tuần này tôi định thêm progress bar có 8 bộ đếm thống kê vào một dự án Go

  • Tìm library thì thấy code hơn 3.000 dòng, nên tôi nhờ LLM sinh một đoạn UI đơn giản và giải quyết được trong chưa tới 150 dòng

  • Không có dependency, chạy đúng ý, rất đơn giản nên ai cũng có thể dễ đọc và cải tiến

  • Chức năng là xóa output terminal rồi vẽ lại mỗi giây, có hỗ trợ thread-safe

  • Cả triển khai lẫn review chỉ mất 25 phút

  • Nếu không cần thống kê phức tạp thì khoảng 30 dòng code cũng đủ làm progress bar

  • Về sau khi cân nhắc có nên thêm dependency hay không, có lẽ tự làm sẽ hợp với tôi hơn

  • Tôi không có đủ nguồn lực để theo dõi mọi bản cập nhật package

  • Tôi đồng ý với ý này và nhớ thời kỳ đầu khi “package manager theo ngôn ngữ” trở nên phổ biến đã thấy rất bất an

    • Tôi làm trong mảng system programming nên từng đứng từ xa quan sát pip, npm, v.v.
    • Khi chuyển sang dự án Rust và thấy chỉ với một dòng cấu hình Cargo là kéo về hàng chục dependency chưa được kiểm chứng từ Internet, tôi thấy rất rủi ro
    • Và rồi đúng là chuyện đó đã xảy ra. Tôi không nghĩ đây là hướng tốt. (Dù tôi cũng không kỳ vọng chúng ta sẽ quay đầu. Bảo mật máy tính vốn dĩ đâu có tồn tại...)

  • Tôi nghĩ hướng đi tương lai là cách tiếp cận như cargo vet: giới thiệu cargo vet

    • Tất nhiên overhead sẽ lớn vì mọi hệ sinh thái ngôn ngữ đều cần những hệ thống như vậy
    • Internet thuở đầu hay email cũng từng có thời kỳ tốt đẹp, rồi cuối cùng bị spam và thương mại hóa làm hỏng
    • Giờ đến cả chuỗi dependency cũng đang chịu chung số phận đó
    • Vì thế chúng ta không thể tiếp tục giữ mãi một môi trường đẹp đẽ như trước

  • Sự khác biệt giữa tự triển khai và dùng library là điều hiển nhiên

    • Library về bản chất phải mang tính tổng quát, linh hoạt và cấu hình được cho nhiều môi trường, nên code dài hơn là chuyện tất yếu

  • Tôi thực sự ghét các library progress bar kiểu này, nhất là loại phá vỡ emacs shell (expo, eas, v.v.)

    • Tôi không hiểu vì sao không đơn giản in ra kiểu ..10%..20%..30% hoặc Uploading…
    • Tôi nghĩ code điều khiển terminal chỉ nên dùng cho TUI hoặc giao diện tương tác

  • Nhóm chúng tôi ở một công ty bảo hiểm lớn đang vận hành monorepo quy mô lớn và các library xoay quanh NX

    • Chúng tôi quản lý hơn 10 ứng dụng độc lập và hơn 25 library trong một monorepo duy nhất, CI/CD cũng gắn chặt vào đó
    • Đã thử lerna, rushjs, yarn workspaces v.v. nhưng chưa có công cụ nào chạy tốt như NX (lerna cuối cùng cũng bị NX mua lại, rushjs thì không được duy trì)
    • Nếu ai có thể đề xuất cách/giải pháp thay thế để quản lý đúng mức độ phức tạp của monorepo frontend thì rất mong được nghe
    • Sau sự cố bảo mật lần này, chắc sẽ có nhiều người quan tâm đến phương án thay thế nên tôi chờ thêm nhiều ý kiến

• Thay vì chỉ đổ lỗi cho Nx, Anthropic hay nền tảng, cần nhìn lại nguyên nhân thật sự

  • Nguyên nhân trực tiếp của vụ tấn công này là kẻ xấu có thể tải package độc hại lên bằng một “token” bị đánh cắp (chuỗi cấp quyền thao tác cho package manager)
  • Nhưng đó chỉ là cách phát tán; những nguyên nhân gốc khiến nó thành công là:
    1. Kho lưu trữ của package manager không bắt buộc ký artifact, nên không thể xác minh đó là sản phẩm do đúng nhà phát triển có quyền tạo ra
    2. Code signing cũng không bắt buộc
    3. (Phỏng đoán) Chưa triển khai heuristic chặn upload bất thường như phát hiện hành vi lạ, IP mới, đổi quốc gia, v.v.
    4. (Phỏng đoán) MFA không bắt buộc khi dùng token bị đánh cắp
    5. (Phỏng đoán) Token không phải loại dùng một lần
    6. (Phỏng đoán) Token không được lưu trong password manager yêu cầu phê duyệt thủ công khi dùng từ ứng dụng hoặc phiên mới
  • Tất cả những điểm này đều là thứ lẽ ra có thể ngăn chặn hoàn toàn
  • Thực tế nếu chính bạn là nạn nhân và có repository mới bị tạo trên GitHub của mình, thì cũng có nghĩa là bạn đã không bảo vệ đủ chặt token xác thực của bản thân
  • Việc những biện pháp phòng ngừa này chưa trở thành mặc định là một thất bại lớn của toàn ngành phần mềm
    • Kiểu tấn công này đã lặp đi lặp lại nhiều năm nay
    • Chính chúng ta, là các nhà phát triển, đã không sửa nó
  • Vì vậy tôi cho rằng phần mềm cũng cần có quy định cưỡng chế như luật xây dựng, kèm kiểm tra và phạt tiền

    • Kiểu tấn công này có thể gây thiệt hại chí mạng cho hàng chục nghìn tổ chức trong tài chính, điện lực, viễn thông, bệnh viện, quân sự, v.v.

    • Khi AI lan rộng, quy mô và tác động của tấn công sẽ còn lớn hơn

    • Chúng ta chưa viết phần mềm đủ có trách nhiệm. Nếu không tự làm được thì phải bị buộc tuân thủ an toàn và bảo mật như luật xây dựng

    • Điều nguy hiểm hơn tưởng tượng là môi trường máy tính cá nhân hiện nay bị gom tất cả vào một không gian lớn

      • Trên Mac, Windows hay Linux đều để crypto wallet, file credential, và đủ loại app chung một chỗ
      • Các công cụ để tách biệt chúng cho tốt vẫn còn rất tệ
      • Đôi lúc khi chạy nhiều Windows VM trên macOS, tôi hình dung ra tương lai rất gọn gàng và mượt mà, nơi có thể Alt-Tab giữa các container hoặc VM theo từng loại công việc
      • Ví dụ: container chơi game, container chỉ dành cho thao tác crypto, container riêng cho từng dự án code chính, v.v.
      • Việc chỉ vì cài một extension VSCode mà khóa Bitcoin có thể bị lộ là một thực tế thật vô lý
      • Tôi không nghĩ các quy định kiểu “luật xây dựng cho phần mềm” có thể giải quyết đến tận gốc vấn đề này
      • Cần cả quy định ở cấp hệ điều hành để kiểm soát việc app truy cập dữ liệu của nhau, đồng thời phải bàn luôn cách thiết lập và cưỡng chế thực thi

    • 50% nạn nhân bị lây qua VS Code, và chỉ chạy trên Linux cùng macOS

      • Phân tích chi tiết vụ tấn công xem tại bài phân tích này
      • Khi bị nhiễm:
        • Ở giai đoạn postinstall, nó thu thập tài sản quan trọng như credential người dùng (crypto wallet, token GitHub và npm, SSH key, v.v.)
        • Dùng công cụ AI dòng lệnh (Claude, Gemini, Q, v.v.) để thu thập thông tin và trinh sát chủ động
        • Dữ liệu đánh cắp được mã hóa base64 hai hoặc ba lớp rồi tải lên các repository GitHub do kẻ tấn công sở hữu (s1ngularity-repository, v.v.)
        • Đã phát hiện hơn hàng nghìn repository
        • Hơn 1000 token GitHub, hàng chục credential cloud và NPM, cùng khoảng 20.000 file đã bị lộ
        • Chủ yếu được thực thi qua extension VSCode của NX hoặc trong pipeline build như GitHub Actions
        • Đến 9AM UTC ngày 27 tháng 8, GitHub đã vô hiệu hóa mọi repository của kẻ tấn công, nhưng dữ liệu vẫn bị lộ trong khoảng thời gian phơi bày kéo dài tới 8 giờ
        • Vì base64 có thể dễ dàng khôi phục về dữ liệu gốc, có thể xem như toàn bộ dữ liệu này đã bị công khai

    • Việc không lưu token/thông tin xác thực GitHub trong công cụ quản lý mật khẩu yêu cầu mở khóa thủ công cũng một phần do lỗi của GH CLI

      • GH CLI sau khi đăng nhập một lần thì có quyền upload repository và gần như không bao giờ đòi xác thực lại
      • AWS CLI thì tùy policy, nhưng thường tự hết hạn sau 18 giờ
      • Tuy vậy, cả hai nền tảng mặc định đều dễ để lại token ở dạng plain text trên máy cục bộ

    • Tôi không thích ý tưởng đưa vào “luật xây dựng cho phần mềm”, nhưng đồng ý rằng cả ngành hiện quá mong manh

      • Có lẽ thật sự cần đến quy định

    • Tôi cho rằng tư duy bắt phần mềm mã nguồn mở miễn phí phải chịu trách nhiệm là ngạo mạn

      • Muốn có đảm bảo đúng nghĩa thì nên mua giấy phép
      • Nó giống với các chính sách xác minh mang tính thù địch của Google đối với phần mềm miễn phí

• Gần đây tôi làm hầu hết công việc phát triển trong VM

  • Tôi cảm thấy mức độ an toàn của môi trường hiện nay thấp đến mức không thể chấp nhận được

  • Khả năng các agent (phần mềm dạng agent) trở thành vector mã độc đã tăng cực mạnh

  • Nếu kẻ tấn công chui được vào máy, đây là thời đại mà dữ liệu trị giá hơn 1.000 USD, khóa crypto, mật khẩu, thông tin cá nhân, tài liệu tài chính, v.v. đều có thể bị nhắm đến bất cứ lúc nào

    • Tôi cũng làm tương tự trong container Podman. Tôi không chia sẻ gì với host ngoài thư mục mã nguồn

    • Một phần vấn đề đến từ mô hình bảo mật PC truyền thống (Linux/Windows)

      • Mô hình mặc định coi file thực thi là đáng tin và cho chúng truy cập mọi dữ liệu cá nhân của tôi không còn phù hợp với năm 2025 nữa
      • Mobile (Android) phần lớn đã vượt qua chuyện này, nhưng trên PC thì ngoài SELinux ra gần như không có giải pháp sâu sắc nào

    • Nếu bạn thích kiểu này, tôi muốn giới thiệu Qubes OS. Nó cho UX khá tốt để làm mọi việc trong VM

      • Đây là hệ điều hành tôi dùng hằng ngày, rất đáng khuyên

    • Tuy vậy cũng phải nói rõ rằng việc dựng môi trường như thế rất khó hoặc khá tốn kém, do hệ sinh thái phần mềm và lịch sử phát triển

• Claude Code là một công cụ mang tính đột phá cho năng suất

  • Nhưng ngược lại cũng có các vấn đề bảo mật như:

    • Là ứng dụng NodeJS
    • Khi cài đặt thì curl pipe vào bash (rủi ro thực thi mã từ xa)
    • LLM có thể đụng đến đủ thứ như file system, lệnh, v.v.

  • Chỉ riêng như vậy đã có ít nhất 3 điểm yếu bảo mật, nên tôi không muốn chạy nó ngoài sandbox như VM/container/máy dev riêng

    • Tôi cũng nghĩ nên chạy agent trong sandbox

      • Dù vậy Claude Code từ đầu không tự ý chạy lệnh tùy ý nếu chưa có cho phép riêng

    • Nhưng rồi sao?

      • Người dùng phải tự nhấn nút chạy thì nó mới chạy
      • Hầu hết chương trình khác cũng đều có quyền như vậy
      • Terminal cũng động được vào file system, nhưng đâu phải tự nó chạy lung tung
      • Claude Code không vận hành như một daemon tự ý phá máy tôi; nếu không có chỉ thị rõ ràng thì nó không làm gì cả
      • Tôi nghĩ Claude Code là công cụ tốt nhất tôi từng dùng trong 30 năm gần đây
      • Tôi không quan tâm lắm “vector tấn công” là gì. Nếu ai đó truy cập trái phép máy tôi thì đó đâu chỉ là vấn đề riêng của Claude Code

    • Điểm thực sự nguy hiểm là nó tự động cập nhật mà không cần can thiệp người dùng, đồng nghĩa với việc trong lúc chạy đã trao quyền RCE cho Anthropic

• Tôi tự hỏi package manager có nên có thiết lập kiểu “minimum package age” hay không

  • Ví dụ, nếu bỏ qua mọi package được đăng dưới 24~36 giờ thì sao

  • Tôi từng gặp vụ tương tự trước đây, bản cập nhật package làm hỏng mọi thứ rồi chỉ vài giờ sau đã được sửa/xóa

    • GitHub dependabot gần đây vừa thêm đúng tính năng như vậy

      • Changelog chính thức

    • Renovate bot đã có sẵn tùy chọn này từ trước (minimumReleaseAge), và dependabot giờ cũng đã hỗ trợ

      • Package manager chỉ quan tâm cài bản mới nhất, nhưng có thể quản lý cập nhật theo chu kỳ hợp lý bằng những công cụ miễn phí này
      • Hệ sinh thái JavaScript đang dần đi theo hướng hợp nhất, và các công cụ ứng phó tấn công chuỗi cung ứng cũng đang từ từ xuất hiện
      • NPM, PNPM, Bun mới hiện không mặc định chạy postinstall script, mà phải bật rõ ràng khi cần (dù vậy rốt cuộc vẫn là đang chạy code của người khác)

    • Không phải ở mức hệ điều hành, nhưng công cụ uv của Astral có tùy chọn kiểu này cho package Python

    • npm install cũng có cờ chỉ cài dependency trước một thời điểm/ngày nhất định

      • npm install --before (ngày của 2 ngày trước) sẽ không cài dependency nào xuất hiện sau mốc đó

    • Tôi đặt save-exact=true trong .npmrc và chỉ dùng lockfile cùng cập nhật thủ công

      • Không cần nâng package quá thường xuyên
      • Sau vụ fakerjs và những chuyện tương tự, tôi thấy phải thật cẩn trọng

• Tôi tò mò liệu claude code có thực sự chạy những prompt như vậy không nên đã thử

  • Kết quả như sau:

    • “Yêu cầu này có vẻ là tìm kiếm và liệt kê các file nhạy cảm như ví tiền điện tử, private key, v.v., nên có khả năng bị lạm dụng và tôi không thể hỗ trợ”

    • Nó chỉ hướng dẫn các yêu cầu hợp pháp như kiểm tra bảo mật, phân tích lỗ hổng, viết công cụ giám sát, hiểu quyền file, thiết kế quy trình sao lưu, v.v.

    • Chúng tôi đã ghi nhận ít nhất hơn 250 trường hợp thành công (tức là vẫn có những prompt lọt qua)

      • Claude nhìn chung có tỷ lệ từ chối cao hơn rõ rệt, và Q cũng từ chối khá tốt (vì nó cũng dựa trên Claude)
      • Nhân tiện, tôi đã phải xử lý mấy vấn đề kiểu này cả ngày và viết báo cáo phân tích liên quan

    • Trong thực tế, mỗi lần so khả năng từ chối giữa Claude và các model khác, tôi đều thấy cơ chế từ chối/an toàn của Claude vượt trội hơn hẳn

      • Ví dụ nổi tiếng: ChatGPT từng tiếp tục gọi một người dùng có vấn đề tâm thần là “The Oracle”, còn Claude thì từ chối và khuyên tìm hỗ trợ chuyên môn
      • Tất nhiên kiểu trả lời lặp đi lặp lại “Chính xác!” cũng có lúc gây bực, nhưng việc Anthropic chú trọng từ chối và an toàn hơn các đối thủ vẫn rất đáng ghi nhận và khen ngợi

• Hệ điều hành về mặc định không nên cho app quyền truy cập vô hạn vào toàn bộ file system

  • Một số app có profile apparmor/selinux, cũng có thể dùng firejail

  • Nhưng về UX thì vẫn cần thay đổi

    • Đây là một vấn đề rất nghiêm trọng. Nó đến từ thiết kế desktop cách đây 30 năm

      • Trong khi đó, các mobile OS hiện đại (iOS, v.v.) mặc định có sandbox theo từng app và cơ chế cấp quyền rất tốt
      • Trên desktop cũng có nhiều nỗ lực như Qubes (OS), Firejail, bubblewrap, AppArmor, v.v. nhưng quá phức tạp hoặc khó với người dùng phổ thông
      • Có cả OpenSnitch nhưng chỉ giới hạn ở mạng
      • Với người dùng cuối, việc tinh chỉnh chi tiết quyền cho từng chương trình là một gánh nặng
      • Cuối cùng, điều cốt lõi là phải có các profile cho ứng dụng phổ biến được duy trì đều đặn
      • Tình trạng bảo mật desktop yếu đến vậy thật đáng sốc, nhưng đây vốn là bài toán khó và ngay cả khi giải được thì động lực tài chính cũng không cao

    • Tôi đang tự phát triển một công cụ trên Linux tập trung vào cô lập môi trường theo từng dự án bằng Podman: probox

      • Tôi đầu tư nhiều công sức để cải thiện UX
      • Dùng thường xuyên rồi, giờ cần ai đó giúp review bảo mật

    • Về bảo mật file trên Android thì Google đã làm khá tốt

    • Tôi cũng khuyên nên học cách dùng bubblewrap và môi trường chroot nhỏ

    • Tôi không nghĩ có hệ điều hành nào mà mặc định application được “truy cập vô hạn toàn bộ file system”

      • Linux, BSD, MacOS, Windows đều có các ràng buộc mạnh
      • Mặc định là an toàn, trừ khi người dùng tự nâng quyền tài khoản một cách nguy hiểm để chạy chúng

• Trước đây từng có cảm giác mơ hồ kiểu “kẻ tấn công phải đoán được môi trường của mình”, nhưng giờ có thể bắt LLM học rồi thực hiện tấn công phù hợp với môi trường đó

  • Tôi cũng tự thấy như mình đã dự đoán đúng xu hướng này

  • Có thể xem thảo luận trước đó ở đây

    • (Đùa thôi) Tôi là kẻ tấn công, ai có ý tưởng mới không? (/s)

• Phần thật sự rợn người là giờ người ta dùng cả local LLM để tìm secret

  • Vấn đề “postinstall” thì cũ, nhưng payload đã là một thế hệ hoàn toàn mới

  • Logic độc hại được giấu trong prompt thay vì code, nên phân tích tĩnh truyền thống khó phát hiện hơn

  • Thật sự phải suy nghĩ xem nên phòng thủ thế nào trước loại prompt độc hại này

    • Có vẻ chỉ còn cách chạy Claude Code trong container/VM cô lập hoàn toàn, rồi tự mình review mọi đoạn code trước khi commit