Quy trình xác thực Windows. Một lỗi xác thực Windows NTLM cũ cho phép bạn ẩn danh người dùng. Lưu trữ mật khẩu trong cơ sở dữ liệu tài khoản

11.02.2011 Jean de Clercq

Tất nhiên, bất kỳ quản trị viên Windows nào cũng phải xử lý hai giao thức xác thực chính trong môi trường Windows nhiều lần: Kerberos và NTLM. Bài viết này tập trung vào cách Kerberos và NTLM được hỗ trợ trên Windows 7 và Windows Server 2008 R2. Nhưng trước tiên, tôi muốn làm nổi bật sự khác biệt chính giữa các giao thức này.

Các nhà phát triển của Microsoft lần đầu tiên triển khai Kerberos trong Windows 2000. NTLM đã được sử dụng sớm hơn nhiều, trong những ngày của Windows NT. Kerberos là một giao thức xác thực dựa trên khái niệm bên thứ ba đáng tin cậy (TTP), trong khi NTLM dựa trên cơ chế thử thách / phản hồi. Sự khác biệt giữa hai giao thức được mô tả chi tiết hơn trong bảng.

Khi trao đổi dữ liệu trong quá trình xác thực bằng giao thức NTLM, tài nguyên máy chủ (ví dụ: máy chủ tệp) tạo ra một yêu cầu được gửi đến máy khách. Máy khách tạo phản hồi NTLM bao gồm băm mật khẩu của người dùng và máy chủ xác minh tính đúng đắn của phản hồi này. Nếu máy khách đang sử dụng tài khoản cục bộ, máy chủ xác minh phản hồi của người dùng bằng cách sử dụng hàm băm mật khẩu của người dùng, được lưu trữ trong cơ sở dữ liệu Cục quản lý tài khoản bảo mật (SAM) cục bộ. Nếu máy khách sử dụng tài khoản miền, máy chủ sẽ gửi phản hồi đến bộ điều khiển miền để xác minh, bởi vì chỉ bộ điều khiển miền mới lưu trữ bản sao của hàm băm mật khẩu người dùng trong cơ sở dữ liệu Active Directory (AD) của họ.

Trong Windows Kerberos, bên thứ ba đáng tin cậy là bộ điều khiển miền Windows 2000 trở lên lưu trữ dịch vụ Trung tâm phân phối khóa Kerberos (KDC). KDC tạo điều kiện xác thực giữa máy khách hỗ trợ Kerberos và máy chủ. Dịch vụ KDC được tự động cài đặt như một phần của hệ thống AD và bao gồm hai hệ thống con: Dịch vụ xác thực (AS) và Dịch vụ cấp vé (TGS).

Khi người dùng đăng nhập vào miền Windows bằng giao thức Kerberos, trước tiên máy khách Windows xác thực người dùng với bộ điều khiển miền bằng mật khẩu của người dùng. Đồng thời, khách hàng yêu cầu xuất vé Ticket Grant Ticket (TGT) cho dịch vụ xác thực. TGT có thể được coi như một mật khẩu tạm thời (theo mặc định, thời gian tồn tại của nó là 8 giờ), sẽ thay thế mật khẩu của người dùng trong các yêu cầu xác thực tiếp theo. Khi người dùng cần truy cập tài nguyên máy chủ, máy khách sẽ xuất trình TGT để cấp TGT xác thực cho tài nguyên máy chủ. Cần biết rằng, không giống như NTLM, Kerberos không được sử dụng để xác thực cục bộ với Trình quản lý tài khoản bảo mật của Windows; phạm vi của nó được giới hạn trong xác thực miền trên bộ điều khiển miền.

Kerberos là giao thức xác thực tiêu chuẩn trong Windows 2000 và các phiên bản mới hơn của Microsoft. Trong các hệ điều hành này, giao thức xác thực được xác định bằng cơ chế thương lượng. Nếu giao thức Kerberos mặc định không phù hợp hoặc không được hỗ trợ bởi một trong các thành phần máy khách hoặc máy chủ liên quan đến xác thực, Windows sẽ chuyển sang NTLM.

Tại sao lại là Kerberos?

Kerberos hiệu quả hơn NTLM vì một số lý do. Với Kerberos, mật khẩu băm của người dùng ít bị lộ ra ngoài hơn so với NTLM. Hàm băm của mật khẩu chỉ được tiết lộ khi người dùng yêu cầu TGT - về bản chất, cứ tám giờ một lần. Mặt khác, với NTLM, mật khẩu băm sẽ bị lộ ra bất cứ khi nào máy khách sử dụng NTLM để xác thực với máy chủ. Đây là một lợi thế quan trọng của giao thức Kerberos so với giao thức NTLM; thực tế là có những công cụ đặc biệt kiểm tra lưu lượng mạng để tìm các băm mật khẩu. Các công cụ này nắm bắt các hàm băm được phát hiện và bắt buộc khôi phục mật khẩu người dùng từ chúng.

Một ưu điểm khác của Kerberos là nó sử dụng tem thời gian để bảo vệ khỏi các cuộc tấn công truyền lại gói tin. Đây là lý do tại sao điều quan trọng là phải có một dịch vụ đồng bộ hóa thời gian hoạt động hoàn hảo trong môi trường Windows lấy Kerberos làm trung tâm. Trong Windows 2000 và các phiên bản mới hơn của hệ thống, dịch vụ thời gian hết hộp. Nếu đồng hồ máy tính trên các máy tính khác nhau không được đồng bộ hóa, điều này có thể dẫn đến lưu lượng bổ sung trong quá trình xác thực Kerberos hoặc trong trường hợp xấu nhất, tình huống này có thể gây ra lỗi trong quá trình xác thực.

Ngoài những điều trên, giao thức Kerberos triển khai các tính năng xác thực nâng cao như xác thực lẫn nhau và ủy quyền xác thực. Xác thực lẫn nhau có nghĩa là người dùng và dịch vụ xác thực lẫn nhau, trong khi NTLM bị giới hạn trong việc xác thực người dùng. Nếu không có tính năng này, các tình huống có thể phát sinh khi người dùng cung cấp thông tin đăng nhập của họ cho một máy chủ không có thật.

Một dịch vụ có thể truy cập tài nguyên từ xa thay mặt người dùng bằng cơ chế ủy quyền xác thực. Nói cách khác, người dùng có thể thay mặt họ cấp cho hệ thống proxy quyền chứng minh danh tính (người dùng) của mình trên máy chủ ứng dụng. Do đó, máy chủ ứng dụng có thể đưa ra quyết định ủy quyền không dựa trên danh tính của hệ thống proxy mà dựa trên danh tính của người dùng. Tính năng xác thực ủy quyền rất hữu ích trong các ứng dụng nhiều tầng như truy cập cơ sở dữ liệu bằng giao diện người dùng dựa trên Web.

Cuối cùng, phải nói rằng mặc dù các chuyên gia của Microsoft đã thực hiện rất nhiều việc hiện đại hóa giao thức NTLM, cụ thể là họ đã tạo ra phiên bản NTLMv2 được hỗ trợ trong môi trường NT4 SP4 và các phiên bản mới hơn, các thuật toán mã hóa hiện đại hơn được triển khai trong Sản phẩm Microsoft Kerberos. Tôi sẽ trình bày chi tiết hơn về vấn đề này trong phần Công cụ mã hóa Kerberos.

Hạn chế của giao thức NTLM

Những lợi ích của xác thực Kerberos là không thể phủ nhận. Nhưng ngay cả trong AD Server 2008, Windows thường sử dụng NTLM, chẳng hạn như khi bạn kết nối với hệ thống Windows trước Windows 2000 hoặc khi bạn kết nối với tài nguyên được chia sẻ bằng lệnh net use và địa chỉ IP (không phải tên NetBIOS) . Ngoài ra, các ứng dụng không có tên chính của dịch vụ (SPN) được định cấu hình đúng cách sẽ vẫn sử dụng NTLM.

Để biết giao thức nào - NTLM hoặc Kerberos - bạn hiện đang sử dụng, bạn có thể hình dung lưu lượng NTLM bằng tiện ích netmon hoặc một trình theo dõi mạng khác; một giải pháp thay thế là kiểm tra nội dung của bộ đệm ẩn vé Kerberos bằng công cụ klist (đi kèm với Windows 7 và Server 2008). Trong Windows 7 và Server 2008, Microsoft đã triển khai Chính sách Nhóm mới mà bạn có thể sử dụng để giám sát và chặn việc sử dụng NTLM của người dùng và ứng dụng của bạn. Có ba chính sách như vậy: một chính sách dành cho lưu lượng NTLM gửi đến (để giám sát và chặn ở cấp máy chủ), một chính sách khác dành cho lưu lượng NTLM đi (để giám sát và chặn ở cấp máy khách) và một chính sách dành cho lưu lượng tên miền (để giám sát và chặn ở cấp bộ điều khiển miền). Chúng nằm trong vùng chứa Đối tượng Chính sách Nhóm Tùy chọn Bảo mật (CPO), có thể được truy cập bằng cách chọn tuần tự các mục Cấu hình Máy tính, Cài đặt Windows, Cài đặt Bảo mật, Chính sách Cục bộ (xem Hình 1). Tất cả đều bắt đầu với phần tử Network security: Restrict NTLM:.

Mỗi cài đặt chính sách có các tham số kiểm tra và khối. Khi bạn bật tính năng kiểm tra NTLM, chương trình sẽ tạo các mục nhật ký sự kiện với dữ liệu NTLM gốc và các số 8001, 8002, 8003 và 8004. Các mục nhật ký được lưu trữ trong vùng chứa Hoạt động với Trình xem sự kiện (Cục bộ), Nhật ký ứng dụng và dịch vụ, Microsoft , Windows, NTLM. Tôi khuyên bạn nên bắt đầu bằng cách kiểm tra NTLM trong môi trường thử nghiệm và đảm bảo rằng tất cả các ứng dụng của bạn được trình bày đúng ở đó. Nếu bạn bắt đầu tự ý chặn việc sử dụng giao thức, rất có thể một số ứng dụng sẽ không hoạt động. Để tránh mất sự kiện, bạn nên cài đặt giải pháp thu thập sự kiện kiểm toán trước khi thử nghiệm các công cụ kiểm toán NTLM; bạn có thể sử dụng Trình thu thập sự kiện tích hợp sẵn của Windows, Đăng ký sự kiện hoặc giải pháp của bên thứ ba. Ngoài ra, tôi khuyên bạn nên bắt đầu giám sát NTLM trên các máy chủ trước. Bạn có thể kết nối các máy khách để phân tích chi tiết sau khi rõ ràng rằng máy chủ đang sử dụng giao thức NTLM. Khi bạn hiểu ứng dụng nào đang sử dụng NTLM, bạn có thể phát triển chiến lược chặn NTLM. Chiến lược này có thể bao gồm chiến lược loại trừ các ứng dụng cũ không thể viết lại hoặc cấu hình lại và sẽ luôn yêu cầu NTLM.

Thật không may, các cài đặt NTLM đã đề cập không thể được áp dụng trên các hệ thống Windows cũ hơn. Tuy nhiên, các hệ thống này cho phép kiểm soát phiên bản NTLM. Ví dụ: bạn có thể tắt đoạn mã LM của giao thức xác thực NTLM (vì đoạn mã này vốn đã yếu) hoặc buộc NTLMv2. Để thực hiện việc này, hãy sử dụng cài đặt GPO của Network Security: LAN Manager Authentication Level, nằm trong vùng chứa GPO của Computer Configuration \ Windows Settings \ Security Settings \ Local Policies \ Security Options (xem Hình 2).

Công cụ mã hóa Kerberos

Các giao thức mật mã được sử dụng bởi các giao thức xác thực đóng một vai trò quan trọng trong việc đảm bảo an ninh cho sau này. Như tôi đã đề cập trước đó, Kerberos đạt điểm cao hơn NTLM trong lĩnh vực này. Thuật toán mã hóa RC4 lần đầu tiên được triển khai trong giao thức Windows Kerberos trong Windows 2000 và vẫn được hỗ trợ trong các hệ thống Server 2008, cũng như Windows 7 (chính xác hơn là phiên bản RC4_HMAC_MD5 của nó được hỗ trợ). Trên Server 2008, Windows Vista và phiên bản mới hơn, Microsoft đã bổ sung hỗ trợ cho Tiêu chuẩn mã hóa nâng cao, AES và Windows 7 và Server 2008 R2 hỗ trợ loại mã hóa Kerberos AES (AES128_HMAC_SHA1 và AES256_HMAC_SHA1). AES là một thuật toán mã hóa mới hơn và mạnh hơn DES. Logic Kerberos trên bộ điều khiển miền sẽ chuyển đổi sang tiêu chuẩn mã hóa AES khi bạn nâng cấp miền AD của mình lên Cấp chức năng miền (DFL) của Windows 2008.

Trong Windows 7 và Server 2008 R2, các kiểu mã hóa DES để xác thực Kerberos bị tắt theo mặc định. Điều này có thể gây ra sự cố tương thích nếu một trong các ứng dụng cũ được mã hóa cứng chỉ để mã hóa DES hoặc nếu tài khoản Windows đang chạy một dịch vụ (tài khoản dịch vụ) được định cấu hình để chỉ sử dụng mã hóa DES. Các dịch vụ hoặc ứng dụng này sẽ không thành công nếu bạn không thể định cấu hình lại dịch vụ hoặc ứng dụng tương ứng để hỗ trợ loại mã hóa khác (RC4 hoặc AES) hoặc nếu bạn không khôi phục hỗ trợ DES.

Để tìm hiểu xem bạn có các ứng dụng hoặc dịch vụ được mã hóa riêng bằng tiêu chuẩn DES hay không, bạn có thể chạy trình theo dõi mạng khi ứng dụng hoặc dịch vụ tương ứng khởi động và kiểm tra nội dung của các trường Etype trong tiêu đề xác thực Kerberos. Để xác định xem người dùng AD hoặc tài khoản máy tính hoặc tài khoản máy tính được định cấu hình để chỉ sử dụng các loại mã hóa DES, bạn phải xác minh rằng tùy chọn Sử dụng kiểu mã hóa Kerberos DES cho tài khoản này được chọn trên tab Thuộc tính tài khoản của đối tượng. Các thuộc tính này có thể được truy cập từ phần đính vào MMC của Người dùng AD và Máy tính.

Nếu bạn hoàn tất các bước kiểm tra ở trên và thấy rằng bạn đang gặp sự cố này, bạn có thể bật mã hóa DES để xác thực Kerberos trên máy tính chạy Windows 7 hoặc Server 2008 R2 bằng cách sử dụng cài đặt GPO bảo mật mạng: Định cấu hình các loại mã hóa tương thích với tiêu chuẩn Kerberos; các cài đặt này nằm trong Cấu hình Máy tính, Cài đặt Windows, Cài đặt Bảo mật, Chính sách Cục bộ, Vùng chứa GPO Tùy chọn Bảo mật.

Vì vậy, trong hai giao thức xác thực của Windows, Kerberos là giao thức được ưu tiên. Quản trị viên phải luôn nhấn mạnh rằng người dùng và ứng dụng sử dụng Kerberos chứ không phải NTLM. Các hạn chế mới về việc sử dụng NTLM trong Windows 7 và Server 2008 R2 tạo cơ hội tuyệt vời để chúng tôi đạt được mục tiêu này.

Jean de Clercq ( [email được bảo vệ]) là một nhân viên của Văn phòng An ninh HP. Chuyên về quản lý danh tính và bảo mật trong các sản phẩm của Microsoft

Xác thực trên Windows Server 2008 R2 và Windows 7

Gần đây đã phải đối mặt với vấn đề này: FireFox, Chrome, Opera không muốn vượt qua Ủy quyền NTLM... Người duy nhất đã vượt qua là I E... Tôi quên nói rằng vấn đề này được quan sát trên Windows7... Các phương pháp khắc phục sự cố này sẽ được mô tả bên dưới.

Opera: không chính thức hỗ trợ NTLM- ủy quyền, mặc dù trong cài đặt, bạn có thể tìm thấy một mục cho phép bạn bật hoặc tắt tùy chọn này. Do đó, trong cài đặt của máy chủ proxy, bạn cần thêm ủy quyền cơ bản... Để vô hiệu hóa Ủy quyền NTLM(và thực sự làm cho trình duyệt này hoạt động thông qua proxy) chúng tôi thực hiện như sau:

1) gõ vào trình duyệt about: config
2) chuyển đến phần NetWork và bỏ chọn thông số Bật NTLM
3) khởi động lại trình duyệt.

Đúng, có một cảnh báo (có thể nói là hơi bất tiện): ở lần bắt đầu đầu tiên, bạn sẽ phải nhập mật khẩu đăng nhập (hoàn toàn, nghĩa là với miền) và chọn hộp "Cứu"... Bây giờ, với mỗi lần mở trình duyệt tiếp theo, bảng ủy quyền sẽ xuất hiện và bạn chỉ cần nhấn "VÂNG"... Bất tiện, nhưng bạn có thể làm gì.

Ghi chú: đôi khi trên một số hệ điều hành, ngược lại, bạn phải bật Ủy quyền NTLM... Có lẽ nó cũng phụ thuộc vào các phiên bản trình duyệt và hệ điều hành.

FireFox, Chrome: họ ủng hộ, mặc dù bạn cần phải shaman một chút. Tôi sẽ mô tả một số tùy chọn mà tôi có trên Internet, bạn có thể phải thử mọi thứ cho đến khi tìm được cái phù hợp với mình.

1) bạn sẽ cần thêm vào sổ đăng ký HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa một tham số được gọi là LmCompatibilityLevel kiểu DWORD và gán một giá trị cho nó 1 ... Sau đó, bạn sẽ cần khởi động lại máy tính (đây là tùy chọn phù hợp với tôi)

2) Đến Firefox có thể vượt qua ntlmủy quyền, có vẻ như chỉ cần mở about: config trên thanh địa chỉ là đủ và thay đổi các thông số thành như sau:

network.negotiate-auth.delegation-uris = http: //, https: //
network.negotiate-auth.trusted-uris = http: //, https: //

Sau đó khởi động lại trình duyệt.

3) Mở trình chỉnh sửa chính sách ( gpedit.msc) Cấu hình máy tính -> Cấu hình Windows -> Cài đặt bảo mật -> Chính sách cục bộ -> Cài đặt bảo mật -> Bảo mật mạng: Mức xác thực Trình quản lý mạng LAN và đặt thông số Gửi LM và NTLM - sử dụng bảo mật phiên NTLMv2 khi đàm phán.

Sau đó, chúng tôi đóng chính sách và khởi động lại.

Nếu bạn có phiên bản tiếng Anh, thì như sau: máy chính sách-> cấu hình máy tính-> cài đặt cửa sổ-> chính sách cục bộ-> tùy chọn bảo mật-> Bảo mật mạng: Cấp xác thực Trình quản lý LAN và chọn LM & NTLM - Sử dụng phiên NTLMv2 nếu được thương lượng.

4) Một tùy chọn khác là định cấu hình qua mực_ldap:

chương trình cơ bản auth_param / usr / lib / ink3 / ink_ldap_auth -b "cn = users, dc = office, dc = ru" -f "sAMAccountName =% s" -h 192.168.0.74 -D "cn = administrator, cn = users, dc = office, dc = ru "-w" secpass "
auth_param cơ bản trẻ em 5
lĩnh vực cơ bản auth_param Proxy inet của tôi
auth_param thông tin đăng nhập cơ bản trong 60 phút

external_acl_type nt_groups% LOGIN / usr / lib / ink3 / ink_ldap_group -R -b "cn = users, dc = office, dc = ru" -f "(& (cn =% v) (memberOf = cn =% a, cn = người dùng, dc = office, dc = ru)) "-D" cn = quản trị viên, cn = người dùng, dc = office, dc = ru "-w" secpass "-h 192.168.0.74

acl tất cả src 0.0.0.0/0.0.0.0
acl group_inet bên ngoài nt_groups inet

http_access allow group_inet
http_reply_access cho phép tất cả
icp_access cho phép tất cả
http_access từ chối tất cả

Vẫn thử 🙂

Các nhà nghiên cứu đã nói chuyện tại các hội nghị trong nhiều năm rằng công nghệ Đăng nhập một lần không an toàn. Microsoft đã sử dụng một hệ thống xác thực duy nhất như vậy cho mọi thứ trong một thời gian dài, và các chuyên gia bảo mật thông tin cho biết vào năm 1997 rằng đây không phải là một ý tưởng hay. Một lần nữa, tính dễ bị tổn thương của đăng nhập một lần nói chung và trong trường hợp làm việc với tài nguyên SMB nói riêng đã được nhà nghiên cứu người Nga ValdikSS chứng minh. Anh ta mô tả một phương pháp cho phép bạn xâm nhập Tài khoản Microsoft của nạn nhân, ẩn danh người dùng Microsoft và tìm ra dữ liệu về VPN.

Trên thực tế, để thực hiện thành công một cuộc tấn công, kẻ tấn công chỉ cần ngụy trang một liên kết đến tài nguyên SMB của chính mình (tài nguyên mạng: tệp và thư mục, máy in, v.v.), chẳng hạn như dưới một bức ảnh và buộc nạn nhân phải mở. nó. Cuộc tấn công hoạt động trên tất cả các hệ điều hành hiện đại, bao gồm cả Windows 10 với các bản cập nhật mới nhất. Hơn nữa, những vấn đề này với xác thực NTLM không chỉ được thảo luận vào năm 1997 mà chúng được ghi nhớ thường xuyên. Vì vậy, vấn đề này đã được nêu ra (PDF) vào năm ngoái tại hội nghị BlackHat. Thật không may, không có gì thay đổi so với những đề cập thường xuyên.

Trên "Habrahabr", người dùng ValdikSS đã nói về cách "lỗi từ những năm 90" này có thể được khai thác ngày nay. Nhà nghiên cứu viết:

“Ngay khi bạn cố gắng mở liên kết đến tài nguyên SMB trong trình duyệt tiêu chuẩn (Internet Explorer, Edge) hoặc bất kỳ ứng dụng nào chạy qua lệnh gọi API Windows tiêu chuẩn hoặc sử dụng Internet Explorer làm công cụ kết xuất HTML (Outlook, Windows Explorer), tài nguyên SMB ngay lập tức nhận được chi tiết tài khoản của bạn ngay cả trước khi bạn nhìn thấy hộp thoại đăng nhập và mật khẩu. Đối với kẻ tấn công, chẳng hạn, chỉ cần thêm liên kết đến ảnh từ máy chủ SMB trên trang web hoặc gửi cho bạn một email chỉ đủ để mở và - bùm! - dữ liệu tài khoản của bạn nằm trong tay kẻ tấn công. "

Mặc dù việc rò rỉ tên tài khoản và băm mật khẩu của máy tính gia đình không được coi là một thảm họa, nhưng khi nói đến miền công ty, một cuộc trò chuyện hoàn toàn khác bắt đầu.

“Từ tên miền, có thể dễ dàng hiểu tài khoản thuộc tổ chức nào và sau đó, nếu mật khẩu đã được brute-force thành công, bạn có thể thử xác thực các tài nguyên của công ty có thể truy cập từ Internet (thư, VPN) .

Nhưng mật khẩu không phải lúc nào cũng cần thiết để đoán. Nếu bạn biết trước một số tài nguyên mà bạn có thể nhập bằng xác thực NTLM, bạn có thể trong thời gian thực, ngay khi máy khách kết nối với máy chủ SMB của bạn, các yêu cầu proxy từ máy khách đến máy chủ từ xa và từ máy chủ tới máy khách, và ValdikSS giải thích.

Tình hình còn trở nên trầm trọng hơn do trong các hệ điều hành hiện đại, Microsoft đang tích cực thúc đẩy việc sử dụng một Tài khoản Microsoft duy nhất, theo nghĩa đen, buộc người dùng phải tạo một Tài khoản. Đối với người dùng Tài khoản Microsoft, các cuộc tấn công như vậy có thể nguy hiểm gấp đôi và không chỉ đối với các tổ chức mà còn đối với các cá nhân. Thực tế là trong trường hợp có cuộc tấn công vào máy chủ SMB của kẻ tấn công, dữ liệu sẽ được chuyển, trên thực tế, sẽ làm tổn hại đến Tài khoản Microsoft của nạn nhân và nhiều dịch vụ được liên kết với nó (Skype, Xbox, OneDrive, Office 360, MSN, Bing, Azure, v.v. Hơn nữa).

Nhà nghiên cứu cũng viết rằng trong một số trường hợp, cuộc tấn công có thể được sử dụng để trích xuất dữ liệu về thông tin đăng nhập và băm mật khẩu của kết nối VPN của nạn nhân.

Đồng thời, ValdikSS đã mô tả một số cách để khai thác các vấn đề với xác thực NTLM. Ngoài những điều rất rõ ràng, nhà nghiên cứu đề xuất sử dụng lỗ hổng để ẩn danh người dùng:

“Khai thác với mục đích tắt tên thú vị hơn. Tài khoản sẽ được gửi từ các trang của trang web nếu nạn nhân sử dụng Internet Explorer hoặc khi nhấp vào bên trong thư, trong trường hợp Outlook. Hầu như tất cả các giao diện web của dịch vụ thư đều lọc ảnh bằng tệp: // Scheme khi hiển thị thư (tệp: // Scheme là một dạng tương tự của \\ Scheme), nhưng không phải Yandex, không coi đây là lỗ hổng của nó (nói chung là đúng). Ẩn danh bằng thư nguy hiểm hơn vì cung cấp liên kết không chỉ đến địa chỉ IP với tài khoản Windows mà còn với thư.

Tệp: // Scheme của Chrome cũng hoạt động, nhưng chỉ từ thanh địa chỉ. Tải lên bất kỳ thứ gì có hình ảnh SMB hoặc nhấp vào liên kết sẽ không thành công. Vì Chrome phổ biến hơn nhiều so với Internet Explorer, nên kỹ thuật xã hội sẽ phải được áp dụng.

Bạn có thể ăn cắp tài khoản vì lợi ích của riêng bạn. Một số nhà cung cấp VPN sử dụng tên người dùng và mật khẩu giống nhau cho cả đăng nhập và xác thực VPN. Tư cách thành viên của một tài khoản đối với một dịch vụ cụ thể có thể được xác định bằng địa chỉ IP của kết nối đến của người dùng. Và nếu bạn có Tài khoản Microsoft và bạn tìm thấy mật khẩu từ hàm băm, thì xin chúc mừng - bạn có quyền truy cập vào các tệp trong đám mây OneDrive, thư Outlook, tài khoản Skype nếu nó được liên kết với tài khoản Microsoft và nhiều hơn nữa. "

Kết luận, ValdikSS viết rằng bạn có thể bảo vệ chống lại các cuộc tấn công như vậy, ví dụ: bằng cách hạn chế quyền truy cập vào cổng TCP 445 cho tất cả các phạm vi địa chỉ, ngoại trừ:

• 192.168.0.0/16
• 169.254.0.0/16
• 172.16.0.0/12
• 10.0.0.0/8
• fd00 :: / 8
• fe80 :: / 10

Cũng trong phần bình luận cho bài viết, người dùng đã đề xuất phương pháp sau:

Windows Registry Editor Phiên bản 5.00

"RestrictReceivingNTLMTraffic" = dword: 00000002
"RestrictSendingNTLMTraffic" = dword: 00000002

Ngoài ra, nhà nghiên cứu đã tạo ra một trang đặc biệt cho phép anh ta kiểm tra hệ thống của mình để tìm lỗ hổng đối với kiểu tấn công này.

Tôi đã cấu hình thành công xác thực ntlm. Thật không may, cấu hình cho phép ủy quyền bán cơ bản. Ví dụ: khi tôi sử dụng trình duyệt web rùa svn1.8.4 (với quyền truy cập đặc quyền lib), chrome hoặc IE, họ đã thoát NTLM thành công mà không yêu cầu bất cứ điều gì. Tôi thấy người dùng được xác thực trong tệp nhật ký. Thật không may, khi tôi sử dụng ví dụ như FireFox hoặc Maxthon chưa được định cấu hình, trình duyệt này sẽ nhắc tôi nhập thông tin đăng nhập. Tôi không cần điều này vì tình huống tương tự cũng xảy ra khi tôi cố gắng truy cập từ máy tính mà không có máy tính.

Tôi đang sử dụng máy chủ windows làm bộ điều khiển miền, windows7 / 8 làm máy khách hệ thống, linux / debian làm máy chủ web. Tôi đã định cấu hình kerberos từ Linux do windows AD, winbind để xác thực NTLM cục bộ và loạt apache 2.2. Để xác thực keo apache, tôi sử dụng mô-đun mod_auth_ntlm_winbind.so apache2 và trong ngữ cảnh config / ntlm để duy trì giao tiếp winbind. Điều này hoạt động chính xác, ví dụ cho apache:

#defaults cho thư mục www chính Tùy chọn Chỉ mục Theo dõiSymLinks MultiViews AllowOverride Không có # modified, ngăn chặn bất kỳ quyền truy cập ip nào, để thêm quyền truy cập không xác thực từ các máy chủ được chỉ định trong tương lai Đơn hàng từ chối, cho phép từ chối từ tất cả #allow từ IP / mask #settings cho NTLM auth với winbind helper AuthName "NTLM Authentication" NTLMAuth trên NTLMAuthHelper "/ usr / bin / ntlm_auth --domain = MY.WINDOWS.DOMAIN --helper-protocol = ink-2.5-ntlmssp" NTLMBasicAuthoritative trên AuthType NTLM yêu cầu người dùng hợp lệ # debecause

Tôi đã hy vọng có thể tôi có thể thực hiện một số chuyển hướng bằng cách sử dụng biến authtype apache và sau đó thêm vào cấu hình phía trên ghi lại:

RewriteEngine trên RewriteRule ^ /cgi-bin/TestAuth.pl?DollarOne=1&AUTH_TYPE=%(AUTH_TYPE)&REMOTE_USER=%(REMOTE_USER)

Và tập lệnh mẫu TestAuth.pl dưới dạng nội dung cgi:

#! / usr / bin / perl sử dụng nghiêm ngặt; cảnh báo sử dụng; sử dụng Data :: Dumper; # cách dễ dàng cho các biến hệ thống in print "Loại nội dung: văn bản / trơn \ r \ n"; #respectint giao thức HTML print "\ r \ n"; print "Môi trường chứa: \ r \ n"; in "x \ r \ n"; print Data :: Dumper-> Dump ([\ @ ARGV, \% ENV],); #print tất cả các đối số tập lệnh và các biến quy trình

Thật không may, trong mọi trường hợp, sử dụng ntlm auth dựa trên windows và nhắc nhập thông tin đăng nhập, tôi luôn thấy rằng AUTH_TYPE luôn là NTLM. Sau đó, không có cách nào để biết trình duyệt đang làm gì. Trong tình huống này, tôi có thể truy cập từ các khách hàng từ miền.

Tôi đã thử quấn hepler ntlm. Thật không may, tôi không thấy bất kỳ điều gì quan trọng trong kết xuất của mình với bốn cách kết hợp thành công / thất bại và quyền truy cập IE được kích hoạt bởi một yêu cầu kiến ​​FF. Tôi nghĩ rằng tình huống tương tự cũng xảy ra khi trình trợ giúp ntlm xác thực với máy chủ samba cục bộ, nhưng tôi chưa bao giờ kiểm tra điều này.

Bây giờ tôi đang cố gắng thực hiện một số cấu hình với nhiều loại auth, Basic và NTLM. Tôi đang cố gắng làm Cơ bản trước và lọc điều này khi mọi thứ đều không thành công và chuyển hướng nó đến trang thông tin. Thật không may, hiện tại không có thành công nào với kết hợp NTLM: (NTLM luôn được thực hiện trước.

Sau đó, có ai có ý tưởng làm thế nào để ngăn chặn thông tin đăng nhập? Làm cách nào để thu hồi quyền truy cập từ các khách hàng được mời? Làm thế nào để nhận ra thông tin đăng nhập từ dấu nhắc hoặc từ cửa sổ api ứng dụng khách?

0

2 câu trả lời

Tôi hiện đã giải quyết vấn đề này bằng cách chuyển NTLM sang xác thực Kerberos. Tất cả những cái sẵn sàng cho winbind đều chạy trực tiếp dưới kerberos vì trước đây tôi đã định cấu hình kerberos cho winbind với giao tiếp máy chủ AD. Vì kerberos là mã nguồn mở, các nhà phát triển đã dự đoán các danh tính phụ khác nhau trên điểm cuối của người dùng. Một cờ rất hữu ích nằm trong mô-đun apache2.2 kerberos:

KrbMethod Thương lượng trên KrbMethodK5Passwd off

Đây là những gì tôi muốn. Trình duyệt nhận được một khung krb với thuộc tính "Không bật lên thông tin đăng nhập của người dùng", sau đó ứng dụng khách không làm như vậy. Nhưng nếu vậy (một số loại không tương thích?), Mô-đun máy chủ Apache sẽ phát hiện điều này và nên thu hồi xác thực.

Sử dụng NTLM của Microsoft, điều này không thể thực hiện được vì giao thức có sai sót. Khung NTLM đầu tiên sau khi mã trang web 201 trả về không có cách nào để thêm thuộc tính "không nhắc người dùng về thông tin đăng nhập". Sau đó, tôi có thể lọc khung đó sau cửa sổ bật lên hoặc ký hiệu khóa phiên hệ điều hành. Trình duyệt này luôn hiển thị cửa sổ bật lên khi khóa phiên hệ điều hành không khả dụng.

Cuối cùng, đây là một cơ hội khác. Người dùng mất một thời gian để nhập thông tin đăng nhập hoặc chấp nhận khi thông tin đăng nhập được lưu trữ trong trình duyệt. Tôi có thể đếm thời gian từ khi gửi khung xác thực đến trình duyệt và soạn khung từ máy khách. Khi thời gian quá dài, tôi có thể hủy bỏ. Thật không may, điều này có thể tạo ra các ủy quyền sai trên các máy tính hoặc mạng bận.

Tôi sẽ sử dụng cả hai phương pháp trong tương lai :) Sẽ rất vui nếu mọi thứ có thể được thực hiện với mô-đun auth apach winbind. Sau đó, tất cả cấu hình có thể được đóng gói trong apache, giống như đối với kerberos auth.

Cảm ơn tất cả các bạn vì nghiên cứu thú vị và sự giúp đỡ của bạn :)

Sử dụng xác thực NTLM không đảm bảo ủy quyền ít thông tin xác thực. Nếu bạn có thông tin đăng nhập Windows hợp lệ mà máy chủ có thể nhận ra, bạn sẽ không nhận được lời nhắc mật khẩu.

Nếu người dùng không có thông tin đăng nhập NTLM còn thiếu hợp lệ, họ sẽ được nhắc cung cấp chúng. Đây không phải là cách để quay lại xác thực "cơ bản".

Thật không may, không thể xác định xem người dùng đã cung cấp thông tin đăng nhập hay họ đã chuyển qua hệ thống.

Có lẽ hãy đặt một câu hỏi mới về những gì bạn muốn người dùng của mình trải nghiệm (tức là các trang web khác nhau dành cho người dùng bên trong và bên ngoài) và ai đó có thể trợ giúp theo cách khác.