Tôi đã kiếm tiền từ Facebook như thế nào? (Phần 2)

Đây là phần 2 và cũng là phần cuối của bài Tôi đã kiếm tiền từ Facebook như thế nào? Các bạn có thể theo dõi phần 1 tại đây. Các bạn nên đọc cả phần 1 để hiểu rõ nội dung của bài nhé!

​

Trong phần 1, tôi đã nói về cách chiếm tài khoản bằng API không an toàn, cho phép thay đổi mật khẩu của mọi tài khoản admin không có tương tác với user. Với lỗi này, tôi đã nhận được khoản tiền thưởng 7.500 USD từ Nhóm bảo mật Facebook. Trong phần 2, tôi sẽ nói về cách chiếm tài khoản thông qua kiểm soát cookie và xâu chuỗi nó với Internal SSRF. Nhờ đó, tôi nhận khoản tiền thưởng lên tới 5 con số. Nào, cùng bắt đầu nhé!

Xin lưu ý là một số tên gọi và thông tin trong bài viết đã được thay đổi theo yêu cầu của Facebook cũng như các đối tác của hãng.

Sau khi nhận được báo cáo cho lỗ hổng mà tôi tìm thấy trong Phần 1, Facebook đã giảm thiểu rủi ro của lỗ hổng. Do đó, tôi phải đọc lại lịch sử Burp Suit và theo dõi thêm.

​

Như các bạn có thể thấy trong hình, ô mà tôi đánh dấu số 1 màu xanh là các cookie ASPXAUTH.

Các bạn có hiểu ý của tôi ở đây không? ASPXAUTH có nghĩa là 80% có lỗ hổng, nhưng để khẳng định điều đó, các bạn cần phải có:

• validationKey (string) (Khóa xác thực (chuỗi)): Khoá được mã hoá hex để xác thực chữ ký
• decryptionMethod (string) (Phương thức giải mã (chuỗi)): (mặc định “AES”).
• decryptionIV (string) (Giải mã IV (chuỗi)): vector khởi tạo được mã hoá hex (mặc định đối với vector 0)
• decryptionKey (string) (Khoá giải mã (chuỗi)): Khoá được mã hoá hex để giải mã

Thú thật, tôi chẳng có yếu tố nào trong 4 cái kể trên, vậy làm thế nào tôi kết luận là có lỗ hổng? Thực ra, hầu hết ứng dụng sử dụng ASPXAUTH đều chỉ dùng email hoặc user trong cookie được mã hoá bằng khoá mã hoá và có thời gian hết hạn. Tôi đã khai thác điểm này trong các chương trình tìm kiếm lỗ hổng khác và nó có hiệu quả.

Vậy nên ở đây, tôi nghĩ là cứ thử xem, cũng không mất gì cả. Tôi lên Google và tìm các trang web khác có sử dụng ứng dụng tương tự - tôi nghĩ là tôi đã rất may mắn khi tìm được một website có sử dụng ứng dụng và các khoá mã hoá tương tự. Quan trọng là tôi phải sử dụng đúng username của admin.

Tôi đã làm thế và tìm thấy một trang web khác sử dụng ứng dụng tương tự và tính năng đăng ký có hoạt động. Tôi đã dùng một username được sử dụng bởi admin Facebook để đăng ký, sau đó chặn truy vấn và lấy được ASPXAUTH, thay vào bằng ASPXAUTH đã hết hạn của Facebook. Các bạn đoán xem chuyện gì đã xảy ra?

​

Trong giây lát, bảng điều khiển (Panel) của tôi bị mất nhưng rồi lại vào được. Giờ, hãy dành chút thời gian để nói về lỗi ASP.net mà hầu hết các nhà phát triển phải cẩn trọng để bảo đảm bảo mật khi phát triển ứng dụng. Một số lưu ý là:

• ASPXAUTH phải được lưu trữ trong cơ sở dữ liệu và ứng dụng phải kiểm tra xem nó có hợp lệ không.
• ASPXAUTH đôi khi phải chứa nhiều thông tin hơn, ngoài tên người dùng, để xác thực thêm.
• Các khóa mã hóa và giải mã của các trang phải khác nhau (phải thay đổi các khóa mặc định).

Kết luận 1: Tôi có thể đăng nhập bằng bất kỳ tài khoản admin nào miễn là biết username. Theo tôi, lỗ hổng này có độ phức tạp rất thấp nhưng mức ảnh hưởng lại cao. Chỉ riêng báo cáo lỗ hổng này, tôi có thể nhận khoản tiền thưởng 7.500 USD như trong phần 1, nhưng tôi muốn nhiều hơn thế.

Ngoài lựa chọn tạo mẫu, tôi nhận thấy bảng điều khiển còn hiển thị một lựa chọn khác là kích hoạt API. Điều này khiến tôi thấy hơi ‘lấn cấn’. Thông thường sẽ có một lỗi SSRF ở đây với không giới hạn. Tôi đã viết một đoạn tin nhắn gửi Nhóm bảo mật Facebook trình bày nghi vấn của tôi về một lỗi SSRF quan trọng trong ứng dụng và xin được kiểm tra thử xem. Dưới đây là câu trả lời của họ:

​

Thời điểm ấy, tôi vẫn đang trao đổi với họ về báo cáo phần đầu tiên (Chiếm tài khoản), bởi những lỗ hổng này được báo cáo một tuần sau bài viết phần đầu tiên. Như bạn có thể thấy, Nhóm bảo mật Facebook vẫn nghĩ là tôi cho rằng có phương thức bỏ qua xác thực và SSRF khác ngay cả khi tôi đã giải thích các lỗ hổng với họ kèm bằng chứng. Theo tôi hiểu, họ gián tiếp đồng ý cho tôi kiểm tra lỗi SSRF.

Sau đó, tôi viết một tập lệnh nhỏ và tải nó lên trình chỉnh sửa của Facebook. Tập lệnh cho phép tôi gửi bất kỳ yêu cầu với bất kỳ dữ liệu (GET, POST, PUT, PATCH, HEAD, OPTIONS) tới bất kỳ URL nào, nội bộ hoặc/và bên ngoài.

​

Từ backend của tập lệnh, tôi có thể thay đổi phương thức truy vấn và dữ liệu đã gửi, v.v.

Lúc này, tôi có thể leo thang lỗ hổng lên RCE, LFI nếu tôi ‘mày mò’ hơn một chút (Tôi cũng không thực sự chắc chắn 100% về điểm này, sau đó tôi đã yêu cầu Facebook cấp cho tôi quyền dịch ngược ứng dụng nhưng họ không chấp nhận và tin là tôi sẽ không làm gì tiếp).

Và tôi đã cố gắng nhắm vào tập lệnh canary của Facebook Một lần nữa, đoán xem chuyện gì đã xảy ra?

​

Thật may, tôi nhận được Canary token. Tiếp theo là gì đây? Tôi phải viết báo cáo mới, điền đầy đủ thông tin chi tiết bao gồm các tập lệnh và mã PoC theo yêu cầu.

Kết luận 2: Bằng cách viết một tập lệnh để gửi các truy vấn đặc biệt tùy ý, tôi có thể lấy được Internal SSRF và có quyền truy cập vào mạng nội bộ Facebook. Độ phức tạp ở đây tôi cho là thấp và mức ảnh hưởng là rất nghiêm trọng.

Ảnh hưởng của lỗi SSRF này:

Một cuộc tấn công SSRF thành công thường có thể dẫn đến các hành động hoặc truy cập trái phép vào dữ liệu trong mạng nội bộ Facebook, trong chính ứng dụng dễ bị tấn công hoặc trên các hệ thống backend khác mà ứng dụng có thể giao tiếp. Trong một số tình huống, lỗ hổng SSRF có thể cho phép kẻ tấn công thực hiện lệnh tùy ý.

Việc khai thác SSRF để kết nối tới các hệ thống của bên thứ ba bên ngoài có thể dẫn đến các cuộc tấn công nguy hiểm, bắt nguồn từ tổ chức lưu trữ ứng dụng dễ bị tấn công, kéo theo rủi ro trách nhiệm pháp lý và thiệt hại về danh tiếng.

Để biết thêm thông tin về các lỗ hổng SSRF, hãy xem bài viết trên portswigger.

Kết luận cuối cùng: Xâu chuỗi cả hai lỗ hổng, tôi nhận ra có thể xâm nhập vào mạng nội bộ Facebook (SSRF) bằng cách chiếm tài khoản để tiếp cận tập lệnh đã upload bên trong ứng dụng dùng để gửi các truy vấn đặc biệt tuỳ ý như tôi muốn.

Giờ thì hãy xem tôi làm được gì từ chuỗi lỗ hổng tìm được.

• Tôi có thể truy cập bất kỳ tài khoản nhân viên Facebook nào trong bảng điều khiển.
• Không cần tôi giải thích thì các bạn cũng biết mức độ hấp dẫn của những thông tin hacker có thể tìm thấy sau khi đăng nhập thành công.
• Tôi có thể sử dụng SSRF để truy cập mạng nội bộ Facebook (intern.our.facebook.com).
• Cố gắng thêm chút nữa, tôi tin mình có thể leo thang lỗ hổng này và khai thác để quét mạng/máy chủ nội bộ.

Chúng ta đều biết SSRF quan trọng như thế nào, đặc biệt là nó không bị giới hạn. Tôi có thể dễ dàng chỉnh sửa nội dung cũng như phương thức truy vấn. Theo các hướng dẫn của Facebook, lỗ hổng này tương đương khoản tiền thưởng 40.000 USD và thêm 5.000 USD nữa nếu tôi có thể chỉnh sửa nội dung truy vấn và phương thức truy vấn.

Sau thời gian dài chờ đợi, cuối cùng tôi cũng nhận được tin nhắn gửi từ Facebook.

​

Số tiền tôi được thưởng từ Facebook là 40.000 USD cộng thêm 2.000 USD (mà đáng lẽ là 7.000 USD).

Tôi hỏi họ tại sao mình không nhận được toàn bộ số thưởng thêm (5.000 USD) và câu trả lời là:

​

Tổng số thưởng tôi nhận được là 54.800 USD.

Tôi báo cáo lỗ hổng này nhiều ngày sau lỗ hổng được viết trong phần 1.

Thời gian báo cáo như sau:

• Thứ 4, ngày 9/9/2020 – Báo cáo các lỗ hổng.
• Thứ 2, ngày 26/10/2020 – Facebook yêu cầu tôi tạo một báo cáo mới. Đã áp dụng biện pháp giảm thiểu.
• Thứ 2, ngày 26/10/2020 – Báo cáo được Phân loại.
• Thứ 5, ngày 25/2/2021 – Xử lý lỗ hổng và nhận thưởng, sau 6 tháng.
• Thứ 6, ngày 5/3/2021 – Nhận số tiền thưởng 5.300 USD.

Một tip ‘Vàng’ mà tôi muốn dành cho những người tìm kiếm lỗ hổng, đó là khi bạn nhìn thấy ASPXAUTH thì hãy cố gắng lấy cookie từ website có sử dụng ứng dụng tương tự và thử nghiệm phương pháp mà tôi đã dùng.

• Tạo các cookie ASPXAUTH mới từ trang web khác.
• Kiểm tra xem cookie có hoạt động trên trang web mục tiêu không.

Tôi rất hài lòng với kết quả của mình dù phải chờ đợi tận 6 tháng và giữ bí mật báo cáo vì những lý do không thuyết phục lắm. Tôi rất mừng vì mọi chuyện đều khá suôn sẻ và đây không phải SSRF duy nhất tôi tìm thấy. Nói thật, tôi còn tìm thấy những lỗ hổng thú vị hơn nhưng Facebook không tiết lộ vì hãng đã ký một thỏa thuận với nhà cung cấp vài tuần sau khi các báo cáo được Phân loại.

Phần 2 cũng là phần cuối. Nếu có điều gì chưa rõ ràng hay chậm trễ trong việc cung cấp phần 2, mong các bạn thông cảm. Tôi cũng đã phải chờ một thời gian để xin giấy phép và sửa báo cáo. Vì vậy, rất nhiều thứ đã bị loại bỏ hoặc làm mờ nhằm đảm bảo tính riêng tư cho các bên.

Nguồn: Infosec​