Chúng ta thực sự đã tránh được một mối đe dọa lớn

• Một vụ tấn công chuỗi cung ứng gần đây trong hệ sinh thái gói NPM trên thực tế đã có thể gây ra thiệt hại lớn hơn nhiều
• Kẻ tấn công đã lợi dụng các thư viện phổ biến nhưng chỉ dùng mã độc theo hướng thay đổi địa chỉ ví tiền mã hóa
• Vụ tấn công này được thực hiện bằng cách đánh cắp thông tin xác thực 2FA của nhà phát triển thông qua email phishing tinh vi
• Nếu nó bị sử dụng theo cách nguy hiểm hơn (ví dụ: đánh cắp API key), đã có khả năng gây ra thiệt hại cực lớn
• Bài viết nhấn mạnh nhận thức rằng mọi dependency đều có thể tiềm ẩn rủi ro và tầm quan trọng của việc hiểu toàn bộ cây phụ thuộc

---

Tổng quan về vụ tấn công và những lo ngại

• Gần đây, các gói phổ biến trong NPM, một trong những hệ sinh thái package lớn nhất, đã bị lộ trước tấn công
  • Ví dụ về chức năng: xử lý màu trong terminal, ánh xạ tên màu-RGB, decorator debug cho hàm, utility xác định giá trị giống mảng, v.v.
• Những dependency phổ biến này được sử dụng rất rộng rãi, và khi mã đã lọt vào thì khả năng cao sẽ được triển khai ngay vào môi trường production
• Nếu nó chứa proxy độc hại, đánh cắp API key hoặc các kiểu tấn công nghiêm trọng khác, hậu quả có thể đã tồi tệ hơn rất nhiều
• Trên thực tế, mã độc này chỉ hoạt động theo cách chỉnh sửa địa chỉ thanh toán tiền mã hóa trong ví online (ví dụ: MetaMask)

Mức độ tinh vi của cuộc tấn công phishing

• Điểm khởi đầu của vụ tấn công là một email phishing được dựng rất khéo
  • Tạo cảm giác cá nhân hóa bằng cách sử dụng username NPM
  • Dẫn người dùng tin tưởng bằng thông điệp "vì lý do bảo mật, hãy thay đổi mật khẩu và thông tin xác thực 2FA"
  • Nội dung được xây dựng sao cho người dùng bình thường rất dễ mắc bẫy, kết hợp với cách vận hành khá đặc thù của NPM
  • Nêu rõ thời hạn cụ thể để tạo cảm giác khẩn cấp, khiến người dùng bận rộn dễ mất cảnh giác và bấm vào liên kết phishing
  • Sử dụng domain .help tương tự domain chính thức của NPM
• Điểm nổi bật nhất chỉ là việc dùng "npmjs.help" thay vì domain chính thức
  • Ngày nay nhiều gTLD (Generic Top Level Domain) mới được dùng rộng rãi cho blog hay tài liệu, nên điều này cũng có thể trông rất tự nhiên

Thiệt hại tiềm tàng của vụ tấn công

• Email phishing đã có thể đánh cắp thông tin 2FA của người dùng, sau đó chèn mã tấn công để phát hành package mới
• Các thư viện tiêu biểu bị nhắm tới gồm is-arrayish, color-string, color-name vốn được dùng cực kỳ rộng rãi
  • Nếu mã độc được mở rộng không chỉ để chặn tiền mã hóa mà còn để đánh cắp API key, nó có thể gây ra hậu quả mang tính hủy diệt
  • Ví dụ như làm lộ hàng loạt API key của OpenAI, AWS, dẫn tới thiệt hại dài hạn và trên quy mô lớn
• Trên thực tế, phần lớn các thư viện bị nhiễm chủ yếu được dùng trong công cụ dòng lệnh, nên mục tiêu đánh cắp tiền mã hóa bị giới hạn ở mức đó

Nhắm vào hệ sinh thái Web3 và chiến lược của kẻ tấn công

• Có vẻ vụ tấn công lần này chủ yếu nhắm vào người dùng Web3 (những người thanh toán qua trình duyệt, v.v.)
  • Bằng cách chọn các thư viện phổ thông không liên quan trực tiếp tới Web3 làm mục tiêu, kẻ tấn công tránh được khả năng bị hệ sinh thái Web3 nhanh chóng phát hiện và chặn lại
  • Ví dụ: ngay cả khi kiểm tra kỹ các thư viện tích hợp với MetaMask, vẫn rất khó dự đoán rằng cuộc tấn công lại xuất phát từ utility liên quan đến màu chữ

Bài học cho hệ sinh thái phát triển

• Trường hợp này nhấn mạnh rằng mọi package dependency đều có thể thực sự là mã độc
  • Trên thực tế tồn tại giới hạn trong việc luôn kiểm soát hoặc giám sát toàn bộ cây phụ thuộc
  • Điều này cho thấy trong luồng triển khai production nhanh và dưới áp lực thời gian, việc rà soát bảo mật rất dễ bị đẩy xuống hàng sau
• Về sau, tầm quan trọng của việc nắm được toàn bộ cấu trúc dependency của dự án và quản lý cẩn trọng sẽ còn tăng lên

Kết luận và lưu ý

• Nội dung này không nhằm chỉ trích hay quy trách nhiệm cho bất kỳ ai; điều quan trọng là nhận thức rằng ai cũng có thể trở thành mục tiêu của phishing
• Tình hình có thể đã thay đổi sau khi bài viết này được đăng, nên nếu có điểm chưa rõ hoặc nghi ngờ sai sót, cần tự xác minh trực tiếp

Tags:

[GN⁺]

Ý kiến trên Hacker News

• Vụ tấn công chuỗi cung ứng npm của nx là viên đạn mà rất nhiều công ty đã không tránh được; chỉ cần cài plugin nx cho VS Code là nó tự động kiểm tra phiên bản nx mới nhất trên npm, và nếu có phiên GitHub (ví dụ đăng nhập tài khoản công ty qua GH CLI) hoặc thông tin xác thực quan trọng trong file .env thì tất cả đều có thể bị rò rỉ; đây là chuyện không thể tránh chỉ bằng cách khóa dependency hay quản lý tốt cập nhật bảo mật; hệ sinh thái này cần một thay đổi sâu sắc hơn ở cấp độ nền tảng; xem chi tiết tại thông báo bảo mật chính thức

  • Tôi tránh mọi thứ liên quan đến NPM; ngoại lệ duy nhất là typescript compiler, nhưng nếu nó được viết lại bằng Go thì tôi cũng sẽ bỏ luôn; với Go, khả năng khai báo phiên bản tối thiểu rất tốt, và những gì tải về tuyệt đối không bị thực thi trong quá trình biên dịch; còn với NPM, mã nguồn thường khác với trên GitHub nên tôi không xem đó là thứ đáng tin
  • Extension cho editor là mục tiêu tấn công cực kỳ hấp dẫn vì chúng được tự động cài đặt và cập nhật trong môi trường phát triển có mức rủi ro cao; tôi thấy lạ là vẫn chưa có làn sóng thâu tóm quy mô lớn bởi các bên xấu như với extension trình duyệt; tôi có nghe nói đội ngũ VS Code đầu tư rất nhiều vào phát hiện malware, nhưng không rõ mọi editor như Sublime có quy trình kiểm định kiểu này hay không
  • Tôi giữ toàn bộ package và cơ sở dữ liệu ở máy cục bộ, và làm việc trên máy dev trong chế độ máy bay; chỉ bật mạng khi git push

• Chúng ta thật sự chỉ vừa kịp thoát khỏi một tình huống cận kề thảm họa; tôi không thể tin nổi kẻ tấn công có quyền truy cập vào các package như vậy lại chỉ tung lên một công cụ trộm tiền mã hóa đơn giản; nếu là cơ hội trời cho như thế, có vẻ đáng để đầu tư thêm khoảng một tuần nhằm cài một exploit tinh vi hơn: khóa API, thêm SSH public key, làm lộ IP máy chủ, profile trình duyệt hoặc session token trên máy của lập trình viên, thậm chí cả thông tin thẻ Amazon trên desktop của tôi; có quá nhiều thứ có thể đánh cắp; kể cả không tự dùng thì cũng rất dễ bán trên các diễn đàn dark web; đôi lúc tôi tự hỏi phải chăng các tội phạm mạng giỏi nhất đã có việc ổn định, thu nhập cao ở các công ty công nghệ nên chỉ còn lại các vụ tấn công đơn giản kiểu này

  • Kiểu tấn công này chắc chắn sẽ bị phát hiện rất nhanh, nên có vẻ chúng không chọn cách âm thầm mà là chiếm toàn bộ tài khoản rồi đánh nhanh rút gọn; chúng cần một cách tự động để moi được nhiều tiền nhất trong vài giờ, và tiền mã hóa rõ ràng là đáp án; nếu backdoor không đủ tinh vi để không bị nửa thế giới soi code phát hiện, thì cũng chẳng có lý do gì phải chuẩn bị lâu hơn
  • Tiền mã hóa bị đánh cắp thì không thể đảo ngược giao dịch, hoàn tiền hay khôi phục, nên thực tế là tài sản chắc chắn cầm được; ngược lại API hay SSH key của lập trình viên gần như chẳng có giá trị, và dù có may mắn thì cuối cùng muốn quy đổi thành tiền mặt cũng lại phải qua tiền mã hóa
  • Đột nhập nhanh, trộm vài trăm nghìn USD, rút ra, rồi vài tháng sau lặp lại y như vậy; chỉ cần né được cảnh sát thì có thể sống cả đời không lo nghĩ; ăn cắp thứ như khóa AWS cũng không đem lại lợi ích lớn đến thế; cũng có bọn nhắm vào mật khẩu hay cơ sở dữ liệu password manager thay vì tiền mã hóa, nhưng rốt cuộc chúng vẫn thường nhắm đến các trang liên quan đến crypto; ngay lúc này chắc chắn cũng có những kẻ đang kiên nhẫn chờ thời điểm xâm nhập doanh nghiệp, và chúng sẽ ẩn mình cho tới khi thành công mà không để lộ dấu vết
  • Đây không phải kiểu cơ hội một lần trong đời; từ giờ bọn tội phạm sẽ nhận ra rằng chỉ cần nhắm vào vài "lập trình viên" là có thể dễ dàng tiếp cận hàng triệu USD, và các thủ đoạn táo bạo hơn sẽ liên tục xuất hiện; nếu bạn là người bảo trì mã nguồn mở, đã đến mức bạn phải thật sự suy nghĩ xem mình đang che giấu danh tính ngoài đời trên mạng tốt đến đâu

• Thói quen trì hoãn của tôi là một kỹ năng sinh tồn; vì tôi luôn đợi người khác beta test trước, nên trước đây công ty tôi đã dùng Microsoft Office 2000 suốt 12 năm, và nhờ vậy có 10 năm yên bình không phải xử lý sự cố nâng cấp hay đào tạo lại; tôi cũng có thói quen tuyệt đối không bấm vào link trong email

  • Xe Honda của tôi và Kubernetes cũng như vậy; tôi giữ chiếc xe đời 2006 đủ lâu để bỏ qua nhiều thế hệ rắc rối lớn nhỏ trong việc tích hợp giữa ô tô và điện thoại, và chỉ gần đây thôi thì việc kết nối iPhone trên xe đời 2023 mới trở nên thật sự mượt; Kubernetes cũng vậy, nhờ trì hoãn đề xuất của sếp suốt một thời gian dài mà giờ mới chuyển sang khi EKS, GKE các thứ đã đủ trưởng thành nên đỡ khổ hơn hẳn; nếu tôi nghe theo ngay từ 6~7 năm trước thì chắc đã tốn vô số công sức vô ích
  • Trong hệ sinh thái npm, nếu bạn không cập nhật mỗi 54 giây thì đã bị bỏ lại rất xa rồi
  • Cách đó có hiệu quả với package độc hại mới xuất hiện, nhưng không giúp được khi phần mềm đã nhiễm sẵn lại còn dính cả worm
  • Tôi sẽ trả lời vào ngày mai
  • "Mặc định hoãn dùng bản mới trong 2 tuần" là một biện pháp phòng thủ rất hiệu quả trước tấn công chuỗi cung ứng

• Với startup nhỏ thì khó, nhưng với các tay chơi lớn như npm, tôi nghĩ họ nên giữ chỗ trước tất cả phiên bản TLD của domain npm như "npm.io", "npm.sh", "npm.help"; việc kẻ tấn công chiếm được domain "npm.help" đã khiến vụ tấn công này hiệu quả hơn nhiều

  • Giống như AWS bảo khách hàng phải cảnh giác phishing, nhưng lại đổi địa chỉ email hóa đơn chính thức từ [e-mail] sang [e-mail]; vì là địa chỉ chưa từng thấy nên trông gần như một email phishing, nhưng lại là chính thức nên rất dễ gây rối; thậm chí email báo trước cũng trông rất đáng ngờ, đến mức tôi không mở file PDF đính kèm cho tới khi thật sự nhận được hóa đơn; các công ty đang tự tạo ra sự nhầm lẫn không cần thiết trong khi lại dặn khách hàng cẩn thận với phishing
  • Có hơn 1.500 TLD, và dù một số bị giới hạn hoặc là mã quốc gia, tôi vẫn tò mò không biết chi phí thực tế mỗi năm để đăng ký hết các TLD kiểu này là bao nhiêu; chắc cũng có nơi cung cấp dưới dạng SaaS
  • Nhìn vào danh sách TLD thì thấy domain quá nhiều; kể cả với công ty lớn, dù vẫn nên cố giữ trước các TLD tương tự để giảm phishing, tôi nghĩ cũng không thể chặn hoàn toàn được
  • Việc đầu tiên là luôn xác minh đó có đúng là domain chính thức hay không; nếu là registrar giảm giá mới đăng ký gần đây hoặc domain sắp hết hạn thì tôi sẽ mặc định nghi ngờ; nhất là khi link đó còn gây áp lực kiểu "không còn thời gian" bằng cách nhấn mạnh deadline; tôi cho rằng liên lạc chính thức chỉ nên dùng domain đại diện nổi tiếng chính thức (hoặc subdomain của nó)
  • Tên miền npm và các biến thể tương tự có vô số cách biến tấu, nên thực tế không thể ngăn chặn chỉ bằng cách giữ chỗ tất cả; chỉ nhìn tên domain đã có thể nghi ngờ là phishing, nhưng thực tế những tên như npmjs.help vẫn có thể bị bấm nhầm

• Nếu ai đó kết hợp sự cực kỳ bài bản kiểu Jia Tan với các lỗ hổng bảo mật lỏng lẻo của chúng ta như plugin editor, shell userland các thứ thì sao? Các công cụ dành cho lập trình viên chạy với quyền siêu người dùng nhưng lại là thứ ít được kiểm chứng nhất; bản thân tôi cũng không thể tự mình kiểm định từng thứ như elisp, neovim, vscode, hay các công cụ userland đơn giản; trường hợp tốt nhất cũng chỉ là lấy từ nixpkgs; chỉ cần tung ra một plugin VSCode tốt hơn rồi chờ 1~2 năm là xong, GG

  • Tôi hy vọng một ngày nào đó sẽ có người thật sự giải quyết được vấn đề xkcd số 1200

• Dù các ví như MetaMask là mục tiêu, tôi nghe nói MetaMask được bảo vệ khá tốt trước kiểu tấn công này nhờ module cô lập LavaMoat; nếu có bài phân tích chi tiết về mức độ bảo vệ thực tế thì tôi rất muốn đọc; cá nhân tôi không liên quan đến MetaMask, nhưng tôi rất tò mò những biện pháp ứng phó bảo mật như vậy hiệu quả đến đâu trong thực tế tấn công thật (vốn thường triển khai chậm hơn); tiện thể thêm bài liên quan

• Trước câu nói rằng "sự thật là cuối cùng bạn cũng sẽ dính loại tấn công phishing này", bản thân tôi nghĩ có lẽ mình thì không; tôi có thói quen tuyệt đối không nhập thông tin xác thực vào link trong email nếu đó không phải thứ tôi trực tiếp yêu cầu trước đó, ví dụ như reset mật khẩu; tôi nghĩ đây là kỹ năng bảo mật mà ai cũng buộc phải học trong năm 2025

  • Cách nói "kiểu phishing 'này'" làm nó nghe như một cuộc tấn công tinh vi nào đó, nhưng thực ra đây lại chỉ là một trường hợp lập trình viên dính email phishing rất bình thường; một sai lầm cực kỳ cơ bản, đôi khi đến cả nhân viên hành chính còn không mắc; dĩ nhiên ai cũng có thể sơ suất, nhưng tôi nghĩ chính sự bất cẩn rõ ràng và lỗi nghiệp dư đã khiến chuyện này lặp đi lặp lại

• Trái với mô tả trong bài rằng "mọi malware chỉ đơn giản thay thế địa chỉ ví tiền mã hóa", lý do MetaMask không bị ảnh hưởng là vì:

1. package không được cập nhật ngay vào thời điểm bị tấn công, và
2. MetaMask được bảo vệ bởi LavaMoat cả ở bước cài đặt lẫn lúc chạy; trong khi payload độc hại này nhắm vào các trang web dùng ví khác có tương tác với MetaMask; tham khảo thêm, tôi có tham gia phát triển LavaMoat; xem chi tiết tại GitHub của LavaMoat

• Các kho package mở lớn cần giải pháp bảo mật mạnh hơn rất nhiều, hoặc ít nhất là phải có một tập package cốt lõi được thẩm định, đáng tin cậy; hệ sinh thái Python, Rust và các hệ khác cũng tương tự, đều đang vận hành dựa trên niềm tin

  • Vấn đề cốt lõi của npm là không bắt buộc namespace; người mới dùng Java hay than rằng "sao Maven không dễ như npm", nhưng càng về sau tôi càng đánh giá cao hệ thống namespace của Maven và sự ám ảnh của nó với kiểm soát chất lượng; POM xml đúng là bất tiện, nhưng cách quản lý thay đổi bảo thủ đó tạo ra niềm tin; bài viết liên quan: Vì sao namespace quan trọng trong các kho mã nguồn mở công khai
  • Nếu như trường hợp này, khi chính tài khoản của maintainer package bị chiếm đoạt, thì cả namespace lẫn các biện pháp cấu trúc khác cũng vô nghĩa; giải pháp duy nhất là trì hoãn để các bản phát hành mới không được áp dụng ngay lập tức
  • Các bản phân phối Linux cũng dựa trên niềm tin, nhưng để có quyền đưa package lên thì bạn phải "chứng minh" được độ tin cậy, và toàn bộ hệ thống xác minh niềm tin đều tồn tại; còn NPM thì giống một hệ thống mở nơi gần như ai cũng có thể tải lên

• Lập luận rằng "chuyện này không thể ngăn được" chỉ xuất hiện ở những hệ sinh thái bị xâm phạm thường xuyên nhất

  • Chính xác đó mới là vấn đề, một kết luận quá lười biếng