Một chuyên gia bảo mật đã phát hiện nhiều lỗ hổng bảo mật nghiêm trọng trong hạ tầng kỹ thuật số của McDonald’s. Các lỗ hổng này cho phép tiếp cận trái phép dữ liệu nhạy cảm của khách hàng và các hệ thống nội bộ của tập đoàn.

Quá trình điều tra kéo dài nhiều tháng, buộc chuyên gia phải áp dụng phương pháp tiếp cận không theo quy ước để báo cáo sự cố, do các kênh bảo mật truyền thống không hiệu quả.

Khởi đầu phát hiện và các lỗ hổng ban đầu

Cuộc điều tra bắt đầu từ việc ứng dụng di động của McDonald’s chỉ thực hiện xác thực điểm thưởng ở phía máy khách (client-side validation). Điều này cho phép người dùng tiềm năng có thể yêu cầu đồ ăn miễn phí mà không cần đủ điểm.

Sau những khó khăn trong việc báo cáo phát hiện ban đầu qua các kênh chính thức, chuyên gia bảo mật đã tiếp tục nghiên cứu tư thế an ninh của McDonald’s. Qua đó, họ phát hiện ra nhiều lỗ hổng bảo mật nghiêm trọng hơn đáng kể.

Điểm yếu trong McDonald’s Feel-Good Design Hub

Nền tảng McDonald’s Feel-Good Design Hub, kho tài nguyên trung tâm chứa các tài sản thương hiệu và tài liệu marketing được sử dụng trên 120 quốc gia, ban đầu chỉ được bảo vệ bằng xác thực mật khẩu phía máy khách.

Ngay cả sau khi McDonald’s triển khai hệ thống xác thực đúng đắn theo báo cáo của chuyên gia, một lỗ hổng nghiêm trọng vẫn tồn tại. Bất kỳ ai cũng có thể đăng ký quyền truy cập bằng cách đơn giản thay đổi “login” thành “register” trong URL. Điều này cho thấy sự thiếu sót trong quy trình kiểm tra bảo mật sâu hơn sau khi vá lỗi.

Hệ thống đăng ký cung cấp các thông báo lỗi hữu ích, chỉ rõ những trường thông tin nào là bắt buộc. Điều này khiến việc tạo tài khoản trái phép trở nên đơn giản một cách đáng báo động. Việc cung cấp quá nhiều thông tin trong thông báo lỗi có thể bị kẻ tấn công lợi dụng để thu thập thông tin.

Đáng lo ngại hơn, nền tảng này gửi mật khẩu qua email dưới dạng văn bản thuần túy (plaintext) cho người dùng mới. Đây là một thất bại cơ bản trong thực hành bảo mật cho một tập đoàn lớn vào năm 2025. Việc gửi mật khẩu plaintext làm tăng nguy cơ rò rỉ dữ liệu nhạy cảm nếu email bị chặn hoặc hệ thống thư điện tử bị xâm phạm.

Tiết lộ khóa API và cấu hình tìm kiếm

Chuyên gia đã tìm thấy các khóa và bí mật API (API keys and secrets) của McDonald’s được nhúng trực tiếp trong mã JavaScript của Design Hub. Điều này có thể cho phép các đối tượng độc hại gửi thông báo trông giống như thông báo chính thức của McDonald’s tới người dùng. Kẻ tấn công cũng có thể thực hiện các chiến dịch lừa đảo (phishing) tinh vi sử dụng chính hạ tầng của công ty. Đây là một lỗ hổng nghiêm trọng có thể dẫn đến xâm nhập trái phép và lừa đảo người dùng cuối.

Ngoài ra, cấu hình tìm kiếm Algolia của McDonald’s đã tiết lộ nhiều chỉ mục (indexes) chứa thông tin cá nhân của người dùng đã yêu cầu quyền truy cập vào các hệ thống khác nhau của McDonald’s. Việc lộ lọt thông tin cá nhân này là một ví dụ điển hình về rò rỉ dữ liệu nhạy cảm, có thể dẫn đến các hậu quả pháp lý và làm giảm uy tín của thương hiệu.

Tiếp cận trái phép hệ thống cấp điều hành

Có lẽ điều đáng lo ngại nhất là các tài khoản thành viên phi hành đoàn (crew member) cơ bản có thể truy cập các hệ thống cấp điều hành thông qua hạ tầng cổng thông tin nhân viên của McDonald’s. Điều này cho thấy sự thiếu phân quyền nghiêm ngặt trong hệ thống nội bộ.

Hệ thống TRT, chỉ dành cho mục đích sử dụng nội bộ của tập đoàn, cho phép bất kỳ thành viên phi hành đoàn nào tìm kiếm và xem thông tin liên hệ của nhân viên McDonald’s trên toàn cầu, từ quản lý cửa hàng đến các giám đốc cấp cao (C-suite executives). Mức độ tiếp cận thông tin nhạy cảm này là một rủi ro đáng kể đối với an toàn thông tin của toàn bộ tổ chức.

Hệ thống này thậm chí còn bao gồm một tính năng “mạo danh” (impersonation) cung cấp thông tin chi tiết về nhân viên. Tính năng này, nếu bị lạm dụng, có thể dẫn đến các cuộc tấn công lừa đảo nội bộ hoặc chiếm đoạt tài khoản.

Lỗ hổng trong hệ thống Global Restaurant Standards (GRS)

Hệ thống Global Restaurant Standards (GRS), được thiết kế cho các chủ nhượng quyền, không yêu cầu xác thực đối với các chức năng quản trị. Lỗ hổng này mở ra cánh cửa cho các cuộc tấn công tiềm tàng vào hệ thống quản lý nhượng quyền.

Chuyên gia đã chứng minh điều này bằng cách tạm thời sửa đổi nội dung trang chủ thông qua các điểm cuối API không được bảo vệ. Điều này làm nổi bật mức độ dễ dàng mà các đối tượng độc hại có thể thao túng nền tảng. Một lỗ hổng bảo mật trong API có thể gây ra những hậu quả nghiêm trọng, từ thay đổi thông tin đến chèn mã độc hại.

// Ví dụ minh họa về truy cập API không được bảo vệ (không phải mã thực tế)
// Endpoint: /api/grs/admin/homepage_content
// Method: PUT
// Body: { "content": "Nội dung đã bị thay đổi bởi kẻ tấn công." }

// Trong môi trường thực, một yêu cầu HTTP PUT đơn giản tới endpoint này
// mà không cần token xác thực hoặc kiểm tra quyền sẽ cho phép thay đổi dữ liệu.

Để tìm hiểu thêm về các chiến lược bảo mật API, có thể tham khảo các nguồn uy tín như CISA: API Security Strategy hoặc các hướng dẫn chuyên sâu về REST API Security.

Thách thức trong quy trình tiết lộ lỗ hổng có trách nhiệm

Chuyên gia đã đối mặt với những trở ngại đáng kể khi cố gắng thực hiện quy trình tiết lộ có trách nhiệm (responsible disclosure). Cuối cùng, họ phải gọi điện đến trụ sở McDonald’s và gọi ngẫu nhiên tên các nhân viên bảo mật tìm thấy trên LinkedIn cho đến khi kết nối được với người có thẩm quyền tiếp nhận báo cáo lỗ hổng bảo mật.

McDonald’s trước đây đã công bố thông tin liên hệ về bảo mật nhưng đã gỡ bỏ ngay sau khi triển khai. Điều này khiến không có cơ chế báo cáo rõ ràng nào cho các nhà nghiên cứu bảo mật. Sự thiếu hụt kênh liên lạc này làm tăng rủi ro khi các lỗ hổng có thể bị lạm dụng trước khi được vá.

Kết luận về tác động và bài học

McDonald’s đã giải quyết các lỗ hổng được báo cáo. Tuy nhiên, vụ việc này làm nổi bật những thách thức hiện tại trong các thực hành bảo mật của doanh nghiệp và quy trình tiết lộ có trách nhiệm đối với các thương hiệu tiêu dùng lớn. Việc quản lý lỗ hổng bảo mật một cách chủ động và có kênh liên lạc rõ ràng là yếu tố then chốt để duy trì an toàn thông tin trong kỷ nguyên số.

Các sự cố như vậy nhấn mạnh tầm quan trọng của việc kiểm tra bảo mật toàn diện, không chỉ ở lớp ứng dụng mà còn ở hạ tầng API, hệ thống quản lý người dùng và quy trình xử lý dữ liệu nhạy cảm. Để tránh rò rỉ dữ liệu và các cuộc xâm nhập trái phép, các tổ chức cần liên tục đánh giá và cải thiện tư thế bảo mật của mình.