Facebook Messenger đã để lộ dữ liệu cá nhân người dùng như thế nào?
facebook
18
originull
1
hacking
17
White

Hùng PV viết ngày 16/12/2016

Một lỗ hổng bảo mật cực kỳ nghiêm trọng, có ảnh hưởng trực tiếp đến quyền riêng tư của khoảng 1 tỷ tài khoản Facebook và có khả năng ảnh hưởng tới hàng triệu website khác

Dự tính có tới 1.8 tỷ tài khoản người dùng thường xuyên và tin tưởng Facebook có đủ khả năng giữ an toàn tuyệt đối thông tin cá nhân và các cuộc trò truyện của họ trên Messenger. Và ở một khía cạnh nào đó thì mạng xã hội nói chung hay Facebook nói riêng, dựa trên sự chia sẻ thông tin. Ước tính có tới 350 triệu ảnh được tải lên mỗi ngày và có tới 300 nghìn status được đăng lên mỗi phút.
Facebook Messenger, bạn biết đó, một trong những tính năng rất phổ biến với khoảng 1 tỷ người dùng thường xuyên. Không giống như ảnh hay status để dành cho việc công bố hay chia sẻ, sức mạnh của Messenger là khả năng tạo ra hội thoại giữa người dùng một cách riêng tư, và được cho là bảo mật.
Trong bài này, chúng tôi sẽ phân tích về một lỗi bảo mật cực kỳ nghiêm trọng đã được tìm thấy trên Facebook, lỗi này được cho là có khả năng ảnh hưởng tới hàng triệu website khác , có thể được khai thác để đánh cắp thông tin riêng tư và tấn công bằng các phương thức độc hại.
Hacker sử dụng lỗi “Originull” để có quyền xem tất cả nội dung chat riêng tư của người dùng, bao gồm cả ảnh và các tệp tin đính kèm được gửi qua Facebook Messenger. Lỗi này đã được khám phá bởi nhóm Ysrael Gurt và đã được report tới Facebook.

Hot quá! Hay quá! Vậy, nó là gì?

Trước hết, đây là một lỗ hổng bảo mật. Hacker sử dụng phương thức cross-origin bypass-attack, cho phép hacker sử dụng một website bên ngoài truy cập và đọc nội dung chat riêng tư của người dùng Facebook.
Thường thì browser sẽ bảo vệ người dùng Messenger khỏi các yếu tố nguy hại kiểu như thế này, bằng cách chỉ duyệt cho các trang của Facebook được quyền truy cập vào thông tin này. Facebook sẽ dựng lên một “cây cầu” nhằm mục đích cho phép các “trang con” (subsites) của Facebook.com có quyền truy cập vào thông tin của Messenger. Chuyện sẽ chẳng có gì nếu Facebook không mắc phải một sai lầm trong việc quản lý định danh các trang con, cấp cho những trang độc hại quyền truy cập vào Messenger chats.
Ví dụ: hacker gửi cho user một trang web, user mở trang đó lên, và...xong, bạn đã cấp quyền cho hacker xem được toàn nội bộ dung chat trong Facebook Messenger, bao gồm cả ảnh, tệp đính kèm trong Messenger của bạn. Lỗ hổng này cũng ảnh hưởng khi người dùng gửi tin từ máy khác hay kể cả là từ điện thoại di động.
Imgur
Ảnh 1: nội dung chat được hiển thị trên trang bugsec.com (không thuộc Facebook.com đâu nhé). User ID của người gửi là số bên trái đó.

Sâu hơn vào technical một chút nhé

Facebook Messenger được quản lý bởi một server riêng rẽ nằm ở địa chỉ:
{number}-edge-chat.facebook.com
Chat thì vẫn được chạy trên trang chủ www.facebook.com như thường.
XML HTTP Request (XHR) được sử dụng để giao tiếp giữa JavaScript và server.
Trong JavaScript, để có quyền truy cập dữ liệu đến từ 5-edge-chat.facebook.com , Facebook bắt buộc phải thêm header “Access-Control-Allow-Origin” vào nguồn gọi, cùng với giá trị true của header “Access-Control-Allow-Credentials”, như thế thì dữ liệu vẫn có thể truy cập được kể cả khi cookies đã được gửi đi.
Imgur
Imgur
Ảnh 2: Original request
Nhìn chung, đây chỉ giống như là một CORS bình thường. Để bảo vệ thông tin khỏi việc bị các site khác đọc được, Facebook kiểm tra header trang ban đầu. Nếu request đến từ một trang chưa được cấp phép thì server sẽ trả lại mã lỗi 400 cùng với giá trị “badorigin” trong header “xfb-chat-failure-reason”
Imgur
Imgur
Ảnh 3: Request từ một Origin khác

Chú ý: Facebook chấp nhận các GET request bình thường tới chat domain, nhưng thực ra thì thường những request GET đâu có header Origin đâu. Header “Origin” là một header đặc biệt được gửi bởi browser chỉ khi sử dụng XHR request.
Thế nên khi mà server nhận được một request GET, thì nó chưa chắc, đúng hơn là hầu hết không có chứa header “Origin”. Trong rất nhiều ngôn ngữ lập trình, khi mà header này không được xác định thì nó sẽ được nhận mặc định với giá trị “null”. Do đó, nếu server của Facebook expected nhận giá trị “null” trong header “Origin” thì nó sẽ không block các request từ cái “Origin” này đâu.
Giống như kiểu cơ chế lọc tách riêng với cơ chế trả lời các request, và bộ trả lời thì mặc định là chấp nhận các giá trị trong “Origin”, bởi vì nếu nó không hợp lệ thì bộ lọc đã drop các request đó rồi. Cách thiết kế dev này cho phép Facebook thêm các Origin hợp lệ chỉ bằng cách sửa code ở một vị trí duy nhất, đó là bộ lọc.
Cuối cùng, vì “null” origin được phép pass qua bộ lọc cho nên là các request này được chấp nhận là request GET bình thường. Bộ trả lời lấy giá trị từ “Origin” và paste thẳng vào header “Access-Control-Allow-Origin” trong response.
Imgur
Imgur
Ảnh 4: Request không chứa Origin và response trả về chứa Originull

Chúng ta đã xác định được chắc chắn rằng nếu gửi một request từ một trang, không có header Origin hoặc Origin = “null” thì chúng ta sẽ nhận được một response với header “Access-Control-Allow-Origin” cũng có giá trị là “null”.
Bắt tay vào việc nhé.
Đầu tiên, chúng ta sẽ chuẩn bị tool “Burp” ($350/year), nó cho phép ta sửa bất kỳ thông tin request nào. Khi ta gửi request với Origin “null” thì Facebook cũng trả lời với “null” ở header “Access-Control-Allow-Origin”
Điều này đồng nghĩa với việc nếu ta có thể khiến browser gửi “null” trong header “Origin” thì sẽ nhận được giá trị “null” của “Access-Control-Allow-Origin” trong response.
Imgur
Imgur
Ảnh 5: Request có chứa “null” Origin

Trong bài test này, chúng tôi nhận ra rằng mình có thể sử dụng data scheme để gửi request với Origin = “null”. Khi sử dụng data scheme, browser sẽ đặt Origin thành “null” vì lý do bảo mật.
(Một chút javascript nhé)
Imgur
Ảnh 6: một đoạn code nhỏ

Imgur
Ảnh 7: Một trang HTML

Imgur
Ảnh 8: Test trên Firefox

Imgur
Ảnh 9: Test trên Chrome

Dựa vào bài test dataschema bên trên, cộng với những hiểu biết về các phương pháp xử lý của Facebook, chúng tôi có thể tạo ra một cuộc tấn công hợp lệ hướng vào người dùng Messenger.

Một số thông tin background về Facebook Chat API

Facebook sử dụng XHR request lặp đi lặp lại gửi tới server để kiểm tra tin nhắn mới. Server thì chỉ trả lời khi mà có tin mới mà thôi, hoặc khi mà timeout. Phương pháp này đồng nghĩa với việc luôn có một XHR request đợi trả lời từ server. Khi mà server trả lời thì JavaScript sẽ mở thêm request mới tới server.
Imgur
Ảnh 10: Server trả lời Timeout. Vẫn sử dụng “null” Origin
Imgur
Ảnh 11: Server trả lời khi có tin nhắn mới
Chú ý chỗ bôi vàng seq trong 2 ảnh trên
Để chắc chắn rằng tin nhắn đến đúng thứ tự, mỗi request đều có một sequence number được thể hiện bằng giá trị của seq trong chuỗi trả về.

Request parameter được tạo bằng các bước sau:

Mỗi request đều là một phần của một “pool”
Giá trị “pool” hợp lệ được gửi trong response trả lời cho một request rỗng
Imgur
Imgur
Ảnh 12: ta nhận được một giá trị pool

Cùng với “pool”, mỗi request được build hợp lệ với một sequence number, bắt đầu từ 0 (kiểu đánh index). Trong response, server cũng sẽ gửi sequence number kế tiếp.
Imgur
Ảnh 13: server trả về response cùng với tin nhắn. Chú ý vào seq của request và response nhé, nó là 2 và 3 đó

Kết hợp lại, chúng ta sẽ tạo được đoạn một đoạn code sau. Đoạn code này sẽ giao tiếp với Facebook API, nhận tin, in ra màn hình và gửi tới BugSec server.
Imgur
Ảnh 14: đoạn code 76 dòng sau khi hoàn thành
Sau đó đoạn code này được convert thành mã Base64, chèn vào target của Refresh trong tag meta.
Imgur
Ảnh 15: payload

Khi mà victim (vô tình hay hữu ý) truy cập vào trang chứa đoạn mã độc này, đoạn code sẽ bắt đầu bắt lại hết các tin nhắn của victim rồi gửi lên server của BugSec.
Imgur
Ảnh 16: đoạn js đã gửi tin nhắn lên BugSec serv
Imgur
Ảnh 17: nội dung chat được hiển thị trên trang bugsec.com (không thuộc Facebook.com đâu nhé). User ID của người gửi là số bên trái đó.

Lỗi này đã được báo cáo tới Facebook thông qua trương trình Bug Bounty. Phía họ đã phản hồi rất nhanh và đã sửa được lỗi này trong vòng vài ngày.

Nguồn: BugSec.com
https://www.bugsec.com/wp-content/uploads/2016/12/Blog-Post-BugSec-Cynet-Facebook-Originull.pdf

View PDF at google drive

HùngPV 17-12-2016

Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Hùng PV

1 bài viết.
6 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Bài viết liên quan
White
27 4
(Ảnh) Phân tích mã độc Facebook lây lan qua tin nhắn và hướng dẫn cách ngăn chặn mã độc Facebook tự động gửi tin nhắn cho toàn bộ bạn bè. Phân t...
Juno_okyo viết gần 2 năm trước
27 4
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
1 bài viết.
6 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!