Tại Sao Việc Sử Dụng Chương Trình Cục Bộ Thông Qua Cổng Cục Bộ Để Xác Thực Dịch Vụ Bên Thứ Ba Là Không an Toàn

Anonymous trong Nguyên Lý Biên Dịch và Chất Lượng Mã

2018-03-01 Khoảng 900 từ 5 phút

Tại sao việc xác thực dịch vụ bên thứ ba thông qua chương trình cục bộ bằng cổng máy tính là không an toàn?

Sáng nay có đồng nghiệp phàn nàn về quy trình xác thực quyền dịch vụ bên thứ ba của phần mềm DingTalk trên Windows, cho rằng giao diện người-máy kém thân thiện và tiện lợi so với QQ. Tôi liền chia sẻ góc nhìn: việc sử dụng chương trình cục bộ có quyền hạn thông thường để thực hiện xác thực tập trung sẽ tiềm ẩn nhiều lỗ hổng bảo mật nghiêm trọng, cần phải thận trọng.

Thực tế, giải pháp an toàn nhất là tận dụng cơ chế hỗ trợ sẵn từ hệ điều hành, ví dụ như UAC trên Windows. Quy trình tiêu chuẩn thường diễn ra như sau: ứng dụng thứ ba gửi yêu cầu xác thực đến máy chủ, hệ thống sẽ chuyển tiếp yêu cầu này về client cục bộ, sau đó client sẽ hiển thị cửa sổ xác nhận tương tác với người dùng. Chỉ khi người dùng chấp thuận, máy chủ mới cấp quyền cho ứng dụng bên thứ ba.

Tuy nhiên điểm yếu lớn ở đây là nếu cửa sổ xác nhận không được xây dựng ở cấp độ hệ điều hành, thì trên Windows rất dễ bị các chương trình cùng cấp có quyền hạn thông thường tấn công xâm nhập. Tất nhiên vẫn có thể phòng ngừa bằng các biện pháp đối chứng bổ sung - ví dụ như hiển thị mã xác thực đặc biệt tương tự như mã CVV trên thẻ tín dụng. Nghe nói QQ sử dụng hình đại diện người dùng làm cơ chế xác minh bảo mật, nhưng tôi chưa dùng thử nên không khẳng định chắc chắn.

Việc xây dựng hệ thống như vậy đòi hỏi sự phối hợp đồng bộ giữa ứng dụng bên thứ ba và máy chủ. Trước tiên cần thực hiện liên kết tài khoản qua một lần nhập thủ công, chẳng hạn nhập số QQ tại ứng dụng bên thứ ba hoặc ngược lại. Trên Windows có thể dùng hàm FindWindow để định vị cửa sổ QQ, sau đó truyền token xác thực thông qua tin nhắn tùy chỉnh nhằm hoàn tất giao thức bắt tay xác lập kết nối.

Nghe vậy đồng nghiệp phản bác rằng hệ thống xác thực của QQ đơn giản hơn nhiều, có vẻ sử dụng kết nối qua cổng cục bộ. Ban đầu tôi chưa tin, nhưng trải nghiệm nhiều vụ việc trước đây khiến tôi phải điều chỉnh lại nhận định về mức độ quan tâm đến an ninh của đội ngũ thiết kế Tencent. Việc đánh cắp quyền hạn người dùng từ các sản phẩm của Tencent đã trở thành “món hàng hot” trên chợ đen anh hùng mạng.

Do máy tôi không cài QQ nên tôi đã tìm kiếm thông tin và phát hiện ra tài liệu “Nguyên lý thực hiện đăng nhập nhanh QQ”. Quả nhiên, client QQ đang mở cổng 4300 để lắng nghe kết nối, sử dụng giao thức HTTP thô sơ (không phải HTTPS). Nếu còn nghi ngờ, bạn có thể ping địa chỉ “localhost.ptlongin2.qq.com” được đề cập trong tài liệu - kết quả phân giải sẽ là 127.0.0.1.

Tại sao phương pháp này lại cực kỳ nguy hiểm? Vì cổng mạng cục bộ hoàn toàn nằm ngoài khả năng kiểm soát của cơ chế quản lý quyền hạn hệ điều hành. Dù bạn đã bật tường lửa hay UAC, cũng không thể ngăn chặn các ứng dụng lạ đang cố gắng truy cập tiến trình xác thực của QQ. Nếu thay bằng named pipe, trên Linux có thể dùng phân quyền tập tin để hạn chế truy cập, nhưng trên Windows thì chưa chắc đã thực hiện được. Còn với socket mạng cục bộ thì gần như không có biện pháp kiểm soát nào khả thi.

Trong quá khứ, việc can thiệp vào các cửa sổ không thuộc hệ thống trên Windows là một chuyện quá dễ dàng, giờ đây có được cải thiện gì không thì chưa rõ. Nhưng ngay cả khi cửa sổ xác nhận không bị tấn công trực tiếp, thì việc không qua máy chủ trung gian đã tạo ra lỗ hổng chí mạng: bất kỳ ứng dụng nào cài đặt trên máy người dùng đều có thể giả lập yêu cầu xác thực mà không cần có chứng chỉ ủy quyền chính thức từ Tencent. Cửa sổ xác nhận cũng không liệt kê rõ ràng các quyền cụ thể đang được yêu cầu. Điều này đồng nghĩa với việc chỉ cần cài đặt phần mềm độc hại (như các sản phẩm từ Qihoo 360), kẻ tấn công có thể dễ dàng chiếm quyền tài khoản QQ khi người dùng đang đăng nhập.

Theo tôi, nếu bắt buộc phải sử dụng xác thực qua máy chủ, cổng cục bộ chỉ nên được dùng để thiết lập liên kết ban đầu giữa hai ứng dụng cục bộ, nhằm đơn giản hóa quy trình liên kết. Cách này sẽ giảm thiểu rủi ro bảo mật, bởi vì quá trình liên kết chỉ thực hiện duy nhất một lần, và có thể áp dụng các phương pháp phức tạp hơn nhưng an toàn hơn để đảm bảo tính toàn vẹn.