Hơn 100.000 kho lưu trữ bị nhiễm được phát hiện trên GitHub

 (apiiro.com)
1 điểm bởi GN⁺ 2024-03-01 | 1 bình luận | Chia sẻ qua WhatsApp
  • Chiến dịch repo confusion (nhầm lẫn kho lưu trữ) bắt đầu từ giữa năm 2023 đang bùng phát trở lại, với hơn 100.000 kho lưu trữ chứa payload độc hại tương tự được phát hiện trên GitHub
  • Kẻ tấn công tạo các bản sao độc hại giống kho lưu trữ hợp pháp để khiến nhà phát triển nhầm lẫn, kết hợp sao chép, chèn loader, tải lại lên, fork hàng loạt và quảng bá âm thầm
  • Khi chạy kho lưu trữ độc hại, sau 7 lớp làm rối mã, mã Python và binary sẽ được tải xuống, đánh cắp dữ liệu nhạy cảm như thông tin đăng nhập, mật khẩu trình duyệt và cookie
  • Dù GitHub tự động xóa phần lớn các fork, những kho lưu trữ tránh được phát hiện và các bản tải lên thủ công vẫn tồn tại; chỉ cần 1% sống sót cũng duy trì được hàng nghìn kho lưu trữ độc hại
  • Luồng tấn công đã dịch chuyển từ gói độc hại trên PyPI sang kho lưu trữ GitHub, khiến chuỗi cung ứng phần mềm bên ngoài package manager cũng trở thành bề mặt tấn công trực tiếp

Cách thức tấn công nhầm lẫn kho lưu trữ

  • Nhầm lẫn kho lưu trữ giống dependency confusion ở chỗ nó dụ người dùng tải kho lưu trữ độc hại thay vì kho lưu trữ hợp pháp
  • Điểm khác biệt nằm ở vị trí bị khai thác
    • dependency confusion lợi dụng cách package manager hoạt động
    • nhầm lẫn kho lưu trữ dựa vào tình huống con người chọn nhầm kho lưu trữ trông giống nhau
  • Chiến dịch lần này phát tán hàng loạt kho lưu trữ độc hại trên GitHub để tăng khả năng lây nhiễm
    • Sao chép các kho lưu trữ hiện có như TwitterFollowBot, WhatsappBOT, discord-boost-tool, Twitch-Follow-Bot
    • Chèn malware loader vào bản sao
    • Tải lại lên GitHub với cùng tên
    • Tự động fork mỗi kho lưu trữ hàng nghìn lần
    • Quảng bá âm thầm trên diễn đàn, Discord và các nơi khác

Luồng sau khi chạy kho lưu trữ độc hại

  • Khi người dùng sử dụng kho lưu trữ độc hại, payload ẩn sẽ gỡ 7 lớp làm rối mã
  • Sau đó nó tải mã Python độc hại và tệp thực thi binary
  • Mã độc chủ yếu dựa trên một phiên bản sửa đổi của BlackCap-Grabber
  • Mục tiêu thu thập là thông tin xác thực đăng nhập của nhiều ứng dụng, mật khẩu và cookie trình duyệt, cùng các dữ liệu bí mật khác
  • Dữ liệu bị đánh cắp được gửi đến máy chủ C&C (command-and-control) của kẻ tấn công, rồi các hoạt động độc hại tiếp theo diễn ra
  • Có thể xem phân tích mã liên quan trong technical analysis của Trend Micro

Tự động xóa của GitHub và các kho lưu trữ còn sót lại

  • GitHub xác định hoạt động tự động hóa và nhanh chóng gỡ bỏ phần lớn kho lưu trữ đã fork
  • Tuy nhiên, hệ thống phát hiện tự động bỏ sót nhiều kho lưu trữ, còn các kho lưu trữ được tải lên thủ công vẫn tồn tại
  • Vì chuỗi tấn công được tự động hóa ở quy mô lớn, chỉ cần 1% còn lại cũng tương đương hàng nghìn kho lưu trữ độc hại
  • Tìm kiếm 🔥 2024 language:python trên GitHub có thể thấy một số kho lưu trữ hiện đang lan rộng
  • Nếu tính cả các kho lưu trữ đã bị xóa, tổng quy mô đạt đến hàng triệu
    • Việc xóa thường diễn ra vài giờ sau khi tải lên, nên khó ghi nhận đầy đủ
    • Nhiều kho lưu trữ gốc vẫn còn, việc xóa chủ yếu nhắm vào fork bomb
    • Ví dụ, trong danh sách kho lưu trữ của Mattia69, phần tóm tắt hiển thị hàng nghìn fork, nhưng trong chi tiết fork thì không thấy
  • Một số người dùng vô tình fork kho lưu trữ độc hại cũng tạo ra hiệu ứng mạng xã hội kỹ thuật thứ cấp

Thời điểm diễn tiến của chiến dịch

  • Tháng 5/2023: Phylum báo cáo các gói độc hại được đưa lên PyPI
    • Các gói này chứa phần đầu của payload hiện tại
    • Chúng lan truyền qua các lệnh gọi os.system("pip install package") được cài vào fork của các kho lưu trữ GitHub phổ biến như chatgpt-api
  • Tháng 7–8/2023: Nhiều kho lưu trữ độc hại được đưa lên GitHub và truyền payload trực tiếp thay vì lấy gói từ PyPI
    • Đây là thay đổi sau khi PyPI gỡ các gói độc hại và cộng đồng bảo mật chú ý nhiều hơn
    • Aliakbar Zahravi và Peter Girnus của Trend Micro công bố phân tích kỹ thuật
  • Từ tháng 11/2023 đến nay: Hơn 100.000 kho lưu trữ chứa payload độc hại tương tự đã được phát hiện, và con số tiếp tục tăng
  • Lý do phương thức này có lợi cho kẻ tấn công rất rõ ràng
    • GitHub có quy mô lớn nên ngay cả nhiều instance cũng tương đối nhỏ và khó bị phát hiện
    • Khác trước đây, package manager không tham gia nên không còn tên gói độc hại rõ ràng làm chỉ báo
    • Kho lưu trữ mục tiêu nằm trong các ngách nhỏ và ít phổ biến, khiến nhà phát triển dễ clone nhầm kho lưu trữ giả mạo độc hại

Dịch chuyển từ package manager sang SCM

  • Sự dịch chuyển từ gói độc hại trên PyPI sang kho lưu trữ độc hại trên GitHub phù hợp với xu hướng đã quan sát được trên nhiều package manager và nền tảng SCM
  • Khi cộng đồng bảo mật tập trung nhiều hơn vào package manager, đường tấn công đã chuyển sang nơi khác
  • GitHub và các nền tảng tương tự giúp dễ tự động tạo tài khoản và kho lưu trữ, đồng thời cung cấp API tiện lợi và rate limit lỏng lẻo dễ vượt qua
  • Do có thể ẩn mình giữa vô số kho lưu trữ, SCM trở thành mục tiêu phù hợp để âm thầm lây nhiễm chuỗi cung ứng phần mềm
  • Các chiến dịch dependency confusion, mã độc trong package registry và phát tán mã độc qua SCM cho thấy dù có nhiều công cụ và cơ chế bảo mật, bảo mật chuỗi cung ứng phần mềm vẫn dễ tổn thương

Chỉ báo kiểm tra lây nhiễm

  • Cần tìm các mẫu sau trong mã Python và điều tra các kết quả khớp
    • exec(Fernet
    • exec(requests
    • exec(__import
    • exec(bytes
    • exec("""\nimport
    • exec(compile
    • __import__("builtins").exec(
  • Cần kiểm tra và gỡ bỏ các kho lưu trữ liên quan đến tự động hóa nền tảng xã hội, bot và game nếu có trên máy cục bộ
  • Nếu bắt buộc phải sử dụng, hãy cài đặt lại nhưng xác minh kỹ nguồn gốc hoặc chạy trong sandbox
  • Nếu có khả năng đã clone loại kho lưu trữ này, cần xem như các cookie, thông tin xác thực và khóa sau đã bị đánh cắp và ứng phó tương ứng
    • Trình duyệt: dịch vụ tài chính, dịch vụ email, dịch vụ tiền mã hóa, Amazon, eBay, AliExpress, Facebook, Instagram, Twitter, Youtube, Discord, TikTok, Telegram, Twitch, Steam, Yahoo, ExpressVPN, Spotify, dịch vụ streaming
    • Ứng dụng: Exodus, Atomic Wallet, Guarda, Coinomi, Ethereum
  • Danh sách đầy đủ checksum tệp khó xử lý thực tế, nhưng có thể xem một số mục phổ biến trong VirusTotal graph
  • Cloudflare đã vô hiệu hóa bản ghi DNS của các địa chỉ độc hại được phát hiện sau khi nhận thông báo

Phòng thủ và ứng phó

  • GitHub đã được thông báo và đã xóa phần lớn kho lưu trữ độc hại, nhưng chiến dịch vẫn tiếp diễn
  • Các cuộc tấn công nhằm chèn mã độc vào chuỗi cung ứng đang ngày càng lan rộng
  • Có nhiều giải pháp bắt malware ở cấp hệ thống và mạng, nhưng chuỗi cung ứng vẫn là bề mặt tấn công lớn và sinh lợi cho kẻ tấn công
  • Nếu phát hiện kho lưu trữ độc hại, dù có thuộc chiến dịch này hay không, có thể báo cáo qua abuse or spam report của GitHub
  • Apiiro đã xây dựng hệ thống phát hiện mã độc để giám sát các codebase được kết nối
    • Phân tích mã dựa trên LLM
    • Phân rã mã thành đồ thị luồng thực thi đầy đủ
    • Engine heuristic
    • Giải mã, giải mã động và gỡ rối mã
  • Nếu không giám sát các payload độc hại bị chèn, bảo mật của tổ chức sẽ phụ thuộc vào những điều kiện như nhà phát triển không chọn nhầm kho lưu trữ gần như giống hệt, CI/CD hoàn toàn không có lỗi cấu hình và mã bên thứ ba an toàn 100%
  • Cần một cách tiếp cận vượt ra ngoài phát hiện và thu thập lỗ hổng thông thường, để phơi bày rủi ro thế hệ tiếp theo trong chuỗi cung ứng phần mềm và ứng dụng

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-03-01
Các ý kiến trên Hacker News

  • Vượt ra ngoài cảnh báo chung rằng cần cẩn trọng với mã lấy từ kho công khai hoặc nguồn bên ngoài và phải xác minh cây phụ thuộc, tôi tò mò nếu có lượng lớn mã độc trong các kho công khai thì điều đó sẽ ảnh hưởng thế nào đến các LLM và công cụ tự động hóa được huấn luyện trên nội dung đó
    Có vẻ cũng có khả năng các phần độc hại vô tình bị trộn vào khi những công cụ như Copilot tạo ra câu trả lời mã dài
    Những thứ như lỗ hổng injection đơn giản thì đã thường xuyên được chứng kiến

    • So với việc backdoor vô tình xuất hiện trong đầu ra của LLM, tôi lo hơn về khả năng cơ quan tình báo cài backdoor vào đầu ra của LLM
      Hiện tại có thể chưa xảy ra, nhưng trong vài năm tới thì có vẻ hoàn toàn khả thi
    • LLM không chỉ dán lại mã có lỗ hổng từng có trong dữ liệu đầu vào, mà có vẻ còn tự tạo ra lỗ hổng mới
      AI không đưa ra bất kỳ bảo đảm nào về tính chính xác
    • Tôi vừa đăng một vấn đề liên quan đến LLM về việc chiếm đoạt bot chuyển đổi safetensors của Hugging Face: https://news.ycombinator.com/item?id=39549482
      Nó cho thấy kẻ tấn công có thể kiểm soát bot dịch vụ liên kết với không gian chuyển đổi Hugging Face Safetensors, một dịch vụ phổ biến dùng để chuyển đổi các mô hình máy học không an toàn trong hệ sinh thái sang phiên bản an toàn hơn
    • Đúng là có rủi ro, nhưng nó tương tự rủi ro khi bạn chấp nhận PR của đồng nghiệp mà không rà soát, khiến mã có lỗ hổng được sao chép từ đâu đó lọt vào
      Nếu dùng LLM thì cần đầu tư nhiều công sức hơn vào code review, và tôi cho rằng sự đánh đổi đó là đáng giá
    • Số mẫu được phát hiện trong chiến dịch này lớn đến mức đây là rủi ro thực tế hơn tôi nghĩ
      Tuy nhiên, để dẫn đến sự cố thực tế thì chủ yếu có hai rào cản: trình sinh mã được chỉ thị nội bộ để tránh loại mã đó, và do đặc tính của LLM, khả năng nó lặp lại nguyên văn địa chỉ của kẻ tấn công thực sự là thấp
      Dù vậy, nhiều vector tấn công như bind shell, từ chối dịch vụ, rò rỉ tại chỗ vẫn còn tồn tại

  • GitHub đang thất bại theo cách tương tự như Usenet đã thất bại
    Ai cũng có thể tạo kho lưu trữ, và không có gì giúp phân biệt kho chính thức với kho spam
    Giống như Amazon từng hướng tới “cửa hàng của mọi thứ” rồi bị quy luật “90% của mọi thứ là rác” đánh trúng, trở thành một cửa hàng mà phần lớn là rác, GitHub cũng phải quyết định sản phẩm của mình là “kho lưu trữ cho mọi người” hay “mã có thể tin cậy”
    Ví dụ, ngay cả PG JDBC chính thức dường như cũng không có yếu tố nào mà spammer không thể tái tạo; vậy làm sao có thể tin rằng đây không phải là kho bị nhiễm: https://github.com/pgjdbc

    • Có vẻ GitHub đã chọn kho lưu trữ cho mọi người ngay từ khi công ty mới thành lập cách đây 16 năm
    • Nếu là thư viện Java thì thông thường bạn sẽ tải từ Maven Central, chứ không phải GitHub
      Sonatype yêu cầu chứng minh quyền sở hữu tên miền đảo ngược được dùng trong groupId, trong trường hợp này là org.postgresql
      Cách làm ở đây: https://central.sonatype.org/faq/how-to-set-txt-record/
      Nếu muốn yên tâm hơn, vì mọi artefact được đăng lên Maven Central đều được ký, bạn cũng có thể kiểm tra chữ ký GPG, nhưng nhược điểm là phải lấy khóa mà Postgres dùng để ký qua một kênh độc lập với Sonatype
      Với PG, tìm nhanh thì tôi không thấy khóa
    • Có vẻ mọi người chưa thực sự cảm nhận được con số này nhỏ đến mức nào
      GitHub có khoảng 500 triệu kho lưu trữ, nên mức này thực ra là khá tốt
    • Hơn 100.000 kho bị nhiễm là không tốt, nhưng điều đó không có nghĩa là GitHub đã thất bại
      Một lập trình viên sẵn sàng dùng kho bị nhiễm thì dù GitHub không có những kho như vậy, họ vẫn có thể tìm ra rất nhiều cách khác để tạo ra sản phẩm không an toàn
    • Nếu chứng minh quyền sở hữu tên miền, bạn có thể nhận huy hiệu đã xác minh trên trang tổ chức, và điều đó có thể tăng độ tin cậy lên khá nhiều
      Có vẻ tổ chức được lấy làm ví dụ đơn giản là chưa làm việc đó

  • Vấn đề chuỗi cung ứng đúng là rất đau đầu
    Tôi không trực tiếp nhắm tới các bản phát hành npm, nhưng để giám sát một dự án trình duyệt web ảo hóa nhẹ tên BrowserBox, tôi đang tạo bản phát hành npm và dùng socket.dev
    Dự án này cũng có khoảng 800 phụ thuộc nếu tính toàn bộ phụ thuộc con, chỉ dùng 19 phụ thuộc cấp cao nhất; xét trên toàn bộ stack thì vẫn là khá nhẹ
    Giờ tôi đang cân nhắc snapshot toàn bộ 800 phụ thuộc vào namespace @browserbox trên npm, rồi theo dõi các lỗ hổng được phát hiện để vá
    Nghe có vẻ điên rồ, nhưng tình hình hiện tại là vậy; ít nhất nếu làm thế thì có thể tự đảm bảo các lỗ hổng chuỗi cung ứng phía Node/JS nằm trong mức bảo mật của công ty
    https://socket.dev
    https://github.com/BrowserBox/BrowserBox

    • Tôi không biết npm có bao nhiêu tính năng tương tự, nhưng crates.io và cargo có các công cụ như cargo audit và cargo deny để kiểm tra CVE trong cây phụ thuộc ngay trong pipeline
      Vì file khóa duy trì sha256 của toàn bộ cây, nên ngay cả khi kho lưu trữ bị hack cũng không cần mirror để chống thay đổi
      Ghim vào phiên bản chậm hơn bản mới nhất vài tháng có vẻ là điểm cân bằng hợp lý: tránh CVE mới mà cũng không bị mắc kẹt quá lâu ở phiên bản cũ để rồi phải sửa một lần thật lớn
      Số lượt tải xuống có vẻ là một thước đo ổn khi so với các phụ thuộc cấp cao nhất có mục đích tương tự, nhưng đó là đánh giá chủ quan
      Austral dùng linear types để cấp quyền chi tiết cho các phụ thuộc
      Kiểu như thư viện đồ họa không cần I/O tệp, và thư viện truyền dữ liệu qua mạng không cần quyền truy cập micro
      Chỉ là biện pháp giảm nhẹ, nhưng tôi muốn thấy điều này ở các ngôn ngữ khác
    • Cách nói “chỉ khoảng 800 phụ thuộc” nghe hơi rợn người
      Khoảng 10 năm trước, sau khi chuyển từ .NET sang Java, tôi đã bất ngờ vì thời gian dành cho dependency hell tăng mạnh; còn hiện nay, cả dự án Java lẫn Python đều ngốn rất nhiều thời gian cho cập nhật lỗ hổng và vấn đề phụ thuộc
      Tôi nghĩ lý do .NET ít gặp vấn đề này hơn là vì việc đưa vào quản lý gói tự động diễn ra tương đối muộn, NuGet cũng còn khá trẻ, nên khi đó nhiều dự án chưa áp dụng và văn hóa tránh các cây phụ thuộc bắc cầu khổng lồ còn mạnh
      Các vấn đề gần đây của Boeing trông cũng tương tự
      Trong vài thập kỷ qua, họ chuyển ngày càng nhiều khâu sản xuất cho nhà cung ứng bên ngoài và tập trung tối ưu chi phí, khiến quản lý chuỗi cung ứng ngày càng khó; nhìn rộng ra thì khá giống văn hóa chuỗi cung ứng của kỹ nghệ phần mềm hiện đại
      Khi tôi làm ở một công ty tài chính cấm trình quản lý gói vì lý do bảo mật chuỗi cung ứng, việc quản lý phụ thuộc là ít phiền nhất và vấn đề chất lượng cũng ít nhất
      Có những lợi thế ở thứ mã sẽ không bao giờ thay đổi trừ khi ta thay đổi nó một cách rõ ràng
      Chúng tôi tự triển khai khá nhiều phần mà người khác thường lấy gói về dùng; vì chỉ làm những gì cần thiết và áp dụng tiêu chuẩn mã cao hơn, nên dễ hiểu, dễ debug và dễ sửa hơn
      Chi phí viết ban đầu là một lần và được khấu hao tốt, nhưng chi phí lặp đi lặp lại khi xử lý thứ mã cố làm mọi thứ cho mọi người về lâu dài lớn hơn và thường tích lũy
      “Simple Made Easy” của Rich Hickey minh họa rõ hiện tượng này: đơn giản và dễ dàng là hai thứ khác nhau; các lựa chọn đơn giản ban đầu có thể trông khó hơn, nhưng khi hiệu ứng bậc hai tích tụ, về lâu dài chúng trở nên dễ hơn

  • Tôi đã nhận ra chuyện này trước đó khi tình cờ thấy các kho lưu trữ tương tự
    Vốn dĩ tôi đã không chạy bừa mã từ bất kỳ repo nào, nhưng giờ ngay cả khi tin tưởng repo và chủ sở hữu, tôi vẫn bật VM sandbox
    Có lẽ lập trình viên ngày nay nên tách rõ ít nhất ba môi trường: công việc, sở thích và cá nhân

    • Chính việc phải nói rằng lập trình viên nên tách môi trường công việc, sở thích và cá nhân đã cho thấy độ phức tạp của đời sống số đã lớn đến mức khiến người ta nghi ngờ liệu nó có bền vững lâu dài hay không
    • Mỗi năm trôi qua, Qubes lại trông như một lựa chọn hợp lý hơn
    • Tôi hiện cũng làm như vậy, không chỉ vì phần mềm độc hại tiềm tàng
      Có những dự án tuy không độc hại nhưng được thiết kế cẩu thả hoặc viết một cách ngớ ngẩn
      Một chương trình tôi chạy gần đây đã thêm 3 dòng vào ~/.bashrc trước cả khi tôi yêu cầu nó làm bất cứ việc gì, và mãi vài ngày sau tôi mới biết
      Tôi không hiểu lập trình viên nào lại cho rằng đó là ý hay, nên giờ mỗi khi chạy mã bên ngoài tôi đều dùng sandbox
    • Nghe như một lý do tốt để dùng Qubes OS, nơi mọi thứ mặc định chạy trong VM
      Đó là OS dùng hằng ngày của tôi
    • Không trộn lẫn môi trường công việc và cá nhân chẳng phải là điều cơ bản nhất sao
      Thực sự có nhà tuyển dụng nào cho phép chuyện này à?

  • Tò mò ở nơi làm việc mọi người dùng công cụ nào để tránh những vấn đề như thế này, và có hài lòng với cấu hình hiện tại không
    Chúng tôi là một nhóm khá nhỏ đang phát triển một SDK có lượng tải xuống hằng tuần lớn, đã đánh giá các giải pháp dựa trên snyk, aikido.dev, renovate, v.v., nhưng chưa rõ chúng có giúp ích cho vấn đề kiểu này hay không
    Vì vẫn là nhóm nhỏ nên việc xử lý các công cụ có nhiều dương tính giả như snyk cũng là một gánh nặng

    • Thay vì dùng trực tiếp kho GitHub, chúng tôi dùng các gói công khai từ những kho gói phổ biến như NuGet, PyPI, npm, và đặt Repository cùng Firewall của Sonatype làm proxy giữa chúng tôi và kho gói
      Sonatype phân tích mọi gói, gắn nhiều loại metadata, rồi định nghĩa các chính sách có thể dùng trong Firewall để lọc phần còn lại
      Cách này chỉ áp dụng cho dependency công khai, nhưng sau vài năm sử dụng thì thấy hoạt động khá tốt
      Cho đến nay chưa gặp vấn đề mã độc nào; các gói có lỗ hổng đã biết không thể lọt vào codebase, và nếu phát hiện lỗ hổng trong những gói đang dùng thì chúng tôi nhận được cảnh báo
    • Ở nơi làm việc chúng tôi dùng Semgrep Supply Chain và khá hài lòng
      Nó chia các lỗ hổng chuỗi cung ứng phát hiện được thành có thể tiếp cận, không thể tiếp cận và chưa xác định, nên việc phân loại dễ hơn nhiều, và thời gian đánh giá lỗ hổng mới giảm đáng kể
    • Có vẻ trong nhánh thảo luận này nhiều người đang nhầm lẫn giữa mã độc và lỗ hổng
      Các vendor được nhắc đến không phát hiện mã độc, mà chỉ phát hiện lỗ hổng
      Dù phát hiện lỗ hổng tốt đến đâu, bạn vẫn không được bảo vệ khỏi mã độc được cài vào codebase
    • Tôi đang làm một công cụ mã nguồn mở tên Packj để phát hiện các gói PyPI/NPM/Ruby/PHP/Maven/Rust nguy hiểm, như gói công khai là mã độc, gói bị bỏ mặc, gói typosquatting, v.v.
      Nó thực hiện phân tích tĩnh, động và metadata, kiểm tra hơn 40 thuộc tính như thực thi shell, dùng khóa SSH, giao tiếp mạng, dùng decode+eval, rồi đánh dấu các gói nguy hiểm
      https://github.com/ossillate-inc/packj
    • Trivy đáng để xem qua
      Cho đến nay nó hoạt động khá tốt
      https://trivy.dev/

  • Tò mò không biết thực hành tải script cài đặt shell bằng curl rồi chạy bằng sudo liệu có sắp chấm dứt không
    Kiểu “để cài phần mềm của chúng tôi, hãy chạy curl [https://somesite/install.sh](<https://somesite/install.sh>;)' | sudo sh” có vẻ rất khớp với loại mã bị nhiễm được nhắc trong bài

    • Với tư cách là tác giả của nghiên cứu này, tôi có thể xác nhận
      Hệ thống của chúng tôi mỗi tuần liệt kê khoảng 100 trường hợp theo mẫu đã nói, và trong số đó khoảng 3% là mã độc
      Tôi rất muốn thấy thực hành này chấm dứt
    • Đáng tiếc là npm i cũng có cùng quyền hạn
      Trong các công cụ tải dependency phổ biến hiện nay, tôi chỉ biết go get là không chạy mã đối địch tại thời điểm cài đặt hoặc build
      Ít nhất thì chúng ta cần công cụ tốt hơn để làm việc trong sandbox, nhằm khoanh vùng vụ nổ
      Cách của ChromeOS, nơi “máy ảo có thể mở cửa sổ Wayland trên desktop chính”, khá gọn gàng, nhưng lần cuối tôi xem thì đoạn code đó không sạch lắm cũng không dễ tái sử dụng
    • Với ví dụ kiểu này nên dùng example.com
      Đó là domain được dành riêng cho mục đích này: https://www.rfc-editor.org/rfc/rfc2606.html#section-3
    • Nó cũng không hẳn tệ hơn các lựa chọn thay thế thực tế như “thêm repository cho bản phân phối và tin nó”, “tải .deb/.rpm/trình cài đặt”, hoặc tệ nhất là “tin gói do bên thứ ba đóng gói chứ không phải nhà phát hành”

  • Trong npm có thể giảm thiểu việc thực thi mã độc bằng --ignore-scripts
    https://blog.uirig.com/getting-rid-of-npm-scripts

    • Đổi lại, mã độc đã tải xuống có thể được chạy trong môi trường production
      Nếu may mắn, nó có thể có hành vi bất thường trong CI và bị phát hiện
      Giải pháp thực sự là một hệ thống uy tín như https://github.com/crev-dev/cargo-crev, nhưng đáng tiếc là hầu như không được dùng
    • Từ góc độ bảo mật, đó nên là mặc định
      Cũng nên chú ý đến nhận xét rằng cần Makefile

  • Khi các báo cáo như thế này liên tục xuất hiện, trong vài tháng qua tôi đã dần cải thiện bảo mật cho môi trường phát triển
    Tôi đang dùng dev containers của VSCode để phát triển: https://code.visualstudio.com/docs/devcontainers/create-dev-...
    Một khi đã tạo sẵn thì khá dễ dùng dù không có nhiều kiến thức về Docker, và phù hợp để chạy ứng dụng web/console, nhưng những thứ như Flutter hay Electron thì khó
    Tôi cũng đã quen với GitHub Codespaces cho các dự án nhỏ: https://github.com/codespaces
    Trước đây tôi từng tham gia một buổi live coding trong phỏng vấn, nơi phải sửa một dự án Node đơn giản; nếu là bây giờ, trong tình huống như vậy chắc chắn tôi sẽ dùng container hoặc Codespaces: https://www.welivesecurity.com/en/eset-research/lazarus-luri...
    Với các best practice cho npm, Node, Docker, tôi thường xuyên đọc hướng dẫn của OWASP và áp dụng theo kiểu dùng image Docker nhỏ nhất có thể và tag image rõ ràng: https://cheatsheetseries.owasp.org/cheatsheets/NodeJS_Docker...
    Với các package npm/python, trước khi cài đặt tôi kiểm tra bằng socket.dev các vấn đề như truy cập biến môi trường, gọi mạng, tấn công chuỗi cung ứng, thay đổi gần đây về quyền sở hữu mã nguồn; cũng có thể vô hiệu hóa toàn cục các script postinstall như OWASP khuyến nghị: https://cheatsheetseries.owasp.org/cheatsheets/NPM_Security_...

  • Có một trường hợp chưa đến 1 năm trước về một repository chứa virus Trojan: https://github.com/orgs/community/discussions/63603

    • Repository đó tự nhận là công cụ đánh cắp mật khẩu, và nếu ai đó tải về, giải nén rồi bị đánh cắp thông tin cá nhân và tệp tin thì tôi không hiểu vấn đề nằm ở đâu
      Nó chỉ hoạt động đúng như repository đã tuyên bố

  • Chỉ riêng việc hiển thị rằng đây là repository chính thức cũng có thể thu hút được một mức độ chú ý nhất định

    • Biết đâu sau này GitHub sẽ bắt đầu bán cái dấu tích xanh đó
      Chắc sẽ chẳng có chuyện gì xảy ra đâu /s
      Dù vậy, tôi đồng ý rằng GitHub nên thể hiện rõ hơn repository nào là repository chính thức của dự án