Khi AI không phải là mắt xích yếu: Lộ dữ liệu ứng viên McHire

Chuyện gì đã xảy ra

Vào tháng 6 năm 2025, các nhà nghiên cứu bảo mật Ian Carroll và Sam Curry đã tiết lộ một chuỗi lỗ hổng trong McHire, nền tảng tuyển dụng của McDonald's do Paradox.ai xây dựng và được phần lớn các cửa hàng nhượng quyền của McDonald's sử dụng. Các báo cáo công khai từ Wired và BleepingComputer cho biết tập dữ liệu bị lộ khoảng 64 triệu ứng viên, với tên, địa chỉ email, số điện thoại và bản ghi cuộc trò chuyện có thể truy cập được bởi bất kỳ ai đi theo con đường mà các nhà nghiên cứu đã làm.

Tiêu đề lan truyền nhanh nhất đã coi đây là một cuộc tấn công prompt injection vào chatbot "Olivia". Cách hiểu này là sai. Các nhà nghiên cứu cho biết họ đã thử prompt injection trước, và nó đã thất bại: bot bị ràng buộc chặt chẽ với các phản hồi được lập trình sẵn và không bao giờ có dữ liệu backend mà nó có thể bị lừa để rò rỉ. Sự thỏa hiệp không liên quan gì đến mô hình ngôn ngữ.

Điểm vào thực tế là một trang đăng nhập quản trị Paradox.ai trên McHire, có thể truy cập từ internet công cộng. Các nhà nghiên cứu đã thử thông tin đăng nhập "123456" / "123456" trên một tài khoản thử nghiệm mà, theo báo cáo công khai, đã được để hoạt động từ năm 2019. Họ đã vào được.

Khi đã vào bên trong, một lỗ hổng Insecure Direct Object Reference (IDOR) cổ điển trên API ứng viên đã cho phép họ tăng một ID số và kéo hồ sơ của bất kỳ ứng viên nào. Không có khai thác mô hình, không có kỹ thuật mới lạ, không có zero-day. Thông tin đăng nhập mặc định cộng với một tham chiếu đối tượng không được xác thực.

Tại sao mô hình này cứ lặp lại

Thất bại thú vị ở đây không phải là kỹ thuật, mà là tổ chức. Chatbot là thành phần "AI" dễ thấy, vì vậy nó đã thu hút sự chú ý về bảo mật. Quản trị web nhàm chán đằng sau nó là bán kính vụ nổ thực sự, và hầu như không ai nhìn vào nó theo cách đó.

Điều này xảy ra bất cứ khi nào người mua coi nhà cung cấp AI là một sản phẩm AI chứ không phải là một ứng dụng SaaS tình cờ chứa một mô hình. Mô hình được đánh giá red-team. Bảng điều khiển quản trị, API ứng viên, bộ lưu trữ, ghi nhật ký kiểm tra, chính sách xoay vòng thông tin đăng nhập — những thứ có hàng thập kỷ các chế độ lỗi đã biết — được coi là hệ thống ống nước.

Cấu trúc khuyến khích nhà cung cấp củng cố điều đó. Các nhà cung cấp AI giao hàng nhanh chóng, thường trước khi họ có một chương trình bảo mật trưởng thành, và các nhóm mua sắm của khách hàng hỏi về hành vi của mô hình hơn là về ứng dụng xung quanh. Một tài khoản thử nghiệm từ năm 2019 với mật khẩu "123456" tồn tại trong khoảng trống đó trong nhiều năm vì không ai giới hạn việc xem xét để tìm thấy nó.

Các vụ vi phạm AI tốn kém nhất trong hai năm tới sẽ không phải là khai thác mô hình. Chúng sẽ là các lỗ hổng web thời những năm 1990 trong ứng dụng bao quanh mô hình.

Kịch bản của kẻ tấn công từng bước

Trình tự được tiết lộ rất ngắn, và đó là phần không thoải mái. Một kẻ tấn công có kỹ năng không cần một chuỗi các nguyên thủy mới lạ.

Bước 1: liệt kê bề mặt nhà cung cấp AI

Xác định nhà cung cấp bên thứ ba đằng sau chatbot dễ thấy. Trong trường hợp này, bot tự nhận là do Paradox.ai xây dựng, điều này chỉ ra một bề mặt quản trị riêng biệt — một trang đăng nhập trên cùng tên miền McHire.

Bước 2: thử các thông tin đăng nhập rõ ràng

Thông tin đăng nhập mặc định và yếu vẫn là cuộc tấn công mang lại hiệu quả cao nhất chống lại các bảng điều khiển quản trị của nhà cung cấp. Báo cáo cho thấy một tài khoản thử nghiệm duy nhất với "123456" / "123456" là đủ.

Bước 3: chuyển từ quản trị viên sang dữ liệu

Vai trò quản trị viên đã lộ ra một API ứng viên nội bộ. API đã sử dụng một định danh số tuần tự và không kiểm tra xem tài khoản gọi có được ủy quyền để đọc từng ứng viên cụ thể hay không. Lặp lại ID đã trả về các bản ghi tùy ý.

Bước 4: xác nhận phạm vi và tiết lộ

Các nhà nghiên cứu đã dừng lại ở bằng chứng về tác động, xác thực kích thước của tập dữ liệu và báo cáo cho Paradox.ai và McDonald's. Paradox.ai đã vô hiệu hóa tài khoản thử nghiệm và được cho là đã khắc phục IDOR trong vòng vài giờ sau khi tiết lộ.

Những gì người phòng thủ đã bỏ lỡ

Ba điều, theo thứ tự mức độ nghiêm trọng giảm dần.

Thứ nhất, không có vệ sinh thông tin đăng nhập trên bề mặt quản trị của nhà cung cấp. Một tài khoản thử nghiệm có trước khi triển khai sản xuất, với mật khẩu số sáu ký tự, có thể truy cập từ internet công cộng năm năm sau khi nó được tạo. Bất kỳ cuộc kiểm tra thông tin đăng nhập định kỳ nào cũng sẽ tìm thấy nó.

Thứ hai, không có kiểm tra ủy quyền trên API ứng viên. IDOR là một trong những lỗ hổng web lâu đời nhất, được ghi chép đầy đủ nhất trong danh mục OWASP. Việc một cuộc gọi quản trị viên được xác thực trả về các bản ghi ứng viên tùy ý có nghĩa là API đã thực thi xác thực nhưng không thực thi ủy quyền.

Thứ ba, không có đánh giá bảo mật về bề mặt nhàm chán. Chatbot đã thu hút sự chú ý vì nó là AI. Đăng nhập quản trị viên, cổng API và lưu trữ 64 triệu bản ghi PII đã không nhận được sự giám sát tương tự — tại McDonald's, tại Paradox.ai hoặc tại các cửa hàng nhượng quyền đã triển khai McHire.

Danh sách kiểm tra phòng thủ thực tế

Các bản sửa lỗi không hấp dẫn. Chúng cũng là những gì sẽ ngăn chặn sự cố này.

• Liệt kê mọi bề mặt xác thực được hiển thị bởi bất kỳ nhà cung cấp AI nào bạn sử dụng, bao gồm bảng điều khiển quản trị, môi trường thử nghiệm và công cụ hỗ trợ khách hàng. Coi chúng như các ứng dụng web quý giá, không phải như hệ thống ống nước cho mô hình.
• Yêu cầu nhà cung cấp xác nhận bằng văn bản rằng không có thông tin đăng nhập mặc định hoặc được chia sẻ nào tồn tại trong sản xuất, và các tài khoản thử nghiệm được tạo trong quá trình giới thiệu sẽ bị xóa khi triển khai.
• Chạy các thử nghiệm IDOR/BOLA được xác thực chống lại mọi API mà nhà cung cấp hiển thị, đặc biệt là các API trả về bản ghi cho mỗi người dùng. OWASP API Security Top 10 xếp hạng điều này #1 có lý do.
• Buộc SSO với nhà cung cấp danh tính của bạn cho mọi bề mặt quản trị của nhà cung cấp, để thông tin đăng nhập không thể trôi dạt độc lập và các tài khoản cũ sẽ chết khi nhân viên rời đi.
• Giới hạn đặc quyền phiên quản trị để một tài khoản quản trị bị xâm phạm không thể liệt kê toàn bộ tập dữ liệu ứng viên hoặc khách hàng.
• Yêu cầu nhà cung cấp ghi nhật ký và cảnh báo về các mẫu đọc hàng loạt chống lại các API nhạy cảm. Việc kéo hàng chục triệu hồ sơ ứng viên không nên giống như một ngày bình thường.

Cách kiểm thử tấn công hiện đại sẽ phát hiện ra điều này

Một cuộc tấn công có phạm vi, được ủy quyền chống lại bề mặt nhà cung cấp McHire — không phải chống lại chatbot — sẽ tìm thấy điều này vào buổi chiều đầu tiên. Các kiểm tra liên quan đã được thực hiện tốt: tấn công credential-spray chống lại đăng nhập quản trị viên, kiểm soát truy cập ngang được xác thực trên mọi API được tham số hóa và xem xét các tài khoản thử nghiệm và quy trình đặt lại.

Mô hình tự nó không cần một nhóm đỏ trong câu chuyện này. Mô hình đã hoạt động chính xác. Các hàng rào bảo vệ của chatbot đã được giữ vững. Bài học là một đánh giá bảo mật ứng dụng kỹ lưỡng về sản phẩm bao bọc sẽ gắn cờ mọi bước của chuỗi giết người trước khi nó được triển khai.

Những gì cần theo dõi tiếp theo

Hãy mong đợi nhiều hơn thế này. Các nhà cung cấp AI đang hấp thụ nhiều quy trình làm việc nhạy cảm hơn — tuyển dụng, yêu cầu bồi thường, dịch vụ khách hàng, lập lịch trình — và các bảng điều khiển quản trị backend xung quanh các quy trình làm việc đó hiện đang chứa các tập trung dữ liệu cá nhân được quy định mà trước đây nằm trong các hệ thống khó tiếp cận hơn.

Hai điều cần theo dõi trong chương trình của riêng bạn: nhà cung cấp AI nào nắm giữ nồng độ dữ liệu cá nhân được quy định cao nhất thay mặt bạn, và quyền hợp đồng của bạn để kiểm tra bề mặt quản trị của họ trông như thế nào. Nếu bạn không thể chạy đánh giá bảo mật ứng dụng được xác thực chống lại bảng điều khiển của nhà cung cấp, bạn đang tin rằng tài khoản thử nghiệm tiếp theo đã bị xóa, API tiếp theo thực thi ủy quyền và mật khẩu mặc định tiếp theo đã được xoay vòng. Tiết lộ McHire cho thấy điều gì xảy ra khi niềm tin đó bị đặt sai chỗ.