Burger King bị hack: Vượt qua xác thực để nghe lén âm thanh tại quầy drive-thru

• Một nhóm nghiên cứu bảo mật đã phát hiện lỗ hổng vượt qua xác thực trong hệ thống drive-thru của Burger King
• Lỗ hổng này cho thấy khả năng truy cập trái phép vào luồng âm thanh của drive-thru
• Việc thiếu kiểm soát nội bộ đã tạo ra môi trường cho phép giám sát theo thời gian thực
• Kẻ tấn công có thể trực tiếp thu thập dữ liệu giọng nói mà không cần quy trình phức tạp riêng biệt
• Vụ việc này một lần nữa cho thấy tầm quan trọng của bảo mật hạ tầng CNTT trong ngành dịch vụ ăn uống

---

Tổng quan vụ việc

• Một nhóm nghiên cứu bảo mật đã khai thác lỗ hổng vượt qua xác thực trong hệ thống âm thanh drive-thru của Burger King
• Lỗ hổng này cho phép người bên ngoài truy cập vào luồng âm thanh trong hệ thống mà không cần xác thực riêng

Cách thức tấn công

• Nguyên nhân là do không cấu hình xác thực HTTP hoặc chính sách xác thực yếu trên giao diện web
• Kẻ tấn công chỉ cần biết địa chỉ IP của hệ thống là có thể xác nhận khả năng truy cập trực tiếp vào dữ liệu âm thanh

Tác động và mức độ rủi ro

• Lỗ hổng này làm dấy lên nguy cơ rò rỉ thông tin cá nhân, chẳng hạn như nghe lén cuộc trò chuyện của khách hàng theo thời gian thực
• Kẻ tấn công bên ngoài có thể dễ dàng đánh cắp quy trình vận hành và thông tin khách hàng của cơ sở kinh doanh

Hàm ý

• Vụ việc cho thấy các vấn đề trong thực trạng quản lý thiết bị IoT và mạng lưới của ngành dịch vụ ăn uống và bán lẻ
• Nhu cầu về cơ chế xác thực mạnh và kiểm tra bảo mật định kỳ ngày càng trở nên cấp thiết

[GN⁺]

Ý kiến trên Hacker News

• Blog hiện không truy cập được, nên chia sẻ liên kết Web Archive

• Nếu xem phần diễn biến sau đó, có vẻ nhà nghiên cứu bảo mật này đã tuân thủ quy trình công bố có trách nhiệm và chỉ đăng bài sau khi lỗ hổng đã được vá, nhưng vẫn không nhận được bất kỳ phản hồi nào từ công ty. Tức là về nguyên tắc chỉ được thưởng khi có thỏa thuận trước, nhưng dù có lý do để kỳ vọng được trả thưởng thì cuối cùng vẫn không có tin tức gì. Bản thân tôi cũng từng phát hiện một lỗ hổng bảo mật nhạy cảm ở một startup nổi tiếng và đã gửi báo cáo chi tiết qua nhiều email theo đúng quy trình chính thức, nhưng chỉ nhận được lời mời vào HackerOne; trong khi các khoản thưởng trước đó khoảng $2,000, tôi nghĩ phát hiện của mình đáng giá $10,000~$50,000. Nhưng tôi cũng không có thời gian để viết bản báo cáo chính thức mà họ yêu cầu, và vì $2,000 thì tôi thấy không đáng để làm. Trong trường hợp như vậy, tôi cũng thắc mắc liệu mình có thể viết một bài blog công khai hay không

  • Thực ra đã có liên hệ từ phía công ty, nhưng bài viết đó lại bị DMCA (thông báo vi phạm bản quyền số). Ngay cả khi xem ảnh chụp email cũng không rõ lý do gì khiến nó bị coi là vi phạm DMCA, nên trông như một trường hợp lạm dụng DMCA điển hình. Công ty tạo ra yêu cầu DMCA bằng AI này thậm chí còn nhận đầu tư từ Y-Combinator. Tham khảo
  • Nói chính xác thì thay vì "công bố có trách nhiệm", nên gọi là "công bố có phối hợp (coordinated disclosure)", vì cụm "có trách nhiệm" có xu hướng khiến một số hành vi trông có vẻ đạo đức hơn
  • Nếu không có quy định mạnh và thực thi đủ sức nặng thì chuyện này sẽ không chấm dứt. Hiện nay doanh nghiệp đang đứng trước lựa chọn: trả bug bounty, hoặc chấp nhận rủi ro lớn hơn sau này như kiện tụng hay khủng hoảng PR. Từ góc nhìn doanh nghiệp, họ sẽ chọn phương án chi phí thấp hơn giữa việc chắc chắn phải chi tiền ngay bây giờ và một rủi ro không chắc chắn trong tương lai. Nếu trong tương lai có một mối đe dọa thực sự, chẳng hạn thay vì trả bounty $100,000 thì sẽ bị phạt $10,000,000 sau một sự cố bảo mật nghiêm trọng, và nếu CEO biết rằng phớt lờ báo cáo để trục lợi tài chính có thể khiến mình mất cả nhà nếu bị phát hiện, thì họ sẽ chọn trả bounty. Gánh nặng rủi ro phải được chuyển sang phía nhà cung cấp
  • Nếu đăng chuyện này công khai, các bình luận hoặc tiêu đề báo chí có thể còn thẳng thừng hơn hoặc pha chút chế giễu rồi lan rộng, và nếu đúng lúc thiếu tin nóng thì có thể bùng lên trên toàn quốc. Câu chuyện "không được trả thưởng" là điều ai cũng dễ đồng cảm, nên xét về PR thì đây là một lựa chọn tệ
  • Nếu mục đích là khiến doanh nghiệp tỉnh ra và trả bounty một cách hợp lý, thì tôi nghĩ việc đăng công khai cũng là điều có thể chấp nhận về mặt đạo đức

• Tôi nghe nói bài đăng bị gỡ xuống vì có khiếu nại DMCA gửi đến Cloudflare. Tôi biết DMCA có nhiều tầng xử lý; chuyện công ty hosting xử lý thì dễ hiểu, nhưng nếu tôi tự host không dùng Cloudflare thì sẽ ra sao? Tôi còn tò mò hơn là liệu DMCA có thể được gửi tới ISP hay nhà đăng ký domain của tôi không

  • Ban đầu tôi không hiểu vì sao lại chắc đó là do DMCA, nhưng sau khi xem bài đăng liên quan thì đã hiểu
  • Thông thường DMCA sẽ được chuyển tới ISP. Tùy ISP mà họ có chuyển tiếp cho người dùng hay không. Hồi trước (thời người ta tải phim qua torrent), các hãng phim gửi DMCA hàng loạt nên chuyện này còn phổ biến hơn nhiều
  • Vào khoảng 2008~2009 tôi từng vận hành vài máy chủ bare-metal tại SoftLayer (Dallas, TX), và có một khách hàng là diễn đàn nhạc Nam Mỹ. Mỗi khi ai đó tải MP3 lên, trung tâm dữ liệu sẽ chặn định tuyến lưu lượng tới máy chủ đó ngay khi nhận được yêu cầu DMCA. Không thể tưởng tượng nổi đến năm 2025 sẽ còn xuất hiện những công cụ gì nữa

• Tôi nghĩ việc các cuộc trò chuyện ở drive-thru bị ghi âm mà không có thông báo riêng có thể là kiểu vụ việc mà các luật sư ở những bang yêu cầu "sự đồng ý của cả hai bên (two-party consent state)" sẽ rất thích. Dĩ nhiên có thể phản biện rằng việc hét to ở nơi công cộng thì không có kỳ vọng về quyền riêng tư, nhưng tôi vẫn cho rằng đây là một rủi ro pháp lý

  • Ghi âm ở nơi công cộng nhìn chung không phát sinh trách nhiệm pháp lý ngay cả khi không có sự đồng ý. Nếu drive-thru là nơi công chúng có thể đi vào, thì có thể ghi âm mà không cần xin phép hay thông báo riêng. Tuy vậy, tôi mới biết rằng một số bang cấm cả việc ghi âm ở nơi công cộng. Những luật như vậy đến nay vẫn chưa bị Tòa án Tối cao Liên bang Mỹ giữ nguyên hay bác bỏ
  • Tôi cũng tò mò liệu ở nơi công cộng có thật sự vẫn phải có sự đồng ý của cả hai bên hay không

• Điều khiến tôi ngạc nhiên nhất là lại có cả một hệ thống quy định cách nói chuyện ở drive-thru. Nó ép phải giữ giọng điệu tích cực và dùng những câu động viên như "You rule", nhưng đứng từ phía người làm thì không thể lúc nào cũng làm vậy được. Thực tế chỉ cần món gọi không bị thiếu là khách đã hài lòng rồi. Hơn nữa chất lượng hệ thống âm thanh ngoài đời thường kém đến mức khó mà nghe ra đó là "You rule" hay gì khác. Tôi không hiểu vì sao lại phải micromanage bằng phần mềm kiểu này với một người lật burger với mức lương $6/giờ

  • Trớ trêu là công việc trả lương càng thấp thì quản lý lại càng có xu hướng khắt khe và soi mói hơn. Ví dụ nếu bạn là lập trình viên kiếm hơn $100,000/năm và làm từ xa thì nghỉ ốm một tuần chẳng có vấn đề gì, nhưng nếu là nhân viên call center làm theo giờ thì không báo trước 48 tiếng là bị kỷ luật ngay. Thậm chí nếu đang trong diện kỷ luật thì còn không được trả tiền nghỉ ốm. Không có giấy xác nhận của bác sĩ nữa thì còn có thể bị sa thải
  • 1. Thực ra làm công việc lật burger hoàn toàn không có gì xấu cả. 2) Về bản chất, đây là cấu trúc trong đó những lao động lương thấp giao việc kiểu này cho những lao động còn lương thấp hơn. Cần có một mức độ cảm thông nhất định

• Hơn 40 năm trước ở L.A., có người phát hiện kiosk drive-up của Burger King được nối với nhà hàng bằng liên kết vô tuyến RF. Họ tìm ra tần số và kiểu điều chế, rồi có thể dùng máy thu phát cầm tay để giao tiếp trên cùng kênh đó. Họ đặt một máy quay ở bãi đậu xe gần đó, quay lại cảnh trêu chọc khách hàng drive-thru cho vui, và tạo ra một video tên là "Attack on a Burger King". Những người này là kỹ sư phát thanh truyền hình, và hồi đó đoạn video này còn được chuyền tay xem trong studio. Cuối video là cảnh một nhân viên chạy ra lao về phía khách hàng, còn các hacker thì trêu vị khách rằng hãy chạy đi. Tôi không biết video đó có từng được đưa lên nền tảng streaming hay không

  • Ngày xưa hầu hết tai nghe drive-thru của các cửa hàng đồ ăn nhanh đều dùng băng tần thương mại VHF. Một nhóm tên là "Phone Losers of America" rất nổi tiếng với kiểu trò đùa này. Video YouTube tham khảo "I'm in the freezer at QuikTrip!"

• Câu kiểu "Họ gửi mật khẩu dưới dạng văn bản thuần trong email. Mà là vào năm 2025 đấy. Sự tận tụy với việc làm bảo mật tệ đến mức đáng nể" với giọng mỉa mai như vậy làm bài viết còn buồn cười hơn

• Nói cho đúng thì, nếu hệ thống buộc đổi mật khẩu ngay sau khi đăng nhập lần đầu, thì việc gửi mật khẩu tạm ở dạng văn bản thuần qua email chưa chắc đã là vấn đề lớn

• Đúng là blog đã bị gỡ, và tôi xem bản sao lưu qua liên kết archive.is

  • Chia sẻ thông báo DMCA đó
  • Cũng hướng dẫn thêm liên kết Web Archive có vẻ an toàn hơn về lâu dài

• Ôi, đây đúng là một ví dụ rất tệ. Khá nghiêm trọng, nhưng những sai sót kiểu này đến giờ vẫn xảy ra rất nhiều ngay cả ở các tập đoàn lớn. Tôi tin chắc là còn ít nhất vài chục doanh nghiệp khổng lồ khác vẫn đang lặp lại đúng những sai lầm này