Bài này viết về gì?
Chào mọi người, tôi là @chung96vn. Ở bài viết này tôi sẽ trình bày cách mà tôi đã tìm được hai lỗ hổng bảo mật CVE-2020-8863 và CVE-2020-8864 trên các dòng Router DIR-867, DIR-878, and DIR-882.
Cụ thể trong bài này tôi sẽ trình bày một cách chi tiết từ cách tiếp cận đến cách tôi phát hiện ra hai lỗ hổng bảo mật này. Có thể nói 2 lỗ hổng bảo mật này không khó để phát hiện, nhưng để hiểu và khai thác được chúng thì cũng cần phải tốn một chút thời gian và công sức. Nhưng thực sự mà nói thì dễ tìm v*i l**, tôi chỉ là may mắn hơn các bạn mà thôi =))
Tôi đã tiếp cận target này như thế nào?
Thực sự mà nói thì khi tôi gà và chẳng làm được gì còn anh em ngoài kia cứ bug này bug kia nên cũng chọn một cái target nào đó mà tôi nghĩ là nó easy nhất để thử thôi. Ban đầu tôi có thử và tìm được một số bug trên một dòng router khác của D-Link, tuy nhiên sau khi đem đi report thì tôi biết nó là End Of Life (EOL) product. Sau đó tôi lên trang chủ của D-Link và pick đại một con route bất kì để nghiên cứu và nó là DIR-882.
Tóm tắt về 2 CVE
2 CVE nêu ở trên đều là lỗ hổng bảo mật liên quan đến quá trình xác thực của hệ thống web quản trị của thiết bị. Cụ thể là lỗ hổng bảo mật cho phép một người dùng bất kỳ có thể truy cập và sử dụng các chức năng quản trị thiết bị trên web quản trị mà không cần sử dụng bất kì thông tin xác thực nào.
Thông tin chi tiết
Thông thường với các target kiểu này tôi thường tập trung vào tìm các lỗi không cần thông tin xác thực bởi với quan niệm của tôi thì nếu cần thông tin xác thực thì mức độ nguy hiểm của lỗi đối với các thiết bị này sẽ giảm đi khoảng 99%. Chính vì thế việc đầu tiên khi tìm bug trên các thiết bị này tôi tập trung vào tìm hiểu cách thức mà hệ thống này xác thực người dùng.
Việc đầu tiên tôi làm là đọc và vẽ lại mô hình thuật toán dùng để xác thực của thiết bị này. Có thể nói đây là thuật toán rất an toàn và được sử dụng bởi nhiều các thiết bị khác nữa. Tuy nhiên việc triển khai code các thuật toán đối với từng thiết bị còn tồn tại nhiều điểm yếu dẫn đến có thể tận dụng để bypass qua lớp xác thực này.
Dưới đây là mô hình đăng nhập được sử dụng trong thiết bị DIR-882 của D-Link.
Nhìn vào quy trình trên ta thấy việc xác thực có liên quan mật thiết đến password của tài khoản admin. Tuy nhiên việc lập trình để tích hợp thuật toán xác thực trên không phải lúc nào cũng hoàn hảo mà thông thường sẽ tồn tại một số điểm yếu do phải tích hợp thêm để phù hợp với từng thiết bị.
CVE-2020-8863
Nguyên nhân gây nên bug này là do việc tích hợp một chức năng PrivateLogin mà tôi vẫn không hiểu nó tạo ra với mục đích gì hay là một backdoor được thiết lập sẵn trong thiết bị.
Nhìn vào hình vẽ trên chúng ta có thể thấy, nếu giá trị PrivateLogin được gửi kèm trong gói tin request login và có giá trị là “Username” thì giá trị được sử dụng để tính toán privatekey là Username được gửi kèm theo thay vì là password của tài khoản admin. Như vậy chúng ta có thể hoàn toàn tính toán được giá trị privatekey qua đó sử dụng chúng cho các bước xác thực tiếp theo.
Như vậy việc đầu tiên là thực hiện gửi gói tin request login với giá trị PrivateLogin kèm theo để lấy về các giá trị cần thiết để tính toán privatekey.
Sau khi thực hiện request trên chúng ta có được các giá trị cần thiết như cookie, challenge, publickey và từ đó tính toán được giá trị của privatekey.
Sau khi có được giá trị privatekey chúng ta hoàn toàn có thể sử dụng chúng để xác thực các chức năng yêu cầu người dùng phải đăng nhập.
CVE-2020-8864
Khác với CVE-2020-8863, lỗ hổng bảo mật này có vẻ sẽ quen thuộc hơn với các bạn có tìm hiểu về pwnable. Nguyên nhân gây nên CVE-2020-8864 là do việc sử dụng các hàm so sánh chuỗi ký tự không đúng cách. Cụ thể lập trình viên sử dụng các hàm so sánh như strncmp mà không kiểm tra kỹ giá trị độ dài cần so sánh dẫn đến có thể tận dụng để vượt qua bước xác thực mà không cần thông tin tài khoản.
Nhìn vào hình trên chúng ta có thể thấy nếu giá trị LoginPassword có độ dài là 0 thì hàm strncmp sẽ luôn return về 0 tức là việc so sánh AuthenKey và LoginPassword là luôn trả về kết quả là giống nhau.
Tuy nhiên vượt qua được bước xác thực là chưa đủ bởi để sử dụng được các chức năng của quản trị viên chúng ta cần phải có được giá trị của privatekey thay vì chỉ cần giá trị của cookie, tuy nhiên trong trường hợp này chúng ta không tính toán được giá trị của privatekey.
Vậy làm thế nào để có được giá trị của privatekey, và nó có thực sự cần thiết hay không?
Để giải quyết được vấn đề này chúng ta cần phải tìm hiểu về cách thức kiểm tra xem người dùng đã đăng nhập thành công hay chưa. Dưới đây là mô hình kiểm tra xác thực người dùng
Nhìn vào mô hình trên chúng ta có thể thấy để xác thực thì giá trị Hnap_Auth_key cần phải được tính toán dựa vào privatekey. Tuy nhiên lập trình viên lại tiếp tục mắc phải một lỗi khi sử dụng hàm strncmp với kích thước kiểm tra phụ thuộc vào dữ liệu người dùng gửi lên server. Như vậy nếu Hnap_Auth_key có độ dài bằng 0 thì kết quả trả về luôn là Authenticated. Tuy nhiên trong trường hợp này chúng ta không thể tạo được Hnap_Auth_key với độ dài bằng 0 bởi giá trị này nằm ở đầu của HNAP_AUTH header.
Để giải quyết vấn đề này tôi đã có một ý tưởng là sử dụng Hnap_Auth_key có độ dài là 1 và brute force giá trị này trong khoảng tối đa 16 ký tự, điều này là hoàn toàn khả thi vì số lượng request cần tối đa là 16.
Kết luận
Có thể nói hai lỗ hổng bảo mật trên là không khó để có thể phát hiện và khai thác. Tuy nhiên để có thể đến được các bước mà tôi đã nói ở trên chúng ta cần phải có cả một quá trình nghiên cứu, tìm hiểu. Tôi cũng đưa ra một số lời khuyên cho các bạn trẻ muốn đi theo con đường này như sau:
- Hãy tìm hiểu và nghiên cứu thật nhiều và thành quả sẽ đến với bạn trong một tương lai không xa.
- Muốn đi nhanh thì đi một mình, muốn đi xa thì đi cùng nhau và vừa rồi tôi cũng đã hợp tác với một người anh (@phieulang) để nghiên cứu về lĩnh vực này và dưới đây là một trong những thành quả nghiên cứu chung đầu tiên của hai anh em.
What Next???
Ngoài những CVE được nhắc đến trong bài này tôi còn tương đối nhiều bug khác trên các thiết bị khác nhau của D-Link. Và tôi cũng dự kiến sẽ chia sẻ chi tiết và cụ thể hơn cách tôi tìm bug trên dòng thiết bị này tại hội thảo Hacker Mũ Cối sắp tới.
Chính vì thế bạn nào quan tâm và hứng thú thì cùng đón chờ thông tin chính thức của sự kiện Hacker Mũ Cối nhé.
Thanks for reading!