Lộ khóa API Stripe khiến dữ liệu 688.363 khách hàng có nguy cơ bị khai thác

Các nhà nghiên cứu cho biết đã tìm thấy 650 khóa bí mật trực tiếp sk_live và chín khóa giới hạn. Trong số các tài khoản bị ảnh hưởng, 573 tài khoản có thể nhận thanh toán, 531 tài khoản có thể thực hiện chi trả và 519 tài khoản có cả hai khả năng này.

Vì sao chỉ một khóa trực tiếp cũng có thể gây thiệt hại lớn?

Khóa bí mật Stripe là thông tin xác thực để gọi API, không đơn thuần là một mã nhận diện. Phạm vi truy cập phụ thuộc vào quyền của khóa và cấu hình tài khoản, nhưng nếu bị chiếm đoạt, khóa có thể mở đường tới dữ liệu người bán và các hoạt động thanh toán trái phép.

Theo các thử nghiệm được mô tả trong báo cáo, chỉ một khóa còn hoạt động đã đủ để:

• Truy cập danh sách khách hàng
• Tạo liên kết thanh toán giả mạo
• Thực hiện các khoản thanh toán thử nghiệm

Những khả năng này có thể dẫn tới việc thu thập hàng loạt dữ liệu khách hàng, lạm dụng hệ thống thanh toán, hoàn tiền trái phép, lừa đảo có chủ đích và các chiến dịch mạo danh liên quan đến thanh toán. Với tài khoản có quyền chi trả, doanh nghiệp còn phải kiểm tra ngay cấu hình và thông tin đích nhận tiền.

Điểm nguy hiểm nhất là tốc độ. Một bí mật máy chủ bị lộ có thể biến lỗi quản lý thông tin xác thực thành sự cố gian lận đang diễn ra trước khi doanh nghiệp kịp nhận ra các dấu hiệu bất thường.

Vì sao các nhà nghiên cứu chưa gọi đây là vụ xâm nhập hạ tầng Stripe?

Khi phân tích các tệp được phát hành ở chế độ ngoại tuyến, các nhà nghiên cứu nhận thấy cấu trúc thư mục và các đối tượng mang định dạng Stripe phù hợp với dữ liệu được xuất qua các endpoint API hợp lệ. Họ không dùng những khóa bị lộ để đăng nhập hoặc truy cập môi trường trực tiếp của các doanh nghiệp trong quá trình rà soát.

Phân biệt này rất quan trọng: điểm kiểm soát có khả năng nằm ở nơi người bán lưu trữ hoặc để lộ bí mật, chẳng hạn:

• Máy tính của lập trình viên hoặc quản trị viên bị nhiễm infostealer
• Kho mã nguồn công khai và lịch sử Git
• Tệp .env hoặc cấu hình máy chủ bị phơi ra ngoài
• Bộ nhớ đám mây, bản sao lưu và các lớp container
• Hệ thống CI/CD, nhật ký GitHub Actions
• Máy chủ cấu hình sai hoặc các công cụ tự động quét biến môi trường bị lộ

Tuy nhiên, con đường đánh cắp ban đầu của 659 bộ thông tin xác thực vẫn chưa được xác định. Đây là các tuyến lộ khả dĩ, không phải kết luận rằng toàn bộ dữ liệu bắt nguồn từ một nguồn duy nhất.

Một đợt phát hành liên quan làm các con số trở nên khó đối chiếu

Hudson Rock cho rằng một đợt phát hành khác trên diễn đàn có liên quan đến cùng tác nhân. Đợt này được mô tả là gồm 669 thư mục nhà cung cấp và 1.033 khóa API bị xâm phạm, với dung lượng quảng cáo 33 GB; tệp tải xuống được liên kết được cho là nhỏ hơn. Tác nhân cũng tuyên bố đang nắm khoảng 20.000 khóa API Stripe bị xâm phạm và có thể phát hành thêm các đợt khác.

Không nên cộng các con số trên thành một tổng đã được xác minh. Sự khác biệt giữa 659 tài khoản người bán, 669 thư mục nhà cung cấp và 1.033 khóa có thể xuất phát từ các bộ dữ liệu khác nhau, việc một tài khoản có nhiều khóa hoặc cách đếm không giống nhau. Con số 20.000 khóa vẫn chỉ là tuyên bố chưa được xác minh của tác nhân.

Những quốc gia có nhiều người bán bị ảnh hưởng nhất

Phân bổ được nêu trong các báo cáo hiện có gồm:

• Mỹ: 212 người bán
• Anh: 81
• Pháp: 57
• Canada: 38
• Brazil: 30
• Australia: 27

Đây là phân bổ của bộ dữ liệu được báo cáo, không phải kết luận cuối cùng về phạm vi toàn bộ sự cố.

Doanh nghiệp dùng Stripe cần làm gì ngay?

1. Xoay vòng toàn bộ khóa trực tiếp có khả năng bị lộ

Thu hồi và thay thế mọi khóa trực tiếp từng xuất hiện trong mã nguồn, nhật ký, bản sao lưu, dữ liệu giám sát endpoint, ảnh container hoặc hạ tầng công khai. Không nên chờ phát hiện giao dịch gian lận mới xử lý một khóa có nguy cơ bị lộ.

2. Kiểm tra nhật ký API và hoạt động thanh toán

Rà soát nhật ký API, nhật ký bảo mật và Dashboard Stripe để tìm:

• Lệnh gọi API không quen thuộc
• Liên kết thanh toán mới được tạo
• Khoản thu thử nghiệm hoặc trái phép
• Lệnh hoàn tiền bất thường
• Thay đổi quyền truy cập
• Địa chỉ IP hoặc tần suất truy cập đáng ngờ

Hãy lưu giữ các nhật ký liên quan để phục vụ việc dựng lại dòng thời gian sự cố.

3. Xác minh cấu hình chi trả

Kiểm tra cài đặt chi trả, thông tin tài khoản ngân hàng liên kết và các đích nhận tiền. Mọi thay đổi đáng ngờ cần được báo ngay cho Stripe và tổ chức tài chính liên quan, theo quy trình ứng phó và thông báo sự cố áp dụng cho doanh nghiệp.

4. Thay khóa có quyền rộng bằng khóa giới hạn

Mỗi dịch vụ chỉ nên sử dụng khóa có phạm vi quyền nhỏ nhất cần thiết cho hoạt động của dịch vụ đó. Tách biệt hệ thống sản xuất, môi trường phát triển và vai trò vận hành; tránh dùng một bí mật có quyền rộng cho nhiều ứng dụng.

5. Tìm bí mật ở cả hiện tại lẫn lịch sử

Kiểm tra kho mã nguồn hiện tại và lịch sử Git, đầu ra CI/CD, nhật ký GitHub Actions, tệp .env, lớp container, bộ nhớ đám mây, tài liệu và bản sao lưu để tìm giá trị sk_live. Bất kỳ khóa nào được phát hiện cũng cần bị thu hồi và thay thế, kể cả khi nó không còn xuất hiện trong phiên bản mã nguồn hiện tại.

6. Đừng xem quét bí mật của GitHub là lớp bảo vệ duy nhất

GitHub cho biết tính năng quét bí mật được bật tự động cho kho công khai. Với kho riêng tư và kho nội bộ thuộc tổ chức, doanh nghiệp cần bật GitHub Secret Protection trên các gói đủ điều kiện.

Tuy vậy, cơ chế này không thể bảo vệ những bí mật đã bị sao chép vào nhật ký, bản sao lưu, dữ liệu giám sát endpoint hoặc các tệp đã được tải xuống. Quét mã nguồn cần đi cùng hệ thống quản lý bí mật tập trung, thời hạn sống ngắn cho thông tin xác thực, kiểm soát quyền truy cập và giám sát liên tục.

Bài học chính cho người bán

Các báo cáo hiện có chưa chứng minh Stripe bị xâm nhập, nhưng sự việc cho thấy một khóa API trực tiếp bị lộ có thể nhanh chóng mở đường tới dữ liệu khách hàng và hành vi lạm dụng thanh toán. Với doanh nghiệp, bảo vệ nền tảng thanh toán không chỉ là trách nhiệm của nhà cung cấp: bí mật trong môi trường sản xuất phải được giữ ngoài mã nguồn và nhật ký, cấp quyền tối thiểu, xoay vòng nhanh và được điều tra ngay khi xuất hiện hoạt động API hoặc chi trả bất thường.