Khai thác lỗ hổng ứng dụng Web qua Telerik Web UI trên Framework ASP.NET(CVE-2017-9248)

Từ Cryptographic Issues – Generic tới RCE như thế nào?

Đọc sơ qua và dịch lại đoạn mô tả từ CVE thì nôn na là như sau: “Telerik.Web.UI.dll trong Progress Telerik UI cho ASP.NET AJAX trước R2 2017 SP1 và Sitefinity trước 10.0.64-12.0,không bảo vệ đúng cách Telerik.Web.UI.Dialog-ParameterEncodingKey hoặc MachineKey, giúp kẻ tấn công từ xa dễ dàng đánh bại các cơ chế bảo vệ mật mã, dẫn đến rò rỉ MachineKey, tải lên hoặc tải xuống tệp tùy ý, XSS hoặc thỏa hiệp ASP.NET ViewState”, hiểu một cách đơn giản là có thể giải mã và truy cập vào web UI đó, ta có thể upload file tùy ý.

Vậy là đã hiểu sơ bộ rồi. Làm sao để phát hiện?

Đầu tiên, đó là webserver đó phải sử dụng framework là ASP.NET

Thứ 2: Sử dụng Telerik Web UI

Thứ 3: Phiên bản phải nằm trong bảng sau:

Để tìm phiên bản, cách đơn giản nhất: Tổ hợp phím Ctrl+U để tìm nguồn trang: Nhấn Ctrl+ F để tìm kiếm: Telerik.Web.UI.

Bây giờ chúng ta sẽ thực hành luôn :))

Tìm version: Chúng ta vào tin tức hay bài viết bất kỳ, thực hiện cách trên ta thu được:

Oke, vậy thấy luôn version là 2012.1.215.40. Tra bảng thì thấy có rồi(chỉ lấy phần 2012.1.215).

Tìm “Dialog Handler”: Hầu như là có dạng như sau: domain/ Telerik.Web.UI.DialogHandler.aspx

Thấy đang load dialog là ta đã định vị được vị trí để truy cập đến webserver.Nếu nó không nằm ở domain thì phải thử ở sub-tree nhé!

Mục tiêu là tìm được link truy cập đến Document Manager.

Thật may mắn khi đã có người public cách exploit tool cho việc giải mã này, có tại exploitdb: https://www.exploit-db.com/exploits/43873

Việc chúng ta là học cách sử dụng nó để giải mã.

Download về đặt tên là dp_crypto.py

Tại linux system dùng lệnh sau: $ python3 dp_crypto.py

Nếu đọc và nghiên cứu nhiều tài liệu khác thì mặc định chúng ta sẽ là 48 hex 9, nôn na nó chỉ giải mã hexa thôi. Còn link dialog thì chúng ta đã tìm kiếm ở bước trên rồi, chạy thôi:))

Trong đó 48 là độ dài khóa mặc định, có thể điều chỉnh đến khi nào tìm thấy?(Đang bruteforce mà!).

Ngay khi chạy, thì kết quả cho là fail, tức là không giải mã được.Do độ dài khóa hay chưa thử hết?

Lúc đó, thấy fail là tụt cả cảm xúc. Chợt nhận còn sự lựa chọn thứ 2, đó là all 21, nghĩa là thử hết mã ascii chăng. Tại sao cơ hội đến mà không thử?

Sau khi thử thì rất lâu sau đó, tự nhiên đã giải mã được key position đầu, ôi hạnh phúc lắm, thế sau khoảng thời gian thì đã có hết các key và có cả link truy cập vào. Oke, vậy là đã pass được một phần rồi.

Truy cập link:

Kinh nghiệm rút ra là chỉ nên thay đổi chiều dài khóa, còn all 21 là đã thử hết bảng mã rồi, có thể điều chỉnh accuracy, nhưng thường nên để vậy, thử thay đổi độ dài khóa trước khi điều chỉnh accuracy.

Thử thách mới lại đến, nói đến upload được thì trong đầu nghĩ ngay là upload shell còn gì nữa. Tìm code shell ở đâu? Lên google search cmd.apsx thì kết quả đầu tiên là link này: https://github.com/tennc/webshell/blob/master/fuzzdb-webshell/asp/cmd.aspx

Thế là down về và upload, thì máy windows báo có virus và upload lên webserver thì báo lỗi. Thực sự lúc này vô cùng nản chí và bó tay không biết làm thế nào? Thử upload text,.. lại được, nhưng không có quyền sửa và xóa. Thực sự lúc đó, gần như bỏ cuộc. Chợt thử tìm thêm có code khác không thì gặp được link này: https://github.com/tennc/webshell/blob/master/fuzzdb-webshell/asp/cmdasp.aspx

Cùng tác giả nhưng đoạn code này sau khi thử upload lại được.

Kết quả: