0
0
Lập trình
TT

Cuộc Tấn Công Phishing Lớn Nhất Nghiêm Trọng Với NPM

Đăng vào 2 ngày trước

• 8 phút đọc

Cuộc Tấn Công Phishing Đáng Kinh Ngạc Trên NPM

"Chào mọi người, tôi đã bị tấn công. Xin lỗi vì điều này, thật xấu hổ." Đây là cách mà Josh Junon (tên người bảo trì: Qix-) thông báo về những gì mà các chuyên gia an ninh mạng đang gọi là cuộc tấn công chuỗi cung ứng lớn nhất trong lịch sử.

Chỉ với 10 từ đó, ông đã tiết lộ cách một email phishing duy nhất đã làm lộ 18 gói JavaScript quan trọng nhất trên thế giới — những gói có 2.6 tỷ lượt tải xuống hàng tuần — có khả năng ảnh hưởng đến hàng triệu ứng dụng trên toàn cầu.

Nếu bạn đã viết JavaScript trong 5 năm qua, cuộc tấn công này có thể đã ảnh hưởng đến bạn.

Những Gói Bạn Không Biết Mình Cần

Các gói bị xâm phạm không phải là các framework thời thượng hay thư viện nổi bật. Chúng là cơ sở hạ tầng vô hình mà mọi thứ dựa vào:

  • chalk (300M lượt tải hàng tuần) - Tô màu văn bản trong terminal
  • debug (358M lượt tải hàng tuần) - Tiện ích gỡ lỗi
  • ansi-styles (371M lượt tải hàng tuần) - Phong cách terminal
  • supports-color (287M lượt tải hàng tuần) - Phát hiện hỗ trợ màu
  • strip-ansi (261M lượt tải hàng tuần) - Loại bỏ mã ANSI

Đây là các phụ thuộc của các phụ thuộc — tương đương số kỹ thuật số của các ốc vít và bu lông. Có thể bạn chưa bao giờ cài đặt chúng trực tiếp, nhưng chúng đang nằm trong node_modules của bạn ngay bây giờ.

Chạy lệnh npm ls chalk trong bất kỳ dự án nào. Tôi sẽ chờ.

Cách Nó Đã Xảy Ra (Spoiler: Thật Đơn Giản)

Josh Junon đã nhận được một email trông giống như từ hỗ trợ npm:

  • Người Gửi: support@npmjs.help (chú ý tên miền giả)
  • Chủ Đề: "Khẩn Cấp: Cập Nhật 2FA Của Bạn Hoặc Tài Khoản Sẽ Bị Khóa Ngày 10 Tháng 9"
  • Chiêu trò: Tactics khẩn cấp cổ điển trong những gì ông gọi là "một tuần căng thẳng"

Chỉ cần một cú nhấp chuột. Một tài khoản bị xâm phạm. 2.6 tỷ lượt tải hàng tuần trở thành vũ khí.

Tên miền đã được đăng ký chỉ 3 ngày trước cuộc tấn công. Kẻ tấn công đã chơi trò chơi dài hạn.

Phát Hiện Trong 5 Phút Đã Cứu Internet

Dưới đây là dòng thời gian mà mọi nhà phát triển nên cảm thấy sợ hãi:

  • 9:00 AM UTC: Các gói độc hại được công bố trên npm
  • 9:05 AM UTC: Các hệ thống tự động của Aikido Security đã phát hiện ra sự xâm phạm
  • 10:00 AM UTC: Công bố công khai và cảnh báo cộng đồng
  • 11:30 AM UTC: Hầu hết các gói độc hại đã bị gỡ bỏ

5 phút. Đó là mức độ gần gũi mà chúng ta đã đến với một thảm họa toàn cầu.

Nếu Aikido không phát hiện ra điều này ngay lập tức, chúng ta sẽ phải đối mặt với các ứng dụng bị xâm phạm trên toàn bộ hệ sinh thái JavaScript.

Kẻ Tấn Công Thực Sự Đã Làm Gì

Phần mềm độc hại được chèn vào có mục tiêu rõ ràng: đánh cắp tiền điện tử.

Mã đã chiếm quyền kiểm soát các API trình duyệt (fetch, XMLHttpRequest, window.ethereum) và âm thầm thay thế địa chỉ ví tiền điện tử trong thời gian thực. Người dùng sẽ thấy giao diện giao dịch bình thường của họ, nhưng các khoản thanh toán đã được chuyển hướng đến các ví do kẻ tấn công kiểm soát.

Nó đã nhắm đến nhiều blockchain: Ethereum, Bitcoin, Solana, Tron, Litecoin và Bitcoin Cash.

Dịch nghĩa: Nếu bạn đã thực hiện giao dịch tiền điện tử trong khoảng thời gian 2.5 giờ đó và ứng dụng của bạn sử dụng các gói này, tiền của bạn có thể đã rơi vào tay kẻ xấu.

Tại Sao Đây Chỉ Là Khởi Đầu

Nhà nghiên cứu an ninh Roger Grimes đã nói đúng: "Có bao nhiêu người phải bị xâm phạm khi sử dụng MFA có thể bị lừa trước khi chúng ta nhận ra rằng nó không hiệu quả hơn mật khẩu?"

Kẻ tấn công đã mắc phải một sai lầm quan trọng: họ đã tham lam và tìm kiếm lợi nhuận nhanh từ tiền điện tử thay vì tối đa hóa thiệt hại. Lần sau, có thể chúng ta sẽ không may mắn như vậy.

Hãy tưởng tượng nếu họ đã:

  • Chèn ransomware thay vì đánh cắp tiền điện tử
  • Ẩn mình trong nhiều tháng thay vì vài giờ
  • Nhắm đến việc phá hủy dữ liệu thay vì lợi nhuận tài chính

Sự Thật Khó Chịu Về Phát Triển Hiện Đại

Cuộc tấn công này đã phá vỡ ba giả định cơ bản:

1. Vấn Đề Tin Tưởng

Chúng ta cài đặt hàng trăm gói từ những người lạ mỗi ngày, với giả định rằng chúng an toàn. Cuộc tấn công này đã chứng minh giả định đó là sai lầm thảm khốc.

2. Vấn Đề Điểm Thất Bại Đơn Lẻ

Một buổi sáng tồi tệ của một người bảo trì đã gần như phá hủy internet. Yếu tố buýt cho cơ sở hạ tầng quan trọng thực sự là một người.

3. Vấn Đề Phát Hiện

Hầu hết các nhóm không có bất kỳ cái nhìn nào vào bảo mật chuỗi cung ứng của họ. Chúng ta đang bay mù.

Cách Bảo Vệ Bản Thân (Trước Khi Nó Xảy Ra Lần Nữa)

Các Hành Động Ngay Lập Tức:

  1. Kiểm tra các tệp lockfile của bạn - Ghi chú các phụ thuộc vào các phiên bản cụ thể
  2. Chạy npm audit - Tìm kiếm các lỗ hổng đã biết
  3. Sử dụng npm ci trong môi trường sản xuất - Đảm bảo cài đặt có thể tái tạo
  4. Theo dõi các phụ thuộc của bạn - Sử dụng các công cụ như Snyk, Aikido hoặc GitHub Dependabot

Chiến Lược Dài Hạn:

  1. Triển khai Phân Tích Thành Phần Phần Mềm trong CI/CD của bạn
  2. Xem xét các registry riêng cho các ứng dụng quan trọng
  3. Xem xét lại cây phụ thuộc của bạn thường xuyên - Bạn có thực sự cần 1,000+ gói không?
  4. Bật MFA chống phishing ở mọi nơi

Yếu Tố Con Người:

  1. Không bao giờ nhấp vào các liên kết trong email bảo mật khẩn cấp - Truy cập trực tiếp vào trang web
  2. Xác minh các thông tin liên lạc nghi ngờ qua các kênh thay thế
  3. Khi mệt mỏi/căng thẳng, hãy cẩn thận hơn - Đó là lúc những sai lầm xảy ra

Điều Này Có Nghĩa Gì Đối Với Cộng Đồng JavaScript

Chúng ta đã xây dựng toàn bộ hệ sinh thái của mình trên nền tảng của sự tin tưởng và tiện lợi. Cuộc tấn công này đã phơi bày cách mà nền tảng đó thực sự mong manh.

Những câu hỏi chúng ta cần trả lời:

  • Liệu các gói quan trọng có nên có nhiều người bảo trì mặc định không?
  • Chúng ta có cần các quy trình kiểm tra tốt hơn cho các bản cập nhật gói không?
  • Làm thế nào chúng ta có thể cân bằng giữa tiện lợi và bảo mật?
  • Điều gì sẽ xảy ra khi cuộc tấn công tiếp theo tinh vi hơn?

Dilemma Của Các Nhà Phát Triển

Là các nhà phát triển, chúng ta bị mắc kẹt giữa những lựa chọn không thể:

  • Viết mọi thứ từ đầu → Tái phát minh bánh xe, giới thiệu lỗi
  • Sử dụng các gói hiện có → Kế thừa các rủi ro bảo mật chưa biết
  • Kiểm tra mọi phụ thuộc → Không thể thực hiện ở quy mô lớn
  • Tin tưởng vào hệ sinh thái → Hy vọng cho điều tốt nhất

Không có câu trả lời hoàn hảo, nhưng nhận thức là bước đầu tiên.

Tại Sao Josh Junon Thực Sự Là Một Người Hùng

Trước khi bạn đổ lỗi cho nạn nhân, hãy nhớ rằng: Phản ứng minh bạch của Josh Junon có thể đã cứu internet.

Sự công bố ngay lập tức và chân thực của ông đã cho phép cộng đồng phản ứng trong vài phút thay vì vài giờ hoặc vài ngày. Sự thẳng thắn của ông về việc bị "tấn công" trong một tuần căng thẳng nhắc nhở chúng ta rằng những người bảo trì cũng là con người.

Ông không cần phải:

  • Thừa nhận sai lầm công khai
  • Giải thích chính xác cách mà điều đó xảy ra
  • Chịu trách nhiệm ngay lập tức

Nhưng ông đã làm. Đó là loại tính minh bạch mà hệ sinh thái của chúng ta cần.

Kết Luận

Ngày 8 tháng 9 năm 2025 sẽ được nhớ đến như ngày mà ảo tưởng về bảo mật của hệ sinh thái JavaScript cuối cùng đã sụp đổ.

Thực tế trầm trọng:

  • Một email phishing duy nhất đã làm lộ 2.6 tỷ lượt tải hàng tuần
  • Sự phát hiện xảy ra do may mắn, không phải do thiết kế
  • Cuộc tấn công tiếp theo sẽ tinh vi hơn
  • Chúng ta đều bay mù trong các lựa chọn phụ thuộc của mình

Các hành động cần thực hiện:

  • Kiểm tra các phụ thuộc của bạn hôm nay
  • Triển khai giám sát chuỗi cung ứng
  • Thực hành vệ sinh bảo mật tốt
  • Hỗ trợ những người bảo trì các gói quan trọng

Đây sẽ không phải là cuộc tấn công chuỗi cung ứng cuối cùng. Câu hỏi là: liệu chúng ta có sẵn sàng cho lần tiếp theo không?


Thảo Luận

  • Bạn đang quản lý bảo mật chuỗi cung ứng cho các dự án của mình như thế nào?
  • Liệu các gói mã nguồn mở quan trọng có nên được tài trợ khác không?
  • Những công cụ nào bạn sử dụng để theo dõi các phụ thuộc?
  • Bạn đã bao giờ bị phishing chưa? (Hãy thành thật!)

Hãy nhớ: Chúng ta đều ở đây cùng nhau. Chia sẻ kinh nghiệm của bạn và hãy làm cho hệ sinh thái an toàn hơn cho mọi người.


Bạn đã kiểm tra package-lock.json của mình gần đây chưa? Bởi vì sau khi đọc điều này, có lẽ bạn nên làm vậy.

Gợi ý câu hỏi phỏng vấn
Không có dữ liệu

Không có dữ liệu

Bài viết được đề xuất
Bài viết cùng tác giả

Bình luận

Chưa có bình luận nào

Chưa có bình luận nào