Recon is King: Khi tất cả hơn nhau ở ... độ lỳ!

Cũng đã rất lâu rồi chưa viết lại bài. Có thể do các case chưa đủ wow, phần còn lại là do lười :v Nhưng có lẽ chính xác là do LƯỜI! Nhưng vừa rồi mình gặp một case có thể cho là đủ WOW để chia sẻ với mọi người! Ở case này thực sự là cần sự kiên trì và không ngừng tìm tòi!

Bắt đầu

Câu chuyện cũng đơn giản là một hunter khác trên sàn mời collab với mình tên: lala, anh ấy tìm ra một domain khá là dị của program. Lập tức bắt tay vào pha recon từ domain được cho. Nhưng cái vấn đề ở đây với tất cả các subdomain và domain mình có được là vấn đề về Đăng nhập. Trang nào cũng như thế này:

Thực sự là rất khó đấy! Cái này gần như là một rào cản mà khi thực hiện tìm lỗ hổng thì khiến nhiều hunter bỏ qua và tìm mục tiêu mới ngay! Cũng nhiều người hỏi làm thế nào để có thể tìm được nhiều bug, câu hỏi này khó, bởi thành thật mà nói, với case này mình đã không bỏ cuộc, mình cho máy chạy 24/24 trong vòng gần 1 tuần để kiếm ra được lỗ hổng! Nên mình hiểu được cảm giác bất lực khi tìm lỗ hổng của mọi người như thế nào, CỰC KỲ CHÁN!!!

Với kinh nghiệm của bản thân, mình cũng bắt đầu với những công cụ tương tự mọi người thôi, không có cao siêu, hay lạ lẫm gì đâu. Đây là các công cụ mình sử dụng trong recon:

Thực hiện Passive recon:

• gau: Get all url
• waybackurls: wayback machine nhưng bản cli
• Virus total: Này không chỉ check virus đâu nhé!

....

Thực hiện Active recon:

• dirsearch: Công cụ fuzzing path đơn giản mà hiệu quả
• FFUF: Công cụ fuzzing mọi thứ mà bạn muốn
• Nuclei: Cái này thì cho mình cái view nhanh nhất một số lỗ hổng tồn tại trong mục tiêu nhanh nhất

...

Lỗ hổng kỳ diệu

Với trường hợp này, mình kết hợp cả Passive và Active để recon cùng lúc, tăng cơ hội và giảm thời gian tìm kiếm. Nhưng vấn đề sinh ra là tại sao mình không tìm ra một thông tin nào có giá trị thế nhỉ? Đây là lúc mình nản, tập trung vào một mục tiêu trong vòng 2-3 tiếng nhưng không có gì thì có lẽ là một thứ khiến mình chán nản thật sự đấy! Nhưng, mọi thứ xoay chuyển, tại sao ư? Do mình thiếu xót trong quá trình recon đấy!

Bước ngoặc ở đây là gì? IIS & ASP.NET, trong công cuộc tìm kiếm lỗ hổng trong suốt 1 năm qua thật sự là hiếm khi mình tấn công một hệ thống nào đó là ASP.NET, thường đa số mục tiêu sẽ là PHP. Bởi vì sao? Bởi nó dễ làm, dễ đoán. Đôi khi việc tấn công lại còn đơn giản đến bất ngờ. Nhưng khi đã hiểu hệ thống base trên ASP.NET, mình lại tiếp tục mày mò đi sâu vào đó! Thật trùng hợp, ngay lúc này, nuclei đã báo về có 1 url Telerik UI được sử dụng. Bạn biết gì không? Lần đầu tiên biết đến lỗ hổng liên quan đến framework này là tầm 2020, nghĩa là 5 năm rồi. Trong nhiều lần thử, thì thật sự chưa lần nào thành công, yeah, chưa một lần nào thành công cả! Mình cũng chia sẻ phần này cho lala, và bạn biết gì không? Anh ấy dùng Macbook, ok trong đầu nghĩ, ok chắc ý trời, thôi, để tính sau vậy!

Tìm tòi thêm một lúc, mình mới biết là có một tool chuyên trị cho case này là shortscan. Đây là trang web chạy trên IIS và lỗ hổng cố hữu các hệ thống này là IIS Short Name. Đây là lỗ hổng xảy ra trên máy chủ web IIS (Internet Information Services) khi Windows sử dụng định dạng tên tệp 8.3 để tương thích với các hệ thống cũ. Vậy nó trông như thế nào?

Rất may mắn, trang web dính lỗi thật, nhưng theo mình đấy là một tính năng! Từ đây, mình mới hiểu ra tại sao mình không fuzz ra một endpoint nào của trang web, chính vì việc nó có prefix dạng: AD_, SP_... trước các tên file, do vậy mình mới không thể nào tìm ra một endpoint nào khả thi. Ok, thế này thì lại tiếp tục thôi nhỉ? Bắt đầu đoán thôi. Tìm tòi thêm tí nữa thì lại thấy có một tool hỗ trợ cho case này để từ các short name kia, có thể tìm ra tên file hoàn chỉnh: GitHub-Shortname-Scanner. Bây giờ thì công việc recon đã đơn giản hơn tý rồi đấy. Mình có được những thông tin trên rồi, vậy làm tiếp thế nào? Phải xây dựng một cái word list cho mục tiêu này chứ sao! Ta có những gì nào?

• Short name của file
• Công cụ tìm tên file cho short name
• Nó sử dụng dạng file aspx (nhìn shortscan ta thấy)

Bây giờ là lúc để tricky, ta không thể nào mà cầm nguyên giá trị RT_BUD?.ASP? này của shortscan ra để tìm được, chắc chắn là không thể tìm được! Nên ta cần tách ra khỏi prefix và tìm tất cả các từ đó. Từ RT_BUD thành BUD, rồi sau đó dùng công cụ mà tạo word list thôi. Bởi vì sao ư? Mình đọc code của cái tool kia, và nó sẽ search tên file trên github, và lấy tất cả về, vì vậy nên sẽ có những cái file extention không dùng được trong trường hợp này, ví dụ PHP thì chạy thế nào trên ASP được đúng không? Được bước đầu tiên của khởi tạo word list rồi! Tiếp theo là thay thế tất cả các file extention lại cho đúng, bởi vì đây là ASP.NET mà! Giờ thì cứ thế mà bỏ vào shortscan lấy endpoint thôi! Nhưng đến đây chưa xong, bởi vì sao ư? Tuy tìm được endpoint thật đấy, nhưng mà cái vấn đề là Authen!

Cứ truy cập lại bị đẩy ra trang đăng nhập, thật là bất lực! Ok giờ thì FFUF thôi, fuzz tới chết, thật sự đây là một trong những cách cuối cùng để có thể tìm được thứ mà bạn cần! Và cái độ lỳ nằm ở phần này, thử qua hàng chục word list, nhìn từng dòng response trả về và cần phải hiểu bạn đang làm gì?

ffuf -u https://domain.com/?FUZZ= -w wordlist.txt -mc 200

Và, sau gần 1 tuần, chính xác, gần 1 tuần, ngày nào cũng giành ra đôi tiếng tối về ngồi fuzz, liệu bạn có như vậy không? Hãy comment nhé!

Cuối cùng trái ngọt cũng đậu, nhưng mà làm mình phải giật mình. Thật sự là xa tận chân trời, gần ngay trước mắt. Cái mình tìm lại là một thứ rất quen thuộc với ASP.NET, nó chính là VIEWSTATE. Chỉ cần đúng cái param này là có thể bypass được Authen hệ thống. Mình phải dụi mắt vài lần, thử lại vài lần để chắc chắn là mình đúng, chứ không phải là một ảo ảnh mà mình gặp. Và chính xác, nó hoạt động thật. Thử hết cái đống tìm ra từ shortscan thì nó trả về 200 hết thật bằng Intruder của Burp. Cho chắc thì bật render lên, thấy web load nội dung của endpoin thật, không còn là trang login nữa @@ Thật sự đây là case dị nhất về bypass Authen mà mình gặp, và do chính mình tìm ra, chưa từng gặp từ trước đây!

Mình cũng đoán được là do dùng cách thức như vậy, nên khi load các trang như Profile thì sẽ chả có gì hiện ra như ảnh trên. Nhưng với kinh nghiệm, và 1 chút tò mò, mình tự hỏi, AD liệu có phải là viết tắt của Admin? Và mình thử luôn, chính xác là lúc ấy mục tiêu chỉ muốn tìm được impact lớn nhất đó là Bypass Authen lead to Admin take over. Nên quyết định tìm cho được các endpoint prefix AD_

Bất ngờ chưa? Cái Magic Param(này là mình gọi cho case này thôi) kia đã cho mình luôn quyền quản trị hệ thống, mà không cần bất kỳ một authen nào trên web!?! Thật kỳ diệu!!!

Giờ thì nhanh chóng tạo tài khoản, và submit bug thôi!

Lỗ hổng may mắn

Các bạn nhớ đến Telerik phía trên chứ? Yeah, ông bạn lala dùng Macbook và không có kinh nghiệm về lỗ hổng ấy! Và trong đầu mình luôn quan niệm, đã có 1 lỗi, thì chắc chắn là còn những lỗi khác. Mình xoáy vào Telerik, vì RCE mới là cái mình thích! Và lỗ hổng Telerik là 1 trong số ấy. OK, cài đặt môi trường và build POC theo hướng dẫn của link github

https://github.com/noperator/CVE-2019-18935

Để mà build được POC thì phải cài VS, bản nào cũng được và cài cái này vào:

Cũng khá mất công, do đụng đến đâu thì mò tìm đến đó. Loay hoay 1 hồi cũng build được cái POC sleep, để hẳn 15s cho nó chắc kèo:

Lần này lại phải dụi mắt phát nữa, nghĩ thầm trong đầu, ủa sao nó trả response chậm dữ??? Thấy báo về response cũng sấp xỉ 15s. Mình mừng quá, thêm phát nữa. Ủa, sao lại không được rồi? Vừa mừng vừa lo. Mình cứ nghĩ AV nó chém rồi Thế là vội dựng ngay 1 cái POC revshell hứng vội connect về cho chắc kèo còn viết report.

Tầm này thì không trật đi đâu được nữa, cap vội cái hình rồi report thôi!

Bonus tip

Ở case Telerik, cái quan trọng nhất của nó chính là phải biết version của nó là gì? Nhiều trường hợp sẽ không thể tìm được version vì nó không trả về theo cái cách check bình thường trong link git trên! Nên mình nghĩ ra một cách, trong thời đại AI mà, mình bảo nó list hết các version của Telerik UI từ năm 2013 đến 2019 cho chắc kèo, rồi thực hiện fuzz, lại là fuzz, đúng vậy, cái mình nói ban đầu đấy, lỳ là cái gì đó quan trọng trong cái thế giới bug này. Nhiều người họ chỉ làm bề mặt thôi, không đi sâu vào cái họ tấn công. Nên nhiều khi nó như bức ảnh này này:

Và cũng thật may mắn, trên con đường tìm bug, có được những người bạn tạo động lực cho mình, respect Shady:

Và chia sẻ luôn cho mọi người, sau lỡ có gặp thì biết đâu cũng may mắn như mình!

Version:

2013.1.220 2013.1.403 2013.1.417 2013.2.611 2013.2.717 2013.3.1015 2013.3.1114 2013.3.1324 2014.1.225 2014.1.403 2014.2.618 2014.2.724 2014.3.1024 2015.1.204 2015.1.225 2015.2.604 2015.2.623 2015.2.729 2015.2.826 2015.3.930 2015.3.1111 2016.1.113 2016.1.225 2016.2.504 2016.2.607 2016.3.914 2016.3.1018 2016.3.1027 2017.1.118 2017.1.228 2017.2.503 2017.2.621 2017.2.711 2017.3.913  2018.1.314 2018.2.516

Và cứ thế mà quất thôi:

for ver in (cái đống ver trên); do
python3 CVE-2019-18935.py -p {payload} -v "$ver" -u https://domain/Telerik.Web.UI.WebResource.axd?type=rau 2>/dev/null;
done

Chốt hạ

Cuối cùng thì cũng chốt hạ được thêm 1 lỗi File backup expose bằng việc fuzzing, hên hệ thống Database public internet, nên cái cấu hình lấy được trong file backup sử dụng được, cũng khá khôi hài vì 1 SQLi thì được Exceptional, nhưng kiểm soát được DB thì chỉ được Critical, thế là phải hỏi lại triage ngay

Và ngay sau đó nó lên Exceptional ngay!

Kết

Đây là hướng mình tấn công một mục tiêu trong bug bounty, có thể giống, có thể khác. Phong cách mỗi người là do họ chọn. Mình chọn cách đi đụng đâu, đánh đó. Và bỏ thời gian ra học thêm các thứ mới, chứ mình cũng như mọi người, cũng phải bắt đầu từ đầu thôi, nhiều khi học xong chả dùng sẽ quên, nhưng sẽ biết tìm nó ở đâu. Lâu lâu xem vid PewPew thấy cái này khá đúng này:

Còn khi đã thấy một mục tiêu tiềm năng, thì thường mình sẽ cào bằng hết thì thôi, và hẹn các bạn trong một blog khác với cùng kiểu cào bug không để xót 1 lỗ hổng nào trong hành trình mới dưới đây!