KoreanHackerTeam
Moderator
0x00 前言
FOX-IT는 고객이 회사 조직에서 발생하는 일반적인 보안 위험을 이해하도록 할 수 있습니다. 공격자가 NT LAN Manager 인증 프로토콜을 활용할 수있는 경우 (이하 NTLM 인증이라고 함) 자격 증명 재사용의 위험이 있으며,이 프로토콜은 일반적으로 Microsoft Active Directory에서 활성화 될 수 있습니다. NTLM 인증의 불안은 15 년 넘게 진행되었습니다. 이 프로토콜은 피해자의 자격 증명을 예상과 다른 서비스로 전달함으로써 피해자의 자격 증명을 남용하는 "릴레이"로 알려진 프로세스를 통해 피해자의 세션을 가로 채서 남용 될 수 있습니다. 대부분의 경우 NTLM 인증은 기본 인증 방법으로보다 안전한 Kerberos로 대체 된 경우에도 기본적으로 여전히 지원 및 활성화됩니다.이 기사에서는 유명한 SMBRELAYX 도구의 여우 확장 인 NTLMRELAYX를 사용하여 LDAP, IMAP 및 MSSQL에 자격 증명을 전달하는 방법을 보여줍니다. 그러한 공격을 방어하기 위해 :
가능하면 엔터프라이즈 조직 내에서 NTLM을 완전히 비활성화하고 Kerberos로 전환하십시오.
NTLM을 비활성화 할 수없는 경우 자격 재사용의 위험을 줄이기 위해이 기사에서 논의 된 설정 및 지침을 참조하십시오.
0x01 NTLM中继简要说明
NTLM 인증은 챌린지-응답 프로토콜입니다. 도전 - 응답 프로토콜은 공통 공유 비밀 (이 경우 사용자 비밀번호)을 사용하여 클라이언트를 인증합니다. 서버는 질문을 보내고 클라이언트는 질문의 응답에 응답합니다. 도전이 서버에서 계산 된 챌린지와 일치하면 인증이 허용됩니다. NTLM 인증은 복잡한 프로토콜이며 여기에서는 간단한 설명 일뿐입니다. 매우 자세한 설명은 http://davenport.sourceforge.net/ntlm.html에서 찾을 수 있습니다.1.NTLM身份验证流程
NTLM 인증 프로토콜에는 3 단계가 있습니다.협상 인증 : NTLM 인증의 첫 번째 단계는 프로토콜 협상 및 클라이언트가 지원하는 기능입니다. 이 단계에서 클라이언트는 클라이언트가 수락 한 NTLM 버전을 포함하여 서버에 인증 요청을 보냅니다.
서버 챌린지 : 서버는 자체 메시지에 응답하여 NTLM 버전과 사용하려는 기능을 나타내는 자체 메시지에 응답합니다. 이 메시지에는 "도전"값도 포함되어 있으며 인증에 중요합니다.
인증 응답 : 클라이언트는 챌린지에 따라 응답을 반환하고 해당 도메인의 사용자 이름과 비밀번호를 포함합니다.
3 개의 메시지와 상호 작용 한 후 서버는 인증이 성공하거나 인증이 실패한다는 메시지를 응답합니다. 클라이언트와 서버 간의 세션은 이제 사용 된 프로토콜에 따라 인증됩니다. 이 과정은 다음 그림에 나와 있습니다.
2.滥用NTLM
공격자로서,이 과정은 공격자와 연결하기 위해 클라이언트를 납치 할 수 있다면이 과정을 남용 할 수 있습니다. 이 작업을 수행하는 방법은 다음 섹션에서 설명됩니다. 공격자에게 인증 된 연결된 클라이언트가 있으면 챌린지-응답주기가 완료 될 때까지 3 개의 메시지를 클라이언트와 서버 간의 서버로 쉽게 전달할 수 있습니다.
연결이 인증되면 공격자는 단순히 클라이언트에 오류 메시지를 보내거나 연결을 끊을 수 있습니다. 그런 다음 공격자는 세션을 사용하여 릴레이 인증 사용자의 서버와 상호 작용할 수 있습니다.
3.跨协议（cross)中继
NTLM 인증은 다른 프로토콜에 캡슐화되지만 상단 프로토콜에 관계없이 메시지는 동일합니다. 이를 통해 다른 프로토콜에서 NTLM 메시지를 사용할 수 있습니다. 예를 들어, HTTP로 인증하는 클라이언트는 "인증"헤더에서 NTLM 인증 메시지를 보냅니다. 공격자는 이러한 메시지를 HTTP 헤더에서 가져와 SMB와 같은 다른 프로토콜에서 사용할 수 있습니다.NTLM은 SMB, HTTP (S), LDAP, IMAP, SMTP, POP3 및 MSSQL과 같은 다양한 프로토콜에서 지원됩니다.
4.获得中继流量
아직 설명되지 않은 또 다른 것은 클라이언트를 실제 서버가 아닌 공격자에게 연결하는 방법입니다. 전환 가능한 트래픽을 얻는 방법에는 여러 가지가 있습니다.안전하지 않은 방식으로 IP를 해결하는 호스트 트래픽
자동 검색 프로토콜 남용으로 인한 트래픽
중간 중간 공격을 통해 얻은 트래픽
4.不安全的名称解析协议
FOX-IT에서는 안전하지 않은 프로토콜을 사용하여 이름 해상도 트래픽을 사용하는 경우가 종종 있습니다. 워크 스테이션 또는 서버는 일반적으로 네트워크에 더 이상 존재하지 않는 호스트 또는 DNS를 사용하여 호스트 이름을 해결할 수없는 호스트로 구성됩니다. 이 경우 Windows 워크 스테이션은 NBNS 및 LLMNR과 같은 이름 해상도 프로토콜로 되돌아 가며, 이는 동일한 네트워크의 호스트를 요청하여 호스트 이름을 IP 주소로 해결하기 위해 방송 트래픽에 의존합니다. 동일한 네트워크 세그먼트의 모든 호스트 가이 트래픽을 볼 수 있으므로 (방화벽 구성에 따라) 모든 호스트는 요청에 응답 할 수 있습니다. 이를 통해 공격자가 요청 된 이름의 주소를 위조 할 수있는 기회를 제공합니다. 프로세스는 다음과 같습니다.
5.自动发现（WPAD)协议
아마도 지난 몇 년 동안 해커에서 가장 악명 높은 기능은 WPAD (Windows Proxy Auto Detection) 기능입니다. 이 기능은 기본적으로 DNS를 통해 WPAD라는 호스트 이름을 찾습니다. 실패하면 위에서 설명한 LLMNR 및 NBNS를 통해 공격 한 다음 찾을 수있는 첫 번째 호스트에 연결할 수 있습니다. 인증을 자극 할 때 워크 스테이션은 NTLM 인증을 사용하여 자동으로 인증을 시도하고 공격자가 릴레이 할 수 있기 때문에이 기능의 남용이 더 쉬워집니다. Microsoft는 2016 년 6 월이 분야에서 일부 문제를 패치했지만 때로는 Fox-It은 여전히 네트워크에서이를 만납니다.6.中间人攻击
공격자가 희생자 트래픽을 인수하는 중간 중간 공격은 특히 ARP 스푸핑과 같은 기술을 사용할 때 회사 네트워크에서 종종 매우 파괴적입니다. 그러나 엔터프라이즈 장치가 공개 WiFi 네트워크와 같은 신뢰할 수없는 네트워크에 연결하면 공격자는 TLS에 의해 보호되지 않는 피해자를 공격하고 피해자의 워크 스테이션에 의해 신뢰되는 위치로 리디렉션 할 수 있습니다. 그런 다음 자동 인트라넷 감지가 활성화되면 (기본 설정 인) 피해자가 자동으로 인증됩니다.
7.使用Ntlmrelayx在任何地方中继NTLM
NTLM 인증을 남용 할 수있는 몇 가지 도구가 있습니다. 그중 하나는 Core Security의 Impacket 라이브러리의 일부인 Smbrelayx입니다. NTLMRELAYX는 FOX-IT가 개발 한 SMBRELAYX 도구의 확장 및 부분 재 작성입니다. 다양한 프로토콜에 적합한 릴레이 기능이 있습니다. 이 도구는 여러 대상을 수용하여 각 대상간에 반복되어 시스템을 인증 할 시스템을 찾습니다. 이 도구에는 SMB 및 HTTP 서버가있어 NTLM 인증을 SMB, HTTP (S), IMAP, LDAP 및 MSSQL로 전달할 수 있습니다.8.中继到SMB
SMB 로의 릴레이는 이미 SMBRELAYX의 일부인 고전적인 공격입니다. 이 공격에 익숙하지 않은 경우 SMB로 릴레이하면 공격자가 장치에 관리 권한이있는 경우 공격자가 SMB 서명이 장애가있는 호스트에서 파일을 실행할 수 있습니다. ADMIN이 아닌 사용자의 경우 NTLMRELAYX는 SMBClient Shell을 시작하는 옵션을 추가하여 공격자가 파일 다운로드 또는 업로드와 같은 주식과 상호 작용할 수 있습니다. 이 공격은 인터랙티브 플래그 (-i)를 사용하여 수행 할 수 있으며, 예를 들어 NetCat과 연결될 수있는 로컬 TCP 쉘을 생성합니다.
9.中继到LDAP
LDAP 로의 릴레이는 NTLMRELAYX의 새로운 기능입니다. LDAP는 디렉토리를 직접 쿼리하는 데 사용되기 때문에 흥미로운 프로토콜입니다. 여기에는 공격자에게 관심이있는 많은 정보가 포함되어 있습니다. 더 흥미로운 점은 기본적으로 컴퓨터 계정을 포함한 도메인의 모든 계정 이이 정보의 대부분을 읽을 수 있다는 것입니다. NTLMRELAYX가 다른 FOX IT 개발 도구 LDapDomainDump와 통합되는 곳입니다. 이 도구는 사용자, 그룹 멤버십, 도메인 컴퓨터 및 도메인 정책을 포함하여 가능한 많은 정보를 도메인에서 수집하려고합니다.
10. 中继到IMAP
현재 버전의 Exchange에서 기본적으로 활성화되지는 않지만 많은 엔터프라이즈 조직은 Exchange 서버에서 IMAP를 통해 NTLM 인증을 수행합니다. 이를 통해 릴레이에 IMAP를 통해 공격자가 피해자의 이메일에 직접 액세스 할 수 있습니다. NTLMRELAYX는 IMAP에 중계되면 이메일에서 키워드를 검색하거나 사용자의 지정된받은 편지함에서만 모든 최신 이메일을 다운로드 할 수있는 옵션이 있습니다.
:
11.中继到MSSQL
MSSQL 로의 릴레이는 현재 이론적 증거로만 존재하지만 쿼리는 명령 줄에 지정할 수 있으며, 이는 데이터베이스의 희생자에 실행됩니다.0x02 缓解措施
기업 조직은 이러한 공격에 저항하기 위해 무엇을 할 수 있습니까? 위의 모든 공격은 NLTM 인증 프로토콜 남용을 남용하므로 완전한 솔루션은 NTLM을 완전히 비활성화하고 Kerberos로 전환하는 것입니다. 그러나 많은 엔터프라이즈 조직에는 Kerberos 인증을 지원하지 않는 레거시 제품 또는 운영 체제가 있으므로 NTLM을 비활성화하면 비즈니스에 상당한 영향을 미칩니다. 완화로서, 다양한 설정을 통해 중간에 인간 공격의 위험을 최소화 할 수 있습니다.SMB 서명 활성화 : SMB 서명은 모든 트래픽을 서명하도록하여 SMB로 릴레이를 차단합니다. 서명에는 사용자의 비밀번호가 메시지를 인증하기 위해 사용자의 비밀번호가 필요하므로 연결을 전달하는 공격자는 공격자에게 피해자의 암호가 없기 때문에 서버에서 수락 한 커뮤니케이션을 보낼 수 없습니다.
LDAP 서명 활성화 : SMB 사인과 유사하게 LDAP 서명은 LDAP에 대한 설계되지 않은 연결을 방지합니다. TLS를 통한 연결은 LDAP 로의 연결로 간주 되므로이 설정은 TLS를 통해 LDAP 로의 릴레이 공격을 방지하지 않습니다.
인증 확장 방지 기능 : 인증을 확장하여 인증을위한 확장 된 보호는 서버에 연결하는 데 사용되는 TLS 채널이 클라이언트가 인증 할 때 사용되는 채널과 동일하도록하여 특정 릴레이 공격을 방지합니다. 이 설정은 주로 IIS에 적용됩니다.
SPN 대상 이름 확인 활성화 : SPN 대상 이름 확인은 클라이언트가 인증 중이라고 생각하는 대상 이름을 확인하여 SMB에 대한 중간 공격을 방지 할 수있는 또 다른 완화입니다. 이름이 서버와 일치하지 않으면 인증이 거부됩니다.
내부 웹 사이트에서 HTTPS를 사용하는지 확인하십시오. 불안정한 HTTP 프로토콜을 통해 내부 웹 사이트에 액세스 할 때 사용자는 연결의 진위를 확인할 수 없습니다. 모든 내부 웹 사이트가 HTTPS 방법 만 통과하도록함으로써 중간 공격은 덜 효과적입니다.
一般强化以防止中间人攻击
이러한 특정 서버 측 설정 외에도 다음 일반 경화는 NTLM 릴레이를 방지 할 수 있습니다.자동 인트라넷 감지 비활성화 : 도메인에서 NTLM 인증이 필요한 경우 브라우저 (주로 인터넷 익스플로러)가 신뢰할 수있는 웹 사이트 만 자동으로 인증해야합니다. 그룹 정책을 통해 자동 인트라넷 감지가 비활성화 될 수 있으며 자동 인증을 적용하는 내부 웹 사이트의 화이트리스트에 따라 자동 인증 만 수행 할 수 있습니다. 위에서 언급했듯이 여기에서만 HTTPS 웹 사이트를 사용하는 것이 좋습니다.
Windows Agent 자동 감지 비활성화 : WPAD의 보안 문제는 주로 Microsoft MS16-077 보안 업데이트에 의해 해결되지만 그룹 정책을 통해 WPAD를 비활성화하는 것이 좋습니다.
LLMNR/NBNS 비활성화 : 이러한 안전하지 않은 이름 해상도 프로토콜은 일반적으로 잘 구성된 네트워크에서 필요하지 않습니다. 그것들을 비활성화하면 공격자가 이름 해상도 스푸핑을 수행 할 가능성이 줄어들어 공격자가 피해자가 공격자 서버에 연결하도록 속이는 것을 어렵게 만듭니다.
0x03 获取Ntlmrelayx
NTLMRELAYX는 IMPACKET 저장소에 제출되었으며 IMPACKET 샘플 디렉토리에서 찾을 수 있습니다.0x04 더 많은 리소스
NTLM을 이해하려는 대부분의 연구는 다음 자원의 도움으로 이루어졌습니다.
http://davenport.sourceforge.net/ntlm.html (명확한 설명이지만 일부 부품은 Microsoft 오픈 소스 이전의 역 프로토콜을 기반으로 구식입니다)
http://ubiqx.org/cifs/smb.html#smb.8.5 (위와 유사)
https://msdn.microsoft.com/en-us/library/cc236621.aspx (공식 계약 문서, 매우 기술적)
https://technet.microsoft.com/en-us/library/2006.08.securitywatch.aspx(lmcompatibilitylevel 설명)