Một nhà nghiên cứu bảo mật đã phát hiện lỗ hổng nghiêm trọng trong cổng thông tin cho thuê nhà Beam Living, công ty thuộc quỹ đầu tư Blackstone. Lỗ hổng cho phép bất kỳ ai biết email của nạn nhân có thể truy cập dữ liệu nhạy cảm như 4 số cuối SSN, ngày sinh, địa chỉ, số điện thoại qua query GraphQL. Sự việc được vá âm thầm sau hơn 3 tuần báo cáo liên tục.

Lỗ hổng GraphQL tại Beam Living (Blackstone) lộ SSN, ngày sinh, địa chỉ của hàng loạt người thuê nhà

Một nhà nghiên cứu bảo mật ẩn danh vừa công bố chi tiết về lỗ hổng nghiêm trọng trong hệ thống quản lý hồ sơ thuê nhà của Beam Living, một công ty thuộc danh mục đầu tư của tập đoàn Blackstone. Chỉ cần biết địa chỉ email của nạn nhân, kẻ tấn công có thể truy cập vào dữ liệu cá nhân cực kỳ nhạy cảm bao gồm 4 số cuối SSN, ngày sinh, địa chỉ nhà, số điện thoại và điểm tín dụng. Đáng chú ý, quá trình tiết lộ lỗ hổng cho công ty kéo dài nhiều tuần với sự phản hồi thiếu chuyên nghiệp trước khi lỗi được vá âm thầm.

Lỗ hổng nằm ở đâu?

Trong quá trình xin thuê nhà tại Beam Living, nhà nghiên cứu (người yêu cầu giấu tên) đã để ý đến các yêu cầu mạng từ trình duyệt. Anh phát hiện ra rằng khi xem hồ sơ cá nhân, hệ thống gửi một query GraphQL tới endpoint pd-dlcore.beamliving.com/graphql với tham số là địa chỉ email của người dùng:

{
  "operationName": "contact",
  "variables": {
    "contactId": "[email protected]"
  }
}

Điều bất thường nằm ở chính thiết kế này: đáng lẽ hệ thống phải lấy danh tính người dùng từ phiên đăng nhập (session cookie), thì ở đây nó lại chấp nhận email như một tham số đầu vào. Đây là một "mùi" mã nguồn rất kinh điển — nếu không có kiểm soát phân quyền, ai cũng có thể thay đổi email này thành email của người khác.

Hậu quả khủng khiếp

Nhà nghiên cứu đã kiểm tra với email của một người bạn (người cũng từng sử dụng dịch vụ này) và kết quả thật đáng sợ. Query trả về toàn bộ thông tin sau:

4 số cuối của Social Security Number (SSN)
Ngày sinh (date of birth)
Địa chỉ nhà và mã bưu chính
Số điện thoại
Địa chỉ IP
Điểm tín dụng (credit score)
Tình trạng xác minh danh tính
Thông tin thú cưng (tên, giống loài, thông tin giấy phép)
Thông tin liên hệ khẩn cấp
Lịch sử thuê nhà và tình trạng đơn

Mức độ ảnh hưởng không chỉ giới hạn ở một tòa nhà. Beam Living sử dụng cổng thông tin dùng chung cho nhiều khu căn hộ lớn tại New York, bao gồm: 8 Spruce, StuyTown, Peter Cooper Village, Kips Bay Court, Parker Towers. Bất kỳ ai đã từng nộp đơn qua cổng này và hồ sơ vẫn còn trong hệ thống đều có nguy cơ bị lộ dữ liệu.

Quá trình tiết lộ thiếu chuyên nghiệp

Ngay sau khi phát hiện, nhà nghiên cứu đã dừng mọi thử nghiệm và báo cáo cho Beam Living. Tuy nhiên, quá trình xử lý diễn ra rất tệ so với một công ty thuộc tập đoàn lớn như Blackstone:

14/06: Gửi email đầu tiên tới team hỗ trợ — không nhận được phản hồi.
16/06: Gửi email nhắc lại về mức độ nghiêm trọng — vẫn không có hồi âm.
23/06: Liên hệ trực tiếp với nhân viên leasing, nhờ kết nối tới team an ninh.
24/06: Cảnh báo lỗ hổng vẫn đang tồn tại — nhân viên hứa sẽ chuyển tiếp đơn.
26/06 – 08/07: Tiếp tục cảnh báo dữ liệu người dùng vẫn bị phơi bày.
09/07: Sau một cuộc gọi điện, lỗ hổng cuối cùng cũng được vá âm thầm.

Đáng nói, trong cuộc gọi ban đầu, đại diện Beam Living khẳng định "không có vấn đề gì cả". Nhưng thực tế họ đã âm thầm vá lỗi ngay sau đó. Nhà nghiên cứu nhận xét:

"Tôi rất mừng vì lỗi đã được sửa, nhưng đây không phải cách mà một công ty (đặc biệt là công ty thuộc sở hữu của gã khổng lồ như Blackstone) nên xử lý việc tiết lộ lỗ hổng."

Bài học cho các nhà phát triển

Lỗ hổng này không phức tạp về mặt kỹ thuật. Nó thuộc dạng IDOR (Insecure Direct Object Reference) — một lỗi logic kinh điển mà mọi lập trình viên backend đều nên biết. Bài học rút ra:

Không bao giờ sử dụng dữ liệu do client gửi lên làm khóa tham chiếu trực tiếp mà không kiểm tra quyền.
Luôn lấy danh tính người dùng từ session/token đã được xác thực.
Đối với hệ thống xử lý dữ liệu nhạy cảm như SSN hay ngày sinh, cần có cơ chế bảo vệ nhiều lớp và kiểm tra phân quyền ở tầng dữ liệu.
Cần thiết lập quy trình tiếp nhận báo cáo bảo mật (security disclosure policy) rõ ràng và được tôn trọng.

Minh họa lỗ hổng GraphQL trong hệ thống Beam Living

Lời khuyên cho người dùng tại Việt Nam

Tại Việt Nam, các nền tảng cho thuê bất động sản, dịch vụ tài chính hay ứng dụng gọi xe đều có thể gặp rủi ro tương tự. Khi cung cấp thông tin nhạy cảm như CCCD (căn cước công dân), số tài khoản ngân hàng hay địa chỉ nhà trên bất kỳ nền tảng trực tuyến nào, người dùng nên:

Kiểm tra xem website/dịch vụ có chính sách bảo mật và quy trình xử lý lỗ hổng công khai hay không.
Hạn chế cung cấp quá nhiều thông tin nếu không thực sự cần thiết cho giao dịch.
Theo dõi các kênh thông tin về các vụ rò rỉ dữ liệu để kịp thời thay đổi mật khẩu hoặc cảnh báo ngân hàng.

Phản hồi trả về dữ liệu nhạy cảm từ GraphQL

Tương lai nào cho Beam Living?

Hiện Beam Living đã vá lỗ hổng và xác nhận làm việc với nhà nghiên cứu. Tuy nhiên, việc một lỗi bảo mật ở mức độ "phơi bày toàn bộ hồ sơ người thuê" có thể tồn tại trong thời gian dài và không có thông báo công khai nào tới những người bị ảnh hưởng đặt ra câu hỏi lớn về trách nhiệm của các tập đoàn địa ốc trong thời đại số. Các nạn nhân có email xuất hiện trong hệ thống gần như chắc chắn không hề hay biết dữ liệu của mình đã bị lộ, và việc "vá lỗi âm thầm" không giải quyết được hậu quả nếu dữ liệu đã bị khai thác trước đó.

Giao diện đăng nhập cổng thông tin Beam Living

Câu chuyện này một lần nữa khẳng định rằng: bảo mật không phải là một tính năng "thêm vào sau", mà là yêu cầu sống còn trong thiết kế hệ thống. Và khi lỗ hổng xảy ra, cách bạn phản hồi sẽ quyết định mức độ mất niềm tin của người dùng — dù cho bạn có là một gã khổng lồ đến từ Blackstone đi chăng nữa.